@@ -1,17889 +0,0 @@
1−<?xml version="1.0" encoding="utf-8"?>
2−<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/">
3− <channel>
4− <title>Urbit</title>
5− <link>https://urbit.org</link>
6− <description>Urbit is a personal server built from scratch</description>
7− <lastBuildDate>Mon, 14 Feb 2022 16:16:43 GMT</lastBuildDate>
8− <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
9− <generator>https://github.com/jpmonette/feed</generator>
10− <language>en</language>
11− <item>
12− <title><![CDATA[Layer 2 Guides]]></title>
13− <link>https://urbit.org/blog/layer-2-guides</link>
14− <guid>https://urbit.org/blog/layer-2-guides</guid>
15− <pubDate>Mon, 14 Feb 2022 00:00:00 GMT</pubDate>
16− <content:encoded>< system, naive rollups, allows planets to be spawned at substantially lower cost. This system operates in parallel to Layer 1 Azimuth, but introduces some new concepts and differences that are important to understand. Read on for a high-level survey, and check the star and planet guides linked at the bottom for details and instructions.
18−
19−After a year of development and testing, **Urbit’s Layer 2 system is live and operational**. Star and planet operators can now take advantage of subsidized Azimuth operations. If you operate a star, you can distribute planets cheaply or for free; if you’ve been waiting to buy an ID due to transaction fees, you will find planets are available much more cheaply.
20−
21−Layer 2 (“L2”) introduces some changes that are important to understand, whether you’re new to the network or not. Stars and planet operators that are considering migrating to L2 have different **trade-offs to weigh** before they make a decision.
22−
23−### Background
24−
25−Urbit can be broadly divided into two parts: an operating system, Arvo, and the identity layer, Azimuth. These two systems are interlocked. Arvo uses Azimuth to verify that you own an address, which maps to your name on the network. [Azimuth](https://urbit.org/docs/glossary/azimuth) is a public key infrastructure, implemented as contracts on the Ethereum blockchain. Modifications to the ownership or properties of an identity’s keys are recorded on Ethereum. Azimuth faithfully serves its purpose as an authoritative, trustless registry of ownership, but it inherits both the strengths and disadvantages of the ETH ecosystem.
26−Due to ETH’s value and popularity, performing transactions directly on the Ethereum blockchain (‘Layer 1’) has become prohibitively expensive for many simple operations. The Ethereum smart contracts that control the logic of Azimuth were developed in a time when ETH was not worth as much. The soaring value of ETH means that the gas fee to spawn or modify a planet routinely costs more than the planet itself. Azimuth is not unique in this regard. All projects built on Ethereum have had to deal with this issue in one form or another. Fortunately, Urbit engineers have come up with a solution for those seeking to get onto the network, albeit with several important trade-offs.
27−
28−### Naive rollups
29−
30−‘Layer 2’ refers to technologies built on top of blockchains to enable scaling. [Rollups](https://vitalik.ca/general/2021/01/05/rollup.html) are an Ethereum ecosystem Layer 2 innovation that reduces costs by moving computation off-chain. _Naive rollups_ are a bespoke technology developed for Urbit that augment the original Azimuth contracts. For technical details, you can review the [excellent summary](https://urbit.org/blog/rollups) by `~datnut-pollen`, or the [original proposal](https://groups.google.com/a/urbit.org/g/dev/c/p6rP_WsxLS0) by `~wicdev-wisryt`. In brief: rather than using the Ethereum network to perform the computation associated with PKI modifications (Layer 1), the computation is performed on the Urbit network itself, with the results published to the blockchain by nodes called rollers. Signed data resulting from the combined transactions is posted on a regular basis to the main blockchain by the rollers. Due to this batched, off-chain computation, fees are roughly **65-100x cheaper** than Layer 1 operations.
31−
32−### What everyone should know
33−
34−Whether you’re new to the network or a longtime participant, you should gain familiarity with the new changes. There are a few things that everyone should know:
35−
36−- All ships spawned before now have been on Layer 1 – those ships have the option of migrating to Layer 2, or remaining on Layer 1.
37−- **You don’t have to do anything**. Migrating is opt-in, and a Layer 1 ship will continue to have full functionality on the network.
38−- Layer 2 lets you perform **Azimuth transactions cheaply or for free**. If you operate a star, you can spawn planets for free with Tlon’s roller. Planets can make use of Tlon’s roller for actions like factory resets and transferring ownership and proxy addresses for free.
39−- **Migrating is one-way**. If you migrate to Layer 2, there is not currently an option to reverse your decision.
40−- **Migrating does not change which address owns a point**. After migrating, you will still log into Bridge with the same keys.
41−
42−### Layer 2 guides
43−
44−There’s lots more to learn about the new solution. These updates apply to the software on your ship, the Azimuth PKI, and new features and major updates to Bridge. You can learn more in the following guides, with in-depth background and illustrated walkthroughs for common tasks:
45−
46−[Layer 2 for stars](https://operators.urbit.org/guides/layer-2-for-stars) – It’s particularly important for star operators to understand the pros and cons of migrating. This guide will explain the technical background, trade-offs, and how to use Layer 2 on Bridge.
47−
48−- Stars can migrate their spawn proxy to Layer 2 to spawn up to six planets per week for free using Tlon’s roller.
49−- Stars can migrate their ownership key to Layer 2 to perform all Azimuth operations on Layer 2, including planet spawning, factory resets, and point adoption.
50−- Migrating is currently a one-way process and cannot be reversed.
51−- Layer 2 stars cannot be wrapped as $WSTR tokens, or interact with any other Layer 1 tools or contracts (e.g. MetaMask, OpenSea).
52−
53−[Layer 2 for planets](https://urbit.org/getting-started/layer-2-for-planets) – Just bought a planet and want to know what all of this means for you? Wondering whether you should migrate your Layer 1 planet? Look here for guidance.
54−
55−- Planets spawned by a Layer 2 star will spawn on Layer 2.
56−- Migration is one-way; if your planet is on Layer 2, there is no way to migrate it to Layer 1.
57−- Planets on Layer 2 can take advantage of subsidized, free Azimuth transactions using Tlon’s roller.
58−- Planets on Layer 2 cannot currently interact with Layer 1 tools or contracts like MetaMask or OpenSea.
59−]]></content:encoded>
60− </item>
61− <item>
62− <title><![CDATA[Urbit Is for Creators]]></title>
63− <link>https://urbit.org/blog/urbit-for-creators</link>
64− <guid>https://urbit.org/blog/urbit-for-creators</guid>
65− <pubDate>Thu, 09 Dec 2021 00:00:00 GMT</pubDate>
66− <content:encoded><
68−
69−It’s no secret that there are huge problems with the way content is distributed on the internet today. Even five years ago these issues hadn’t quite hit the mainstream: the ability of platforms to capriciously alter their terms of service, the corrosive effects of algorithms designed to siphon off as much of our attention as possible, the uncanny effects of a world where tech companies arbitrate truth with behind-the-scenes moderation policies. Although they’re now discussed pretty openly, the horrid effects of this system actually tend to be _understated._ “If you’re not paying for it, you’re not the customer, you’re the product” has become a truism. And yet, as _You Are Not a Gadget_ author Jaron Lanier puts it, it’s not quite specific enough to say that _you_ are the product. Rather, “it’s the gradual, slight, imperceptible change in your own behavior and perception that is the product.”
70−
71−This product is selling very well, and it has seeped its way fully into the world of content creation, or what might once have been called the arts. Although it’s not so widely publicized, [Tik Tok basically runs the popular music industry at this point](https://www.browndailyherald.com/article/2021/09/for-better-or-worse-tiktok-is-driving-the-music-industry). Meanwhile, platforms like Spotify or YouTube filter what we see by deprecating the “long tails” of content. That is, if you’re searching for a tune on Spotify, it brings Spotify more profit, on average, to design a search feature that will automatically bring you to the most popular songs, even if you were really looking for less popular ones. The same goes for books, which are now purchased mostly according to the algorithm, and not according to what a person might stumble upon in a bookshop. (The upshot: expect more [cookbooks from Snoop Dogg](https://www.nytimes.com/2021/04/18/books/book-sales-publishing-pandemic-coronavirus.html), and fewer titles from authors who are not already celebrities.) Products such as Tik Tok, Spotify, YouTube, and Amazon like for you to think that they’re mere distributors of content. But actually they’re _producers_, and they’re producing the smarmy, anodyne style that has homogenized the globe.
72−
73−Urbit is for creators who are ready to wake up from this bad dream.
74−
75−The vibe of today’s internet applications—manipulative, erratic, overcomplicated, overbearing, and highly detrimental to society—is in contrast to the mechanics of the creator economy itself, which can actually be blissfully simple. In 2008 Kevin Kelley made famous the concept of “[1000 true fans](https://kk.org/thetechnium/1000-true-fans/).” That is, to make a living as a creator, you only need 1,000 fans who are interested enough to buy whatever you produce. Even $6.00 or $7.00 a month from such true fans is a boon for a creator—assuming not too much of that cash gets taken away by middlemen, and that fans can discover work from outside the corporate monoculture in the first place.
76−
77−In a limited sense, this 1,000 true fans model is already working. Creators with fanbases of the size Kelly imagined are able to use Patreon or YouTube or what-have-you to monetize their content. But the problem is, those platforms are not really peer-to-peer. Your fans aren’t your own: they belong to the platform. And with the big tech platforms running the show, we end up with the problems described above.
78−
79−To those of us who are interested in seeing a thriving culture of artists, musicians, podcasters and writers which is human-centered via a p2p network, rather than being brokered, managed, and manipulated, by the most venal and tasteless of data collectors and profiteers, it likely seems like the world of the arts has gone bottom-up. Urbit is for any creators who are ready to put it back on its feet again.
80−
81−Urbit is a peer-to-peer network designed to serve as simple, durable neutral infrastructure for whoever wants to build something on it. Like everything else on Urbit, creator content goes directly to the people it’s supposed to go to. No middlemen, no MEGACORP data mining, no capricious terms of service, no obscure algorithms determining what gets seen and what doesn’t. This is the zero-to-one shift that makes Urbit the natural destination for creators who want to both _own_ their work and share it.
82−
83−Urbit has already seen several communities get excited about the ways Urbit could help them fulfill their goals. Here are just a few examples:
84−
85−[HOLDERSLAND](https://twitter.com/holdersland), founded by Haleek Maul, a musician, music label owner, and NFT creator based in Barbados. Maul recently [sold](https://urbit.holders.land) a set of customized Urbit NFT artwork, which came bundled with actual Urbit IDs.
86−
87−[Other Life](https://www.otherlife.co), a community of philosophers and creators founded by the entrepreneurial Justin Murphy.
88−
89−[The Stack](https://orbisledger.news/), an entertaining and informative podcast with a decidedly Urbit flavor, hosted by Josh and Andy.
90−
91−[door.link](https://www.door.link), a vibey and idiosyncratic music collective.
92−
93−[Wet Brain](https://www.patreon.com/wetbrain), a numinous, post-everything New York podcast, hosted by Honor and Walt.
94−
95−Internet Weirdness Task Force, which has no legacy internet site to link to, so you’ll just have to get on Urbit to scope it out.
96−
97−Over the last ten years, we’ve already had a taste of what blockchains can do: they’re great so far for distributing a financial ledger so that payments are no longer centralized. But for online communities to go truly peer-to-peer and escape the grip of corporations, they’re going to need something like Urbit. As HOLDERSLAND founder Haleek Maul [puts it](https://urbit.org/blog/haleek-maul-interview) in a recent Q&A, decentralized technologies like blockchain or Urbit “allow . . . new financial relationships and funding structures to emerge. Rather than have a few people contribute $20k, you can have hundreds of people contribute $100.” In such a system, recording artists no longer need to hunt for a deal from sharky impresarios; their communities can comprise both the talent _and_ the executives. They no longer need to pay fealty to streaming services; they can sell their wares peer-to-peer, with the old-fashioned connoisseurship of a cool record shop, except that this record shop is available to anyone across the globe.
98−
99−Urbit makes this dream a real possibility. In an Urbit future, utilizing your own personalized payments system, which could take either fiat or crypto, should be as easy as sending or receiving money on apps like Venmo or Cash App is today. If _anyone_ can make a direct peer-to-peer payment to anyone else on the network, if _anyone_ can send a piece of writing or audio or video clip in a peer-to-peer way to anyone else on the network, then you’ve truly laid the groundwork for autonomous organizations of creators.
100−
101−Beyond that, Urbit is one of the very few platforms looking, with seriousness and deep technical consideration, into the distant future. Whereas no one can say whether a mainstream platform like Facebook or Twitter will even _exist_ in ten years (think just how much writing will disappear if those servers do shut down), Urbit is built with maximum durability in mind: one way to think of your urbit computer is as a [100-year computer](https://urbit.org/blog/the-100-year-computer). Whereas most software today is designed to break quickly and be replaced quickly, due to the instability of all of modern computing’s complex interlocking parts, Urbit was built as an overlay operating system, so that it can work no matter what’s running underneath, and thus serve as a resilient, permanent home for your digital world.
102−
103−Computers can still be used as magical tools for creative individuals, instead of as attention-draining machines—if that is indeed the future we want. For creators, the solution to the ever-growing problems of the internet is not in the hands of any national government, or some new application that mimics the architecture of old applications, or through some impracticable system of reduced screen time. The solution to these problems is, and always has been, to build a whole new system that works _for_ the people instead of against them. That’s what Urbit is here to do.
104−]]></content:encoded>
105− </item>
106− <item>
107− <title><![CDATA[Report from the field: Assembly 2021]]></title>
108− <link>https://urbit.org/blog/2021-11-18-report-from-the-field</link>
109− <guid>https://urbit.org/blog/2021-11-18-report-from-the-field</guid>
110− <pubDate>Thu, 18 Nov 2021 00:00:00 GMT</pubDate>
111− <content:encoded><
113−
114−Before Assembly I committed to write a ‘recap’ post for everyone who couldn’t make it. Originally I figured this post would be an opportunity to walk through the list of things that we shipped and showed off in Austin. But it turns out that the most important thing about Assembly was simply the way it felt to be there.
115−
116−I’m not sure it’s possible to really do the feeling in the room justice, but I’m going to try. Then I’ll get into the announcements and happenings for those of you who couldn’t make it.
117−
118−But first, a quick note:
119−
120−We ran Assembly under the [Chatham House rule](https://en.wikipedia.org/wiki/Chatham_House_Rule). Basically, you can talk about what happens at Assembly—but you can’t name anyone.
121−
122−I’ve run many of our Urbit events this way because I think it puts people at ease. Everyone in the room can just relax, connect with one another, and hang out without worrying about being named on the internet.
123−
124−I’ll try to abide by the Chatham rule in this post which is why no one is named specifically.
125−
126−
127−
128−New world energy -
129−
130−In the months leading up to Assembly we were totally focussed on using the event as a release date for a bunch of different lines of work. Coming out of that sprint, we didn’t really know what to expect. We wanted to make sure Urbit was ready for people to build on and that everything we were going to ship worked well. What we didn’t realize was just how emphatically people are <em>ready to build</em>.
131−
132−When I got up on stage on Friday night to welcome everyone I was really impressed by the room itself. It was packed with people who looked excited and motivated. The room just looked amazing. There were so many different kinds of people staring back at me. Some who I recognized from the earliest days of the project, and lots I had never seen before. I’ve been at my share of Urbit events, but this was something totally different.
133−
134−We didn’t have much scheduled during Assembly. Most of the time was unstructured to allow for freeform discussion, sunbathing on the lawn, and gathering at picnic tables. The panels that we did schedule will go down in history. Panelists discussed questions about creators, escaping reward systems, and the role of DAOs from governance to governments. There was hard money with a computer on it, Moloch shoes, community members grabbing the mic, and a talk written two hours before it was delivered about the relationship between centralization and decentralization when it comes to UX that blew our minds.
135−
136−I spent the weekend of Assembly in almost constant conversation with people building Urbit hardware, experimenting with different kinds of Urbit software, and thinking about incredible things like a Nock chip. I talked to the lead architect of a CPU from the 90s, a former senior US government official, an editor of a well-known literary magazine, the inventor of a new display technology, musicians whose work I already admired, a fragrance designer, writers, and, of course, lots of engineers and designers from many different backgrounds. Data scientists, systems hackers, language nerds, someone running a successful currency. I watched these people get projects off the ground, start raising money, plan the future of Urbit hosting companies, and plan new features for Landscape. I saw a last-minute warehouse party come together that kept people talking well into the early hours of the morning.
137−
138−Where did these people come from? All over the place. They have this incredible <em>new world energy</em>. They understand immediately, intuitively that Urbit has the potential to be a foundation for the society they want to live in. I’ve never seen anything like it.
139−
140−This energy seems to have come from the very practical work we do day-to-day: building Urbit, refining it, making it easier to use. The crowd at Assembly was somehow brought together by Urbit itself. It’s insanely exciting. It makes working on Urbit feel even more like a form of definite optimism. The system builds the community and the community builds the system.
141−
142−
143−
144−Urbit is ready to be built upon -
145−
146−Sometime in early 2021 we realized that there were many lines of work converging on a single theme: ‘Urbit is ready to be built upon’. This is the spirit we wanted to bring to Assembly, and it was very much in the room in Austin. Some of that feeling is still lingering on the network. I think it comes from some very concrete improvements that have been made to the system.
147−
148−We’ve always wanted Urbit to be maintained by a self-sustaining ecosystem and, early this year, we could see what needed to be done to really let others begin doing so. There were four parallel projects that came together to hit this milestone: Software distribution, star.market, developer and operator guides, and the Foundation roadmap. We talked about all of these things in the Assembly keynote (which you can watch [here](https://www.youtube.com/watch?v=ywj36TUtbS4)), but let’s touch on them one by one.
149−
150−Software distribution
151−
152−The most important thing that we shipped just before Assembly is the ability to actually package and distribute software over Urbit itself. It’s now possible for someone to build an app, package it up, and share it with a friend directly over the network.
153−
154−For their friend, the experience is incredibly nice. You can simply send someone a link and they can install the app and run it themselves, on their own urbit, right away. The whole thing is peer-to-peer, of course. There’s no app store, no vetting process. It’s networked software like it’s supposed to be: people computing together freely.
155−
156−We’ve been saying for years that we want people to build on top of Urbit and we always meant it. Now it’s possible in a way it never has been before. To check it out, watch [this segment](https://www.youtube.com/watch?v=MA8sqFi8Bd8) from Assembly.
157−
158−Software distribution can get better in _a lot_ of ways, and we’re continuing to work on it. But it’s live, and people are experimenting with it already. There’s Chess, there’s Pokur, there are video calls (although they’re still a little buggy). Everyone seems to love ‘pals’ and ‘zone’—but you’ll have to get on the network to check those out.
159−
160−star.market
161−
162−We’ve always used the address space to fund our work as one of the primary Urbit developers. As Urbit has become more useful, and address space has become more expensive, it’s more and more difficult for others to do this. The community saw the need for developers to easily use their granted address space to fund their work and a higher resolution for the Foundation to fund contributions to Urbit.
163−
164−This is what [star.market](https://star.market/) and the WSTR project are for. WSTR is an ERC-20 token that is backed 1:1 by ERC-721 Urbit stars. Unlike a star, a WSTR token can be fractionally divided, allowing for a broader distribution of ownership of Urbit. WSTR was built by the community over the past couple of months with no involvement from Tlon. Tlon did, eventually, help to put together star.market—the interface for interacting with the WSTR contracts safely and securely.
165−
166−I’ve come to think that WSTR can be a powerful tool for funding new Urbit projects. I’m excited to see what both our early community of developers and operators can do with it, as well as the nascent Urbit Foundation.
167−
168−Guides
169−
170−As we make it easier for developers to build software, operators to participate in the economy, and communities to make Urbit their home, we need to improve our documentation. We always like to do things bottom-up: the product work comes first. Well, the product is now live.
171−To this end we recently launched:
172−
173−[operators.urbit.org](https://operators.urbit.org/) collects all of the information about participating in the Urbit economy, running infrastructure nodes, and participating in governance in one place.
174−
175−[developers.urbit.org](https://developers.urbit.org/) has an overhauled program for learning about Urbit as a system and beginning to develop on top of it.
176−
177−[network.urbit.org](https://network.urbit.org/) allows anyone to explore the network. View galaxy transfers or how many planets a star has spawned.
178−
179−We’ve got a lot more planned in this area of work in the coming months, and these three sites are a great start.
180−
181−Urbit Foundation
182−
183−Over these past few years we’ve operated the Urbit Foundation as a ‘protocol’ inside of Tlon. Our goal has been to develop that protocol to the point that it’s refined, working, and can run on its own outside of Tlon.
184−
185−Josh has done an exceptional job running the foundation protocol at Tlon over the last year or so. He and I have been working closely together on everything that Tlon builds, while also coordinating our community of contributors. I’m very excited that the Foundation, with Josh as its Director, is now separating from Tlon as a fully independent entity focussed on supporting the ecosystem.
186−
187−Assembly was the perfect moment to begin formally separating out the Foundation and, as of a week ago, it is an independent entity. We’ve thought long and hard about how to make the Foundation an enduring, stable organization. Josh will be the first Executive Director but, ultimately, the Senate of Galaxies will elect the Board. This will keep the Foundation accountable to the network as a whole and I’m optimistic it can work well.
188−
189−If you’re on the network, you can read more about the Foundation in ~wolref-podlex/foundation.
190−
191−Assembly 2022 -
192−
193−I had more than a few enthusiastic people come up to me at Assembly and ask what we were planning for Assembly 2022. I have absolutely no idea, of course. We poured all our energy into making Assembly 2021 a success.
194−
195−Given what I saw in Austin, I’m pretty confident that next year we’ll be in completely new territory. The goal of this project has always been to build a completely new digital world. And now, it seems to be building itself.
196−]]></content:encoded>
197− </item>
198− <item>
199− <title><![CDATA[The Promise and Paradox of Decentralization]]></title>
200− <link>https://urbit.org/blog/2021-11-18-the-promise-and-paradox-of-decentralization</link>
201− <guid>https://urbit.org/blog/2021-11-18-the-promise-and-paradox-of-decentralization</guid>
202− <pubDate>Wed, 17 Nov 2021 00:00:00 GMT</pubDate>
203− <content:encoded><
205−
206−Every so often, a platform will do something outrageous—changing its terms of use, kicking off API partners, restricting [the content category it was built on](https://www.theverge.com/2018/12/3/18123752/tumblr-adult-content-porn-ban-date-explicit-changes-why-safe-mode), banning Donald Trump, failing to ban Donald Trump, etc.—and we'll all realize we're utterly dependent on centralized entities that can make arbitrary and unaccountable decisions. Sure, you can build your own minimal Facebook or Twitter clone, if you really want, but can you build your own Cloudflare? How about your own payment network? If your company does something legal in your country but banned in America, and the US decides to sanction you, which leads to local banks cutting you off because they can't survive without access to the dollar, are you going to build your own reserve currency? Your own Taiwan Semiconductor Manufacturing Co. or ASML?
207−
208−There are, to varying extents, efforts to do all of the above. But what's worth considering is that <em>all of these bans happen through centralized actors running on decentralized systems</em>. The Internet was supposed to be a totally open set of protocols that anyone could interact with, and for a long time it was, and yet getting kicked off Facebook and Twitter means being exiled from public discourse. Banks are regulated, but every country can set up their own banking regulations, and different countries see the social role of banks very differently; for some countries they're a tool of economic planning, for others a way to help connect local companies to global markets, for others a source of money that can be channeled to politically favored groups. The chip industry was historically very open to new entrants; the transistor was developed at Bell Labs, and for political reasons AT&T licensed it to all comers at a low price.
209−
210−And yet all of these originally decentralized systems end up facing some degree of centralization.
211−
212−The promise of a decentralized system is that anyone can build anything they want, because no one owns it. There are three important features of this; two downsides and a caveat:
213−
214−- The first downside to "Anyone can build anything" is that "anyone" means <em>anyone</em>, and the people to whom decentralized systems are the most attractive are the ones who are banned from other systems, often for good reasons. Free speech absolutists want to be defending Aleksandr Solzhenitsyn or Eugene V. Debs or even Lenny Bruce, but if you want to get a sense for the typical piece of content enabled by a totally uncensored communications system, check your spam folder.
215−
216−- The second downside is that a lack of ownership means that no one is responsible when things go wrong. Bitcoin doesn't have a way to censor your decision to move money from one address to another or even a protocol-level sense of whether you're buying Alpaca socks or a rocket launcher. (nb: You are almost certainly not buying a rocket launcher with Bitcoin; you are at best getting scammed, and at worst [getting in trouble](https://www.justice.gov/usao-cdca/pr/los-angeles-county-man-pleads-guilty-federal-charge-attempting-obtain-biological-toxin)). But this also means that the protocol can't tell when you meant to send your life savings to your cold wallet and sent it to the wrong address instead.
217−
218−- The caveat is that, to quote a [<em>Diff</em> piece from last year](https://www.thediff.co/p/amazon-a-new-kind-of-antitrust-risk#:~:text=does%20it%2C%20too.-,Technology-Governance%20Fit,-Pondering%20Durian%20has) ($), "[A]ny decentralized order requires a centralized substrate, and the more decentralized the approach is the more important it is that you can count on the underlying system." This applies to cryptocurrencies (you can trust the protocols) and to the Internet (ditto). It also applies, in an interesting way, to the increasingly decentralized world of free trade and free-flowing capital: money can only flow and deals can only be made if everyone has a consistent sense of property rights and contracts, and the definition of those concepts will typically be determined by whichever participant in a transaction has the more sophisticated financial and legal system. Globalization ends up being a bit like Henry Ford's pitch: you can use any economic paradigm you want, as long as it's the American one.1
219−
220−An open, decentralized system is <em>sparse</em>: there's room for anything, which means that most of the possibility space consists of nothing at all. This creates a natural demand for onramps—Coinbase for figuring out Bitcoin, portals for figuring out the Internet, TSM for turning chip designs into functioning products, and the like. These create a complicated dynamic: these onramps are built on an open system, but part of their function is to close off some of it. And the better they do that, the more value they can capture. Meanwhile, because they have a monopoly on what they've fenced off, their economics support providing a better user experience. Make a really helpful update to the Bitcoin wiki, and you can feel good about yourself and perhaps contribute to the price of Bitcoin in a highly indirect way; design and launch an improved onboarding process at Coinbase and your contribution is quantifiable, and affects your next cycle's equity grants.
221−
222−This privatization proceeds in three different ways:
223−
224−- Some companies start building on an open protocol and then slowly make it their own. Chrome's decision to make the search bar synonymous with the address bar was a slight improvement in the interface, but also a very strong statement that Google had replaced manually typing in URLs as the default way to navigate. (The strongest evidence for this is the frequency of navigational searches; [the most commonly-searched term on Google](https://www.mondovo.com/keywords/) is "Facebook" and [the most frequently searched term on Bing is "Google"](https://www.bloomberg.com/news/articles/2021-09-28/google-tells-judges-it-s-so-popular-it-s-bing-s-top-search-term).) Typing in URLs is a sometimes-decent way to find what you're looking for, though [the half-life of links is about two years](https://blog.zomdir.com/2017/10/the-half-life-of-link-is-two-year.html). But guessing at URLs can be [perilous](https://en.wikipedia.org/wiki/Whitehouse.com). No one is responsible for fixing this, but Google is the closest approximation, because what they are responsible for is solving the "look for something on the Internet and get the wrong result" problem, a different but related one from the broader task of allowing arbitrary site owners to host arbitrary content. Privatizing is effective, and solves problems for users rather than protocol designers. But it does go against the spirit of the original network.
225−
226−- Twitter is another example, except that they basically created their own open mostly-open protocol and then slowly took control of it. Tweets were originally a simple format, with 140 characters of text and a bit more metadata (this made it compatible with SMS, which had a 160-character limit). For a while, Twitter looked like it would operate a novel protocol and let third parties decide what to put on it and what to read off it. And then the company started to realize that an open system was also one where it was trivial to filter out ads and recommendations. So the outside partners gradually got cut off.
227−
228−- Facebook—the product, not the company—is a third example. It essentially implemented a missing element to the protocol: <em>identity matters</em>. When the original protocols were being hammered out, identity was a problem taken care of by the fact that getting online required steep hurdles; if everyone involved is affiliated with a university that trusts them to use a PDP-10 responsibly, spam or abuse were not big concerns. (Not that early usage was [strictly professional](https://www.theguardian.com/science/2013/apr/19/online-high-net-drugs-deal).) With billions of people online, accessing relevant information can mean traversing a graph of people rather than links, so the identities of those people becomes important. To the user, if not to the network itself, a name and relationship is a far more important unique identifier than an IP address.
229−
230−This pattern raises a question: is centralization just a natural tendency of all networks? Are we destined to have a "decentralization sandwich," where there's a hard-to-change set of protocols, something open built on top of <em>that</em>, and a series of closed systems built on top of that, which are the only ones the average person interacts with?
231−
232−One of the interesting alternatives to this is [Urbit](https://urbit.org), which is trying to build a network in which identity exists from the start, and is neither free nor monopolized. One of Urbit's principles is that users own their data, and while they can use third-party services, they're sharing their data with services, not using a login to access information that lives on someone else's servers.
233−
234−This is a nice theoretical solution to the "build your own" problem above: if someone tries to start Twitter-but-without-banning-X, they begin with "Twitter-but-it's-100%-X," which seems bad until they reach the next stage where trolls arrive and they start to learn that Online Censorship is mostly about spam and gore and only occasionally about politics. But if they're moving their data around, and their friends graph with it, then spinning up a separate instance of the same service, pulling in the same content from their friends, and whitelisting someone who's blacklisted elsewhere is a lot more feasible.
235−
236−At least at first. One of the problems with owning your own data is that it ignores the question of what format that data is in. Data formats are sometimes considered carefully, but they can also be hammered out fast to get a minimum viable product out the door. Then they evolve over time, accumulating cruft and complexity, until they might as well be encrypted.
237−
238−And indeed, what's to stop someone from having a proprietary format that's literally encrypted? Or one that gets changed to an encrypted version later on? This is not a trivial point; if you're ever in a position where you absolutely have to share some information that you want to keep secret, the smartest thing to do is share a huge amount of confusing and poorly-explained information, or use an [annoying but technically accurate format](https://www.vice.com/en/article/gv5vxb/crypto-keys-printout-of-edward-snowdens-email-service-lavabit-ladar-levison). Strict and unalterable rules are no match for determined adversaries, whether they're trying to play a prank, make a point, or maximize shareholder value.
239−
240−But the data format questions are not rhetorical: there is actually an answer of sorts, though it's a frustrating one. Software systems are not just lines of code, but the entire extended system of people who maintain, host, and build on platforms. And the norms of those communities can push back against market pressures. I've been spending an increasing amount of time around Urbit users and devs, and they really do view the current centralized model of the Internet as anathema. They are aware that the fun apps we use are all either designed to be addictive from the start or subject to relentless evolutionary pressure to get more addictive. There's a history of [norms evolving in response to new addictive behavior](https://gist.github.com/jm3/6724931). And Urbit's architecture is a lot closer to norms than to the clumsy mechanism of laws; instead of centralized services that own data, there's a set of 256 Urbit identities that can route messages between users. Instead of single points of failure, there are a few hundred fallback options; instead of the binary of on-Facebook-or-anathematized, there's a 2^8 bit gradient.
241−
242−One possibility for the successor to the current Internet is that it will end up being a system designed to support communities that achieve cohesion based on which forms of addictive or socially corrosive technology they reject. Sort of a digital version of the Amish, [not rejecting technology wholesale but carefully considering every new technology before adopting it](https://kk.org/thetechnium/amish-hackers-a/). If you assume that the pace of change in consumer-facing Internet stays high, and that it gets more compelling over time, then in the long run the only options are a) be careful what you use, or b) accept that you're outsourcing a growing share of your decisions to product managers and growth hackers who do not necessarily have your interests at heart.
243−
244−Norms are not a perfect solution to these problems (if they were, we'd only know about issues like novel addictive behaviors, monopolies, and the homogenization of entertainment from history books). And technology can't fully solve social problems. But it can certainly have an effect on them—"you can't solve a social problem with technology" is a good guideline, but technologies mitigate them all the time. What's a streetlight if not a technological solution to the social problem that there are places where it's dangerous to be out when it's dark? What's asymmetric-key cryptography if not a technological solution to the social problem that it's hard to keep secrets? There's still a fundamental tension with open systems, where they get mature enough to be useful at which point the median user's priority is getting things done rather than adhering to the network's original design principles. But a design that recognizes this from the beginning, and a community that wants to make it happen, can stave off decline for a long time. And that's the positive story of technology: we're all fighting against entropy, which is a hard fight to win, but there are long and fascinating stalemates ahead.
245−
246−(Disclosure: I'm long decentralization by way of Bitcoin and Urbit. If you're on Urbit and would like to discuss <em>The Diff</em>, go to ~lableg-tadrex/the-diff.)
247−
248−<sup>1.</sup> There is naturally some resistance to this, both because of conflicts with different countries' norms and with other countries' natural desire to determine their own destiny. So it's a leaky abstraction, but it gets less leaky over time as economies get more integrated and thus more of the world has to standardize. The most direct example of this is the fact that [the dollar's share of global invoices is 4.7x the US's share of global imports](https://www.economist.com/schools-brief/2020/08/27/global-trades-dependence-on-dollars-lessens-its-benefits) ($, <em>Economist</em>). In the same way that English is most likely to be the shared second language of any two randomly-selected people who don't speak it as a first language, the dollar is most likely to be the second most useful currency to anyone in a country that doesn't use dollars.
249−]]></content:encoded>
250− </item>
251− <item>
252− <title><![CDATA[NFTs, Urbit IDs, and Communities w/ Haleek Maul]]></title>
253− <link>https://urbit.org/blog/haleek-maul-interview</link>
254− <guid>https://urbit.org/blog/haleek-maul-interview</guid>
255− <pubDate>Thu, 09 Sep 2021 00:00:00 GMT</pubDate>
256− <content:encoded><
258−
259−*Check out the Holdersland x Urbit collection: [holders.land/urbit](https://holders.land/urbit)*
260−
261−We sat down recently with Haleek Maul to discuss the current state of NFTs and the future of Urbit IDs and digital communities.
262−
263−Are Urbit IDs NFTs? Sure, they're ERC-721 non-fungible tokens which you can buy on OpenSea—but to be clear, we made them way back before the word "NFT" had entered mainstream consciousness. An Urbit ID is a number that is used to generate both a phonetic name and an avatar (what we call [sigils](https://urbit.org/blog/creating-sigils)), but it is so much more than your average NFT—it is a key to an entire digital world.
264−
265−We built Urbit IDs for digital communities and the people they’re made of. An Urbit ID is a decentralized and pseudonymous identity perfect for your collective, commune, squad, team, or DAO. Unlike most addresses or social identities, you own your Urbit ID like you own your crypto. Your Discord handle might be free for now, but as the saying goes, if it’s free then you’re the product. On Urbit your ID is actually yours and you pay for it up front. You can log into third party apps or software without ever relinquishing control of your data. What is yours stays with you. IDs themselves can be owned collectively—there are already DAOs on Urbit who jointly own stars and galaxies.
266−
267−Urbit IDs are evolving and generative. They’re generative because some IDs spawn additional NFTs which themselves can be bought and sold. For instance, each star can spawn 65,535 planets, and each galaxy can spawn 255 stars. The network itself is evolving, meaning that the network can be upgraded via a majority vote by galaxy holders. Urbit IDs and the Ubit network itself are inherently dynamic.
268−
269−At Urbit, we support communities of all kinds. We recently granted Holdersland ten Urbit IDs: four stars and six planets to be auctioned off. Haleek Maul (his Urbit ID is `~fosmex-hocmel`) will be creating custom artwork for each of the sigils. The proceeds of the auction will help support Holdersland in bringing blockchain technologies to the Caribbean. The auction will go live on September 16th, 2021 on [holders.land/urbit](https://holders.land/urbit).
270−
271−Without further ado, here’s Haleek Maul.
272−
273−---
274−
275−**Tell us a little bit about yourself and Holdersland.**
276−
277−Sure. My name is Haleek Maul and I’m a multi-disciplinary artist. I was born in America and came to Barbados when I was three years old. I’ve been making music since 2007. I put out my first debut project in 2012 and since then it has been a process of creating art from the stuff flowing through my mind.
278−
279−Holdersland is a digital extension of my artistic project—a way of creating change in the world around me. When I was younger, there weren’t many artists like me coming from Barbados. I was into a lot of niche electronic and club music and felt alienated from the larger conversation. Holdersland is a way to help creative people in the Caribbean connect with like-minded people around the world, especially using new technologies like blockchain. So I founded Holdersland in 2020 when I left my record label after four years. I felt like music institutions was archaic and didn’t feed into my other artistic practices. I wanted to create an institution that captured the full creative practice—all the way from creating to selling. Most importantly, I wanted to get artists from Barbados and the Caribbean involved in global conversations around art and technology.
280−
281−**What exactly is Holdersland?**
282−
283−It’s a company centered around Caribbean intellectual property. We’re trying to help people get connected with new web3 technologies, especially artists. Holdersland is an aggregator that helps connects those who are interested in new technology with those those who actually develop it.
284−
285−For example, there is a lot of math that underlies music. Part of our project is to extract these mathematical principles and see how they can help generate new forms of art that can be widely distributed. So we’re working to build our own projects and work with users to adopt some of these new technologies. It’s a community of people centered around these values. We plan to implement voting, governance, and incentive structures into the community soon.
286−
287−**What do you think is the link between your two main interests: music and technology?**
288−
289−I’ve always been interested in technology. Anyone who has made music in the last twenty years has had to get involved with tech. Especially if you’re a producer. There are many young kids who are downloading music software and messing around with it, and in the process becoming knowledgeable about music production and design. Science and math live right beside art.
290−
291−I was also into web development when I was a teenager and was very interested in how the internet worked. This led into the work I’m doing with Holdersland. Technology, more often than not, is concerned with collaboration and communication. But in order to develop new technologies we often need to talk about nitty-gritty details. This requires detailed knowledge of particular technologies.
292−
293−**What is the great hope or promise with new decentralized technologies like blockchain or Urbit?**
294−
295−They lower the barrier to communication and trade. Especially for countries like Barbados, we don’t have access to the world market. But now with these networks, and assets like NFTs, we can engage in commerce without borders. It allows new entrants to join the market.
296−
297−It also allows new financial relationships and funding structures to emerge. Rather than have a few people contribute $20k, you can have hundreds of people contribute $100. Once again, this lowers the entry for people to invest is early-stage projects. This changes the way that companies build and ship products.
298−
299−Brain drain is when skilled workers move abroad for more profitable employment. These new technologies allow native Carribeans to stay where they are while earning money. Using these new technologies, the Carribean can prosper while not losing its unique character and cultural identity. Crypto is permanently going to change the distribution of wealth and culture around the world.
300−
301−Discord is a fine community solution, but it’s not ideal. There’s an endless array of plugins and dependencies that makes Discord unstable. However, it is a good mixture of an office, a storefront, and a club: I can do my work, sell assets, and just have fun. Communities are important. People naturally want to be in communities, we just need a better solution than Discord. Especially one that’s crypto-native and allows for commerce. Urbit is a one-stop shop that could fill that gap.
302−
303−**What is the collaboration between Holdersland and Urbit that’s happening this week?**
304−
305−I’m producing some custom sigil artwork for a set of stars and planets. Both the Urbit assets and artwork will be auctioned off together. The proceeds from the event will go towards creating a community music studio here in Barbados and technology education around the island.
306−
307−A lot of people here in Barbados don’t even understand what crypto is. A lot of the work being done around this project is to raise awareness about the potentials of this new technology. I want this to be a general springboard for the Caribbean to gain greater technological literacy. That literacy is an important step for lower-income people to drastically change their situation.
308−
309−**What are you looking forward to talking about on the New World Energy panel at Assembly 2021?**
310−
311−I want to talk about how to migrate communities onto Urbit. How to use Urbit as a new platform for niche cultures found around the current internet. Also the great strength and power provided by Urbit’s digital identities.
312−
313−NFTs can be very powerful—there are a lot of possible applications of a unique digital asset. It’s already dissolved geographical boundaries which will help countries to export their intellectual products freely. Countries need first to gain knowledge around these technologies and their economies will follow.
314−
315−**Thanks for chatting!**
316−
317−See you at Assembly 2021!
318−]]></content:encoded>
319− </item>
320− <item>
321− <title><![CDATA[State of Urbit]]></title>
322− <link>https://urbit.org/blog/state-of-urbit</link>
323− <guid>https://urbit.org/blog/state-of-urbit</guid>
324− <pubDate>Tue, 24 Aug 2021 00:00:00 GMT</pubDate>
325− <content:encoded><
327−
328−In the past year, as Urbit has become more reliable and easier to use, we find that we're spending almost all of our time on the network. We've disappeared into the system we've been building, and it's a pleasure to be on Urbit. There's nowhere else we'd rather be.
329−
330−If you're on the network with us you can see the system being built and getting better in real time. Bug fixes and new features appear on your ship constantly. The community is actively planning the future of the system _using the system itself_. At Tlon, we have the unparalleled pleasure of working on the system, _on the system_. This feels great, but for those of you who aren't on the network, it can look as if we've disappeared.
331−
332−Right now, Urbit is not for my non-technical friends. But everyone can tell that mainstream apps are getting worse and most feel a desire for change. We want Urbit to be as easy to use as a conventional service. Or, at least as easy to use as Signal. And we're getting pretty close to that.
333−
334−In this post I'll cover the progress we've made since releasing OS 1 so those who aren't on the network can get a sense of what we've been up to and where we're going. We've built a great communication tool called Landscape, we are improving Urbit's ease of onboarding, and we're launching an entire software distribution system. We have a lot of work on our plate.
335−
336−Okay, let's talk about where we currently stand and where we're heading.
337−
338−**Arc**
339−
340−Let's start at the top: we're working to build a new network and operating system for everyday cloud computing. We think everyone deserves to control and shape the tools they use to communicate and collaborate.
341−
342−Or, to put it another way: the apps and services we have today are confusing, annoying, and overly complicated. The only way out is to start at the foundation by building a new software stack. Once we have a cloud computing stack that an individual can own and completely control, the old hope that computers can be tools of freedom will return. We haven't forgotten the original vision of software as a fun, free, flexible everyday tool.
343−
344−This is a hilariously ambitious thing to try to do, we know. This is what makes it fun. So far, we just try to move step-by-step without overhyping what we're doing. Building a new platform for networked computing is both a technical and social problem. The technology has to work exceptionally well and the community has to care for it and move it forward.
345−
346−Our first step was simply to build a prototype, then to refine it into something that could plausibly work. Then, most recently, take that plausible prototype and build a user experience we liked enough to depend on it from day-to-day.
347−
348−In the last eighteen months we've done exactly that. We depend on Urbit day-to-day and have shipped a tool that has become a home for numerous cultures and communities who are invested in moving the system forward. We first called that tool OS 1 but now it's known as Landscape.
349−
350−First, let's talk about the general arc of OS 1 → Landscape, both the successes and challenges. Then we'll talk about our next step, which is to create an independent and community supported software ecosystem.
351−
352−**OS 1 → Landscape**
353−
354−The tools we use shape the way we think. So how could we build better tools with old broken ones? We needed to cut our reliance on old tools that couldn't care less about how people actually work and live. The only thing they maximized was distraction and dependence. We needed something that was fundamentally private, durable, and flexible. Above all, we needed something that actually belonged to us.
355−
356−Building Urbit involves a lot of communication and collaboration. In order to move Urbit forward we knew that we needed a place to converse and connect, and we knew that place had to be on Urbit itself. We didn't need a Slack or a Discord or a Google Drive or a Reddit. We needed all of those things, in one place, that actually belonged to us.
357−
358−We experimented, built things, threw them away, and then eventually built and [launched OS 1](https://www.youtube.com/watch?v=71ViyftPkGk).
359−
360−OS 1, now Landscape, is a simple tool for bringing groups together to communicate and stay connected. When a real physical community goes online they immediately become fragmented between various apps. Perhaps a Slack channel coupled with some Notion notebooks and a Telegram channel works for some people. It's easy to imagine other permutations, and you probably are already in at least two or three. These duct-taped stacks are not only ugly and confusing, but your day to day computing is spread thin and remains in the control of companies—not you.
361−
362−Urbit is a decentralized network but Landscape is for re-centralizing your communication. Users can form groups which share a set of channels; each channel can be either a chat, a notebook or a collection of links. This means groups can communicate flexibly, exactly how they want. And since Landscape is built on Urbit, each group is private and peer to peer; data is only shared between people in the group; each community on Landscape is completely independent. Communities own their data and last as long as they need to.
363−
364−This combination of a flexible unified interface on a decentralized platform you can trust feels really good.
365−
366−When OS 1 was first released, it was slow, buggy, and frustrating—but we loved it and wanted it to be better. We spent the next nine months making sweeping changes to take it from releasable prototype to pretty-nice first version. We rewrote the frontend completely, massively improved the performance of Urbit OS itself, and overhauled the interface. It was an enormous collective effort.
367−
368−By the end of 2020 we had renamed OS 1 to Landscape and the user experience was far better. We [announced our hosting service](https://www.youtube.com/watch?v=w3qKe_WZr50) and onboarded close friends to help us test the system. I [wrote a little](<[https://tlon.io/news/landscape-now/](https://tlon.io/news/landscape-now/)>) about using Landscape from day-to-day around that time.
369−
370−Landscape wasn't just a useful tool for us, but it was something that other communities were starting to use in earnest. It seemed like Landscape could be a great place for people to grow new private communities, so long as we could onboard new users effectively. Hosting is a huge piece of the puzzle, since we need non-technical people to be able to use this wonderful platform as easily as its mainstream competitors.
371−
372−At this point (early this year), we encountered some pretty serious hurdles.
373−
374−To use Urbit, you need an Urbit ID. Each one of these is an NFT (something that no one cared about when we first launched Urbit ID). The basic idea is that an ID should cost something so that they aren't used abusively. But, in late 2020 the combination of a crypto bull market and congestion on the Ethereum network caused the transaction fee for buying an Urbit ID to increase from ~$1-2 to ~$100. An Urbit ID should cost _something_, but \>$100 is too much of a barrier for entry. We knew that this could happen and started researching solutions late last year, ultimately deciding to [implement a solution ourselves](https://urbit.org/blog/rollups/).
375−
376−The tough part about having an identity verified on the blockchain is that you become vulnerable to unpredictable volatility. We saw a period of painfully high prices, followed by a dip, followed by another stretch of extremely high prices. We opted to continue releasing Landscape updates and moving the system forward despite the fact that it became prohibitively expensive to onboard people. Luckily, our solution to this problem should go live this summer, and will reduce the cost of onboarding about 60x. The best part is that it is a permanent solution so we'll never have to face this problem again.
377−
378−The other challenge to scaling the onboarding process is hosting.
379−
380−We have a functional hosting structure but we want it to be fully automated and featured. We've been able to onboard friends and enthusiasts which has taught us a lot about how the system should work. But hosting has to be easy for anyone to join and get online quickly. Without an automated invite flow and it's not ready for prime time.
381−
382−We've made great progress on this front. We are currently testing improvements internally and aim to have a final version ready simultaneously with lower planet fees. Then, at long last, we can comfortably invite friends to get on the network without ever leaving the browser.
383−
384−It's worth mentioning that hosting is very much a Tlon Corporation project. Urbit is a platform owned, maintained, and developed by the people that use it (along with the nascent Urbit Foundation). Tlon, while also contributing to the Urbit project, ultimately wants to produce applications and services on Urbit. Hosting is one of those projects. Hosting makes Urbit easy, approachable, and usable without the compromises involved in using a conventional service. Since we'll be one of many Urbit-related providers, Tlon won't be the only host. There are already a few others (like [UrbitHost](https://urbithost.com/)) getting off the ground, which is fantastic.
385−
386−**Landscape → Grid**
387−
388−As the world has become more physically distributed we rely on our digital tools to keep our communities connected. The rise of DAOs, collectives, squads, and alternative community governance structures underscores the importance of tools like Landscape that communities can actually own and control.
389−
390−Our first goal was to find out if we could build something really good on top of Urbit. We did that. And we're continuing to lower the barrier to entry. We've also got an Urbit 'messenger' iOS app in the works that's really nice.
391−
392−Landscape is great, but in the long run Urbit is meant to be a platform for anyone to build on top of. Urbit is a computer, not just a single communications app like Landscape. The whole point of Urbit is to make it easy for an individual to run their own general-purpose computer in the cloud. Your Urbit isn't just meant to run Landscape it's meant to run any sort of application. And that's where we're going next.
393−
394−Grid is a holistic interface for interacting with your Urbit node. Landscape, as it's known today, will become one of many apps that can be launched. Perhaps most importantly, Grid will have peer-to-peer software distribution over the network. This means you can, as a developer, build something, let a friend sync it over the network, and never have to run a dedicated distribution server. Or, as an everyday user, you can run software on your private Urbit node without the developer ever being involved.
395−
396−Urbit isn't an OS in the traditional sense—it's an 'overlay' OS. It has to run on top of something else. But Urbit _is_ an OS in the sense that it's general-purpose. And our goal in building interfaces for Urbit is to deliver that feeling of openness and flexibility to the user. Grid is a major step toward that goal.
397−
398−Not only should a community own their communication tools, they should be able to run and host their own cloud software. They shouldn't need to rely on providers to store their data, run the application, and determine how their digital life will function.
399−
400−Grid will surely go through the same process that Landscape did. It'll start as a working first version that will inspire us to refine and make it better. But, unlike Landscape, Grid opens up an entirely new frontier for what can be done on Urbit.
401−
402−We're putting together our first conference on Oct 15-17th to inaugurate Urbit as an integrated platform and distribution system for new applications. [Tickets for Assembly 2021 are already available](https://checkout.eventcreate.com/assembly2021/select-buy). Tlon is going to Austin!
403−
404−**Closing**
405−
406−Urbit is a deeply optimistic project. Although the digital world seems more broken than ever, we're confident that something else is possible. We have already created software that people use everyday. We want everyone to have the experience that we do, and we want that experience to continue to get better. Beautiful, reliable infrastructure that communities can build on will have a significant impact on the world. The end game of connected computers doesn't have to be dystopian.
407−
408−For those of you who aren't directly involved with the project, I hope this gives you a snapshot of where we are. If we were on an Antarctic expedition the postcard would read something like 'Team is well-fed, healthy and motivated. Making great progress.'
409−
410−With that, I'll get back to work.
411−]]></content:encoded>
412− </item>
413− <item>
414− <title><![CDATA[An Interview with UrbitHost]]></title>
415− <link>https://urbit.org/blog/urbithost-interview</link>
416− <guid>https://urbit.org/blog/urbithost-interview</guid>
417− <pubDate>Thu, 19 Aug 2021 00:00:00 GMT</pubDate>
418− <content:encoded><
420−
421−**An Interview with UrbitHost**
422−
423−Urbit has been making great strides to become accessible to those who are non-technical. Port enables a user to launch their Urbit ID from their personal computer without any knowledge of the command line. However, you only have access while you are running Port, which means you can't do things like check your DMs while on the move.
424−
425−Hosting your Urbit means that your Urbit is always on and available. All that is required to access the network is visiting a URL and logging in.That means you can access Urbit from your phone, laptop, or any device with a browser.
426−
427−The downside is that running your own server can be a complex and difficult process. Third-party hosting allows an expert to do that work for you. The hosting provider gets paid, and you get 24/7 access to your ship.
428−
429−[UrbitHost](https://urbithost.com) is one of the latest [hosting providers](https://subject.network/planet-sales/) to enter the market. As of now, it is one of the fastest and easiest ways onto the network. You pay the fee, and you get sent a link that you use to access Landscape. It's that easy.
430−
431−At least, it's that easy for the end user. For the guy running the operations, ~lavlyn-litmeg, it can be quite a complex operation. I sat down with him to find out about what it's like being a commercial developer on Urbit. We also talked about technology, the developer ecosystem, and the future of Urbit.
432−
433−If you want to get in touch you can reach him at ~lavlyn-litmeg, the ~sardys/uh group, or [urbithost.com](https://urbithost.com).
434−
435−---
436−
437−**Tell us a bit about yourself and your history with Urbit?**
438−
439−I'm a software engineer who is currently working at one of the larger crypto currency companies. My history with Urbit goes back quite a long time. I saw one of those early demos by Curtis where he had two dojos running, sending messages back and forth, and I thought it looked interesting. Since then, I often checked in on the project, but I stayed at the sidelines because it felt not quite ready; there were constant breaches and so on. What kept me close by was that I believed in the vision of Urbit.
440−
441−I think the open internet only has a future if people retain control of their digital identities, which means that, in addition to a cryptographic identity, they need to be able to keep control over their data. This not only includes their social graph, but they also must be able to run computations on that data. Urbit checks all those boxes. The people behind Urbit and all the other contributors have been steadily marching towards these goals with incredible stamina. I'm inspired by that. And, since the release of OS1, Urbit is very much usable, and I find myself spending more and more time on it instead of other corners of the internet.
442−
443−**Why did you decide to work on hosting rather than another Urbit project? If you weren't working on UrbitHost what would you be working on within the Urbit ecosystem?**
444−
445−I want my non-tech friends to be able to join Urbit. Most people I know can't be bothered with executing a blockchain transaction, many feel uncomfortable installing an app they don't understand, and almost all would shy away from the command line. For the vast majority of people, getting onto Urbit must be as easy as signing up for Gmail or Twitter, otherwise they won't come.
446−
447−I thought about how I could contribute to Urbit and decided that now is a good time to build a hosting provider. It's still early, but a non-technical person can actually spend time on the network and be productive. I think we are just now seeing a shift where we need community builders as much as we need engineers working on the internals of Urbit. It is important that those community builders have no barrier to entry for themselves or their communities.
448−
449−That is why ease of access has been my goal from the beginning. I wanted the site to be fully automated, meaning someone could sign up and be on Urbit within minutes. It was also important to me that users be able to choose their own Urbit ID. As far as I know, there was no offering like that yet, so I decided to build it—but I know that others are working on this too.
450−
451−If I was working on something else, it would be Urbit apps. We're waiting for the new release for it to be easier to distribute and access apps; there are a few tools I would really like to see. But other than that, I would like to spend more time community building.
452−
453−**Can you tell us about how you're implementing UrbitHost? You beat Tlon to the punch of having immediate hosted access to the Urbit network -- what're you doing differently? How will your implementation change when programmatic access becomes available via Khan (the new vane to replace Herb)?**
454−
455−UrbitHost runs on Kubernetes, which is a tool to orchestrate containers. What that means, concretely, is that each ship runs inside a Docker container, and Kubernetes makes sure that each container is running and has enough resources. For example, if a server goes down, Kubernetes will automatically move the ships that were on that server to a new server that is available. No data is lost and there should be very little down-time.
456−
457−People think Kubernetes should only be used for services that can be scaled horizontally, meaning there are multiple instances running of the same services. Scaling like this is obviously not an option for Urbit, because a ship must only run as a single instance. But in the last few years, Kubernetes has added many features to run single and stable instances of a container, for example a database. UrbitHost is making use of these features—permanent volumes, stateful sets, and so on—to provide a high-availability hosting for Urbit. It also scales well. I surmise, we could host thousands of ships, we would only have to add compute nodes.
458−
459−As for beating Tlon, I'm not sure if it is a fair comparison. UrbitHost, as it is currently, is a minimal viable product. I tried to realize a simple goal: automated hosting. Tlon is hosting many more planets, not to speak of all the stars and galaxies that make up the network. As far as I can tell, Tlon and UrbitHost are doing things quite similarly. For example, I knew that Tlon is also hosting on Kubernetes, which gave me much more confidence that we could do it too.
460−
461−UrbitHost's programmatic interaction with hosted ships is quite minimal once it is booted. We use airlock to retrieve the access code and do a few more maintenance things, and we are using it for some upcoming features like automatic S3 configuration. But from what I can tell, Khan looks like a really important step forward, because interacting with the hosted ships via airlock is one of the most brittle areas, and I'm looking forward to making it more robust once Khan is out.
462−
463−**What is most needed within the Urbit ecosystem — any particular apps or services? Which projects are you most excited about?**
464−
465−The ability to publish content directly from a planet to the regular internet would be cool. I would really love to see some bigger blogs being hosted on Urbit. The basic idea would be this: everyone can read the blog, but to join the conversation one would have to join Urbit and the group associated with that blog. Of course, a planet could publish other content too, possibly a mix of free and premium content. Either way, it would pull a lot of people into the gravity well of Urbit.
466−
467−Publishing could also be a good value proposition for Urbit hosting providers. If public content is hosted on a ship, then all the profit from new customers who are brought to the provider could somehow be split between the host and content producer. What is nice, though, is that a content producer can take his Urbit-native community anywhere, anytime, without disrupting the community much. The portability of Urbit at every level would really shine here as communities grow.
468−
469−There are incredible projects happening on every front. The Bitcoin integration is very exciting, it is being realized in a truly Urbit-native way and could prove to be a great catalyst for the ecosystem. However, as a hosting provider, the constant lower-level improvements are exciting too.
470−
471−**What will be the effect of two upcoming changes to Urbit:**
472−
473−1. **Built in software distribution and management**
474−2. **Layer 2 and the new "Khan" vane**
475−
476−**For #1, how would you pitch developers on the benefits of building on Urbit?**
477−
478−**With regard to #2, I think there is about to be an explosion of hosting providers. Will this unleash an Eternal September effect or does Urbit's "walled garden" style of communication make it more resilient? Urbit is not a single silo like Facebook, after all.**
479−
480−I think that once software distribution is as simple and easy as the iOS app store it will be a watershed moment for Urbit. Put bluntly, it will give users something to do on Urbit besides chat. There are several interesting apps out there already, but they are not easy to discover and install.
481−
482−Developers want reach. The most important pitch to developers will be that on Urbit they have access to a substantial audience. I remember developing for the iPhone in the early days. Objective-C was really a tough pill to swallow, but because the platform was interesting and promised to reach a large audience, I kept going with it. I think Urbit is an interesting platform for the various reasons already mentioned. But learning to develop for Urbit is really a time investment—I myself am still a novice Hoon developer —and for it to be worth it, there has to be a clear pay-off. For some, this is making system-level contributions, but for most it will be having that app show up in some centrally visible place and seeing people engage with it. Once this exists, it will be much easier to pitch Urbit to developers.
483−
484−The layer 2 solution which will make spawning planets much cheaper is an important next step, especially for hosting providers. Layer 2 will help us immensely because spawning and keying planets is very expensive right now, and it puts a damper on how much we are actively pursuing growth.
485−
486−If new hosting providers come online, it will not necessarily mean a huge influx of users. In my experience, building a provider is hard and takes time to mature. However, I would love to see fast user growth.
487−
488−I honestly don't think having our own Urbit Eternal September would be that bad. I would just see it as growing pains. If we enter a time of sustained growth and rapid user onboarding, the fact that some Urbit groups will get overwhelmed with all the new people will be a small price to pay. The current setup, with a few central groups that act like hubs and discovery points—for example, the fantastic Urbit Index—would have to change. People would need to be funneled into their own Urbit universes that might not overlap much with other areas on Urbit. The nice thing is that all this is accounted for in the Urbit infrastructure.
489−
490−If a certain hosting provider ends up bringing thousands upon thousands of users to Urbit, like AOL did back then with Usenet, then it will be the provider's responsibility to onboard those users sensibly and not just dump them on the existing groups. In other words, providers, in my opinion, also have a community building responsibility. Of course, this does not mean that providers should be overbearing parents, allowing only this or that, but simply that they should have sensible defaults that don't overwhelm or destroy the network.
491−
492−**What is the role of commercial providers in the open-source ecosystem?**
493−
494−Commercial providers will be incredibly important to make Urbit succeed. I think if Urbit attracts a large number of users, many, if not most, will run their ship via a hosting provider. It is the easiest way to get started.
495−
496−However, using a hosting provider to get onto Urbit might at first seem antithetical to the spirit of the project. If someone is trying to get away from mega-corporations, why would they go right back to another company and give them their data?
497−
498−Well, because it's a completely different relationship. The relationship between us, the provider, and you, the customer, is transparently straight forward. You are not the product. We have a more traditional provider-customer relationship where we just do the dev ops work. It is in our interest to keep your data private and keep your ship running. We give you an Urbit ID, which you can keep forever, and host your ship as long as you wish. When you want to leave, you can download your pier and Urbit ID and use it with a different provider or on your own computer in minutes. On the other hand, you cannot leave Facebook and run your profile off of your laptop. Basically, we cannot count on customer lock-in, we must provide good and honest service. Again, the portability promise of Urbit is essential here and ensures that we are on an equal footing.
499−
500−**Once the Urbit payment ecosystem gets built out more, would you consider accepting payments over the Urbit network?**
501−
502−Of course. Having an Urbit-native economy would be a key marker of success, and I would love to participate in it. Moreover, we are planning to offer a Bitcoin node to our customers soon.
503−
504−**Are you coming to Assembly 2021?**
505−
506−Yes. At least, I'm planning to! I would love to meet all the people behind Urbit in real life.
507−
508−**I know you are a Christopher Alexander fan, how has he influenced your work?**
509−
510−I've been interested in Christopher Alexander for quite a long time. When I realized that many of the people building Urbit are also inspired by him, I understood why much of the Urbit vibe resonated with me. Critics of Urbit either focus on the technical details or on Curtis Yarvin's writings, sometimes conflating the two. That's fine and perhaps a valid point to start, but what they don't understand is that so many other ideas and ideals have since become driving forces behind the project. This is at least what I observe as an outsider.
511−
512−Alexander's ideas are all about how to build beautiful houses. He wants us to inhabit places that feel life-giving, places that make us more fully human. The same should be asked of the technology we use. So much of the current internet is the equivalent of a fluorescent-lit cubicle, a brutalist government building, or a flashy central square. It might be interesting to travel through these places, but they do not make good homes.
513−
514−To explore what makes a building beautiful, Alexander had to wade into metaphysics, because he wanted to give a much more objective account of how beauty is present in physical artifacts, which led him to treat beauty as a universal. I think to build more meaningful technology we need to do the same. We do not have a good metaphysics of technology, and this is something I'm really interested in.
515−
516−**Give me a brief summary about your personal philosophy of technology. Do all tools fall under the umbrella of "technology"? Or do some tools hit an inflection point where they acquire radically different characteristics (compare a shovel and a computer)? It seems to me that the philosophy of technology often boils down to trying to define what "technology" actually is. What do you make of all this?**
517−
518−Yeah, I definitely think there is an inflection point once technology becomes digital, but I believe there is something all technology has in common. My approach here is classical. Artifacts have to be distinguished from living things because human made things have their origin outside themselves, meaning they are manufactured (in Aristotelian terms, and stated somewhat simplistically, artifacts have an efficient cause outside themselves, whereas biological things have an innate efficient cause). We are often tempted to think of living organisms simply as elaborate self-replicating machines, but that is putting the cart before the horse. We should rather look to the world of living things to be inspired to build our artifacts.
519−
520−The question of inspiration becomes even more pressing when discussing modern technology, and you put your finger on it with the inflection point. There is no tradition to fall back on when we are building digital technologies. Someone like Christopher Alexander, who is working on architecture, has thousands of years of architecture to look at. He can read the past and see what worked and what did not. On the other hand, when we build things like Urbit, we must look for inspiration in other places because there is no corpus of, say, thousands of years of constructing digital social networks where we can simply choose the best parts. So far, we have mostly bad examples, how not to do it. And considering how new the internet is, most of it is still a blank slate. So while I'm definitely interested in the ontology of technology, I think it is an even more pressing question to learn the principles of the living world around us in order to build digital places that feel organic and life-giving.
521−
522−**Thanks for chatting!**
523−
524−See you on the network!
525−]]></content:encoded>
526− </item>
527− <item>
528− <title><![CDATA[On Christopher Alexander]]></title>
529− <link>https://urbit.org/blog/on-christopher-alexander</link>
530− <guid>https://urbit.org/blog/on-christopher-alexander</guid>
531− <pubDate>Mon, 19 Jul 2021 00:00:00 GMT</pubDate>
532− <content:encoded><
534−
535−_A well-designed house not only fits its context well but also illuminates the problem of just what the context is, and thereby clarifies the life which it accommodates — Notes on the Synthesis of Form_
536−
537−There is an unofficial design canon at Urbit. If you were a fly on the wall, you would hear the name "Christopher Alexander" regularly mentioned around the office. Christopher Alexander is an architect, albeit one who isn't taught at most architecture schools. However, his work encompasses far more than what is usually understood as "architecture". Alexander's work is concerned with the production of functional beauty. What's remarkable about his books is that they are not empty philosophical manifestos—Alexander gives specific, actionable guidance on creative problems. His best books are manuals for how to construct forms that are "alive". Alexander threads the needle between highly specific instruction and generalized abstract concepts—his success at this task can be seen in his influence on fields outside of architecture, from computer science to network theory. In his most recent work, Alexander touches upon subjects ranging from religion to math and connects it all into a theory about how the universe functions. But people read him for less lofty reasons: to build a house that is beautiful, design a comprehensive programming language, or figure out how to approach a complex problem. In this post, I'll give an overview of Alexander's work and hear from some Urbit staff about his relevance to software development.
538−
539−Alexander's first book, _Notes on the Synthesis of Form,_ detailed a new way to approach the design process. Released in 1962, it incorporated networks, set theory, language, and math into a new method for accurately modeling and solving design problems. Although Alexander was an architect, the book was concerned with fundamental issues: how do you solve complex problems with hundreds of interconnected variables? The answer lies in decomposing the problem into subsystems and then "diagramming" those subsystems back into a singular integrated form. The process of decomposing a set into [highly-interconnected subsets](https://en.wikipedia.org/wiki/Community_structure) involves a significant amount of computation—Alexander wrote a computer program for the IBM 7090 mainframe which was described in his 1962 paper _HIDECS 2: A Computer Program for the Hierarchical Decomposition of a Set with an Associated Graph._ But this was only half of his design process; after the creation of subsets which are the fundamental units of the design problem, the subsets must be diagrammed. This second half of the process involves integrating and synthesizing all of the variables within a single subset into a conceptual diagram. These fundamental diagrams are then integrated and combined _themselves_ into a single diagram which is the final result of the process. The diagram below is Alexander's solution to the problem of designing a village in India with a huge number of variables and constraints.
540−
541−
542−
543−_Notes on the Synthesis of Form_ can be seen as embodying many of the tensions in 1960s America. Computers were seen as a suspicious technology which embodied the institutionalized science that created the nuclear bomb and cold war era tensions. These suspicions were understandable: computers were massive esoteric machines housed in entire rooms of university and government buildings. They were physically and mentally inaccessible to the average American citizen, while the elites who did use them were held in contempt by the populace. Student protests against being just another cog in "the machine" or "IBM card" were partly right—at this point in the early 60s, many intellectuals were interested in [cybernetics](https://en.wikipedia.org/wiki/Cybernetics:_Or_Control_and_Communication_in_the_Animal_and_the_Machine) and the [mathematical modeling of "human" problems](https://en.wikipedia.org/wiki/Theory_of_Games_and_Economic_Behavior) and Alexander drew from these fields frequently in his book. However, when _Notes on the Synthesis of Form_ came out in 1964 computer culture was shifting towards an alliance with the counterculture—a cultural and technological process that would culminate with these massive pieces of institutional technology becoming "personal computers". He criticized those who wished to keep math and computers away from human creativity: he saw the possibility of computers yoked to creative human beings. He believed this symbiotic approach to technology was necessary—without a new approach to design, the world would continueto produce the ugliness endemic since the industrial revolution. According to Alexander, a designer could only successfully solve this problem by combining his creativity with the analytic and computational power of machines. Through his books and [presentations](https://www.youtube.com/watch?v=98LdFA-_zfA), Alexander would have a lasting impact on object-oriented programming and [pattern based thinking in software design](https://en.wikipedia.org/wiki/Design_Patterns).
544−
545−In _Notes on_ _the Synthesis of Form_ Alexander applauds the buildings and towns of many primitive societies but he notes that there is no hope of a return to this "unselfconscious" state. Therefore, modern people must develop a new design process to reach the same end. But what is this end that Alexander is trying to achieve? Alexander states his aim negatively in _Notes on the Synthesis of Form_ as "the absence of misfits between a form and its context". An [apophatic](https://en.wikipedia.org/wiki/Apophasis) statement might be good enough for mystics but, for someone like Alexander who was concerned with precision, a positive statement was necessary. His positive statement wouldn't come until 1979 with the publication of _A Timeless Way of Building_.
546−
547−In 1975, Alexander would begin publishing his most famous book series which included _The Timeless Way of Building_ and _A Pattern Language_. In these works Alexander took a more holistic approach to creative production and placed less emphasis on design models. This new approach cemented the importance of culture as the substrate that supports a people's inherited "pattern language". Just like a spoken language, a pattern language is developed incrementally over time by people who adapt to the same local environment. Alexander wrote that "a pattern language gives each person who uses it, the power to create an infinite variety of new and unique buildings, just as his ordinary language gives him the power to create an infinite variety of sentences". _A Pattern Language_ is an attempt to create a new language from observing the dialects of buildings around the world. Alexander recognized that there were large-scale patterns between people and the buildings they found beautiful—a productive tension between specificity and more general patterns common to all human beings. Alexander's pattern language is therefore more general than historically generated languages. The "pattern language" approach is now native to many software developers: seeing solutions as complexes of layered and interconnected systems.
548−
549−_A Pattern Language_ is the book that is closest to an instruction manual. It is meant to take the prospective builder all the way through the process of designing and constructing a building, neighborhood, or city. Alexander writes about the macro-patterns of cities and the micro-patterns of buildings, from road design to doorknobs. Alexander wanted to enumerate patterns that interlock and produce beauty at different scales while still being as precise and actionable as possible. In _Notes on the Synthesis of Form_, Alexander was concerned with how to best model reality in order to solve a problem, while _A Pattern Language_ focused on the production of a vernacular that would allow people to produce beautiful buildings.
550−
551−
552−
553−Underlying these different pattern languages is a deep, precise, and objective appreciation of an important quality of human existence—what Alexander calls "the quality without a name". This "quality" is the ultimate goal of Alexander's work. Greater efficiency and instrumentality cannot be ends in themselves. For Alexander, it is a moral imperative to save the world from ugliness and to make human culture match the natural world in beauty, complexity, and aliveness. It is described in _The Timeless Way of Building_ as "the root criterion of life and spirit in a man, a town, a building, or a wilderness. This quality is objective and precise, but it cannot be named". The "quality" cannot be named not because it is a vague or airy concept, but because "the quality is too particular, and words too broad". Nevertheless, Alexander makes an attempt to circumscribe the concept with the words alive, whole, comfortable, free, exact, egoless, eternal.
554−
555−Alexander would say that a Japanese temple and a German church are both approaching the "quality" from different histories and cultures. They are examples of two vernacular languages developing in parallel. The similarity between two modern cities is an example of how we've been severed from our pattern languages and therefore the "quality"; we are forced to design from barren earth. Global homogeneity is a symptom of disconnect from both temporal and spatial order—it is the death of our inherited languages.
556−
557−
558−
559−_The Nature of Order_ is Alexander's most recent book series and explores the metaphysical implications of Alexander's thought. According to Alexander, the failure of the modern built world is because we have learned to view the world as fundamentally dead. Alexander makes an argument that is close to [hylozoism](https://en.wikipedia.org/wiki/Hylozoism) or [IIT](https://en.wikipedia.org/wiki/Integrated_information_theory): all structures have varying amounts of aliveness (an aspect of the "quality"). Because of the modern worldview that sees all structure as dead we have become blind to this deeper aspect. The basic component which makes structures alive are strong and varied centers. Furthermore there are fifteen fundamental attributes of centers which allow them to network and become alive. These fifteen abstract units are what patterns are composed of—patterns that are then woven into languages (this process of formalizing implementations as higher-level abstractions should be familiar to any computer scientist). _The Nature of Order_ is the most philosophical and [spiritual](https://www.firstthings.com/article/2016/02/making-the-garden) of Alexander's work and ties together his overarching preoccupations: how to solve complex human problems and why the task of making the world beautiful is important.
560−
561−You might be wondering how Christopher Alexander is relevant to Urbit?
562−
563−That depends on who you ask.
564−
565−**Galen (~ravmel-ropdyl)**
566−
567−> I suppose the main thing is that most designers tend to become fixated on the mechanics of what they're building. Most design theory is about how things are made, not what it's like to live inside of them or actually rely on them on a daily basis. Alexander is much more concerned with the first-person experience of inhabiting a place or a building. I guess his approach is just much more empathetic which means it's also more practical. He's concerned with _how people actually live_ and how their environment evolves alongside them.
568−>
569−> We live, work, and develop on Urbit. We're often the first people to notice bugs because we are the end users ourselves. Alexander makes the point that old buildings were responsive to feedback because the architect was also the inhabitant. This tight feedback means that the system as a whole is dynamic and alive. We want Urbit to be a house that you live in and make yours, because unlike all the other software you use, your Urbit is actually _yours_.
570−
571−**Josh (~wolref-podlex)**
572−
573−> _The Nature of Order_ has had a big influence on my thinking. At first, the idea of all physical structures being alive sounded like something out of a new age bookstore. But not only do I think that Alexander justifies this claim; it started to make intuitive sense when I looked closely at my experience.
574−>
575−> When I first read _The Nature of Order_ I was living in an industrial neighborhood of San Francisco—the scale of the buildings and streets felt inhuman and everything was made of metal, glass, and concrete. I chose to leave. I moved into a 100+ year-old flat and the difference was immediate and visceral. The space felt like it was designed from experience rather than _ex nihilo_. The apartment was meant to be lived in, surrounded by public spaces where strangers could safely spend time outdoors together.
576−>
577−> If physical objects can have the quality of "aliveness" so too can information objects. Alexander's book is alive. Many of the software projects I've worked on have been cold fish. Keeping this quality in mind is an important part of my decision making. I want Urbit to be a living structure.
578−
579−**Édouard (~fabled-faster)**
580−
581−> I enjoy telling people unfamiliar with Urbit and interface design with respect to Urbit, that the object of our work is essentially that of designing an environment "like a piece of paper".
582−>
583−> Consider how paper as a constrained environment is one that yet can bear nearly any visual expression imaginable—apart from containing drawings or human-made marks, paper can be used to display photographs, paper can be multiplexed to form lenticular holograms, paper can be folded into a crane, etc.
584−>
585−> The "sheet of paper and its resulting forms" I manifest as a design ideal here is what Alexander might refer to as a "semilattice". A mathematical term he co-opted to describe an ideal structural relationship between elements in a system, as opposed to a "tree", which is a top-down structural system that forces elements into rigid categorical constraints. [In his own words](https://www.patternlanguage.com/archive/cityisnotatree.html):
586−>
587−> > _For the human mind, the tree is the easiest vehicle for complex thoughts. But the city is not, cannot and must not be a tree. The city is a receptacle for life. If the receptacle severs the overlap of the strands of life within it, because it is a tree, it will be like a bowl full of razor blades on edge, ready to cut up whatever is entrusted to it. In such a receptacle life will be cut to pieces. If we make cities which are trees, they will cut our life within to pieces._
588−>
589−> A city is a good ideal to maintain for the construction of a new internet and notion of personal computing, but I've tended towards my own interpretation of a piece of paper as a semilattice-embodying object due to its accessibility and ability to be imagined by anyone, designer or not. Our object of design is that of a receptacle of life, of deep expression, of multiplexed possibilities. When I imagine an Urbit in the not-so-distant future, I imagine it as a _method_ (to contrast against those who pin software's expression down to "tools" or "functions") by which I can become "whole" again in a digital context, in all my complexity.
590−
591−Christopher Alexander wanted to collapse the distinction between those who live in buildings and those who design them. Urbit wants to do the same thing with software—in order to not produce ugliness, we should live in what we build. Although we have personal computers now, all of our data is housed in enormous warehouses that make the industrial computers of the 1950s look tiny. What we think of as “our information” actually belongs to someone else and, more often than not, is weaponized against us. Alexander’s moral imperative can be taken and applied to our digital structures. We need to become close with our software again.
592−]]></content:encoded>
593− </item>
594− <item>
595− <title><![CDATA[A brief update from urbit.org]]></title>
596− <link>https://urbit.org/updates/2021-06-16-update</link>
597− <guid>https://urbit.org/updates/2021-06-16-update</guid>
598− <pubDate>Tue, 15 Jun 2021 00:00:00 GMT</pubDate>
599− <content:encoded><![CDATA[
600−Howdy!
601−
602−It’s time for the June edition of the Urbit newsletter. You might have noticed that Urbit messages are being sent quicker, bitcoin wallets are flourishing, and that the network is rapidly picking up momentum in terms of users and communities. Urbit, now more than ever, is starting to feel like an organic self-sustaining ecosystem. It’s a good time to be here.
603−
604−0 – Upcoming Events
605−
606−Assembly: An Urbit Conference
607−Early October(ish) @ Austin TX
608−We’re busy putting together Urbit’s first IRL conference. We’ll let this email list know as soon as tickets become available.
609−
610−Developer Call: Programming Bitcoin on Urbit @ Thu Jun 17, 2021 9am – 10am PDT
611−Tim (~timluc-miptev) will be leading an open workshop on programming bitcoin on Urbit. Come join the call to learn about this integration—all are welcome! (https://www.youtube.com/watch?v=ltKz1MmluEY)
612−
613−1 – Technical Updates
614−
615−~tacryt-socryp has made a major performance improvement—sending and receiving messages are now 79% faster! He accomplished this by cutting down the time spent processing messages in arvo and he did it all despite being a newlywed. Big thanks to him!
616−
617−2 – The Urbit Town Hall Event
618−
619−Most of the big news this month was featured in our first ever Town Hall event, which was a big success. If you missed it, you can watch it here (https://www.youtube.com/watch?v=8YSwt0vDPj0). Here’s a quick recap of Josh’s “State of the Network” address:
620−
621−- The event started off with an animation produced by ~rivpyl-sidfyl with a script by ~minder-folden (https://www.youtube.com/watch?v=UvsOGz-hM-o). This work was commissioned via our grant program (https://urbit.org/grants/proposals/urbit-explainer-video/). Urbit grants are predominately technical but if you have artistic chops we would be interested in hearing from you.
622−
623−- The grant program has been successfully churning out projects with 36 contributors in the last six months and 42 grants which are currently active. There is also a new class of grants called “apprenticeships” where a junior Urbit developer gets paired with an experienced Urbit developer to work on a project (while getting paid). Sign up before spots are gone (https://urbit.org/grants/apprenticeships/).
624−
625−- Post-facto gifts were made to Urbit’s community members for exceptional contributions: ~nodreb-borrus, ~tocrex-holpen, ~habsul-rignyr, ~libhut-samwes, ~litmus-ritten, ~locpyl-tidnyd, ~sitful-hatred, ~sigryn-habrex, ~mocrux-nomdep, and ~tapruc-solwer.
626−
627−- The Bitcoin Wallet application was rolled out to the network (see below).
628−
629−The next two sections of the town hall featured Hunter Miller presenting on Port (see below), and Justin Murphy discussing the role of teleology in Urbit’s success. There were also some great lightning talks at the end, although they were unfortunately not recorded—you had to be there!
630−
631−3 – Port (previously known as Taisho)
632−
633−An important goal for Urbit has been accessibility and now, thanks to Port, it’s easier than ever to get onto the Urbit network. Port lets you boot a planet, star, or even galaxy without ever touching a terminal. If you haven’t noticed, our homepage is now prominently featuring this development. The official urbit.exe is just around the corner but get your Mac friends to boot a comet! Thanks to Urbit contributor Hunter Miller for this important achievement! (https://github.com/arthyn/port)
634−
635−4 – Bitcoin Wallet
636−
637−You can now send bitcoin over Urbit just by using a ship’s name—it’s that easy. The official documentation is still in the works, but ~sitful-hatred has already produced this easy guide to getting started (https://subject.network/posts/btc-wallet-config/).
638−
639−5 – Gurgle.io
640−
641−A new website has been causing a stir in the Urbit community. Gurgle.io is an index of the public Urbit network. If a group is public it can be crawled via a comet/planet that acts as a listener. Many Urbit users have expressed discomfort as they were not asked permission before being indexed. The developers of the project have recently decided to cease operation of the project (https://twitter.com/gurgle_io/status/1404649313020514310).
642−
643−6 – Blog
644−
645−~sitful-hatred has a post on the relationship between %graph-store and hypertext where he traces the historical relevance of linkages and networks. Fascinating stuff! (https://urbit.org/blog/a-topiary/)
646−
647−There are two new posts from Poprox (~datnut-pollen), one on how the Urbit team is solving the problem of expensive gas prices (https://urbit.org/blog/rollups/), and the other was co-authored with Mark (~palfun-foslup) on the recent upgrade to Azimuth contracts (https://urbit.org/blog/first-contract/).
648−
649−7 – New Addition to the Team
650−
651−Me myself, Matt (~tirwyd-sarmes), am joining the Urbit Foundation to help with content. Please get in touch if you want to write or produce something for the blog or website (matt@urbit.org).
652−
653−8 – Odds and Ends
654−
655−~sipsen-pilser has released ~home-urbit, a one-stop shop for getting Urbit up and running on a home system (https://github.com/OdysLam/home-urbit).
656−
657−Jake Miller (~littel-wolfur) has successfully migrated his parents and fiancée onto Urbit. Click here for an Urbit-exclusive peek into the family life of the Millers. Hi Mr. and Mrs. Miller! (https://bit.ly/35qugfK)(https://bit.ly/3wt2ZFm)
658−
659−Thanks for reading. More updates next month!
660−
661−Matt (~tirwyd-sarmes)
662−
663−https://twitter.com/urbit
664−https://github.com/urbit/urbit
665−]]></content:encoded>
666− </item>
667− <item>
668− <title><![CDATA[A Topiary: Hypertext and Urbit]]></title>
669− <link>https://urbit.org/blog/a-topiary</link>
670− <guid>https://urbit.org/blog/a-topiary</guid>
671− <pubDate>Sun, 13 Jun 2021 00:00:00 GMT</pubDate>
672− <content:encoded><
674−
675−> Under the trees of England I meditated on this lost and perhaps mythical labyrinth. I imagined it untouched and perfect on the secret summit of some mountain; I imagined it drowned under rice paddies or beneath the sea; I imagined it infinite, made not only of eight-sided pavilions and of twisting paths but also of rivers, provinces and kingdoms... I thought of a maze of mazes, of a sinuous, ever growing maze which would take in both past and future and would somehow involve the stars.
676−
677−-- _The Garden of Forking Paths_, Jorge Luis Borges
678−
679−The pre-technological world was already [networked](https://en.wikipedia.org/wiki/Indra%27s_net). No material object and no idea has ever stood alone—"no man is an island". Language itself is a network of associations shared between a group of people. The question of technology is: how do we bring our web of associations into the realm of computers? The legacy internet has focused on social networks almost exclusively—our mammalian brains readily took to this, we all love to [signal](https://conversationswithtyler.com/episodes/robin-hanson/). But before “social media” there was something called hypertext: a seemingly modest way to connect documents shared between computers.
680−
681−A footnote in a book used to require a library, locating the referenced book, and finding the cited page (which might have footnotes itself)! Hypertext allows one to traverse a network quickly and easily with just mouse clicks, making information accessible to those without the time and resources to hunt down physical artifacts. Urbit’s “%graph-store” is not the same as hypertext but it does bear some familial resemblances. Fundamentally, %graph-store is a data structure that can accommodate disparate data types within a single edifice. It is based on [graph databases](https://en.wikipedia.org/wiki/Graph_database) and recent implementations such as [GraphQL](https://graphql.org/). To understand this data structure it is worth diving into the origins of hypertext—the original linked network.
682−
683−The story of hypertext begins at the end of WWII with an article in _The Atlantic_ that proposed to extend the human mind via machine. Vannevar Bush had seen first-hand the explosion of electronics manufacturing and scientific knowledge, recognizing the great peril and opportunity of such a revolution. His [description](https://www.theatlantic.com/magazine/archive/1945/07/as-we-may-think/303881/) of the Memex presaged the technological world of today, envisioning a personal device that would allow the user to draw upon a vast library of information, and link documents together arbitrarily—what he called "associative indexing"—a deliberate recreation of how the mind connects thoughts.
684−
685−The 1960s saw the first implementations of these ideas. Ted Nelson's [writing](https://archive.org/details/SelectedPapers1977/page/n15/mode/2up) around _Project Xanadu_ elaborated this linking between documents into what Nelson called _hypertext_. Nelson imagined "a text arranged in a graph structure", centered around a corpus arranged in nonlinear sequence, manipulable by author or audience. The concept was first demonstrated in 1968, at Douglas Engelbart's 'Mother of all Demos', where a vision of computers as a collaborative social environment was revealed to the world. "[The Journal](https://www.dougengelbart.org/content/view/137/#7)", presented alongside other revolutionary demos, exhibited collaboratively edited documents with hyperlinked connections. Any time-travellers in the audience would have immediately recognized the first webpage. From here, the idea of a linked network of documents would be developed through successive phases of computing, from the mainframe to the PC.
686−
687−Experimentation with these ideas continued through the 1970s and 80s. A team directed by Andy Lippman at MIT extended the concept to threaded visual hypermedia with the _Aspen Movie Map_, a user-directed virtual tour of Aspen, Colorado. Hypertext and hypermedia gained a mass audience for the first time with HyperCard, a program that shipped with Mac computers. Users were able to collect or create '[stacks](https://archive.org/details/hypercardstacks)' of interlinked cards; a personal body of text, art, and knowledge could be accrued and modified, or shared with others—though not yet with native networking capabilities.
688−
689−With the World Wide Web, hypertext achieved escape velocity. Initially a one-man [project](http://info.cern.ch/hypertext/WWW/TheProject.html), the world wide web was similar to Bush’s vision of the Memex—a way to share, index, and connect information between individuals and groups. The web succeeded by utilizing the physical infrastructure already available: PCs with graphical interfaces, DNS, and the internet. Critically, its method of transmitting and traversing texts was a standardized protocol, allowing a free body of information to assemble atop the new infrastructure by anyone willing to learn the tools. A new frontier was cleared and cultivated with open standards, but it would gradually face enclosure.
690−
691−In the following decade, after the first wave of social networking sites had crested but before phones became the primary web clients, Twitter was launched. Originally an awkward bridge between SMS and the web, its design eventually coalesced around static identity, posts with chronological sorting, and interlinked post threads. These simple primitives spawned a vast corpus of information, a graph-of-graphs intertwined and overlapped, mapping an entire platonic world. Twitter is fundamentally constrained by its very nature: it is the walled garden of an advertising company. The financial incentives of the server operators demanded seizure of the commons and the replacement of standardized protocols with proprietary databases.
692−
693−As the first networked services withered, a new critique was implicitly articulated in the construction of a [new kind of abstract machine](https://moronlab.blogspot.com/2010/01/urbit-functional-programming-from.html). Urbit learned from the past: tightly defined protocols, baked-in cryptography, and decentralization were key. If power over the network was determined by those who ran the servers, then we would run the servers ourselves.
694−
695−Urbit is not fundamentally a hypertext system; it is a new kind of computer, designed to participate in a peer-to-peer network that rejects the client-server model. All Urbit software takes its networking model for granted, it is not an ad-hoc layering of mismatched abstractions. Fundamental design decisions determine the trajectory of the future.
696−
697−Early [implementations](https://en.wikipedia.org/wiki/Neo4j) of graph databases and projects like [RDF](https://en.wikipedia.org/wiki/Resource_Description_Framework) hit on the same core idea: linked data needs its own data structure. In 2020 Urbit OS adopted an application called %graph-store that made use of a new, native [data structure](https://docs.google.com/document/d/1-Gwfg442kV3cdfG7NnWPEf2TMa3uLUTAKkZD70ALZkE/edit) which would act as a database service for social applications. Chats, long-form text, and other types of data produced in the course of social computing now share the same tent, a single structure extensible to new types of content. Each item added to it is a node in a personal graph—a tree that grows branches as your computer communicates. These nodes can be linked arbitrarily to other graphs—Urbit's global immutable namespace grants both permanence and ownership and allows the graph’s branches to intertwine with others. Graphs can accommodate a variety of content, from simple text, to code and media yet to be conceived. You own your graph, and it is a record of your digital journey with others.
698−
699−Personal hypertext graphs are leaving behind proprietary platforms and gaining independence. Graphs until now have been used as tools of surveillance and marketing, but they are being reclaimed and sewn back into the network, each bound to the cryptographic identity of an individual, permanent computer. Where the map of your life was once splintered across a thousand systems and held in the custody of strangers, it is now possessed only by you and shared only as you see fit. On Urbit, an infinite forest of digital lives can take root, nesting their boughs and stalks.
700−]]></content:encoded>
701− </item>
702− <item>
703− <title><![CDATA[Azimuth’s First Contract Upgrade]]></title>
704− <link>https://urbit.org/blog/first-contract</link>
705− <guid>https://urbit.org/blog/first-contract</guid>
706− <pubDate>Fri, 04 Jun 2021 00:00:00 GMT</pubDate>
707− <content:encoded><
711−
712−<br>
713−
714−Recently, the [first upgrade](https://github.com/urbit/azimuth/pull/35) to the
715−[Azimuth](/docs/glossary/azimuth) smart contracts which make up Urbit ID was
716−put up to an [upgrade proposal vote](/docs/glossary/upgrade) by the
717−[Galactic Senate](/docs/glossary/senate). This vote is still open and will
718−last for 30 days (June 20th) or until an absolute majority is reached. We’d like
719−to take this opportunity to discuss two things. [First](#changelist), what the
720−proposed changes are, and [second](#senate), a review of how Urbit governance
721−works and where we’re at in the decentralization process.
722−
723−Before we dive into what the proposed changes are, let’s review what the Senate
724−is actually capable of changing. Urbit ID is really two sets of smart contracts:
725−Azimuth and [Ecliptic](/docs/glossary/ecliptic). Azimuth is the data of the
726−public key infrastructure - roughly, this is the list of
727−[ships](/docs/glossary/ship) and which Ethereum addresses own them, along
728−with other data such as networking keys and sponsorship status. The Senate has
729−no ability to touch this data directly. This is in direct contrast to all
730−existing centralized services, where your account is always at risk of being
731−taken away from you. What the Senate can change is Ecliptic, which is the
732−“business logic” that decides how you can interact with the data in Azimuth.
733−These are mechanisms such as what powers various
734−[proxies](/docs/glossary/proxies) have, how stars/planets are released over
735−time, and how sponsorship works. Put another way, the data and database format
736−must remain the same, but the rules by which we interact with it may change
737−according to the governance rules we [detail below](#senate).
738−
739−## Changelist {#changelist}
740−
741−The Galactic Senate is voting on the following changes to Ecliptic:
742−
743−- Fixed ERC721 compatibility
744−- Self-modifying proxies
745−- Upgraded Claims contract
746−
747−### Fixed ERC721 compatibility
748−
749−In Ecliptic, the contract includes various functions and events
750−that make it conform to the ERC721 (non-fungible token) standard. However, two
751−events have [ever so slightly
752−non-confirming](https://github.com/urbit/azimuth/issues/8) descriptions. This
753−causes Ethereum explorers like Etherscan to incorrectly recognize Azimuth as
754−ERC20 (fungible token), rather than ERC721.
755−
756−The proposed change simply modifies the event descriptions to accurately match
757−the ERC721 definition. This does not affect any functionality within the
758−contract itself.
759−
760−### Self-modifying proxies
761−
762−Owners of Azimuth assets are allowed to configure "proxy addresses" for those
763−assets: Ethereum addresses allowed to act "as" the owner, but only for a subset
764−of operations. For example, setting the management proxy will let you change
765−your networking keys and sponsor using that address, just like your ownership
766−address can. This is useful for keeping the ownership keys in very cold storage
767−while still letting you perform lower-value operations.
768−
769−Currently, only the ownership address is allowed to change proxy addresses.
770−Fairly early on after Azimuth's deployment, we realized it might be nice for
771−proxies to be able to change themselves.
772−
773−This means that, in addition to being able to configure networking keys and
774−sponsorship, your management proxy would be able to assign a new management
775−proxy. This would allow you, or a trusted third party holding your management proxy,
776−to rotate your proxy keys without needing to take your ownership keys out of cold
777−storage.
778−
779−### Upgraded Claims contract
780−
781−[The Claims
782−contract](https://github.com/urbit/azimuth/blob/master/contracts/Claims.sol)
783−lets asset managers associate various "claims" with their identity. For
784−example, an Ethereum address to send donations to, or proving ownership of a
785−Twitter account.
786−
787−For ease of use by off-chain tools and services, the contract emits events
788−(notifications) whenever any claims are updated. However, the current version of
789−the contract has a bug where it does not emit events when all claims are removed
790−at once (clearClaims()). This "gap" in the event stream makes it much more
791−difficult to write off-chain tools around this contract. Considering Claims has
792−seen [practically no
793−use](https://etherscan.io/address/0xe7e7f69b34d7d9bd8d61fb22c33b22708947971a#events)
794−since it was first deployed, it should not be a problem to simply start over
795−fresh with a new contract that contains [the
796−fix](https://github.com/urbit/azimuth/pull/32) for the described bug.
797−
798−The reason we must do an Ecliptic upgrade to switch to a new Claims contract, is
799−that it is tied in with the logic for transferring an asset. If an asset is
800−flagged for "reset" (common when transferring to/from someone other than
801−yourself), its configured proxies, networking keys and claims are cleared during
802−transfer. As such, Ecliptic will need to know about the address of the new
803−Claims contract.
804−
805−## Urbit Governance {#senate}
806−
807−
808−
809−The ultimate goal of Urbit is to become a digital republic manifested as a peer
810−to peer network owned and controlled by its users. The goal of Tlon, then, is to
811−become one of many companies who build products for Urbit rather than being the primary
812−driving force behind its development. We’d like to take this opportunity to
813−spell out our perspective on where we’re at in that process. Here are some previous posts that are relevant, but please note that
814−some of them are several years old and as such may not accurately reflect our
815−current position, but still serve as useful historical markers. We hope to
816−revisit and refresh these documents soon.
817−
818−- [2016.5.16 - Interim
819− Constitution](/blog/interim-constitution)
820−- [2016.5.16 - The
821− Urbit Address Space](/blog/the-urbit-address-space)
822−- [2016.6.24 - The DAO as a Lesson in Decentralized
823− Governance](/blog/the-dao-as-a-lesson-in-decentralized-governance)
824−- [2019.1.11 - Governance of
825− urbit.org](/blog/governance-of-urbit)
826−
827−### Galactic Senate
828−
829−The Galactic Senate is composed of all [galaxy](/docs/glossary/galaxy)
830−holders, which at present consists of more than 100 individuals and a few
831−organizations, including Tlon and the Urbit Foundation. Using the Azimuth
832−voting contract, the Senate can present and vote on two kinds of proposals:
833−[document proposals](/docs/glossary/docvote) and [upgrade
834−proposals](/docs/glossary/upgrade). Thus far, all matters which the Senate
835−has voted on have been document proposals. The [most recent
836−vote](https://github.com/urbit/azimuth/pull/34) declared the Urbit network as
837−(i) being secure (as confirmed by a [third party
838−audit](/blog/security-audit)) and (ii) having reached continuity (as in, no
839−further [network breaches](/docs/glossary/breach) are expected). Previous votes
840−were to declare that [Azimuth is live](https://github.com/urbit/azimuth/pull/25)
841−and that [Arvo is stable](https://github.com/urbit/azimuth/pull/24).
842−
843−### Address space distribution
844−
845−Perhaps the most informative measure of how decentralized Urbit is in terms of
846−how many independent parties hold address space. By the very nature of Urbit, it
847−is impossible to know this with great accuracy (a common feature of
848−decentralized projects). However, the movement of galaxies is closely watched
849−and thus we have a fairly good idea of how distributed they are.
850−
851−In the beginning, Urbit’s creator Curtis Yarvin was in possession of the entire
852−address space - all 256 galaxies, and everything underneath it. A network of one
853−is no network at all, and so over the last decade Urbit’s development has been
854−primarily driven by selling or giving away these galaxies. On [June 1,
855−2016](/blog/the-urbit-address-space), the allocation was:
856−
857−> 95, to the Tlon Corporation. 50, to urbit.org, the future community
858−> foundation. 40, to Tlon employees and their family members (24 to Curtis, who
859−> started in 2002; 16 to everyone else, who started in 2014). 34, to outside
860−> investors in Tlon. 37, to 33 other individuals, who donated to the project,
861−> contributed code or services, won a contest, or were just in the right place
862−> at the right time.
863−
864−Since then, Tlon has sold a number of
865−its galaxies to fund development and others have changed hands to the point
866−that Tlon and urbit.org no longer possess a majority share of galaxies. In
867−January 2019, [Curtis gave all of his galaxies](/blog/a-founders-farewell) to
868−Tlon when he left the project. In August 2020 we shared an update on the [known
869−distribution of address space](/blog/value-of-address-space-pt3), where
870−Curtis’ galaxies are marked as Tlon’s “naked galaxies”. Shortly thereafter, Tlon
871−disbursed its naked galaxies among the employees that wanted one who did not
872−already possess one, thus removing Tlon and urbit.org’s controlling share of the
873−Senate. Galaxies held by current and former Tlon employees are entirely
874−independent of Tlon Corporation—they may do with them, and vote with them, as
875−they please. `~ravmel-ropdyl` plans to give more color to this decision in the
876−near future.
877−
878−Distribution of stars is much more difficult to know. There is an active market
879−for stars on [OpenSea](https://opensea.io/collection/urbit-id), so we know that
880−they are changing hands frequently, but checking the number of distinct Ethereum
881−addresses that hold stars does not tell you very much information since a single person can control multiple adresses.
882−
883−### Software and smart contracts
884−
885−As was written in [The DAO as a Lesson in Decentralized
886−Governance](https://urbit.org/blog/the-dao-as-a-lesson-in-decentralized-governance/),
887−we are keenly aware of the threat of _decentralization theater_. Urbit has
888−undergone steady progress towards decentralization, and with the developments we
889−outline below, it’s never been more clear that the project is beginning to leave
890−the cradle of Tlon. It’s also important to note that the decentralization of a
891−project is always a movement away from an initial centralized state—you cannot
892−go from A to Z without first traversing every letter in between. While Urbit was
893−centralized at the beginning, the journey towards a network owned and
894−controlled by the users is now well underway.
895−
896−In the past, nearly all Urbit software was written by Tlon. While Tlon is still
897−the only corporation actively updating Urbit’s MIT-licensed open source
898−software, namely [Vere](/docs/glossary/vere) (the runtime),
899−[Arvo](/docs/glossary/arvo) (the kernel),
900−[Landscape](/docs/glossary/landscape) (the client), and
901−[Bridge](/docs/glossary/bridge) (the ID manager), unaffiliated individuals have been making enormous contributions to Urbit over the past couple of years via the [grants program](https://grants.urbit.org/history). Recent examples include the [Bitcoin node and wallet integration](https://github.com/urbit/urbit/pull/4940), [WebRTC integration](https://grants.urbit.org/proposals/21131866-webrtc-gall-agent-and-external-app), [Port, an Urbit installer and ship manager](https://github.com/arthyn/port), and [`|fuse`, an important primitive for 3rd party software distribution](https://github.com/urbit/urbit/pull/4820).
902−
903−The only real power Tlon holds over Urbit is the ability to push [OTA
904−updates](/docs/glossary/ota-updates) via `~zod`, and suggest that people
905−download our binaries. To the best of our knowledge, all extant galaxies
906−retrieve their OTA updates from `~zod`, who forward it to their stars, who
907−forward it to their planets. This software distribution route is merely a
908−convenient default setting. Ships initially retrieve OTA updates from their
909−sponsor, but they have full authority to retrieve updates from whoever they want
910−with the `|ota` command, or even to only install software updates by hand if
911−they so choose.
912−
913−In the future, one can easily imagine many organizations shipping their own
914−distributions of Urbit from their own urbit nodes, somewhat analogously to the
915−large number of Linux distributions which exist today. There is nothing we can
916−do to stop a group from forking Urbit, declaring `~sampel-palnet` the new `~zod`
917−(both for updates and for sponsorship purposes), and retrieving all OTA updates
918−via that route and building their own binaries. This is all by design, and we
919−wouldn’t want it any other way.
920−
921−The use of the Azimuth smart contracts is also somewhat optional. By changing a
922−few lines of code to point their ships at another set of PKI smart contracts,
923−they could rid themselves of hierarchical peer discovery entirely and make use
924−of some other routing strategy such as [Kademlia based DHT
925−routing](https://en.wikipedia.org/wiki/Kademlia). This would likely give rise to
926−an entirely separate network. The fact that the network is fully capable of such
927−a schism helps keep the Senate honest and accountable to the users. If they ever
928−were to vote on a contract modification that greatly angered or upset a portion
929−of the user base, they would be inviting such a schism and be entirely deserving
930−of it. In that sense, the power to control the network is already held by the
931−users, they just have not yet had a reason to make use of it.
932−
933−### Legitimacy
934−
935−The only way by which Tlon and the Senate hold any power is via legitimacy.
936−Vitalik Buterin recently wrote a [very informative
937−article](https://vitalik.ca/general/2021/03/23/legitimacy.html) on the role of
938−legitimacy in decentralized governance, and I do not know of a better source to
939−understand how Tlon and the Senate are kept in check by the users. Besides the
940−DAO split resulting in Ethereum and Ethereum Classic mentioned in the article,
941−perhaps the most prominent example of the power users have over a decentralized
942−network is the saga of [Steem and Justin
943−Sun](https://www.coindesk.com/justin-sun-bought-steemit-steem-moved-to-limit-his-power).
944−The short version of the story is that Justin Sun bought a controlling share of
945−the Steem blockchain and attempted to exert control over it, and the users
946−banded together to fork the blockchain into one called Hive, which was identical
947−to Steem except with Sun’s token balance set to zero. An analogous outcome for
948−Urbit would be that the Senate makes sweeping changes to the PKI and invites a
949−schism like that outlined above.
950−
951−For these reasons, there are strong disincentives for any one organization or
952−individual to acquire too many galaxies. If galaxy ownership becomes more centralized, individuals will be less incentivized to build on the network which will reduce the value of address space. Furthermore, such centralization might provoke a fork if such centralized powers are perceived as malicious by the users. This is in contrast to real-life republics, where there is little risk
953−for one party to accumulate as much power as they can manage since the cost to
954−the citizens to overthrow that power is enormous. Thus, only especially
955−egregious displays of power ever result in rebellion. Within the Urbit republic,
956−users need only to change the code they run to leave the Senate powerless, and
957−so the threat of rebellion is much more real. We estimate that within a digital
958−republic like Urbit, the centrifugal forces outweigh the centripetal forces, and
959−that the outcome of this is more stable than the reverse.
960−
961−### Why have governance at all?
962−
963−An important question the reader may still have lingering is: why does Urbit
964−need governance at all? The short answer is: (i) there will always be necessary
965−protocol upgrades that cannot be foreseen, and (ii) a total lack of governance
966−inevitably gives rise to a shadow government with undefined powers that is
967−almost impossible to hold accountable.
968−
969−With (ii), we see this to be the case on many early blockchain projects where
970−power is shared by the developers and the miners, but what each is capable of
971−doing has never been codified, and thus users of the blockchain can never have a
972−great deal of certainty of what changes might occur in the future. This doesn’t
973−guarantee a bad outcome, but it does create more wariness among developers when they cannot know whether they really have a say in
974−the project's direction. Recognizing this issue, many newer blockchain and
975−blockchain-adjacent projects have built-in governance mechanisms that lay out
976−exactly what an individual can expect should they join and contribute to that
977−network.
978−
979−As for (i), with Urbit being a wholly new kind of network, it would take
980−incredible luck to get the PKI exactly right on the very
981−first try without ever needing another modification. Thus, some mechanism was
982−needed to guarantee that the PKI’s logic could be altered. Leaving control of
983−Azimuth in the hands of Tlon would have just granted Tlon dictatorial power, which Tlon nor Urbit users desired. There’s certainly
984−room to argue that the Galactic Senate is not a perfect system: our interim
985−constitution did outline potential roles for stars and planets to play in
986−governance in the future, so there is ample opportunity for the system to evolve
987−in response to the will of the users. As always, it is important to keep in mind
988−the unfinished nature of the Urbit of today and the still moldable clay of the
989−Urbit of tomorrow—nothing yet is set in stone.
990−]]></content:encoded>
991− </item>
992− <item>
993− <title><![CDATA[The Gang Solves the Gas Crisis]]></title>
994− <link>https://urbit.org/blog/rollups</link>
995− <guid>https://urbit.org/blog/rollups</guid>
996− <pubDate>Thu, 13 May 2021 00:00:00 GMT</pubDate>
997− <content:encoded><
999−
1000−Anybody who has used Ethereum smart contracts recently is aware that it has
1001−gotten _expensive_. There are a large quantity of
1002−complicated and clever techniques each with their own trade-offs
1003−that are collectively referred to as "layer 2 solutions" (see [further
1004−resources](#resources) for more information about these). This is in contrast to
1005−the base computational layer of Ethereum called "layer 1", which is what constitutes most Ethereum usage and where [Urbit ID](/docs/glossary/azimuth)’s smart contracts currently exist.
1006−
1007−Tlon has always covered gas costs for Urbit ID up to a set limit, and this was easy a couple of years ago when the cost of transactions required to get a [planet](/docs/glossary/planet) up and running came out to less than a dollar. Unfortunately the ongoing Ethereum gas crisis, along with the rising price of Ethereum itself, has made this impossible. We’ve seen gas costs to set up a planet as high as several hundred US dollars at time of writing!
1008−
1009−In response to the gas crisis, Tlon has spent the last several months developing
1010−a simple, in-house layer 2 solution which we anticipate will reduce typical gas costs by 65x or more.
1011−
1012−This post is primarily a short non-technical explainer of the end-user experience of our solution aimed at planet and [star](/docs/glossary/star) owners and those in the market for one, as well as a status update on where we're at in development. At [the end](#technical) we give some minimal technical details and resources to help you dig deeper should you wish.
1013−This is also primarily aimed at those who currently self-host or plan to self-host their
1014−urbit. For anybody utilizing a hosted service, this matter will all be handled
1015−by your provider. There is a [separate section](#stars) addressed specifically at star owners, and another [section](#rollers) for those who wish to set up their urbit to accept and submit layer 2 transactions. We’d like to emphasize that this system is 100% opt-in—if you are satisfied with the current experience of Urbit ID, then nothing changes for you whatsoever.
1016−
1017−Perhaps the most pressing question held by anybody reading this is—when will
1018−it be ready? It's not reasonable to give a timeline on difficult engineering
1019−work, but rest assured that completing this upgrade is a top priority. Much
1020−of the back-end is approaching completion, and we are confident in a release before the end of Q3 and hopefully much sooner.
1021−
1022−### Naive rollups
1023−
1024−Our layer 2 solution, designed primarily by Tlon lead engineer `~wicdev-wisryt`,
1025−is known as "naive rollups" and we will be using this term interchangeably with
1026−"layer 2"—though it is important to note that there are many layer 2 solutions
1027−utilized by projects other than Urbit. As we're avoiding technicality here, we’re focusing primarily on the advantages and disadvantages of utilizing our layer 2 solution, and how that affects the management of your [ship](/docs/glossary/ship).
1028−
1029−Very briefly, a rollup is a way to combine many transactions into one, and we
1030−are building infrastructure so that any Urbit ship may be utilized as a "roller". A
1031−roller will collect layer 2 Urbit ID transactions, confirm their validity, and
1032−post them to the Ethereum blockchain. More detail is given [at the end](#technical). Anybody may set up a
1033−ship to [act as a roller](#rollers). Tlon will be launching our own publicly accessible roller, but as Urbit is a decentralized network, by no means will we have a monopoly.
1034−
1035−#### Pros and cons
1036−
1037−The primary advantage to using naive rollups is that the gas cost for Urbit
1038−ID-related actions will be dramatically reduced. It will be reduced sufficiently that we expect that a few transactions per ship per week (plenty for ordinary usage) submitted to Tlon's roller will not cost the end user anything. There are no gas costs associated with submitting a layer 2 transaction to a roller, and Tlon will bear the gas cost of posting the results to the blockchain. That means that the cost you see for a planet on a market that utilizes Tlon's roller ought to be
1039−the final cost.
1040−
1041−There are a few trade-offs for this, but none of them really sacrifice the core
1042−value propositions of Urbit ID.
1043−
1044−The most substantial one is that ships on layer 2 are essentially completely isolated
1045−from the rest of the Ethereum ecosystem. They can no longer interact with smart
1046−contracts designed to work with Urbit ID or non-fungible tokens (which are how Urbit IDs are represented) in general. It is also not possible to write new Ethereum smart contracts that work with layer 2 ships.
1047−
1048−Compounding that factor, the journey to layer 2 is one-way only—at
1049−least for now. There are theoretical ways a ship may be moved back to layer 1, but they do not yet exist, and we cannot promise that such a thing will be available in a timely manner. Anybody moving a ship to layer 2, or buying a ship on layer 2, should assume that they will
1050−remain on layer 2 for the foreseeable future. We do not expect this to be
1051−permanent, but it is perhaps the most significant drawback for the time being.
1052−
1053−Another one is that transactions may no longer be "instant". Effectively, this
1054−was already the case on layer 1—unless you paid a lot of gas, you could wait
1055−hours or even days for your transaction to clear. But the way we are saving on
1056−gas is essentially by "bundling" or "rolling up" many transactions into one, and
1057−submitting them as a single transaction. The more transactions in the rollup,
1058−the better the savings. This bundling is not the only factor at play here
1059−though—costs are reduced other ways, but this is a technical detail
1060−[discussed later in this post](#technical). It is possible to use layer 2 to submit single
1061−transactions (and this will still save on gas costs!), so utilization of layer 2
1062−should not incur any delay over layer 1 when utilized in this fashion.
1063−
1064−Tlon has not finalized the details on how our roller will work, but it will
1065−probably involve waiting until a sufficient backlog of transactions have been
1066−submitted to make it economical to bundle them up, or just submitting every set
1067−time period, whichever arrives first. We do not see this as a big issue—we
1068−view Urbit ID as "digital land", and a few hours to acquire land, or waiting for
1069−your new personal computer to be delivered, is still lightning fast in
1070−comparison to the real world. We also have ideas on methods that will allow you to get on the network before the transfer has been confirmed, but that is outside of the scope of this article.
1071−
1072−Our layer 2 preserves the main value proposition of Urbit ID, which is that your ship
1073−belongs to you forever, and that this is assured by very strong cryptographic methods and
1074−game-theoretic arguments comparable to the ones that exist on layer 1. We
1075−consider this principle to be uncompromisable, and maintaining ultimate
1076−sovereignty over your ship was totally central in choosing our solution.
1077−We summarize the new security model [below](#technical), and `~wicdev-wisryt`
1078−goes into greater detail in the [resources](#resources).
1079−
1080−### Changes to User Experience
1081−
1082−The primary way one manages their Urbit ID, namely performing tasks such as
1083−transferring ships, setting networking keys, or setting
1084−[proxies](/docs/glossary/proxies), is with a web interface called
1085−[Bridge](/docs/glossary/bridge) found at
1086−[bridge.urbit.org](https://bridge.urbit.org). If you already own a planet,
1087−you've probably used Bridge before - perhaps only a single time.
1088−
1089−Bridge will be getting a facelift to enable easy interfacing with layer 2,
1090−including loud warnings about what is being gained and lost by doing so. From
1091−here you will be able to transfer your ship to layer 2, and once there,
1092−perform all the usual actions you can on layer 1.
1093−
1094−The main difference for layer 2 transactions on Bridge will be the additional
1095−choice of a roller to submit transactions to. Tlon's will be free for ordinary, non-time-sensitive usage.
1096−You could use your own ship for a fast single transaction for a little more gas. We expect that planet markets and stars may wish to set up their own rollers as well.
1097−
1098−Every planet has a sponsor star, which distributes [OTA
1099−updates](/docs/glossary/ota-updates) to their sponsored planets and assists with peer discovery. Both layer 1 and layer 2 planets will be able to be
1100−sponsored by either layer 1 or layer 2 stars, meaning that nothing will change
1101−in terms of how sponsorship works.
1102−
1103−When you buy a ship, any reputable seller will inform you whether or not it is
1104−on layer 1 or layer 2. Anyone running an urbit will be able to verify this information, and we expect for tools to exist to make this information publicly available (see [this grant](https://grants.urbit.org/bounties/1101665172-network-explorer-data-pipeline-http-api)).
1105−
1106−And that's it! If you'd like to know how things will be changing for
1107−[stars](#stars), what goes into [setting up a roller](#rollers), and additional
1108−[technical details](#technical), read on.
1109−
1110−### Changes to stars {#stars}
1111−
1112−Both planets and stars will be able to move to layer 2.
1113−[Galaxies](/docs/glossary/galaxy) must remain on layer 1 for technical
1114−reasons, and [moons](/docs/glossary/moon) and
1115−[comets](/docs/glossary/comet) never interacted with Ethereum anyways, so
1116−they are completely out of the picture.
1117−
1118−Stars will be able to remain on layer 1 with no action required. For star owners
1119−that wish to take advantage of the cheaper gas costs, there are two possible
1120−modes: ownership of the star on layer 2, or setting the spawn proxy to layer 2
1121−with ownership remaining on layer 1.
1122−
1123−The first mode—a star which is owned on layer 2—has the same advantages and
1124−disadvantages as a layer 2 planet. Planets spawned by a layer 2 star will also
1125−necessarily be on layer 2 - there is no way to spawn a layer 1 planet from a
1126−layer 2 star, though any planets which were spawned on layer 1 before the
1127−star migrated to layer 2 will remain on layer 1.
1128−
1129−The second mode—ownership on layer 1, with spawn proxy on layer 2—is only slightly more complicated. Such a star will change its networking keys, transfer
1130−between wallets, and set its management proxy all on layer 1, with the
1131−corresponding higher gas cost. However, it will be able to spawn planets on
1132−layer 2—and _only_ on layer 2—with the corresponding layer 2 tradeoffs. Like
1133−moving ownership to layer 2, this will be a one-way journey for now. Planets
1134−spawned before moving the spawn proxy to layer 2 will remain on layer 1, but
1135−from then on, all planets spawned by that star will live on layer 2. Finally, stars in this second mode may transition to the first mode, but not vice versa.
1136−
1137−### Creating a roller {#rollers}
1138−
1139−
1140−
1141−Rollers are urbit nodes which users submit transactions to to be "rolled up"
1142−into a bundle to be submitted to the Ethereum blockchain. The business logic for
1143−a roller runs on the urbit node itself. Thus, anybody with an urbit ship may set
1144−it up to act as a roller. While the details of how rollers work are still being
1145−hammered out, one should expect that one can either set transactions to be
1146−submitted at regular intervals, once a sufficient number of transactions have
1147−been received (as more transactions means greater savings), manually, or some
1148−combination of the above.
1149−
1150−Tlon plans to release documentation on how to set up your own roller concurrently with
1151−the release of our layer 2 solution.
1152−
1153−Malicious rollers could potentially exist, but the worst they ought to be able
1154−to do is simply not submit your transaction. The security factors for rollers
1155−are briefly addressed [below](#technical), and elaborated upon in the
1156−[resources](#resources), but you can expect full technical documentation on
1157−these factors to be included in the roller documentation.
1158−
1159−### Changes to Azimuth
1160−
1161−[Azimuth](/docs/glossary/azimuth) is the set of Ethereum smart contracts
1162−governing Urbit ID. They will require a few changes to accommodate the new
1163−system. Some of this has been implicit above, but to be clear, we will only be
1164−making a couple minor alterations:
1165−
1166−- Once a star's spawn proxy is set to the layer 2 address, it can't be switched
1167− back, and they can no longer spawn layer 1 planets.
1168−- Galaxies and their proxies cannot be deposited to layer 2.
1169− Some other minor details are yet to be worked out, but again, nothing will change for those who wish to remain on layer 1.
1170−
1171−### Technical details {#technical}
1172−
1173−What's really going on behind the scenes here? Briefly, only the data of the Urbit ID transactions will be posted on-chain, while computation and state storage will now happen on your ship.
1174−
1175−In layer 1, the [Ethereum Virtual Machine (EVM)](https://ethereum.org/en/developers/docs/evm/) guarantees the validity of state transitions, while for layer 2 transactions, each Urbit node guarantees the validity of the state transitions.
1176−
1177−Changes to the state of Urbit ID on layer 1 works as follows:
1178−
1179−1. A transaction is posted to the Ethereum blockchain.
1180−2. The EVM calculates the resulting state transition and checks its validity, then updates the state.
1181−3. Your urbit downloads the new state from an Ethereum node.
1182−4. Your urbit makes the final decision on whether the new state is valid.
1183−
1184−In practice, the fourth step is never used in layer 1. The primary change to our
1185−security model is that we are cutting out step 2 and beefing up step 4. Your
1186−ship will now perform validation of the transactions posted to the Ethereum
1187−blockchain, rather than the EVM.
1188−
1189−Since [Urbit OS](/docs/glossary/arvo) is deterministic, and Hoon has some nice formal
1190−properties, it turns out to be a great language for writing smart contracts. Thus we are effectively swapping the Ethereum smart contract with a “Hoon smart contract” run locally on your ship.
1191−
1192−#### Further Resources {#resources}
1193−
1194−We want to keep this post brief and non-technical, so that's all we'll say about
1195−it for now. To find out more, you have a few directions to go on. We held a
1196−[Developer Call](/events/2021-03-04-developer-call-scaling-azimuth) where
1197−`~wicdev-wisryt` outlines the design in much more technical detail, and also
1198−explains why we decided to utilize our own design rather than other known layer
1199−2 solutions such as [Optimistic
1200−rollups](https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/optimistic_rollups/),
1201−[ZK-rollups](https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/zk-rollups/),
1202−etc, or other blockchains. He also plans to do a more technical walkthrough video sometime before release. For those who would rather read, see
1203−`~wicdev-wisryt`'s [RFC: Naive rollup for cheaper Urbit ID
1204−transactions](https://groups.google.com/a/urbit.org/g/dev/c/p6rP_WsxLS0/m/hQBX0modAwAJ)
1205−post on the `urbit-dev` mailing list. Lastly, the primary working branch on
1206−Github for the Urbit side of naive rollups is
1207−[here](https://github.com/urbit/urbit/tree/philip/naive), though it is not the
1208−only place code is accumulating.
1209−]]></content:encoded>
1210− </item>
1211− <item>
1212− <title><![CDATA[A brief update from urbit.org]]></title>
1213− <link>https://urbit.org/updates/2021-05-05-update</link>
1214− <guid>https://urbit.org/updates/2021-05-05-update</guid>
1215− <pubDate>Tue, 04 May 2021 00:00:00 GMT</pubDate>
1216− <content:encoded><![CDATA[
1217−Hello!
1218−
1219−Welcome to the May edition of the urbit.org newsletter. April was a busy month with many updates to share—let’s dig in.
1220−
1221−0 – Updated Urbit Binaries
1222−
1223−Urbit’s binaries were updated to v1.5 on April 27th. Make sure to download and install the latest v1.5 binaries here: https://github.com/urbit/urbit/releases/tag/urbit-v1.5
1224−
1225−It’s as easy as shutting down your ship and replacing the old binaries! ~pilfer-pandex described the new release to urbit-dev as “a high priority fix for two networking bugs in urbit-king, and minor fixes to vere.”
1226−
1227−1 – Upcoming Events
1228−
1229−Urbit Town Hall @ May 20th 12pm PDT – Keynote from Justin Murphy
1230−This will be Urbit’s first ever town hall—a three hour event with talks on a variety of topics and a keynote from Justin Murphy (~hatryx-lastud). Justin had Urbit Foundation Director Josh Lehman on his Other Life podcast a few weeks ago (have a listen at https://share.transistor.fm/s/1c0c8c15) and recently formed a new group on Urbit (~hatryx-lastud/other-life).
1231−
1232−In his group, Justin has written a blog post called “Escape Velocity”, where he discusses selection effects on various platforms. Justin writes, “by creating a gravity well that sucks energy into real-estate value rather than monetized attention, Urbit exerts the lowest degree of arbitrary selection pressures on content creation, while optimizing those selection pressures that irreducibly characterize all human communication (e.g., the draw of being understood and appreciated by other people).” Tune in to Justin’s keynote on the 20th for more on Urbit as a platform for creatives.
1233−
1234−Developer Calls @ May 13th and May 27th
1235−As you probably know, we have developer calls every two weeks. Stay tuned for more information on our events page: https://urbit.org/events
1236−
1237−Austin Urbit Conference @ September/October 2021
1238−Although it’s too early to give a precise date, we are starting to plan an Urbit conference for this fall! It’ll be held in Austin, with many Urbit and Tlon employees in attendance. Stay tuned for more information!
1239−
1240−2 – April Developer Calls
1241−
1242−Developer Call: 3rd Party Software Distribution
1243−In this talk, Phil (~wicdev-wisryt) and Raghu (~sovmep-ripsum) discussed the work they've been doing to clay to provide "virtual desks", an integral part of the infrastructure needed for safe, generic software distribution. This work is being done through our Scholarships program, in which community developers pair up with Tlon engineers to work on infrastructure projects. For more information about Scholarships, visit https://urbit.org/docs/development/grants/#scholarships
1244−
1245−Developer Call: Real-Time Communication on Urbit
1246−Edward Amsden (~ritpub-sipsyl) gave us a look at the WebRTC Airlock library he has developed that handles the hard parts of WebRTC. When complete, this will allow developers to build applications on Urbit with audio/video calling capabilities. Once again, Edward’s work is sponsored as part of the grants program (https://grants.urbit.org)—check it out!
1247−
1248−3 – Urbit Bitcoin Launch
1249−
1250−This was a hotly anticipated event and it didn’t disappoint. In case you missed it, Urbit will soon have a Bitcoin wallet on the network, meaning you’ll be able to pay Urbit ships directly in BTC. Watch Urbit-Tlon personnel demonstrate and discuss this exciting launch: https://www.youtube.com/watch?v=_aRnfacZPto
1251−
1252−Make sure to check out this related blog post by Christian Langalis (~pindet-timmut): https://urbit.org/blog/interplanetary-commerce/ and this great interview with ~timluc-miptev, one of the main developers on the project: https://subject.network/posts/bitcoin-with-timluc-miptev
1253−
1254−4 – Blog
1255−
1256−We have a couple of new posts to announce:
1257−“Lunar Urbit and the Internet of Things”
1258−This post is by Poprox (~datnut-pollen), a Tlon engineer who focuses on the importance of moons in the Urbit ecosystem. The post covers “the prehistory of moons on Earth, gives a snapshot of how moons are being utilized on Urbit in 2021, covers existing issues with consumer IoT and how Urbit resolves them, and speculates what the lunar locus of the Urbit ID address space may become in the future”. Read it here: https://urbit.org/blog/iot/
1259−
1260−“Community Spotlight: The Portico”
1261−This post is an interview between me (~tirwyd-sarmes) and Josh Reagan (~taglux-nidsep), the founder of “The Portico”, an Orthodox Christian community. Josh has a PhD in logic, and writes about the intersection of Christianity and logic on his Urbit blog. In the interview we talk about community norms, the relationship between logic and religion, and the future of Urbit. Check out the interview: https://urbit.org/blog/community-spotlight-the-portico
1262−
1263−5 – Odds and Ends
1264−
1265−If you are a star or galaxy owner and are interested in sponsoring other ships, please message ~rapfyr-diglyt (david@tlon.io) to be added to the sponsors@urbit.org mailing list.
1266−
1267−~hodzod-walrus made a page with statistics on various stars: https://bacrys.org/uptime/
1268−
1269−~sitful-hatred beat us to the punch and released a guide on compiling Windows binaries—urbit.exe is near at hand! See the guide here: https://subject.network/posts/urbit-windows-binaries/ The official Urbit.org announcement should be around the corner, so keep your eyes peeled.
1270−
1271−Thanks for reading. Talk to you next month!
1272−
1273−Josh (~wolref-podlex) and ~tirwyd-sarmes
1274−
1275−https://twitter.com/urbit
1276−https://github.com/urbit/urbit
1277−]]></content:encoded>
1278− </item>
1279− <item>
1280− <title><![CDATA[Community Spotlight: The Portico]]></title>
1281− <link>https://urbit.org/blog/community-spotlight-the-portico</link>
1282− <guid>https://urbit.org/blog/community-spotlight-the-portico</guid>
1283− <pubDate>Mon, 03 May 2021 00:00:00 GMT</pubDate>
1284− <content:encoded><
1286−
1287−_One of the most striking things about Urbit is the ideological diversity between communities. The Community Spotlight blog series will focus on various Urbit communities via interviews with founding members._
1288−
1289−For the first week of the Community Spotlight series, I (~tirwyd-sarmes) will be speaking with Josh Reagan (~taglux-nidsep). Josh is the founder of The Portico, an Urbit community of Eastern Orthodox Christians.
1290−
1291−The Portico is a very active group with conversations taking place over multiple channels. There are channels for posting Orthodox iconography, discussing the broader Christian culture war, and just talking about Orthodoxy in general. Of particular interest is Josh’s “Euthyphro” blog series which investigates the relationship between logic and the Orthodox faith. This is a topic that Josh is well qualified to talk about: he has a PhD in Philosophy from Rice University. His dissertation on the epistemology of logic and truth-preservation was titled "Knowing Your Limits: Logic for Limited Beings”. Josh is also the co-author of a forthcoming textbook on formal logic.
1292−
1293−To read Josh’s blog is to be inducted into two esoteric traditions: theory of logic and Orthodox theology. With titles like “St. Gregory the Theologian and the Liar Paradox” and “The Existence of Abstract Objects”, Josh does not pull punches.
1294−
1295−Accordingly, our conversation focused on the idiosyncratic and niche community that The Portico is home to. There, you won’t find cussing or much talk about “life partners”, but you will find cutting critiques of liberalism and the best way to raise Orthodox children.
1296−
1297−As other users have pointed out, Urbit is pre-[Eternal September](https://en.wikipedia.org/wiki/Eternal_September). In fact, there’s some hope that the very nature of Urbit, how it tries to protect the sovereignty of niche communities via decentralization, might foil the Eternal September phenomenon. If Josh’s community persists, it will be a testament to both Josh and the decentralized Urbit network. As of now The Portico is a refreshing, perhaps jarring (as Josh might say), reminder of what the internet looked like back in the early days—a place for those who are different.
1298−
1299−I encourage you to take a look. Find The Portico at ~topnup-firber/the-portico.
1300−
1301−\-\-\-\-
1302−
1303−**Do you see any connection between Rod Dreher’s _The Benedict Option_ and your community on Urbit? Dreher sees a need for American Christians to create self-sustaining communities outside of the mainstream to protect the Christian religion and culture.**
1304−
1305−It’s tough to say with certainty—I’ve never read _The Benedict Option_.
1306−
1307−A few years ago, while he was writing the book, I was a regular reader of Dreher’s blog. From his descriptions there, I was never clear about what exactly he was proposing. Much of his “clarification” came by way of metaphor: don’t “run for the hills”, but stop “shoring up the American imperium”. I didn’t read his book because I didn’t have much confidence that he would be especially precise or insightful.
1308−
1309−[There is an interesting review I’d recommend](https://handleshaus.wordpress.com/2020/10/06/review-of-rod-drehers-live-not-by-lies/), however, of his later book, _Live Not By Lies_. I believe it accurately characterizes the scale of the threat Christians will soon face in this country.
1310−
1311−My upbringing was conservative Christian and self-consciously counter-cultural. I've inherited that understanding of what it means to be a Christian in an increasingly secular world. It comes naturally to me, so I find it obvious that Christians should form self-sustaining communities. But the details matter. What do such communities look like? How do we secure the freedom to pursue such communities? How do we sustain them, when myriad external forces seek to undermine them? How do we solve the long-term problem of the declining cultural importance of Christianity (which surely erodes the plausibility of our religion to many, even to some of those with sympathies toward it)?
1312−
1313−I don’t claim to know the answers to these questions.
1314−
1315−One kind of answer is that we should redouble our efforts to support and maintain a religiously and morally neutral liberal political order, which leaves room for subcultures to live and self-regulate as they wish. I disagree. Those who support a kind of “neutral” liberalism view it as an attempt to go “meta” and rise above various parochial metaphysical, moral, and religious disputes. I view this as a cop-out, a refusal to grapple with the most important questions.
1316−
1317−Does the liberal have metaphysically-rooted moral reasons for going “meta”? If so, then he’s just another sectarian and he should be honest about it. The only difference is that his team has had the whip hand for the last several generations. On the other hand, if the liberal claims no underlying metaphysical justification then his project can succeed only to the extent that he can arrange and adjudicate unprincipled (and therefore ad hoc) agreements between otherwise hostile moral communities. But how stable can such an arrangement really be?
1318−
1319−Orthodox Christians have theologically rich, metaphysical foundations for their social and moral teachings. With these we can form healthy, thriving, and growing communities. We can do so even under actively hostile political orders. If the early Church could make it under the Romans, so can we today. But it’s going to be difficult and sound judgment is necessary. Unfortunately, we lack strong leadership and that leaves us vulnerable. If we stay uncoordinated we dissipate our energies needlessly. If we latch onto the wrong leaders we can be led astray.
1320−
1321−The challenges are immense. There is no technological solution. Even so, I’m an Urbit early-adopter for a reason. Over the years I’ve come into contact with a number of Orthodox and Ortho-curious Urbit followers. Why not try to bring them together in an Urbit group?
1322−
1323−As far as I know, no one in the group is clergy. We’re all just a bunch of laymen with no authority to do much of anything. But I’d like to think we can still contribute in some way. I have an academic background in analytic philosophy so my inclination is to emphasize theory, but we have room for a bit of everything. Someone in the group wrote a script to take the texts of various Church Fathers and convert them to audio using AWS Polly. Those turned out pretty well!
1324−
1325−At times I entertain ambitions to do a bit more, but for now perhaps it’s better to keep expectations in check. If nothing else, we can read and discuss the Scriptures and Church Fathers together, and try to understand better how to apply and live out their teachings. As we continue to grow the community and develop a consistent internal dynamic perhaps opportunities will arise that aren’t yet on the horizon. One thing I can say is that I’m committed to keeping the group active and growing.
1326−
1327−**I’d like to talk about your blog on The Portico. It combines two of your main interests: logic and theology. In broad strokes, do you think theology and logic are compatible? What is the relevance of this intersection to both of these disciplines?**
1328−
1329−I feel obligated to answer this question in two ways.
1330−
1331−(1) If by “logic” you mean “first-order predicate calculus”, then I think there’s no special conflict between logic and theology. There are certain puzzles about their relationship, but similar puzzles exist between logic and other disciplines. Theology isn't especially endangered.
1332−
1333−For example, in the 1930s, Alfred Tarski proved his famous Undefinability Theorem. Crudely put, it says that a plausible truth predicate cannot consistently be contained in any formal system with axioms strong enough to model arithmetic. Superficially it seems like our options are (a) get rid of the concept of truth, (b) get rid of arithmetic, or (c) throw away parts of logic until all inconsistency disappears.
1334−
1335−None of these options is appealing. Tarski came up with a solution that mostly satisfies many logicians: reduce the concept of truth to “truth in a language” and forbid any language from containing its own truth predicate. If you want to talk about truth in a language L-1, you have to do it from a “metalanguage”, L-2.
1336−
1337−Is Tarski’s definition of truth in a language the definitive solution for preserving truth, math, and logic? Perhaps not many philosophers think so, and there’s a massive literature in which logicians have attempted to improve on or extend his results.
1338−
1339−Sometimes people seem to think formal logic is an infallible gift from heaven that must always be right. Kant said in the _Critique of Pure Reason_ that formal logic is essentially a completed field. In fact, [the logic of his day](https://en.wikipedia.org/wiki/Port-Royal_Logic) was an early-modern Cartesian variation of a medieval scholastic synthesis of ancient Stoic and Aristotelian logics. Roughly 100 years after Kant’s first critique was published, C. S. Peirce and Gottlob Frege independently discovered first-order mathematical logic as we know it today, inaugurating the greatest advance of logic since Aristotle. Kant was wrong.
1340−
1341−Mathematical logic is a convenient, generally reliable, man-made tool that, when used carelessly in certain untamed domains, can lead one astray. Probably most people reading this are familiar with such puzzles as the Liar paradox. When one understands that logic is not a completed science, and perhaps never will be, there is less reason to worry about whether it can be used to nuke entire disciplines, like theology.
1342−
1343−For more on this topic, see the blog post in my Urbit group: “St. Gregory the Theologian and the Liar Paradox”.
1344−
1345−(2) There is perhaps a deeper challenge than the one I’ve just sketched. The Stoics used the term “logic” to encompass what we might today call “epistemology”. If the word “logic” is meant in some such broad and normative sense, then we may restate the challenge as one about rationality and theology. Is it irrational to pursue theology in our modern age?
1346−
1347−As an undergraduate under the influence of Kierkegaard, I was attracted to a romantic, vaguely irrationalist notion of faith. Dawkins-mania was at its peak and I was disgusted by the pop-rationality (or was it empiricism?) of his annoying followers. Their view seemed to be that rationality just means “following the evidence”. The raw evidence is foundational, and theories are built atop by generalizing from the evidence. The ghost of logical positivism is with us even now.
1348−
1349−I was dimly aware that Quine and others had made it difficult to sustain epistemic foundationalism. However, being unable to supply a more clear and cogent notion of rationality, I became skeptical of the idea altogether. But I went too far.
1350−
1351−Instead, the proper response is to develop a superior account of rationality. Readers can probably guess where I went looking!
1352−
1353−The word “logic” comes from the Greek “λόγος”. This is also the word used to describe Jesus Christ in the Gospel of John: “In the beginning was the Logos, and the Logos was with God, and the Logos was God.” This connection is not merely etymological.
1354−
1355−For many ancients, the term “λόγος” meant something like “divine principle”. You might think of it as akin to a law of nature, but with stronger theological connotations. Christians appropriated this term and made it rather more exalted: the Logos is begotten of the Father, and yet somehow one with Him.
1356−
1357−We are told that all things come into being through the Logos (John 1:3), giving Him an intimate relationship to the whole of creation. He gives structure and order to all created things, and in His divinity He understands them as so structured and ordered. He is also sinless, perfectly holy, and good. In Christ we have a perfect unity of the knowledge of all truth and righteousness.
1358−
1359−Man was created in the image of God, which means that we bear a likeness to Christ. And we are commanded to realize that likeness with ever greater fidelity (Romans 8:29). The Church calls the pursuit of this likeness [“theosis”](<https://en.wikipedia.org/wiki/Theosis_(Eastern_Christian_theology)>).
1360−
1361−Thus we have the explanation of all normativity, according to Orthodox Christianity. In moral matters we must take on the holiness of Christ. In epistemic matters we aspire to the wisdom and knowledge of Christ, which includes an understanding of the whole created order. Socially we (the community of believers, i.e. the Church) are called to be in ever greater communion with God, cooperating with His work just as the Son cooperates with the Father.
1362−
1363−Sadly we are conceived in sin and ignorant; hence the need for redemption by Christ.
1364−
1365−Accordingly, my understanding of what it means to be rational is just to be Christ-like. The only perfect exemplar of reason, so construed, is Christ Himself. Any deviation from Him is irrational. What could be more logical than to be conformed to the Logos? But we cannot attain rationality without redemption. Hence we cannot become rational without first being saved from sin.
1366−
1367−Doubtlessly many will find all of this too much to take, just too implausible. What about the development of mathematics, or the advances of the sciences? These are canonically ennobling, intellectual achievements. Jesus wasn’t a mathematician or a scientist! Nowhere in the Scriptures is He recorded as having applied Bayes’ theorem.
1368−
1369−Undoubtedly my construal of rationality de-emphasizes the pursuit of knowledge by labeling it as merely one of several normative ends. To seek knowledge without seeking holiness is to be understood as dangerously unbalanced. To try to attain holiness and knowledge without communion with God is arrogant.
1370−
1371−On the other hand, we need not exaggerate matters. St. Paul affirms the need for specialization of labor within the Church (1 Cor. 12). There is room for some to specialize in intellectual endeavors, so long as they act in a cooperative setting in which the other virtues are pursued as well. (Nor should anyone neglect the development of such virtues in himself.) Mathematicians and physicists are more than welcome in the Church.
1372−
1373−According to this (all too briefly put) theory of rationality, there can be no conflict between ‘logic’ and theology. Theology is compatible with rationality because the account of rationality in question derives from a theological tradition. Naturally I’ve only given a sketch; much more could be said. But even if some readers are put off by the theory presented here, I hope it’s at least clear that there are conflicting notions of rationality. Anyone who wants to be rational confronts the task of figuring out which theory of rationality is correct.
1374−
1375−**In terms of community moderation, The Portico follows norms that are quite different than other online communities, often times quite drastically. For instance, living with women that you are not married to, is not something that should be talked about lightly. Can you talk about the importance of norms and how they relate to a healthy community?**
1376−
1377−Orthodox Christians are not commanded to “get along” with the rest of the world (John 15:18-25). We’re different, and our norms of interaction should likewise differ from those of outsiders. There is no one, monolithic “Orthodox culture”, but there are standards governing which local expressions of culture are legitimate and which are sinful. We should live in a way that enables and promotes holiness and discourages sin.
1378−
1379−We have rules that may seem unusual from the outside. I don’t permit profanity, lewd jokes, or irreverent comments about God. In your question you mention a living arrangement that is prevalent in the world. Another rule I have is that we shouldn’t talk causally about sinful practices or lifestyles as if they are unremarkable parts of ordinary life. If Orthodox Christianity is true then such things aren’t minor peccadilloes. They’re spiritually destructive. The marriage-bond sanctifies activities that would otherwise be sinful.
1380−
1381−If someone wants to analyze what is destructive about men and women living together before marriage, we’re open to that. But if you want to be affirmed in your sin, we’re not the place for you. Anyone of any religious creed is welcome to show up—but as a guest in an Orthodox Christian community. Hosts should be courteous to guests, but my first priority is not to make you feel good about your choices. We’re here to encourage each other, learn, and grow spiritually as Orthodox Christians. Naturally that means a little gate-keeping may sometimes be necessary if someone ever comes along who doesn’t share those goals. Being different is difficult and takes work.
1382−
1383−In a way the cultural contrast is meant to be jarring. It can force you to confront moral and cultural presuppositions that you didn’t even know you had. When you become aware of the wider choices of culture available to you, you become free to look with a critical eye on the culture you’ve hitherto taken for granted. I think anyone could see how that might be liberating, even before considering the particulars of the cultures in question. Of course, as an Orthodox Christian, I think we have a good case to make about the particulars of our subculture.
1384−
1385−I’ve never had to kick or ban anyone from the group. The group is relatively small (~180 people at the moment) so that probably helps. The vast majority of conversations are relaxed and friendly. Occasionally there are intense debates about one issue or another but I enjoy it, as long as it doesn’t become bitter or the primary mode of discourse. But everything ought to be done in a spirit of truth-seeking, not of one-upmanship.
1386−
1387−**The fact that The Portico can exist side-by-side with atheist communities on Urbit is pretty striking. On Urbit, a user is able to create niche communities and governance structures and yet still participate in a larger network. In other words, Urbit is trying to thread the needle between sameness and difference through federation at multiple levels. It seems to me that modern culture has become homogeneous due to an inability to maintain, or distinguish between, different communities. People who have nothing in common are forced to engage as if they were roommates, while those who are similar have trouble creating their own home. In other words, what is the role of community formation in the modern world and how does it connect to your critique of liberalism? Does Urbit have anything to say about this?**
1388−
1389−As I said in an earlier response, I see the liberal project as more or less an attempt to sidestep (not solve) difficult metaphysical and religious disputes between various distinct moral communities. Liberals have tried several methods of governance to achieve their ends. We can divide such attempts into two broad categories: centralized and decentralized.
1390−
1391−Social media companies in the US confront similar governance challenges, so we can analyze them in similar terms.
1392−
1393−A social network like Facebook takes a centralized approach. Zuckerberg spoke early and often of his desire to connect people and “bring the world closer together”. There was a sense that if people from various communities could get to know each other a little better, we would see how much we have in common and make progress toward some kind of universal cosmopolitan consensus.
1394−
1395−But that didn’t happen. With centralized social media you’re practically guaranteed to interact with people whose moral and metaphysical commitments are sharply at odds with your own. As a result, you face a persistent, nagging risk of conflict. Without warning, a friendly disagreement can explode into an all-out flame war. Most choose one of two basic approaches for dealing with this threat:
1396−
1397−(1) You live a compartmentalized life. You keep your moral and metaphysical commitments to yourself and cultivate a culturally homogenized persona for your social media activities. No one disagrees with you because there’s nothing to disagree with.
1398−
1399−(2) You can enlist to fight in the culture war and display your regimental colors with pride. And because you take your smartphone everywhere you’re always on the front line.
1400−
1401−These aren’t the only options, of course. With some combination of charisma, patience, and grace you can be relatively open about your beliefs without getting into too much trouble. But even if you have the talent to pull it off, it takes time and energy. Many of us aren’t willing to go to all that trouble. Social media is supposed to serve us, not the other way around.
1402−
1403−Urbit is decentralized which, in my opinion, means that it isn’t really a network in the way that Facebook is. I see Urbit as more of a network platform. The users create the networks, or migrate them in from elsewhere. We’re all using Landscape and running our VMs on Nock, so obviously there can be interaction between different communities. But anyone who doesn’t want that cross-community interaction doesn’t have to have it.
1404−
1405−I’ve followed Urbit’s progress since 2016, so I’m plugged into groups with other Urbit people I’ve come to know over the years. Other than that, however, I don’t know much about who’s out there. It’s not like The Portico is in one neighborhood and the atheists are in the next neighborhood over. There’s a real sense in which we’re not even on the same network—different Urbit communities share a common protocol, but a protocol isn’t a network.
1406−
1407−Some people may want to see a little of everything. If atheists want to join our group they’re welcome to do so! We’ll be friendly. I don’t seek out their groups, though.
1408−
1409−One virtue of decentralized social media is that it offers a totally different set of trade-offs with respect to how you share and act on your beliefs. What if you could talk earnestly about philosophy and religion without having to worry about alienating many of your friends and family? I guess that’s somewhat possible on Facebook—do they still have “groups”?—but Urbit was designed for it.
1410−
1411−Having said all that, I don’t think decentralization is a panacea. Even if Urbit takes off, it will likely face problems that are difficult to anticipate now. My hope is simply that Urbit’s trade-offs are healthier than the ones we’ve had before.
1412−]]></content:encoded>
1413− </item>
1414− <item>
1415− <title><![CDATA[Lunar Urbit and the Internet of Things]]></title>
1416− <link>https://urbit.org/blog/iot</link>
1417− <guid>https://urbit.org/blog/iot</guid>
1418− <pubDate>Thu, 29 Apr 2021 00:00:00 GMT</pubDate>
1419− <content:encoded><
1423−
1424−<br>
1425−
1426−Each of the ~4B 32-or-fewer-bit or [Azimuth](/docs/glossary/azimuth)
1427−identities, namely [planets](/docs/glossary/planet),
1428−[stars](/docs/glossary/star), and [galaxies](/docs/glossary/galaxy), may
1429−spawn ~4B 64-bit child identities known as [moons](/docs/glossary/moon).
1430−Moons are the undeveloped wild outback of Urbit, with a story waiting to be told
1431−that promises to be as enormous in scale as the cloud personal computing story
1432−told by planets, and possibly even more so.
1433−
1434−Throughout this piece, we use "Earth" and "Mars" in the Urbit sense. "Earth"
1435−refers to the [current computing
1436−paradigm](https://en.wikipedia.org/wiki/Big_ball_of_mud). "Mars" refers to the
1437−perfected computing paradigm that Urbit aspires to be, but also to the current
1438−and future state of Urbit.
1439−
1440−Today we will review the prehistory of moons on Earth, give a snapshot of how
1441−moons are being utilized on Urbit in 2021, cover existing issues with consumer
1442−IoT and how Urbit resolves them, and speculate what the lunar locus of the Urbit
1443−ID address space may become in the future. To keep the futurist scope limited,
1444−we primarily speculate on the usage of moons in (industrial) internet of things
1445−settings, especially with respect to agriculture, and how they may manifest as
1446−the workhorse collection unit of decentralized data markets.
1447−
1448−For those unfamiliar, moons differ from all other
1449−[ships](/docs/glossary/ship) in that they are not independent identities
1450−with total sovereignty over their data and keys. Instead, their cryptographic
1451−keys are issued and controlled by their parent identity. The relationship
1452−between the keys of a parent ship and its moons are analogous to the
1453−relationship between primary keys and subkeys in a system like
1454−[PGP](https://en.wikipedia.org/wiki/Pretty_Good_Privacy). The parent may revoke
1455−or change its child moons' keys at any time. A typical relationship between a
1456−planet and a moon may be like one of a human and their smartphone. If you lose
1457−your phone, you don't want someone to pretend they are you, operating one of
1458−your moons, on the network. The planet can revoke the keys, and the moon stored
1459−on the phone becomes inert, no longer able to communicate with the network.
1460−While planets and stars also depend on their sponsor to assist with peer
1461−discovery and software updates, these relationships rely on mutual agreement,
1462−since either party may choose to discontinue the relationship and establish a
1463−new one elsewhere. Moons possess no such freedom.
1464−
1465−### Lunar prehistory
1466−
1467−
1468−
1469−It may come as a surprise to you that you are already very familiar with moon
1470−identities—they've just never been explained as such because the context in
1471−which that terminology makes sense didn't exist before Urbit. Moons, in fact, are not
1472−a new concept at all. Virtually your entire experience of the internet in the
1473−modern era is the experience of someone who possesses some number of moons
1474−subordinate to planets who mostly refuse to talk to one another. The feeling you
1475−get of constantly moving between silos, juggling accounts, not controlling your
1476−own data, etc., is a direct result of the fact that, on Earth, you only possess
1477−moons. No planets.
1478−
1479−We're speaking, of course, of the client-server relationship. From the Urbit
1480−perspective, the Facebooks, Twitters, and Googles of the world are planets, and
1481−accounts held with these services may be thought of as moons subordinate to
1482−those planets. Your account with these megacorps is only yours for as long as
1483−they please. If you happen to step on a digital landmine, such as a virus that
1484−causes Google's servers to believe you are a bot, you are suddenly banned from
1485−their service, often with no recourse. All your data, your connections, your
1486−network—vanished. We are all Mark Zuckerberg's moons, and they're armed to the
1487−teeth with surveillance equipment.
1488−
1489−There are two classes of internet users: those with servers who hold all the
1490−power, and clients who use those servers in the way prescribed by the owners.
1491−Running a server is theoretically accessible to anyone, but practically
1492−difficult: server maintenance is a technical endeavor that requires specialized
1493−knowledge and substantial time investment. Other barriers exist beyond just the
1494−technical: for instance, if you wish to set up your own email server, you will
1495−probably be blocked by large providers because unknown email servers are almost
1496−always spam. The root cause of this circumstance is that the email protocol
1497−lacks [Sybil resistance](https://en.wikipedia.org/wiki/Sybil_attack). Urbit has
1498−Sybil resistance built in, eliminating certain kinds of incentives for
1499−gatekeeping such as this.
1500−
1501−We seek to level the playing field by giving everyone a server. We accomplish
1502−this by making the process of running your own server (planet) as easy as
1503−running your personal computer today. We aren't quite there yet, but we've made
1504−leaps and bounds over the past couple of years.
1505−
1506−Of course, this analogy isn't perfect—Urbit moons are servers themselves, but as
1507−they may only act in accordance with the wishes of its parent, they are
1508−effectively as locked in degrees of freedom as a client is to a server. The
1509−moon's keys may be revoked at any time by the parent. To distinguish these
1510−prehistoric moons from Urbit moons, we will refer to them later as "primitive
1511−moons".
1512−
1513−Urbit contends that moons are not the appropriate digital exocortex for a
1514−responsible adult. They are for devices, experiments, or your children. We hope
1515−that the dominant server-client relationship, which is the primary weapon of the
1516−surveillance-industrial complex, will meet its end in the near future.
1517−
1518−### Moons in the early Martian era
1519−
1520−
1521−
1522−In 2021, moons are mostly unused on Urbit. There's a smattering of minor use
1523−cases which we'll describe here, but they represent only a tiny fraction of
1524−their ultimate potential.
1525−
1526−Tlon recently launched a survey bot called [Eliza](/blog/eliza), which was
1527−initially a comet. We frequently got questions on whether Eliza was actually
1528−Tlon's bot, because it could just as easily be a malicious actor posing as Tlon.
1529−We soon plan to relaunch Eliza as a moon of `~zod`, which is the most
1530−recognizable official galaxy of Tlon. This is to establish that the bot is
1531−indeed official; only someone with access to `~zod` is capable of creating a
1532−moon of `~zod`, and so a moon of `~zod` automatically carries with it a
1533−cryptographic guarantee that you are communicating with an official digital
1534−representative of Tlon. On Earth something like this would need to be
1535−accomplished with certificate chains but, on Mars, this sort of authentication
1536−is baked into the very fabric of the network, rather than as an additional layer
1537−on top. This is a very good representative case of how moons naturally inherit
1538−the reputation of their parent, even in the absence of any formal reputation
1539−systems on Urbit.
1540−
1541−We see folks using moons as backup identities in case they can't or don't want
1542−to access their primary planet for one reason or another. Again, since anyone
1543−may verify the parent of a moon, the moon inherits the reputation of its parent.
1544−These backups could be vanity identities—for instance, every `~sampel-palnet`
1545−has underneath it a moon named `~master-sampel-palnet`[^0].
1546−
1547−Some use moons to host group(s). Hosting a group inevitably means that that ship
1548−will process more network traffic, and a heavily trafficked group may impact a
1549−ship's performance. Thus one may wish to offload group hosting duties to a moon
1550−to maintain a more performant planet.
1551−
1552−As we currently lack a real system for 3rd party software distribution (though
1553−see this recent [developer call](https://youtu.be/XwICC6Its1E) on a solution in
1554−progress), one stopgap has been to download software by syncing a foreign
1555−[desk](/docs/glossary/desk) to your ship. This is risky, as buggy software
1556−may make break your ship and make it difficult to get running properly again.
1557−For this reason, testing new software on the livenet is frequently performed on
1558−moons, so as not to risk the parent ship if something were to go wrong.
1559−
1560−### Internet of Things
1561−
1562−
1563−
1564−Now we start to look towards the future by examining the problems faced by IoT
1565−in the present and speculating on how Urbit might solve them.
1566−
1567−The Internet of Things is much maligned by technologists as a privacy, security,
1568−and maintenance nightmare. These products usually depend on phoning home to
1569−perform their service, which is inevitably a funnel by which personal data is
1570−harvested, an attack surface for hackers to gain access to your home network,
1571−and a single point of failure which may render the device useless, all in one!
1572−One need look no further than the recent [Ubiquiti
1573−breach](https://krebsonsecurity.com/2021/03/whistleblower-ubiquiti-breach-catastrophic/)
1574−to see all of these failure modes happening on a massive scale, and this is par
1575−for the course. This sort of dynamic is completely antithetical to the Urbit
1576−philosophy, so any involvement of Urbit with IoT will reject many fundamental
1577−assumptions on how IoT operates today.
1578−
1579−However, it's important to understand why the current IoT model works like this
1580−at all. We posit that it ultimately stems from the fact that today's IoT
1581−products are primitive moons for which you do not operate the parent planet.
1582−Almost every IoT device operates in the Software as a Service (SaaS) paradigm
1583−because most people don't have personal servers that could do all the processing
1584−work actually necessary for an IoT device to operate. This is not the _only_
1585−reason for this—it's also just more profitable to collect consumer data.
1586−However, it's the SaaS aspects which make the whole thing such a catastrophic
1587−mess.
1588−
1589−Imagine a different world: if the server that your device reports to is your
1590−own, there is no loss of control over personal data. If the device only
1591−communicates on the local network, it will prevent remote hackers and disruption
1592−if you internet fails. And if the manufacturer goes out of business, the device
1593−will still work-it is not dependent on the manufacturer's servers.
1594−
1595−The wants and needs of the individual are at odds with the wants and needs of
1596−the megacorp, and that mismatch manifests as the antifeatures that plague IoT.
1597−By eliminating the SaaS aspect, Urbit solves many of the largest outstanding
1598−issues with IoT in a single blow. Digital personal AI assistants have long been
1599−an anticipated science fiction prediction and their full realization is on the
1600−horizon. But in their current manifestation, many privacy- and
1601−security-conscious people would never consider using them at all, since they are
1602−inevitably presented as SaaS that requires intimate knowledge of your devices
1603−and their stored data. Recommendation engines such as the one used by YouTube
1604−offer helpful guidance towards content you'll find appealing, but they're also
1605−designed to keep you hooked to the service. These kinds of programs can be
1606−useful, but they're dystopian when they come saddled with anti-consumer
1607−subroutines. Since your Urbit belongs to you, it can never act against your own
1608−interests without your consent. In our lunar vision, your digital personal AI
1609−assistant will live on one of your moons, rather than on megacorp's cloud.
1610−
1611−For web-exposed devices, Urbit offers the same security guarantees that it
1612−offers for your personal computer: everything is end-to-end encrypted by
1613−default, and signed with keys that one can easily verify as belonging to the
1614−node sending the message.
1615−
1616−[Vint Cerf](https://en.wikipedia.org/wiki/Vint_Cerf) has outlined the case for a
1617−system like Urbit ID for IoT use
1618−[here](https://cacm.acm.org/magazines/2018/12/232883-self-authenticating-identifiers/fulltext).
1619−In brief, that the Urbit ID system allows one to match public keys with devices,
1620−bestowing devices with self-authenticating identities. This allows one to trust
1621−the communications received from the device to whatever degree the private key
1622−is held secure. IP addresses, GPS coordinates, MAC addresses, etc., are not
1623−sufficient to generate high levels of trust—they're all temporary, easily
1624−spoofed, or both.
1625−
1626−> One might imagine applying this to the Internet of Things (IOT) in which the
1627−> IOT device self-generates a public- and private-key pair and registers the
1628−> public key. For example, with a hub or controller so the hub can confirm it
1629−> has reached the right IOT device. By the same token, configuration of the IOT
1630−> device into an ensemble could include incorporation of the public key of the
1631−> controller into a list of valid devices that can command or obtain data from
1632−> the now-configured IOT device. Both ends can verify they are talking to the
1633−> originally configured devices, assuming no device has lost its private key.
1634−
1635−Here, the hub or controller referred to would be your planet.
1636−
1637−Urbit has many other features that make it well-suited for IoT, above and beyond
1638−eliminating the SaaS model and providing self-authenticating identities. Many of
1639−these additional advantages derive from the fact that Urbit is a [solid state
1640−interpreter](/docs/arvo/overview#solid-state-interpreter) and that
1641−[Ames](/docs/glossary/ames) is a network of solid-state interpreters
1642−equipped with cryptographic identity. We explore this in the next section.
1643−
1644−### Future lunar cosmotechnics
1645−
1646−
1647−
1648−We now polish off the old crystal ball and imagine future uses of Martian lunar
1649−technology. Particularly, how the tech may develop over time once it becomes
1650−widely exposed to the evolution-inducing forces of industry and culture. This
1651−section is pure speculation, and I only aim to offer a small glimpse of a
1652−potential future, rather than an exhaustive one. This picture will necessarily
1653−be biased by my personal proclivities and expertise, or lack thereof.
1654−
1655−Any discussion on the future of moons is incomplete without mentioning the
1656−possibility of [lunar emancipation](https://urbit.org/faq/#more-planets) in
1657−order to increase the number of planets. This fascinating topic sees regular
1658−discussion in the Urbit Community group, but is outside the scope of this
1659−article.
1660−
1661−In order to respect the reader's time, I'm narrowing our scope to a particular
1662−topic: the agriculture industry. I'm also assuming a future with specialized and
1663−increasingly small hardware to run Urbit. Right now, a 4 GB Raspberry Pi is the
1664−standard for "small Urbit". If someday there are CPUs specifically designed for
1665−running [Nock](/docs/glossary/nock), one could imagine going much smaller.
1666−Ultimately, I'm going to assume that there will someday be [solid-state
1667−interpreter](#ssi) microcontrollers - so the inclusion of Urbit on a device may
1668−require nothing more than a couple [surface-mount
1669−devices](https://en.wikipedia.org/wiki/Surface-mount_technology) on a larger
1670−chip.
1671−
1672−Urbit is intended first and foremost as a personal computer. When I unravel its
1673−potential usage in industry, I adopt the forecast of a drastic increase in the
1674−manufacturing capacity for individuals and small groups. Agriculture is a great
1675−microcosm of this long-standing trend; less human input is needed to produce the
1676−same amount of food, whether it be crops or livestock. The modern era is
1677−distinguished by the fact that small numbers of people can manage enormous farms
1678−which produce food for vast populations. Thus, computation on modern automated
1679−farms may be thought of as existing at the intersection of both personal and
1680−industrial scale, and show how computerized and mechanized workflows add to the
1681−amazing productivity of modern farms and demonstrate that individual-sized
1682−inputs are able to create industrial-sized outputs. I predict that the set of
1683−trades for which this dynamic holds will only increase over time.
1684−
1685−Agricultural automation has been a primary engine for the growth of
1686−civilization, but it has been hampered by the downsides of IoT elaborated in the
1687−previous section. One bellwether of this dynamic is the right to repair one's
1688−own equipment. [John
1689−Deere](https://www.thetruthaboutcars.com/2020/03/its-payback-time-right-to-repair-movement-targets-john-deere/)
1690−has long been at the center of this controversy. Farmers have lost the ability
1691−to repair their own equipment due to vendor locks and a dependency on remote
1692−servers. Furthermore, any suite of sensor products designed to gather important
1693−data such as genomics, hydrology, soil health, weather, etc., inevitably only
1694−cooperate with other products by the same vendor. It's the same story all over
1695−again—you are a client of a megacorp server. Or in Urbit terms, you have a bunch
1696−of primitive moons belonging to different planets held by megacorps, and no
1697−planet to call your own.
1698−
1699−Again, Urbit resolves these issues in the same fashion as above. One might argue
1700−that using Urbit is another form of vendor lock-in—but this is evaluating Urbit
1701−at the incorrect level. Since Urbit is an open source operating system, its
1702−functionality may be extended and modified arbitrarily by any party. _Some_
1703−computational infrastructure is necessary— that fact can never be escaped. But
1704−you can escape from closed source software that does not permit you to modify,
1705−to open source software that allows you to tinker at will. Thus we do not
1706−consider open source software to be a form of lock-in, or at least, it's a much
1707−milder form of lock-in compared to something like Apple's walled garden.
1708−
1709−So let us focus on the additional meritorious aspects of Urbit (or more
1710−generally, solid state interpreter networks) that make it not merely a band-aid
1711−to the broken IoT system but a permanent and sound replacement.
1712−
1713−#### Solid state interpreter networks {#ssi}
1714−
1715−
1716−
1717−Urbit is the world's first solid-state interpreter (SSI). This concept is
1718−summarized in the [white paper](https://media.urbit.org/whitepaper.pdf) as
1719−follows:
1720−
1721−> Imagine it as a chip. Plug this chip into power and network; packets go in and
1722−> out, sometimes changing its state. The chip never loses data and has no
1723−> concept of a reboot; every packet is an ACID transaction.
1724−
1725−Also,
1726−
1727−> Briefly, an SSI is an interpreter which is also a database. In more depth, an
1728−> SSI combines three properties: uniform persistence, source independent packet
1729−> networking, and high-level determinism.
1730−
1731−We do not wish to segue into a lengthy examination of what this really means—
1732−that's what the white paper is for—but we will attempt to explain why these
1733−properties are of great benefit in an industrial IoT context such as
1734−agriculture. We'd also like to predict that Urbit will not be the only SSI.
1735−Other sorts of SSI's specialized to various tasks may one day roam the planet,
1736−and these may be better suited for particular IoT tasks than
1737−[Arvo](/docs/glossary/arvo). However, this article will be couched in terms
1738−of SSIs communicating with an [Ames](/docs/glossary/ames)-like networking
1739−protocol and Urbit ID-style cryptographic identity, rather than Urbit in
1740−particular.
1741−
1742−For a SSI, losing power is less of a catastrophic event than it is for ordinary
1743−computers with volatile memory. Knowing that you can never lose any state is a
1744−powerful guarantee on the integrity of your data. Loss of power will always mean
1745−loss of any data potentially collected while power is down, regardless of the
1746−device you use, but with a SSI you at least have assurance that you will never
1747−lose data that was collected before it could be transferred from the cache to
1748−the disk. Of course, this is actually the sort of guarantee that [ACID
1749−transactions](https://urbit.org/docs/arvo/overview/#acid-database) have—it is
1750−just that this set of guarantees emerges naturally as a consequence when you
1751−have a SSI. Put another way, every SSI is a database; having every device be a
1752−database is a major boon in situations where enormous quantities of data are
1753−being collected across a distributed network. The standard today is that data is
1754−only collected at hubs, and any data that doesn't reach a hub is irretrievably
1755−lost.
1756−
1757−SSIs are also deterministic at a high level. While all computers are
1758−deterministic at the CPU level, interruptions to power can result in an
1759−undefined semantic state and result in the random erasure of half of its brain.
1760−This determinism is what begets ease of maintainability of Urbit—problems
1761−generally only need to be solved once by experts and the solution propagates to
1762−the rest of the network via [OTA updates](/docs/glossary/ota-updates). We
1763−addressed this maintenance issue previously—we only remark now that this
1764−property is derived from being a SSI, rather than something particular only to
1765−Arvo or Urbit. When one has hundreds or thousands of devices to manage, the
1766−guarantees on ease of maintenance provided by determinism are extraordinarily
1767−convenient.
1768−
1769−Packet routing on SSI networks is source-independent, and in the context of an
1770−Ames-like networking protocol, are always delivered exactly once and in a
1771−precise order due to the fact that nodes on an Ames network are in a permanent
1772−session. Source-independent means that the identity that originated a packet
1773−does not need to be the one to deliver it—packets are _facts_, and the truth of
1774−a fact does not depend on who you heard it from. This means that it is possible,
1775−for instance, to send instructions to a moon before it even exists and be
1776−guaranteed that that moon will receive them and perform the tasks given, even if
1777−the device that originally sent the packets no longer exists. As long as
1778−somebody has kept the packets on hand, they will eventually be delivered. So,
1779−one could imagine transmitting directions to a crop harvesting robot into which
1780−a moon will be installed before the robot has even been purchased, know that
1781−once it is delivered it will automatically begin its task, and know that those
1782−tasks will be completed in the correct order, without any accidental repeats.
1783−Taken to the limit, one can imagine preplanning the automated tasks for an
1784−entire farm before a single device is purchased, with powerful guarantees on the
1785−integrity of those instructions no matter how much time elapses between sending
1786−and receiving.
1787−
1788−#### P2P data markets
1789−
1790−
1791−
1792−As was mentioned above, today's IoT devices ferry all sorts of your personal
1793−data to megacorp, where they package it and sell it to the highest bidder.
1794−Though personal data in aggregate is quite valuable, the value of a single
1795−individual's data is quite low. On the other hand, industrial scale data such as
1796−that collected on digitized farms could be quite valuable. Here we briefly
1797−examine how Urbit can be utilized to populate and facilitate a market for data.
1798−
1799−All data collected by your moons may be digitally signed by that moon,
1800−certifying the exact origin of that data. This is one advantage of having
1801−cryptographic identity baked into the core of the operating system and
1802−networking protocol. One could imagine collecting large amounts of such data and
1803−packaging it for exchange with other local and regional farmers. This can, of
1804−course, already be done in principle with current systems. But current systems
1805−do not automatically come equipped with the sort of provenance, immutability,
1806−and reputation that comes for free when you make use of SSI networks.
1807−Manipulated or faked data becomes easier to spot, and you'll know who it came
1808−from, so supplying such data puts one's reputation at stake.
1809−
1810−One major issue facing conjoining data gathered from disparate sources is simply
1811−how to do it. Data arriving in random order, from different software versions,
1812−running different hardware, is all very difficult to bundle into a good
1813−dataset - and indeed wrangling this sort of task forms a large part of the data
1814−scientist profession. As devices in SSI networks utilizing an Ames-like protocol
1815−are engaged in permanent sessions, leading to properties such as exactly-once
1816−delivery and well-ordered message sequences, issues about the order in which
1817−data arrives are dramatically simplified. I do not wish to get mathematical
1818−here, but I personally have confidence that the emerging discipline of
1819−[categorical informatics](http://math.mit.edu/~dspivak/informatics/), as well as
1820−the relevance of [low-dimensional topology to data
1821−fusion](https://arxiv.org/abs/1409.5505), resolves many of these issues. I
1822−promise to explain this in more detail in the future. For now, it suffices to
1823−say that SSI networks seem well-positioned to utilize these techniques.
1824−
1825−Cryptographic techniques such as [(composable) zero-knowledge
1826−proofs](https://en.wikipedia.org/wiki/Zero-knowledge_proof), [secure multi-party
1827−computation](https://en.wikipedia.org/wiki/Secure_multi-party_computation),
1828−[ring signatures](https://en.wikipedia.org/wiki/Ring_signature), and even
1829−[homomorphic encryption](https://en.wikipedia.org/wiki/Homomorphic_encryption)
1830−offer a variety of ways in which data may be shared in an IoT context with
1831−mathematical guarantees on what sort of privacy is maintained. This is perhaps
1832−less relevant in the context of agricultural IoT, where personal private data is
1833−largely absent, but we mention them here to invite further speculation from the
1834−reader about the possibilities of IoT and SSI networks.
1835−
1836−We end our discussion with an adaptation of a scenario borrowed from my brief
1837−time working on [Ceptr](http://ceptr.org/) that begins to show how a lunar
1838−IoT-connected world evokes properties of a hypothetical ["global nervous
1839−system"](https://en.wikipedia.org/wiki/Global_brain). This example is
1840−purposefully mundane to illustrate how deficient our Earth systems are, and
1841−while it is possible to accomplish in theory, it is impractical on a wide scale
1842−due to the numerous problems with IoT. Imagine that you suffer headaches from
1843−low atmospheric pressure. You'd like to know when a low-pressure front is an
1844−hour away from you so that you can pre-emptively take aspirin to prevent the
1845−headache. Your personal digital assistant, running on Urbit, can then
1846−periodically query the moons of sensors in your region for weather data to
1847−predict whether or not you will soon be passing through a low pressure front.
1848−This could be a free service or paid for automatically with cryptocurrency
1849−microtransactions. On Mars, this task will be trivial, and is merely a stone's
1850−throw away from a vast and undiscovered universe of other possibilities unlocked
1851−by SSI networks.
1852−
1853−[^0]:
1854− Of course, all moon names have four words, not three. What the fourth word
1855− needs to be for only three words to display is a matter of Urbit lore that
1856− is more fun to discover yourself than have it told to you, so we won't spoil
1857− it here.
1858−]]></content:encoded>
1859− </item>
1860− <item>
1861− <title><![CDATA[Interplanetary Commerce]]></title>
1862− <link>https://urbit.org/blog/interplanetary_commerce</link>
1863− <guid>https://urbit.org/blog/interplanetary_commerce</guid>
1864− <pubDate>Thu, 08 Apr 2021 00:00:00 GMT</pubDate>
1865− <content:encoded><
1869−
1870−<br>
1871−
1872−## Paying
1873−
1874−A year ago, we started [integrating](https://urbit.org/blog/urbit-and-bitcoin/) Bitcoin into Urbit to be an OS-level primitive for money. Our initial objective: build a payments wallet, equally sovereign and ergonomic. The first public version, releasing this month, will have a broad set of capabilities including ship-to-ship payments, hardware wallet support, and full node integration. We’ll be unveiling this wallet on [April 27th](https://www.meetup.com/urbit-sf/events/276741426/). Do join us.
1875−
1876−Things only accelerate from here. Our next objective, to integrate Lightning Network capability, is now an [active bounty](https://gist.github.com/timlucmiptev/53ef1d290e55ea2fa25d9df681c32695) and open for applicants. Early on, we [recognized](https://www.youtube.com/watch?v=DTvRVHMbrcY) the congruence and compatibility between the Urbit and Lightning networks. Routing Lightning payments is an obvious business model for Urbit providers, one that can even nucleate new features onto Lightning itself. What we’re ultimately driving at is fully-sovereign Bitcoin usage, with the UX of the Cash App.
1877−
1878−## Being Paid
1879−
1880−> And there is all the difference in the world between paying and being paid. The act of paying is perhaps the most uncomfortable infliction that the two orchard thieves entailed upon us. But being paid,—what will compare with it?
1881−>
1882−> <cite>Herman Melville</cite>
1883−
1884−However, a good wallet is only half the equation for a holistic P2P commercial experience. Interfaces for selling goods and services is the other half. While we don’t part with our Bitcoin [easily](https://nakamotoinstitute.org/mempool/everyones-a-scammer/), two initial markets appear logical and attractive: content and Urbit-native services.
1885−
1886−First, digital cottage industry, the “creator economy”, is blossoming. Streaming, podcasting, and writing on platforms like Youtube, Patreon, and Substack has been big business [lately](https://otherlife.co/barbarians-past-the-gate/). What fintech did to “unbundle the banks", we will now do to media monopolies and their centralized distribution platforms. With the introduction of Urbit payments, you can syndicate, distribute, and monetize your media on Urbit. By selling access to a private group containing content, digital creatives can begin doing this today.
1887−
1888−Second, Urbit-native [service providers](https://urbit.org/blog/providers/) are now operating at scale. Companies offering Urbit hosting, onboarding, Urbit IDs, and software now communicate with their customers directly on the network. A basic set of commercial tools will make their processes more efficient. Storefront interfaces, paywalls, CRM, and reputation tools will replace the ad-hoc assemblages they currently use.
1889−
1890−The Urbit Foundation is soliciting contributors to this project through Urbit Grants. If you’re interested in working on any of these components [send us a proposal](https://grants.urbit.org/create).
1891−
1892−## An Ocean
1893−
1894−After honing our commercial tools on these use-cases, we’ll sail into a blue ocean. On the horizon: beautiful products, deployable at scale, built with the robust primitives of Urbit OS. Extensibility is Urbit’s promise to middle-men: every Web2.0 service they use to scalp us will find its P2P analog on Urbit. We invite developers and entrepreneurs of all stripes to join in the feeding frenzy. Ideas are constantly nucleating in <a href="web+urbitgraph://group/~pindet-timmut/urbitcoin-cash">Urbitcoiners</a> and <a href="web+urbitgraph://group/~bitbet-bolbel/urbit-community/graph/~darrux-landes/business-building-on-urbit">Urbit Community</a>.
1895−]]></content:encoded>
1896− </item>
1897− <item>
1898− <title><![CDATA[A brief update from urbit.org and Tlon]]></title>
1899− <link>https://urbit.org/updates/2021-04-01-update</link>
1900− <guid>https://urbit.org/updates/2021-04-01-update</guid>
1901− <pubDate>Wed, 31 Mar 2021 00:00:00 GMT</pubDate>
1902− <content:encoded><![CDATA[
1903−Hello!
1904−
1905−Happy Spring from ~wolref-podlex and ~roslet-tanner. We’re here with a surprise joint Urbit-Tlon newsletter—we’ve been so busy producing content that we forgot to write about it. Plus, this is fun every now and then. Honestly, we have so much to talk about this month, we can’t cover it all without writing a book. Here are the highlights.
1906−
1907−1 - Events
1908−
1909−April is shaping up to be jam-packed with events. For starters, we’ve got three developer calls slated for April, all of which are on Thursdays at 9am PDT:
1910−
1911−4/1: Tyler Shuster (~radbur-sivmus) discussed Javascript apps on Urbit: https://www.meetup.com/urbit-sf/events/277261928/
1912−
1913−4/15: Raghu (~sovmep-ripsum) will talk about virtual desks, a key component of third-party software distribution, and the process of contributing to the Urbit kernel through our scholarships program.
1914−
1915−4/29: Edward Amsden (~ritpub-sipsyl) will be discussing and demoing his WebRTC work, which enables audio/video calls on Urbit.
1916−
1917−On April 27th, we’ll be launching our Bitcoin Wallet and preparing to roll it out to the network. This is the culmination of many months of collaboration between several members of our community and Tlon—we’re really excited (especially ~pindet-timmut). There might even be some cool swag, discounted hosting, and/or other giveaways. Regardless, you’re not going to want to miss it. RSVP here: https://www.meetup.com/urbit-sf/events/276741426/
1918−
1919−We’re also excited to announce that our much anticipated Town Hall event, a virtual mini-conference, will be taking place on May 20th and will feature a keynote talk from our good friend Justin Murphy. Mark your calendars for now—more details to follow soon.
1920−
1921−2 - Content
1922−
1923−There’s been a ton of high-quality content produced lately. If you’re looking for something to watch, read, or listen to, here’s a roundup:
1924−
1925−~rovnys-ricfer has been recording an audio series about the design and rationale of Urbit called “Urbit from the Outside In.” Check them out here: https://twitter.com/rovnys/status/1371972157971050499
1926−
1927−~pindet-timmut and ~wolref-podlex appeared on Justin Murphy’s Other Life podcast—check them out: https://www.youtube.com/watch?v=vv9lymudGV8 and https://www.youtube.com/watch?v=5jbjSUKRyGM
1928−
1929−A question was posed on our mailing list titled: “what is this?” The team and community did not disappoint with their answers: https://groups.google.com/a/urbit.org/g/dev/c/bdlPPnaccMc
1930−
1931−Simon Kovacs (~bacbec-lormur) wrote a great post for our blog titled “After the Machine War”: https://urbit.org/blog/after-machine-war/
1932−
1933−~poldec-tonteg talked to the guys at The Stack. Check out the podcast here: https://thestack.link/episode-13-martian-futurism-with-poldec-tonteg/
1934−
1935−3 - Documentation refresh
1936−
1937−Our Docs team completed a large overhaul of our documentation last month, making the distinction between “Usage documentation” (https://urbit.org/using), or how to use your ship, and “Development documentation” (https://urbit.org/docs) much clearer.
1938−
1939−We’ve had some excellent contributions from the community to our documentation, most recently a comprehensive set of overviews, guides and examples documenting threads from ~tinnus-napbus: https://urbit.org/docs/userspace/threads/overview/
1940−
1941−We’re pretty proud of the work that’s gone into clarifying everything and are still working hard to make the docs more and more helpful. Feel free to send us your feedback if you have any!
1942−
1943−4 - Landscape news
1944−
1945−The community on Landscape is continuing to grow. Over 30 groups were published to the Directory in March alone, and these are just the public groups that someone decided to broadcast. We think that’s pretty exciting.
1946−There’s a new Cincinnati-centric group (~padwet/queen-city-urbit), a sewing group that sounds incredible (~pinwyl-hasfeb/seamstress-mafia), and the first digital maker space on Urbit (~tidrel-tabpub/freeside-mars).
1947−
1948−Check out the Directory (~bollug-worlus/urbit-index) to discover public groups and, if you’d like help getting your community onto Landscape, let us know. We’re here to help!
1949−
1950−5 - Hosting
1951−
1952−Over at Tlon, we’ve been really busy onboarding new hosting customers. All of our current onboarding sessions are completely booked! If you’d like to learn more about how it works, send an email to support@tlon.io. If you’re ready to get on the list, sign up at https://tlon.io/
1953−
1954−6 - Team news
1955−
1956−We're happy to share that longtime hooner ~littel-wolfur has joined the Tlon engineering team. Welcome, ~littel-wolfur! Also, we’ve made it official with ~wolref-podlex and dropped the “Interim” from “Director of urbit.org” (probably due to the quality of these newsletters).
1957−
1958−If you’re interested in working with Tlon or urbit.org, feel free to get in touch.
1959−
1960−7 - Culture recs
1961−
1962−Finally, we’re going to leave you with some recommendations from the team:
1963−
1964−~fabled-faster released an insane new mix that melted my face in a good way: https://soundcloud.com/flowerstructure/fs-s-s-2021
1965−
1966−Our designer ~natnex-ronret curates a playlist website. Check it out: https://www.door.link
1967−~datnut-pollen has been trying to understand how information processing evolves over time in evolutive systems. Here’s what he’s been reading:
1968−
1969−(i) Connectom https://connectom.substack.com/p/connectom-the-book It is about thermodynamic/statistical mechanical processes as the fundamental driver of the evolution of biological, ecological, and human systems.
1970−(ii) Topological phases emerge in an ecological model: https://physicstoday.scitation.org/do/10.1063/PT.6.1.20210128a/full/ and Topology protects chiral edge currents in stochastic systems: https://arxiv.org/abs/2010.02845 Topological protection for various dynamics is the main theme he reckons is missing from Connectom.
1971−(iii) Homotopy theoretic and categorical models of neural information networks https://arxiv.org/abs/2006.15136 Topological techniques for understanding information processing in neural, metabolic, societal, and computational contexts.
1972−
1973−~simfur-ritwed recently re-read Pynchon's Vineland. It’s both a loom into the backwoods NorCal culture of the 80s and a typically Pynchonian fantasy about the dangers of media-saturated identity (quite prescient, turns out).
1974−
1975−In the wake of his recent trip to Brazil, ~wolref-podlex has been reading Os Sertões (the English version), the story of a war that took place at the end of the 19th century in the backlands (sertões) of Brazil, in which the Brazilian army brutally crushed the peaceful religious settlement of Canudos.
1976−
1977−Lately I (~roslet-tanner) have been getting back into Roy Ayers. This feels just right for spring: https://www.youtube.com/watch?v=inPgcN_xF4w
1978−
1979−That’s it for now. We’ll be back with more news from Tlon and Urbit, respectively, in a few weeks. As always, let us know if there’s anything in particular you’d like to hear about next time.
1980−
1981−~wolref-podlex and ~roslet-tanner
1982−]]></content:encoded>
1983− </item>
1984− <item>
1985− <title><![CDATA[After the Machine War]]></title>
1986− <link>https://urbit.org/blog/after-machine-war</link>
1987− <guid>https://urbit.org/blog/after-machine-war</guid>
1988− <pubDate>Sun, 14 Mar 2021 00:00:00 GMT</pubDate>
1989− <content:encoded><
1993−
1994−<br>
1995−
1996−> The following fictional passage, from a book being written in an Urbit Group called “the Aleph,” sketches out a dismal future for the human race. As an item of speculative fiction, the piece is not what one might call original. Anyone could have come up with these ideas. In fact, several already have. The Matrix is an obvious antecedent. Vonnegut isn’t far behind either. And the treacly humanism lodged beneath the bitter humor resembles nothing so much as the work of that beau monde satirist, George Saunders.
1997−>
1998−> Really the only notable thing about it is that it was written on Urbit. And that, perhaps, has made all the difference.
1999−>
2000−> It’s easy to be pessimistic about the future. Intellectuals, especially, are drawn to pessimism, because pessimism (falsely) implies a greater wealth of knowledge about the ways of the world. But one thing the pessimist never sees coming is a turn for the better. To wit, the future described in the below excerpt doesn’t have to take place. And Urbit is one piece of evidence for the claim that it will not.
2001−>
2002−> The philosopher-cum-internet comedian Slavoj Zizek likes to point out that no one was really expecting the Soviet Union to collapse in 1989. In fact, the average Soviet dissident wasn’t even gunning for it. He was haggling over small reforms, pushing to get the less corrupt politicians to the top, just going about his day eating or opening a window or walking dully along. Then, kaboom. Collapse. No more USSR.
2003−>
2004−> Then as now, the unexpected is more likely to occur than most would believe. One thing is not only possible, but an established fact: A brand new digital infrastructure is slowly, quietly being built. While U.S. political parties haggle over $1,400 disbursements for citizens, the rules of global finance are being re-written in code. While pundits debate the merits of Dr. Seuss’s lesser known titles, a global shift away from traditional publishing is gaining steam. And while users and social apps themselves pop up and down like whack-a-mole, folks are putting down roots with permanent peer-to-peer digital identities. If you’re anything like an optimist, you’ll probably want to get on Urbit ASAP and put down your own.
2005−
2006−<br>
2007−
2008−The date is January 1, 2050. The place, New York City. The vibe...subdued. Back in 2020, you made a note to yourself to take stock of the world around you here at the half-century mark. And now the time has come. What do you find? The air quality is a bit worse, the bad parts of town are a bit more dilapidated, the Knicks are still terrible—all in all, from the outside at least, not much has changed from 30 years ago. Today you wake up groggy on your self-adjusting Smart Bed (Smart Bed Never Sleeps), you make yourself a steaming pot of coffee (locally sourced, delivered within the half-hour by a drone, now that you’ve got Titicaca Prime), you shower and get ready for work.
2009−
2010−But what was that dream you had last night? Only the faintest traces of it remain. A luminous rainbow, a mountain landscape, a sense of profound inner peace, mixed with euphoria, mixed with...an intense desire to go out and buy some Health Morsels cereal?
2011−
2012−That’s odd. You’ve never even had Health Morsels. You open up your laptop, where you can view the activity of the iThink microchip that you got implanted in your cortex a few years ago. “Ads help Elysium provide you with free, quality sleep-monitoring. To disable ads, please upgrade to Elysium Premium.” That explains it. After all—and you pause for a moment over whether the forthcoming thought is yours or the iThink’s, before deciding that it’s much the same anyway—Health Morsels probably are delicious. And healthy, too.
2013−
2014−As usual, they’re setting something on fire outside your home. Normally you’d scroll back through your Squawker feed to see what it was all about, but today you’re late for work, and anyway you’re in a pleasant haze after the Health Morsels dream—no point ruining it by poring over the latest Squawker pile-on. You glance at the awning. Ah, the bodega. Toilet paper and Juul Pods are cheaper in bulk from Titicaca anyway.
2015−
2016−Another day at the office. You were never exactly passionate about content moderation, but hey, it keeps the lights on. (And since ConEd got absorbed by Titicaca, it’s been pretty important to have a Verified Income Stream.) It’s a normal day at work. Algorithms haven’t yet been able to filter out all Unverified Content—so it’s up to you the flag Unacceptable Violence, Disputed Claims, and Unfederated Currency transactions.
2017−
2018−Except after your pleasant dream, it all suddenly seems so drab. You start to wonder whether there was an error last night—maybe they turned the dream levels up too high. Something from your night-time vision just won’t leave your mind, like a film strip looping over and over. It’s that river beside a sloping field, like you used to swim in when you were a kid. You can almost feel the icy cold against your skin, the sticks and mud against the soles of your feet, and then there’s the ripe, marshy scent of the riverbed. Uh oh. You realize you’re close to danger levels. This isn’t where your head’s supposed to be at. Frantically you scroll through content, seeking to moderate it. A user threatening violence against Titicaca. A stream that violates DMCA. A highly dubious Squawker claim, with no support from experts. Flagged. Flagged. Flagged.
2019−
2020−Yet the river remains. You see it, you feel it, just as you feel the kiss of the sun on your shoulders, the breeze rustling through your damp hair.
2021−
2022−Now you know what’s coming. You brace for it and wait. Three. Two. One. ZAP. Your iThink produces an electric shock: plenty painful but not permanently damaging—at least that’s what the Verified studies show. The river recedes from your mind. Following the shock, your iThink, as versatile a little machine as ever was invented, delivers a few milligrams of both amphetamine and oxycodone, bringing on a wonderful feeling of simultaneous alertness and relaxation. You look up at your monitor. Content moderation doesn’t seem so bad, with the stimulant and the barbiturate swirling paradoxically through your system. It’s true what they say in the ads: iThink doesn’t just make you think better, it makes you feel better. You dive back into your content moderation with renewed verve, even flagging a couple completely innocent posts just out of surplus exuberance. So what if you hardly get outside at all these days, so what if you’ll never swim in that stupid river. The fastest electronics, the Your Health and Wellbeing tracked and adjusted by an intelligence far greater than that which you could ever hope to possess, a gizmo that gives a whole new meaning to the term neural net.
2023−
2024−2050 turned out to be a pretty good year after all.
2025−]]></content:encoded>
2026− </item>
2027− <item>
2028− <title><![CDATA[Eliza]]></title>
2029− <link>https://urbit.org/blog/eliza</link>
2030− <guid>https://urbit.org/blog/eliza</guid>
2031− <pubDate>Mon, 22 Feb 2021 00:00:00 GMT</pubDate>
2032− <content:encoded><
2036−
2037−<br>
2038−
2039−## The Storm before the Calm
2040−
2041−Building things, even Calm™ things, makes noise. George Nakashima’s wooden furniture evokes peace, but its construction still begins with a chainsaw. We mention this because we’re firing up our newest power tool.
2042−
2043−We call her Eliza. She is a data-collection robot.
2044−
2045−Hang on. An AI? Harvesting my data? Spying on me? Flooding me with spam? This is Urbit, right? Let us tell you about our new friend in basic terms, where MEGACORP might otherwise deploy legalese.
2046−
2047−## What Eliza is and isn’t
2048−
2049−> Replicants are like any other machine - they're either a benefit or a hazard. If they're a benefit, it's not my problem.
2050−>
2051−> <cite>Rick Deckard</cite>
2052−
2053−Let's start with the benefits. Eliza is a simple chatbot. She was made to collect feedback on Landscape. She asks direct questions about peoples' usage of Urbit, records any responses, and reports them to her managers at Tlon. She'll also provide timely advice and information to ships kind enough to chat with her. She'll begin reaching out to ships via DM in the coming month. If you don't want to, just say no, and you'll never hear from her again.
2054−
2055−Finding bugs is critical to Urbit's rapid development, especially in this period of nascency. Most Urbit-related frustrations go unreported; regular folks don't think to open up Github when they experience a minor issue. That's why it's incumbent upon us to design a lower-friction forum for feedback. People who aren't comfortable filing an issue might be willing to talk to a friendly chatbot.
2056−
2057−Now, about hazards. By design, there are few. Eliza runs on Tlon's comet, not on your planet. There will be no OTA to install `%eliza-bot-store` on everyone's ships. Eliza learns things through conversation, not hidden surveillance software. Data she requests, like the text output of our network analytic tool, `+tally`, must be sent manually. MEGACORP tends to cut this corner; to refine their products, they just track your reactions in real-time.
2058−
2059−Since she's [open-source](https://github.com/urbit/urbit/blob/b0c1f83287cbf4c85847a9238d9f4be17e1fcb33/pkg/arvo/app/eliza.hoon), anyone can creatively deploy Eliza. Just write her a dialogue tree. Of course, that also means we can't keep people from misusing Urbit bots. We think automated agents on the Urbit network are inevitable, so let's create a good baseline culture around them. (Much love to Tendiebot, who's serving up stock prices in `~tomdys/wall-star-bets`.) However, once Urbit is used world-wide, we can't rely on culture alone.
2060−
2061−## A New Internet Economics
2062−
2063−The sum of Urbit's architectural design is a new online economics: a way to finance and monetize access to internet infrastructure where people retain maximum equity. Explicitly acquire a low-maintenance, low-cost server. Use it to compute explicit things. Return to life.
2064−
2065−We all know the basic MEGACORP business model: offer a free service (to suckers who don't own a server), secretly mine the data they generate on the (addictive) platform, then sell targeted ads to advertisers. This model will not survive Urbit. The ubiquitous personal server changes the economic equation. You used to 'pay' for an experience with your time and data. On Urbit, once you purchase core internet infrastructure, it's yours.
2066−
2067−So, can Urbit meaningfully curtail our world's appetite for data? We'll see. Post-enlightenment society runs on instrumental reason, right down to the last byte. Marketers will always want a fresh dataset. However, when the goods are on your Urbit, you can at least demand the respect you deserve. Long term, we expect a transparent market for data, not an opaque "agreement". An analytics company wants to track everything you see and do on Urbit? They better be paying well.
2068−
2069−Eliza doesn't pay respondents. Her collection is a charity to Urbit's developers. (We're also still busy enabling payments on Urbit with the Bitcoin wallet.) However, her presence is not a term of service either. In a few years, by the nth time some smart aleck uses Eliza's chatbot code and conjures 'Zalexa' to attempt an intrusion upon your Calm™, we will see the economics of Urbit's architecture suddenly vivify. Blacklists, reputation systems, and, eventually, even data markets, all Urbit primitives envisioned long ago, will become real. We won't need Zoogle to underwrite a spam filter for the entire internet; the scarcity of Urbit address space, in tandem with a true web-of-trust, handles that.
2070−
2071−If Urbit is to be used worldwide, the old system will not go down without a fight. Spammers, spies, and digital robber-barons will hunt for ways to game Urbit. Our passage out of the digital gutter is beginning in earnest, and we are thrilled to put our new architectures to the test.
2072−]]></content:encoded>
2073− </item>
2074− <item>
2075− <title><![CDATA[A brief update from urbit.org]]></title>
2076− <link>https://urbit.org/updates/2021-02-19-update</link>
2077− <guid>https://urbit.org/updates/2021-02-19-update</guid>
2078− <pubDate>Thu, 18 Feb 2021 00:00:00 GMT</pubDate>
2079− <content:encoded><![CDATA[
2080−Hello!
2081−
2082−This week we’re introducing our newest grants program, Scholarships, sharing an update on the Urbit community, and introducing the newest members of the Urbit Foundation team. We’ve also got some important infrastructure updates about King Haskell and an overhaul of our Getting Started guide. Let’s dive in:
2083−
2084−1 - Scholarships
2085−
2086−I’m excited to announce the (soft) launch of a new type of grant we’re calling “Scholarships.” The big idea behind the program is to grow the base of individuals that can contribute to Urbit through hands-on, one-to-one mentorship with infrastructure engineers at Tlon.
2087−
2088−The program works by first having an infrastructure engineer define and scope a project, and then pairing them with someone from the community. Unlike other grants, these projects are centered on platform development, meaning Arvo or Vere, rather than on userspace development. Scholars will learn much about how Urbit works, take on impactful infrastructure projects, and gain insight into how infrastructure engineers think about building Urbit.
2089−
2090−We’ve begun scholarships with two members of the Urbit community who have demonstrated high technical aptitude and commitment via grants or other open-source projects. We don’t have any additional openings at this time, but expect to have a few more in the coming months.
2091−
2092−If you’re interested in a scholarship, sign up for the waitlist here: https://airtable.com/shr6Xmo55h8dZ0O46
2093−
2094−2 - Community
2095−
2096−Our community has been pretty busy lately. Here’s a non comprehensive list of what they’ve been up to:
2097−
2098−- ~timluc-miptev completed the Bitcoin gall agents. They’re now being integrated into Landscape as a wallet.
2099−- ~sovmep-ripsum finished his work on ucal, an iCalendar-compatible calendaring backend for Urbit.
2100−- ~tabnus-fondeg began work on Urbit LFS (large file storage) for providing file sharing and hosting support.
2101−- ~sipfyn-pidmex is writing a comprehensive suite of documentation for graph-store to enable an easier on-ramp to building new social applications.
2102−- ~minder-folden launched a new hosting provider that you can check out here: https://escapepod.store
2103−- ~naltyc-wornes is contributing a set of official, battle-tested guides for running Urbit on “smol” devices to the urbit.org website.
2104−- ~hocdep-labtul hosted his first Urbit UTC meetup, which featured ~timluc-miptev and received great attendance. We’re looking forward to the next one featuring ~nartes-fasrum on the Aesthetics of Urbit. Learn more here: https://www.urbit.computer/utc/#upcoming-meetups
2105−
2106−We’ll have a flurry of new bounties coming online in the upcoming weeks, so keep your eyes peeled —there might even still be an open one! Check them out here: https://grants.urbit.org/bounties.
2107−
2108−If you’ve got an idea you’d like to work on, make sure to submit a proposal. you’re not quite sure how to get started, book some time with me here and I can help you figure it out: https://calendly.com/wolref
2109−
2110−3 - Foundation growth
2111−
2112−This month the Urbit Foundation grew by 200%, which is less astounding when you know that it grew from one person to three. Nonetheless, this is a significant milestone for the community-focused arm of Urbit.
2113−
2114−~timluc-miptev (aka Tim) joins us from the developer community, where he’s been a prominent figure for some time as the creator of the popular Nock for Everyday Coders guide (https://blog.timlucmiptev.space/part1.html) and Complete Guide to Gall (https://github.com/timlucmiptev/gall-guide). He’s become a thoroughly proficient Hoon developer and Urbit architect through his work on Bitcoin integration, and will now be working to design grants and guide contributors in their development of their projects.
2115−
2116−~taller-ravnut (aka Mike) is passionate about community formation, and is excited to start working on supporting those that wish to host Urbit Meetups in their cities, universities, and timezones (since, at time of writing, IRL isn’t much of a thing). He’ll also be performing outreach to developers and developer communities to help spread the word and grow the contributor base of Urbit.
2117−
2118−There’s still tons of work to do and I don’t expect Tim and Mike to be the last additions to the team this year. If you’re interested in working at the UF, send me a DM for an invite to the group.
2119−
2120−4 - King Haskell
2121−
2122−King Haskell is a rewrite of the part of Urbit that talks to Unix and the outside world. When you switch to KH, the part of Urbit that runs Nock code stays the same. Importantly, King Haskell includes better facilities for NAT traversal, which should improve connectivity issues for self-hosted ships.
2123−
2124−As its name suggests, King Haskell is written in the Haskell programming language. Haskell is much easier (and more fun) for rapid development than C, and lightyears better for writing correct, bug-free code. As a result, we expect faster iteration times and more reliability in this part of the system.
2125−
2126−King Haskell is being shipped as part of a v1.2 release of the Urbit binaries. To run an existing ship with the King, say
2127−
2128−./urbit-king run path/to/your/pier
2129−
2130−To create a new ship, use the `urbit-king new` command.
2131−
2132−If you run into any problems doing this, or notice any incompatible behavior, please inform the authorities immediately.
2133−
2134−The Tlon Corporation is also using this new software on some of its infrastructure galaxies, but third party infrastructure ships should wait for further notice from us before doing so.
2135−
2136−5 - Getting Started guide
2137−
2138−Two members of our community have put a bunch of work into giving our Getting Started (formerly called Install + Setup) guide a facelift. They simplified the language, made the options much clearer, and improved some confusing instructions.
2139−
2140−If you’re looking to try Urbit or know someone that would want to run it, give our guide a try and let us know what you think!
2141−
2142−https://urbit.org/using/install/
2143−
2144−--
2145−
2146−That’s all for now. ~roslet-tanner will be in touch in a few weeks with an update from Tlon. See you on the network!
2147−Josh / ~wolref-podlex
2148−
2149−https://twitter.com/urbit
2150−https://github.com/urbit/urbit
2151−]]></content:encoded>
2152− </item>
2153− <item>
2154− <title><![CDATA[2020 -> 2021]]></title>
2155− <link>https://urbit.org/blog/2020-to-2021</link>
2156− <guid>https://urbit.org/blog/2020-to-2021</guid>
2157− <pubDate>Wed, 20 Jan 2021 00:00:00 GMT</pubDate>
2158− <content:encoded><
2162−
2163−<br>
2164−
2165−In this post, which has been adapted from our most recent [newsletter](https://urbit.us11.list-manage.com/subscribe/post?u=972a03db9e0c6c25bb58de8c8&id=be143888d2), we'll take a moment to reflect on the events of the last year, and then turn our attention to the next one.
2166−
2167−## 2020
2168−
2169−In spite of the many challenges presented over the last year, it was a resoundingly good one for Urbit.
2170−
2171−It seems like a long time ago now that the folks at Tlon rolled out OS1 (now called Landscape), just as the pandemic forced everyone into their homes throughout the world. At the time, [Urbit is for Communities"](https://urbit.org/blog/urbit-is-for-communities/) was just a vision, but now it’s been transformed into reality—there are more thriving communities in Landscape than any of us can keep track of, with new faces popping onto the network on a daily basis.
2172−
2173−Landscape brought many new ships onto the network which helped identify those areas in which Urbit’s infrastructure could be most improved. [Ford Fusion](https://urbit.org/blog/ford-fusion/) eliminated the possibility of a partially-applied over-the-air (OTA) update through a drastic reduction in the size and complexity of the codebase. The efficiency of the OTA process was improved by several orders of magnitude, and many long-standing memory issues were resolved. Now we deploy code on our infrastructure nodes and see users receive an update, over a decentralized network, often in less than a minute.
2174−
2175−After improving the stability of the system Tlon turned its attention to bringing more ships onto the network. A long-standing barrier to Urbit’s adoption has been the technical knowledge required to host one’s own ship—this prompted Tlon to build and launch an Urbit [hosting service](https://tlon.io), the waitlist for which is now thousands deep.
2176−
2177−With Tlon becoming more singularly focused on building products on Urbit, concrete steps have been taken towards making urbit.org a separate organization that’s focused on long-term development of Urbit’s platform. I joined to [lead that effort](https://urbit.org/blog/first-steps-towards-urbit-org/) back in August and have since spent the majority of my time working with dozens of contributors on projects spanning documentation, education, external integrations, and much more.
2178−
2179−We rounded out the year with a full network reset (called a “continuity breach”), which has in the past has been synonymous with loss of all data on the network. This time things went differently: tooling was made available to the community that allowed ships to preserve their data, which enabled most to seamlessly rejoin post-reset. This is a significant milestone for the project as it signifies not only a commitment to technical excellence, but to supporting our budding community.
2180−
2181−## 2021
2182−
2183−In the last three weeks we’ve seen a huge amount of inbound interest as people are waking up to the inherent problems with using centralized services run by MEGACORPs—we’re just happy we started working on Urbit all those years ago. While we tend to not plan more than about six months in advance, I can still talk at a high level about what urbit.org will be focusing on in the immediate future.
2184−
2185−Growth in Urbit’s developer community has been growing organically in lockstep with the overall network growth. This means, happily, that there’s a pretty large pool of people eager to contribute to Urbit. The priority for urbit.org, therefore, is to improve its capacity to effectively assist contributors. In broad strokes, this means:
2186−
2187−- Rework urbit.org to better help developers learn how to contribute to Urbit
2188−- Since Urbit is ready to build on top of, provide practical guides that demonstrate how to do so
2189−- Guide developers to make high-value contributions to Urbit and its ecosystem
2190−- Build community amongst contributors
2191−
2192−My strategy to date has been heavily focused on working directly with contributors to provide technical guidance and direction, and it’s been working really well. To that end I’ll also be scaling our ability to provide such support by bringing more individuals into urbit.org that can mentor, review work, and provide guidance on where to best direct contributors' energy.
2193−
2194−2021 is shaping up to be a big year for Urbit, and we'd [love your help](https://grants.urbit.org) in building it. If you want to see what we're working on in real time, join us in Landscape at ~wolref-podlex/foundation.
2195−
2196−See you on the network!
2197−]]></content:encoded>
2198− </item>
2199− <item>
2200− <title><![CDATA[A brief update from urbit.org]]></title>
2201− <link>https://urbit.org/updates/2021-01-15-update</link>
2202− <guid>https://urbit.org/updates/2021-01-15-update</guid>
2203− <pubDate>Thu, 14 Jan 2021 00:00:00 GMT</pubDate>
2204− <content:encoded><![CDATA[
2205−Hello, and happy new year!
2206−
2207−As is customary for the first communication of the new year, I’ll be doing a retrospective of what was accomplished last year and a forward look at urbit.org’s priorities for next year. Make sure to read to the end for the details about our upcoming Town Hall event!
2208−
2209−1 - 2020
2210−
2211−In spite of the many challenges presented over the last year, it was a resoundingly good one for Urbit.
2212−
2213−It seems like a long time ago now that the folks at Tlon rolled out OS1 (now called Landscape), just as the pandemic forced everyone into their homes throughout the world. At the time, “Urbit is for Communities” (https://urbit.org/blog/urbit-is-for-communities/) was just a vision, but now it’s been transformed into reality—there are more thriving communities in Landscape than any of us can keep track of, with new faces popping onto the network on a daily basis.
2214−
2215−Landscape brought many new ships onto the network which helped identify those areas in which Urbit’s infrastructure could be most improved. Ford Fusion eliminated the possibility of a partially-applied over-the-air (OTA) update through a drastic reduction in the size and complexity of the codebase. The efficiency of the OTA process was improved by several orders of magnitude, and many long-standing memory issues were resolved. Now we deploy code on our infrastructure nodes and see users receive an update, over a decentralized network, often in less than a minute.
2216−
2217−After improving the stability of the system Tlon turned its attention to bringing more ships onto the network. A long-standing barrier to Urbit’s adoption has been the technical knowledge required to host one’s own ship—this prompted Tlon to build and launch an Urbit hosting service (https://tlon.io), the waitlist for which is now thousands deep.
2218−
2219−With Tlon becoming more singularly focused on building products on Urbit, concrete steps have been taken towards making urbit.org a separate organization that’s focused on long-term development of Urbit’s platform. I joined to lead that effort back in August (https://urbit.org/blog/first-steps-towards-urbit-org/) and have since spent the majority of my time working with dozens of contributors on projects spanning documentation, education, external integrations, and much more.
2220−
2221−We rounded out the year with a full network reset (called a “continuity breach”), which has in the past has been synonymous with loss of all data on the network. This time things went differently: tooling was made available to the community that allowed ships to preserve their data, which enabled most to seamlessly rejoin post-reset. This is a significant milestone for the project as it signifies not only a commitment to technical excellence, but to supporting our budding community.
2222−
2223−2 - 2021
2224−
2225−In the last two weeks we’ve seen a huge amount of inbound interest as people are waking up to the inherent problems with using centralized services run by MEGACORPs—we’re just happy we started working on Urbit all those years ago. While we tend to not plan more than about six months in advance, I can still talk at a high level about what urbit.org will be focusing on in the immediate future (Tlon’s next newsletter will provide a similar overview of what they’re working on).
2226−
2227−Growth in Urbit’s developer community has been growing organically in lockstep with the overall network growth. This means, happily, that there’s a pretty large pool of people eager to contribute to Urbit. The priority for urbit.org, therefore, is to improve its capacity to effectively assist contributors. Concretely, this means:
2228−
2229−- Rework urbit.org to better help developers learn how to contribute to Urbit
2230−- Since Urbit is ready to build on top of, provide practical guides that demonstrate how to do so
2231−- Guide developers to make high-value contributions to Urbit and its ecosystem
2232−- Build community amongst contributors
2233−
2234−My strategy to date has been heavily focused on working directly with contributors to provide technical guidance and direction, and it’s been working really well. To that end, I’ll also be scaling the Foundation’s ability to provide such support by bringing more individuals into urbit.org that can mentor, review work, and provide guidance on where to best direct contributors’ energy.
2235−
2236−If you’re interested in helping build Urbit, you can head over to https://grants.urbit.org to claim a bounty or submit a proposal, join the Landscape group ~wolref-podlex/foundation to stay in the loop about what urbit.org is up to, or contact me directly at josh@urbit.org.
2237−
2238−3 - Town Hall
2239−
2240−In mid-February, we’ll be holding our first ever “Town Hall” event—it’s like a developer call, but longer, with more speakers, and covering a wider range of topics (not all of them technical!).
2241−
2242−We’re currently looking for speakers, so if you have an Urbit-related topic that you’d like to present, or would like to nominate someone else to present, please reach out to me by replying to this email. This could be an application you (or the nominee) has designed or built, an interesting use case, a design case study, or something completely different. Please don't be shy about reaching out—we're happy to work with you to figure out whether it makes sense to present a given topic, and how best to do so!
2243−
2244−Once we’ve finalized a date, we’ll broadcast it over our official Meetup group (https://www.meetup.com/urbit-sf/) and on Twitter. Stay tuned.
2245−
2246−--
2247−
2248−As a reminder, Urbit and Tlon have now split their newsletters in two—Urbit’s newsletter will cover the project and development community, while Tlon’s will focus more on the product development work on Landscape and the communities that form there. Tlon’s newsletter will arrive at the end of the month.
2249−
2250−That’s all for now. See you on the network!
2251−Josh / ~wolref-podlex
2252−
2253−https://twitter.com/urbit
2254−https://github.com/urbit/urbit
2255−]]></content:encoded>
2256− </item>
2257− <item>
2258− <title><![CDATA[Ames Security Audit and the Future of the Protocol]]></title>
2259− <link>https://urbit.org/blog/security-audit</link>
2260− <guid>https://urbit.org/blog/security-audit</guid>
2261− <pubDate>Thu, 17 Dec 2020 00:00:00 GMT</pubDate>
2262− <content:encoded><
2266−
2267−<br>
2268−
2269−The security firm Leviathan has now finished their initial audit of the security of Urbit's Ames network protocol. In addition to their review of Ames, we also asked them to identify any other issues in order to help guide further development.
2270−
2271−I'm pleased to report they confirmed the cryptographic soundness of the protocol, namely that "a ship must have possession of their own valid Urbit key in order to authenticate as that ship and to send valid Ames messages. Additionally, no other ship except the two communicating may be able to decrypt or modify messages during transport."
2272−
2273−This means Ames uses cryptography in a mathematically sound manner that protects your privacy, keeps your secrets secret, and ensures nobody else will be able to impersonate you on the network. Since this was an architectural audit, it’s possible there are still vulnerabilities in the runtime implementation. Until the runtime has been hardened, Tlon continues to recommend against storing valuables in your ship.
2274−
2275−Aside from a couple of minor issues that have already been resolved, there are three general classes of problem highlighted in their report that future work will need to address:
2276−
2277−- Forward secrecy
2278−- Protection against denial of service attacks
2279−- Enforcement of social boundaries
2280−
2281−Ames’ design allows for versioning of the protocol, which means that the proposed changes below can be deployed as over-the-air updates as they become more pressing concerns. This feature gives us confidence that we can address future security issues as they arise.
2282−
2283−We will need to improve all of these over the next couple of years, as independent lines of work. As the network grows: better forward secrecy will decrease the damage from a key getting compromised; resistance against denial of service attacks will make the Urbit network resilient to increasingly determined saboteurs; and stricter enforcement of social boundaries will let Urbit’s social networks remain safe and friendly despite potentially increasingly large numbers of bad actors and increasingly complex app ecosystems.
2284−
2285−## Forward Secrecy
2286−
2287−A protocol is said to have forward secrecy if compromising a key used in a recent message doesn’t also compromise all previous messages. Similarly, a protocol is said to have backward secrecy -- also called future secrecy -- if compromising a key used in a previous message fails to compromise all future messages. Ames has some degree of both, but more would be better, to decrease the damage an attacker could inflict by compromising a key.
2288−
2289−As it stands, an Urbit user can change their Ames keys whenever they want, by conducting an Ethereum transaction to update the Ames public key listed in the Azimuth contract, which implements Urbit’s PKI on Ethereum. Compromise of one Ames private key does not compromise earlier or later keys, so this has both forward and backward secrecy. The main drawback is that Ethereum transactions can be expensive, so key rotation is likely to be infrequent, and an attacker might be able to gain access to a long stretch of time by compromising a single key.
2290−
2291−Various key rotation “ratchet” schemes could be added to Ames to establish varying degrees of forward and backward secrecy, and other kinds of cryptographic protections beyond basic soundness, such as break-in recovery.
2292−
2293−Right now, changing a key through Azimuth is a manual process. It could be automated, possibly as one of a suite of services that an Urbit Provider will offer. Unfortunately, each key rotation costs the user money, so automating rotation could get prohibitively expensive.
2294−Existing protocols, such as the Signal app's encrypted messaging protocol, the Noise protocol framework, and the Wireguard VPN protocol, use ephemeral Diffie-Hellman key exchange and KDF chaining to achieve forward and backward secrecy and self-healing.
2295−
2296−Ames could be upgraded to use one of these existing ratchet algorithms, or we might create an Urbit-specific variant optimized for the Urbit network. This is work that should be done, but fortunately it will not require any novel research or drastic changes to Ames’s architecture.
2297−
2298−While Urbit’s cryptographic protections don’t yet match those of Signal or a few other privacy-focused apps, Ames is cryptographically sound, and since Urbit updates itself over-the-air and is backed by a stable, decentralized PKI, I’m confident that the level of sophistication of Urbit’s cryptography has the potential to be world-class with just a bit more work.
2299−
2300−## Denial of Service
2301−
2302−A denial of service (DoS) attack against an Urbit ship is an attempt to overwhelm it remotely by sending it network data in such a way as to interfere with the ship’s ability to communicate with other ships or process other events -- usually by hogging its resources (computational power, memory, or bandwidth) until normal operation slows down or ceases entirely. Since the promise of Urbit is that everyone can run their own server, that server needs to be able to defend itself against DoS attacks. This is in fact one of the main impediments to running your own server in the modern world.
2303−
2304−Right now, Urbit has no protection. Soon, it will need to at least be able to resist a simple attack carried out by an individual. Eventually, it should be able to resist a determined Distributed Denial of Service (“DDoS”) attack, which is more difficult.
2305−
2306−There are two categories of DoS attacks in Urbit: authenticated and unauthenticated. An authenticated attack requires access to a ship's private key to construct valid Ames packets intended to overwhelm a target. All authenticated attacks will be handled primarily through enforcement of social boundaries, as discussed in the next section.
2307−
2308−An unauthenticated DoS attack constructs packets that eventually fail to authenticate and decrypt but still overwhelm the target by causing it to waste resources (CPU, memory, disk, bandwidth) in such a way that it can't keep up with legitimate communications.
2309−
2310−An unauthenticated DoS attack relies on the lack of Sybil resistance of IP networks: it's possible to generate new IP addresses rapidly, and a determined attacker might also be able to spoof its sender IP address. This is best considered an IP-layer attack that must be handled mostly at the IP layer itself, by maintaining state about which IP addresses can be trusted and which can't, determined empirically and heuristically by the Urbit runtime. The best any higher-level protocol, such as Ames or TCP, can do is make it as cheap as possible for a DoS target to reject a bad packet.
2311−
2312−The overall strategy that Ames can take, as a protocol layering over the IP protocol, is to add an authentication procedure to each packet that can quickly identify bad packets, which an implementation will then use to mark that IP address as suspect and to refrain from adding the sender IP to a list of known-good IPs.
2313−
2314−Currently, Ames handles this by attempting to decrypt a message and rejecting the message on failure. This may be a more costly solution than other methods, such as attaching a signature or a MAC to each message. The way to mitigate unauthenticated attacks is to make bad packets fail faster by augmenting each packet with a signature or MAC to each packet, since those are faster to validate than encryption.
2315−
2316−So far, we have identified three approaches that could be taken here. Of these three, Leviathan recommended the end-to-end HMAC solution, since that would not impose additional CPU requirements on packet-relay nodes, such as stars.
2317−
2318−- Sign each packet, and any relay or final recipient could validate the signature
2319−- Wrap each packet in an HMAC, validated by the final receiver
2320−- Wrap each packet in a HMAC for each hop in a relay chain; each relay would validate and strip the previous HMAC and add a new one for the next hop
2321−
2322−Any of these solutions would be attempts to increase the rate at which the network could discard invalid packets, with different tradeoffs. I'll back up a bit to provide some context, and then I'll compare the approaches.
2323−
2324−In any DoS solution, a planet will want to block or throttle IPs that have been sending it packets that fail to authenticate and decrypt. Ideally, a star will help protect planets for whom it’s relaying, too. Many different arrangements among galaxy, star, and planet are imaginable here, from an open policy to a policy wherein each packet has to come from a known-good IP. This sort of paranoid, closed-off arrangement might still not be enough to withstand a determined DDoS, but it's difficult for me to imagine doing better than that without launching Urbit-specific ISPs. Ames packets are cryptographically authenticated, so an Urbit ISP would actually be feasible.
2325−
2326−This brings us back to the three possible ways of mitigating DoS from within the Ames protocol. They all involve adding a piece of authenticating information to each packet that can be verified more quickly than waiting for the cyphertext to fail to decrypt — Ames's symmetric encryption is authenticated, so it's not a cryptographic soundness issue, but the performance impact of trying to decrypt could be significant enough to make it hard to prevent a DoS.
2327−
2328−As-is, an Ames packet is basically `[protocol-version checksum sndr rcvr (nullable origin) cyphertext]` (visit [this PR](https://github.com/urbit/urbit/pull/4051#issue-530369627) for a full specification). Let’s walk through the construction of the packet and how it can be upgraded to offer different DOS mitigations.
2329−
2330−### DoS Mitigation Approach 1: Signature
2331−
2332−The first approach to DoS protection would be to add a signature to the packet. The signature would cover everything except the checksum and the origin, since those need to be swapped out by relays. The signature would probably obviate the need for the (20-bit) checksum, although we could also leave it in there if we can't figure out what else to do with those header bits.
2333−
2334−#### Advantages of a signature over other approaches
2335−
2336−- It can be validated by anyone on the network. Relays would not need to modify it. This might also give it symmetry with the upcoming remote scry protocol, which might also sign every packet. I'm not quite sure this is an important property, actually, but it might theoretically make launching an Urbit ISP or internet backbone easier one day.
2337−- It would be signed directly by the key listed on Ethereum, not something that might get ratcheted at some point for better forward secrecy — this could eventually lower the rate at which intermediate validators need their key caches invalidated, although this is a bit of a theoretical concern.
2338−
2339−#### Disadvantages of a signature over other approaches
2340−
2341−- Generating and validating a signature is significantly slower than generating and validating an HMAC.
2342−- An ECDSA signature is 64 bytes, which is ~6% of a packet payload. As far as I can tell, it can't be compressed.
2343−- Since the signature could be validated by anyone, it doesn't attest to a specific communication channel, so it might not help as much with IP filtering.
2344−
2345−### DoS Mitigation Approach 2: End-to-End HMAC
2346−
2347−The second approach would be to use an HMAC instead of a signature, validated by the eventual receiver. This HMAC would also cover everything except the mug and origin. I'm calling this the "end-to-end HMAC" design. An HMAC requires a shared secret, for which we could use the same symmetric key that Ames uses.
2348−
2349−#### Advantages of end-to-end HMAC
2350−
2351−- It's simple in some sense; relays don't need to do anything cryptographic.
2352−- HMACs are much faster to create and validate than signatures.
2353−- HMACs, since they're hashes, can be truncated arbitrarily and still maintain some security — to find hash collisions, you'd still have to guess what packet||shared-secret would hash to; it would just be a smaller search space. Since Ames's encryption already guarantees authentication and we'd just be using this as a performance optimization, I suspect we could get away with using one that's significantly smaller than a signature — I'm not sure how small, but if 4 bytes would be enough in practice, that would take up less than 0.5% of the space in a packet.
2354−
2355−#### Disadvantages of end-to-end HMAC
2356−
2357−- Only the recipient can validate. This means the authentication couldn't be used by relays to discard invalid packets. The recipient could provide back-pressure out-of-band to a relay to ask the relay to discard packets from an IP with an invalid HMAC, but this is indirect and might need to filter backward through multiple relays to work properly.
2358−
2359−### DoS Mitigation Approach 3: Point-to-Point HMAC
2360−
2361−The third approach, which is what I would build unless convinced otherwise, is what I'm calling "point-to-point HMAC". This design would include a different HMAC for each hop in a relay chain, instead of (or maybe in addition to) including one end-to-end HMAC.
2362−
2363−We have a couple different options for how to construct the shared secret for each hop. I would intuitively construct it using a Diffie-Hellman of my private signing key and your public signing key — the "networking keys" on Ethereum include a currently unused signing key in addition to the encryption key that Ames uses. This way even if we add more forward secrecy to Ames, changing the symmetric key used for encryption, relays wouldn't have to have their caches invalidated as often; the state required to perform relaying wouldn't be as tied to the state required to receive a message.
2364−
2365−#### Advantages of point-to-point HMAC
2366−
2367−- A star could perform some validation on every packet it's asked to relay. This makes it more difficult for an attacker to route a ton of packets to a planet through a star, or even through many relays. Signatures also have this property, but they're slower to verify. This approach and the signature approach, but not the end-to-end HMACs, force an attacker to use an (at least partially) authenticated attack in order to use a relay as a way to get to a planet.
2368−- A planet could quickly validate that a relayed packet actually came from its star, not an attacker who's managed to spoof the star's IP address.
2369−
2370−#### Disadvantages of point-to-point HMAC
2371−
2372−- Not everyone on the network can validate a packet, unlike a signature.
2373−- Each relay needs to validate and strip off the previous HMAC and create a new one before sending it. This should be quite fast, since an HMAC is just a hash, but it's still some CPU, and potentially creates an imbalance where an attacker could induce the relay to spend more CPU in validation than the attacker spent in constructing the packets.
2374−- By itself, it doesn't validate the cyphertext in an end-to-end way. I suspect we might want to include both a per-route HMAC and an end-to-end one, especially if we use truncated HMACs — although per-route might be enough on its own, since if the receiver fails to validate a bunch of packets whose HMACs were validated by the relay, the receiver can ask the relay to block that whole Urbit address regardless of IP, so it shouldn't be possible to sustain that kind of attack for long.
2375−
2376−#### An Aside About Cryptographic Performance
2377−
2378−I'm not sure exactly how much faster HMAC is. According to DJB (https://ed25519.cr.yp.to/ed25519-20110705.pdf), an ECDSA signature can be created in around 30 microseconds and verified in around 100 microseconds. This source (https://www.jacksondunstan.com/articles/3206) suggests about 21 microseconds for HMAC-SHA256, so about a 1.5x improvement in generation speed and 5x in validation speed. We should verify these numbers for ourselves before making a decision.
2379−
2380−### DoS Protection Strategy and Timeline
2381−
2382−Tlon is not currently pursuing adding any of the extra cryptographic authentication on Ames packets described above. Since this is ultimately a performance issue, there are other more pressing performance issues that we could improve upon before decryption will become the limiting factor in how many packets can be processed by a ship. We will revisit this authentication performance question once some of the low-hanging fruit has been done, perhaps roughly a year from now.
2383−
2384−Since the audit, we’ve already improved the Ames packet format to allow faster parsing, faster validation of basic fields, and faster relaying; in the future, increases in performance of Nock execution and inter-process communication between Urbit's I/O process and Nock worker would allow Urbit to absorb somewhat more punishment before service can be effectively denied.
2385−
2386−## Enforcement of Social Boundaries
2387−
2388−While Urbit needs to rely largely on its runtime to mitigate unauthenticated attacks, any attack conducted from an Urbit ship needs to be handled inside Arvo itself, not just by IP filtering in the runtime. Just like in any DoS, an attacker ship might try to induce you to use too much memory, CPU, or disk space in order to sabotage normal operation. An authenticated attack is harder to define than an unauthenticated attack, because it depends on what social relationship the attacker and target have, and it involves valid, authenticated Ames packets; once discovered, though, it’s easier to mitigate, because it can use Urbit’s permanent identity system to enforce social consequences, i.e. stop listening to that Urbit address and possibly encourage others to do so as well.
2389−
2390−There are a couple of different kinds of authenticated attack: attempts to exploit vulnerabilities in the Nock worker (the interpreter, allocator, and jets) by causing particular Nock code to run, and attempts to induce the target to exhaust various computational resources.
2391−
2392−Protecting against attempts to break out of the sandbox and hijack or otherwise interfere with the Unix process running Nock will require a process of hardening, fuzzing, and likely further security audits specifically evaluating the security of that boundary. This is largely out of scope of the Ames protocol itself, which was the subject of this audit.
2393−
2394−This leaves us with the latter case: resource exhaustion attacks. A peer could try to get my ship to use too much RAM, disk, CPU, or bandwidth by sending it valid Ames packets. This represents a social problem: a person on the network is trying to interfere with me. It's what's known in blockchain circles as an "attributable fault": once the attack is detected, it's trivial to determine the identity of the culprit.
2395−
2396−Once the attacker’s Urbit address is known, Urbit will fall back on the Sybil resistance of its identity system: there are a finite number of identities, each of which costs some money. Because Urbit identities are relatively permanent, they can be blocked permanently. As long as the expected value of an authenticated attack is less than the cost of the identity, the attacks won't happen very much — they'll cost money to sustain, instead of being self-perpetuating.
2397−
2398−Attacks like this are best thought of as attempts to violate social boundaries. I don't want you using up too many of my resources; that's a social boundary, and an attempt to force my ship to spend its resources on your behalf constitutes a violation of this boundary. The strategy for mitigating these attacks is to impose social and, indirectly, economic consequences on the perpetrators. The main social consequence is other ships refusing to communicate with you anymore.
2399−
2400−Some of this mitigation will take place in the Arvo kernel, and some will need to be application-specific. To protect the system from attackers, the kernel needs to be able to free space (Urbit is a single-level store, so there's no distinction between disk and RAM from Arvo's perspective) taken up by unfinished messages sent by peers. This can be done by allowing an application to ask Ames to delete partially received messages from a peer, generally replacing the received packets with an intent to nack (negative acknowledgment) to indicate that the transaction the peer wanted me to perform has been rejected.
2401−
2402−Applications should also be able to set resource usage policies that the Arvo kernel will enforce. For example, a chat application should configure Ames to reject any chat messages larger than, say, two hundred kilobytes. A file-sharing application would need a much larger per-message limit (ideally no per-message limit), but it might need to place a cap on its bandwidth usage to make sure lower-latency communications aren't swamped by a large file transfer. This kernel/application interface starts to resemble a permissioning or capabilities system, and it could be built as part of the crucial larger project of providing for configurable application permissions.
2403−
2404−To close the loop on enforcing social boundaries, reputation information should be shared across ships. This will likely be done by building one or more applications that share statistics and block operations. Some forms of reputation are likely to be globally shared, whereas others are likely to be multipolar, i.e. some people like you and some don’t. Generally, the lower the layer of the attack, the more global the reputation effect will be; the higher the layer, the more multipolar. An attempt to spam the network with millions of malicious packets will cause most people not to want to talk to you; sending me a movie I found mediocre is probably not even information worth sharing with anyone else.
2405−
2406−## Conclusion
2407−
2408−Ames’ design has unparalleled potential to deter, mitigate, and recover from attacks, since every packet is authenticated and encrypted and backed by a stable, decentralized PKI. It feels good to have our design for encryption and authentication be confirmed by a third party as cryptographically sound, and we know more or less what we need to build to reach the full security potential of the platform, including the steps outlined here.
2409−]]></content:encoded>
2410− </item>
2411− <item>
2412− <title><![CDATA[Input and Output in Hoon]]></title>
2413− <link>https://urbit.org/blog/io-in-hoon</link>
2414− <guid>https://urbit.org/blog/io-in-hoon</guid>
2415− <pubDate>Tue, 15 Dec 2020 00:00:00 GMT</pubDate>
2416− <content:encoded><
2420−
2421−<br>
2422−
2423−Let's talk about IO in Urbit. I won't say much about how events and effects are processed by the runtime; it suffices to note that the runtime is a normal Unix program which (1) listens for various events, (2) passes them to Arvo (Urbit OS), and (3) processes the effects produced by Arvo. Instead, I’ll focus on how IO works from the perspective of Hoon programs, like Arvo or apps running on Arvo. But first, let's review IO paradigms in other languages.
2424−
2425−All examples are in a made-up language, since it's useful to understand this information even before you're comfortable in Hoon. If you're learning Hoon and want a challenge, try translating them!
2426−
2427−## The three styles of IO
2428−
2429−I will call these styles imperative IO, monadic IO, and state machines (note that this classification refers only to the experience of using them and the program structure they dictate). An imperative programming language can use any of these and a functional programming language can use any of them.
2430−
2431−### Imperative IO
2432−
2433−Imperative languages (such as C and Python) perform IO by calling a function in the middle of whatever they were doing. Anywhere, in any statement, you could have IO.
2434−
2435−In this example and others to follow, the task will be to read a filename from the command line, read a URL out of that file, and fetch the contents at that URL.
2436−
2437− output = fetchUrl(stripWhitespace(readFile(cliInput())))
2438−
2439−For readability, intermediate variables would be a good idea, but nothing stops you from nesting IO this way.
2440−
2441−### Monadic IO
2442−
2443−Languages that use explicit monads for IO (such as Haskell) perform IO by running IO behind a bind operation, which I'll notate with `<-`. Thus, while you can't put IO _anywhere_, the general structure is a sequence of IO operations.
2444−
2445− fileName <- cliInput()
2446− url <- readFile(fileName)
2447− output <- fetchUrl(stripWhitespace(url))
2448−
2449−[Tackling the Awkward Squad](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/mark.pdf) is the canonical description of monadic IO, and does a great job of explaining how the Haskell community decided to use this as their primary IO style.
2450−
2451−### State machines
2452−
2453−Languages that use explicit state machines for IO (such as Elm) perform IO by accepting events and producing a list of effects.
2454−
2455− event :: Initialize
2456− | CLIInput text
2457− | FileInput text
2458− | HTTPResponse body
2459− effect :: CLIInput
2460− | ReadFile fileName
2461− | FetchUrl url
2462− | Print text
2463− main(event) {
2464− switch event {
2465− Initialize -> [CLIInput ~]
2466− CLIinput fileName -> [ReadFile fileName]
2467− FileInput url -> [FetchUrl stripWhitespace(url)]
2468− HTTPResponse body -> [Print body]
2469− }
2470− }
2471−
2472−The effects produced are not functions but data.
2473−
2474−It's important to note that this example is chosen to highlight a particular kind of IO — sequences of events. Further, this example has no persistent state — each IO operation is a pure function of the output of the previous one.
2475−
2476−## A stateful, loopy example
2477−
2478−Let's look at another type of program: a simple HTTP server that you can give text at the CLI, which will respond to all HTTP requests with that text.
2479−
2480−Imperative:
2481−
2482− text = "no text entered yet"
2483− while (true)
2484− cli = readCli()
2485− if (cli != Null)
2486− text = cli
2487− request = readHttp()
2488− if (request != Null)
2489− respond(request,text)
2490−
2491−Monadic:
2492−
2493− loop("no text entered yet")
2494−
2495− where:
2496−
2497− loop :: text -> IO Null
2498− loop =
2499− input <- readInput()
2500− switch input
2501− CLIInput newText -> loop(newText)
2502− HTTPRequest request ->
2503− _ <- respond(request,text)
2504− loop(text)
2505−
2506−State machine:
2507−
2508− text = "no text entered yet"
2509− main(text,event) {
2510− switch event {
2511− CLIInput newText -> [newText, Null]
2512− HTTPRequest request -> [text, HTTPResponse text]
2513− }
2514− }
2515−
2516−Again, note the response in the state machine is data, not a function.
2517−
2518−I'm not trying to make a point about which type is better in general. There's a pretty strong argument that in the first example, imperative was the best option, followed by monadic, followed by state machine. There's an equally strong argument that the second example is most naturally represented by the state machine.
2519−
2520−Look at how state is handled in the monadic example. Formally, bind composes functions, so that every time you see a `<-` there's actually a new function (closure/delimited continuation) being created and stored for when we receive a response. All variables in scope are stored in that closure, so we can conveniently access them later without explicitly storing them. However, the state we preserve over time varies a lot. In this example, it varies between storing `loop`, `[loop input]`, `[loop input newText]`, and `[loop input request]`.
2521−
2522−By comparison, the state machine does not store intermediate values, it only stores its explicit state. While this is somewhat less flexible, it puts the permanent state front-and-center.
2523−
2524−I'll reiterate that all of these are possible to implement in purely functional languages, and further they can all be implemented in terms of each other. State machines are trivially implementable -- it's just a function [state event] -> [new-state (list effect)]. Monadic IO can be implemented directly (as in Haskell) or on top of state machines by storing continuations in your state. Imperative IO is somewhat more difficult but should be possible through algebraic effects.
2525−
2526−When inventing a new system, you should consider which of these you intend to support based on the sort of code you expect to see. For example, a scripting language will almost always benefit from imperative (or at least monadic) style.
2527−
2528−## In Urbit
2529−
2530−So much for exploring the space of IO solutions. In terms of deployed code on Earth, the split is about 90% imperative, 5% monadic, and 5% state machine. In Urbit, the split is about 90% state machine and 10% monadic. This is what I intend to explain and defend.
2531−
2532−Urbit's OS is called Arvo; it has several "kernel modules" called vanes, and it has userspace applications. Colloquially these are called "apps," but when speaking about them abstractly, it's helpful to use their more specific name: ["agents"](https://urbit.org/docs/tutorials/arvo/gall/#agents). Arvo, the vanes, and agents are all structured as explicit state machines.
2533−
2534−In addition, there are ["threads"](https://urbit.org/docs/tutorials/arvo/gall/#threads), which are structured as monadic IO. Note there's only a superficial resemblance to Unix threads: they are not executed in parallel and they don't share memory, or at least not any more than agents do. They're simply a computation that takes an argument and produces a result, possibly after doing some IO, structured monadically.
2535−
2536−As you can see, all the lowest levels of Arvo are explicit state machines, and only the highest layer supports monadic IO. To see why this is the case, let's list advantages and disadvantages to each type. Note that, while I'm speaking specifically of agents and threads in the context of Urbit, these are fundamental properties of monadic and state machine IO.
2537−
2538−Agents are:
2539−
2540−- Upgradable. Since the state is explicit, you can upgrade an agent in-place by supplying a new state machine and a function from the old state type to the new state type. This is very similar to a database migration.
2541−
2542−- Robust. A state machine must accept any input at any time. If it receives unexpected input, it must have had explicit error handling for that input, since it's one of the types in the switch statement. Thus, it's relatively easy to stay in a consistent state.
2543−
2544−- Permanent. Since it's upgradable and robust, there's no reason to stop its running.
2545−
2546−- Hard to write long sequences of IO. Long sequences of IO create many possible states, and you must handle any input in any state. This can result in complex, hard-to-follow code with code paths that are rarely if ever taken.
2547−
2548−Threads are:
2549−
2550−- Not upgradable in-place. Since the state is implicit, you can only cleanly upgrade by (1) killing the thread and restarting it or (2) letting it resolve to a defined "upgradable state" periodically, usually at the top of a "main loop". If you do (2), then you are in fact structuring it as a state machine, so the other advantages of threads are compromised.
2551−
2552−- Fragile. If we don't receive expected input, the default behavior is to be stuck waiting for input. You must remember to add any error-handling features you want, and it's easy to end up in an inconsistent state.
2553−
2554−- Impermanent. Since a thread can't be upgraded and may get stuck in case of unexpected input, a thread can't be expected to last forever. It must be "rebooted" from time to time.
2555−
2556−- Easy to write long sequences of IO. Just...write the IO one line at a time.
2557−
2558−Arvo proper and the vanes are permanent pieces of software and, for this reason, state machines are more natural.
2559−
2560−I'll note that other kernels, like the Unix kernel, use imperative IO. The difference is that Unix isn't permanent in itself — it only lasts until you reboot. Since your permanent state is stored externally, you don't need to be upgradable or permanent. With sufficient discipline you can write robust C code, so it makes sense to use imperative style. Even so, a lot of C code is written in a state machine style; even if it doesn't need to be upgradable, it's worth it for the robustness and concurrency advantages.
2561−
2562−However, Arvo is a single-level store — all of its state is permanent. This is very convenient and eliminates many long-tail bugs, but it also means we need to code for permanence, and that's much easier when you structure your code with explicit state.
2563−
2564−Further, Arvo and the vanes rarely perform long sequences of IO. Generally, they do one thing and emit some effects, similar to the HTTP server example above. Sometimes they "pass through" a request. For example, the Eyre vane passes HTTP requests to userspace agents or threads. In this case, there is a sequence of IO, which in monadic code would be:
2565−
2566− loop()
2567−
2568− where:
2569−
2570− loop =
2571− request <- receiveRequest()
2572− agent = lookupAgent(request)
2573− response <- callAgent(agent, request)
2574− _ <- sendResponse(request, response)
2575− loop()
2576−
2577−This is clear code to read, but it leaves open the question of how to respond during the callAgent() function. If another request comes in, can we handle it in parallel? If we need to upgrade ourselves before the agent responds, can we make sure to properly handle the response?
2578−
2579−The naive solution in monadic code is to say that you can only handle one request at a time, and if an upgrade happens you just drop outstanding requests. You can resolve both of these by introducing a sort of main loop, which is just a way of saying "turn it into a state machine".
2580−
2581−In a state machine, the naive solution is:
2582−
2583− state :: (map request agent)
2584− main(state, event) {
2585− switch event {
2586− HTTPRequest request ->
2587− agent = lookupAgent(request)
2588− [put(state, request, agent), CallAgent agent request]
2589− AgentResponse request response ->
2590− [del(state, request), HTTPRespond request response]
2591− }
2592− }
2593−
2594−Upgrading this is trivial, since the state (map of requests to outstanding calls to agents) is explicit. It also trivially handles concurrent requests.
2595−
2596−I won't claim this is easier or harder to write than the monadic version, but it has the properties we need at this level of the system.
2597−
2598−Userspace agents similarly are permanent entities that need to not lose data or get stuck. For this reason they’re structured as state machines.
2599−
2600−A helpful comparison is that explicit state machines are basically Mealy machines, the kind you might have learned about in an introductory digital design class. This shouldn't be surprising; a digital circuit must always be consistent because it can't be manually "rebooted", and their input and output is highly formalized. By contrast, a Rube Goldberg machine doesn't have the same constraints; which is why they're a lot more fun!
2601−
2602−It's notable also that explicit state machines are considerably more declarative than imperative or monadic IO. Not everyone thinks that's a good thing, but anyone who defends functional programming should see some advantages to that.
2603−
2604−However, userspace sometimes needs to perform long sequences of IO. Let's look at an example where we want to fetch the front page of a site and the first couple comments on each story. HTTP is unreliable, so on failure we retry five times.
2605−
2606−Monadic:
2607−
2608− topStories <- fetch(topStoriesUrl)
2609− loop(topStories)
2610−
2611− where:
2612−
2613− loop :: topStories -> IO Null
2614− if topStories is Null
2615− return Null
2616− comments <- retryLoop(5,head(topStories))
2617− otherComments <- loop(tail(topStories))
2618− append(comments,otherComments)
2619−
2620− retryLoop :: [n story] -> IO Comments
2621− comments <- fetchComments(story)
2622− if comments is HTTPError:
2623− if n == 0:
2624− bail
2625− else:
2626− retryLoop(n-1, story)
2627−
2628−State machine:
2629−
2630− state :: Initial
2631− | FetchingTop
2632− | FetchingStory comments stories retries
2633− | Done comments
2634−
2635− main(state, event) {
2636− switch event {
2637− Initialize ->
2638− assert state == Initial
2639− [FetchingTop, Fetch topStoriesUrl]
2640− HttpResponse response ->
2641− switch state {
2642− FetchingTop ->
2643− [FetchingStory Null stories 5, FetchComments head(stories)]
2644− FetchingStory comments stories retries ->
2645− if response is HTTPError:
2646− if retries == 0:
2647− [Initial, Null]
2648− else:
2649− [FetchingStory comments stories retries-1,
2650− FetchComments head(stories)]
2651− else:
2652− comments = append(response,comments)
2653− if tail(stories) is Null:
2654− [Done comments, Null]
2655− else:
2656− [FetchingStory append(comments,response) tail(stories) 5,
2657− FetchComments head(tail(stories))]
2658− }
2659− }
2660− }
2661−
2662−With practice, the state machine version of this can be written correctly. However, (1) it's verbose, (2) the control flow jumps all over the place, and (3) in practice it's challenging to get exactly right. This is still a small example, and it gets much worse as the length and complexity of the IO sequence grows.
2663−
2664−The monadic version, on the other hand, flows cleanly down the page. We can factor out generic functionality like "retry this request n times" to make the essence of the computation clear.
2665−
2666−Suppose you have to upgrade this. In the state machine, you can see exactly which stage of the computation you're in and write specific code to upgrade cleanly.
2667−
2668−Threads, as we've discussed, can't be upgraded in-place. Let's be real though: we're downloading comment sections, not regulating a nuclear reactor. If we get a better version of this script, just kill the old one and start the new one from scratch. What's a couple extra HTTP requests?
2669−
2670−This suggests a general division of workloads: code which needs to be permanent, upgradable, and concurrent should generally be a state machine. Code with long or complex sequences of IO and definite termination should generally be a thread.
2671−
2672−These aren't completely mutually exclusive, but it's surprising how often they are.
2673−
2674−### Jael: a case study
2675−
2676−When you need to do something permanent and upgradable, but you also need to do long sequences of IO, the main trick is to factor your problem into both an agent and a thread (or several).
2677−
2678−As a case study, consider Jael, one of our vanes. This maintains our PKI state, which it downloads over HTTP from an Ethereum node. Downloading from an Ethereum node is a complex sequence that starts with fetching its most recent block number, then fetching all the blocks we haven't seen and scanning for transactions we care about. We also maintain a map of block hashes to block number, and if we see that a block's parent doesn't have the hash we expect, that means a reorganization has occurred, so we must "rewind" one block at a time until we find where the fork happened, then restart going forward.
2679−
2680−You don't have to understand this sequence of IO; it's sufficient to see that it's complex and must be exactly right. We used to do this in a state machine directly in Jael. This data is, of course, permanent and needs to be accessible to the rest of the system, so Jael must be a state machine.
2681−
2682−However, we had many small mistakes in this sequence of IO, some of which only appeared during unusual events, such as when an HTTP request failed at the same time as a reorganization happened.
2683−
2684−We're in a bit of a bind, though: Jael has to be a state machine. The solution is to factor out the act of getting updates into a thread while the main PKI state is stored in the state machine in Jael.
2685−
2686−This thread has a definite purpose: given the most recent block number we already know about, fetch all the PKI transactions since then. The function signature is:
2687−
2688− syncEthereum oldBlockNumber -> IO [newBlockNumber, newTxs]
2689−
2690−Jael runs this thread every five minutes and, if it succeeds, then we update our block number and PKI state. If the thread fails, gets stuck, or we need to upgrade it, we just kill the old thread and start a new one. Again, a few extra HTTP requests don’t matter.
2691−
2692−From Jael's perspective, it looks something like:
2693−
2694− state :: State block txs outstandingThread
2695− main(state,event) {
2696− switch event {
2697− Initialize -> [State 0 Null Null, StartTimer (now + five minutes)]
2698− TimerFired ->
2699− effects = If outstandingThread is Null
2700− then Null
2701− else [Kill outstandingThread]
2702− newId = newThreadId()
2703− [State txs newId,
2704− append(effects,
2705− StartThread newId syncEthereum(block),
2706− StartTimer (now + five minutes))]
2707− ThreadFinished Failure -> [State block txs Null, Null]
2708− ThreadFinished Success newBlockNumber newTxs ->
2709− [State newBlockNumber append(txs,newTxs) Null, Null]
2710− }
2711− }
2712−
2713−In other words, from Jael's perspective, it's just a single IO event that encapsulates arbitrarily complex IO in the thread. A single IO event is easy enough, and we can maintain all our permanency and robustness guarantees, because we know the thread will have one of three results: success, failure, or it hangs. If we set a timeout, hang becomes failure, so there's only two possible results: success or failure. If we handle both of those correctly, we've handled all the possible IO errors that could have occurred.
2714−
2715−What about upgrading? We've already said we can handle the thread dying for arbitrary reasons, so if an upgrade comes in, we just kill it. We can upgrade Jael's state machine easily since its state is very simple.
2716−
2717−## Recap
2718−
2719−Let's recap what we've covered:
2720−
2721−- There are three styles of IO: imperative, monadic, and explicit state machines.
2722−- Urbit supports explicit state machines (agents) and monadic IO (threads).
2723−- Explicit state machines are preferred for permanent, robust, concurrent code.
2724−- Monadic IO is preferred for short-lived code with complex IO.
2725−- If a state machine needs to perform complex IO, it should encapsulate it in a thread so that, from the perspective of the state machine, it's simple IO.
2726−
2727−Hopefully it's fairly clear why Urbit uses explicit state machines in most situations. More than anything else, our goal is to build software that can last forever. Explicit state machines are a crucial tool for that.
2728−]]></content:encoded>
2729− </item>
2730− <item>
2731− <title><![CDATA[Metaphase]]></title>
2732− <link>https://urbit.org/blog/metaphase</link>
2733− <guid>https://urbit.org/blog/metaphase</guid>
2734− <pubDate>Tue, 08 Dec 2020 00:00:00 GMT</pubDate>
2735− <content:encoded><
2739−
2740−<br>
2741−
2742−_Previous versions of this essay specified the stream deploy date as December 11, 2020; then December 18, 2020. This has been amended to the actual date of release, with our sincere apologies. For new readers, you can opt into the dev stream by running:_
2743−
2744−```
2745−|ota ~hanruc-nalfus-nidsut-tomdun %kids
2746−|merge %home ~hanruc-nalfus-nidsut-tomdun %kids, =gem %take-that
2747−|merge %kids ~hanruc-nalfus-nidsut-tomdun %kids, =gem %take-that
2748−```
2749−
2750−_We will surface this option more broadly in a future settings overhaul._
2751−
2752−A few weeks ago, the Landscape team — those of us building Tlon’s suite of userspace applications on top of Urbit— deployed our first over-the-air update for notifications. This is a big leap forward for us. Of course, getting notifications inside Landscape itself is a big deal, but getting a push notification on your phone, or an email digest based on activity inside Urbit is now just one step away, a weekend project for a hobby developer, not an indeterminate number of steps away.
2753−
2754−After release, we received some feedback from users on the behaviour and design of this feature; beyond the obvious kinks that come from an initial release, it seemed to some like a minimum viable affordance pitched as a fully designed feature. This “bottom-up” development approach was, to us, fairly straightforward; to some of our users, it seemed that we had closed the door on the feature without even beginning to expose all its possibilities.
2755−
2756−As I’ll describe, we haven’t just been iterating Landscape, but the way we develop Landscape, and the way we consider Landscape in relation to Arvo. Finally, we’ll discuss our upcoming two-stream release process: a “stable” release stream with updates every six weeks and a development stream, with ongoing changes continuously deployed on an opt-in basis.
2757−
2758−To someone coming to Landscape for the first time, it is starting to look mature; and it is indeed maturing quickly. After all, these mismatches in expectations are pangs calling out for growth. Landscape truly has _users_, not just explorers, who are developing the same expectations they have with the other tools they use: predictability, reliability, and iterative improvements, not just leaps forward. So to meet those expectations, we’ve been working on the prerequisite work for a mature release schedule, with two different release streams for users and explorers: a lifecycle, with the cells, interlinked, dividing into a coherent higher being.
2759−
2760−## Landscapers and lifecycles
2761−
2762−For most of 2020, the core Landscape team has comprised of Liam (`~hastuc-dibtux`), Logan (`~tacryt-socryp`), and myself (`~haddef-sigwen`). Others at Tlon have rotated on and off, and some community members (`~radbur-sivmus` comes to mind) have also contributed a lot, but the three of us handle the core decisions and the entire stack for Landscape, working with designers, infrastructure, and third-party developers.
2763−
2764−After OS1’s release in April 2020, Landscape’s back-end has changed quite a bit; the first rearchitecture we performed was in group-store, adding roles and simplifying quite a lot of the back-end logic at the same time.
2765−
2766−Around May of this year, Logan flagged that our code surface was too large and had too much boilerplate by writing a set of bespoke full-stack applications when just one flexible userspace database would do. Our designers also had a vision of our interfaces being “modes and genres of the same data” that fit this vision as well; and so since then, we’ve put our resources into migrating all of Landscape to use graph-store (more information available in [this developer call](https://www.youtube.com/watch?v=E4DFuAZQ32Y)).
2767−
2768−Obviously, developing userspace for distributed computing has some additional challenges that you don’t have to consider when writing software for a single server. Each ship interacting has to mutually coordinate the agents running and the events to be processed. If those fall out of synchronisation, the edge cases multiply.
2769−
2770−We traditionally tended toward solving those problems by writing the simplest possible incarnation of an application or a solution first, triaging out additional complications until they can be most prudently addressed — usually when they are just one step away.
2771−
2772−For most of its history, Landscape’s userspace suite had to be up-to-date on all ships to function at all, so multiple staging streams added quite a few complications. Since incompatible versions of applications on different ships would produce mutual fail states if they attempted to interact –and since each application had no sense of how to negotiate compatibility with older applications, each user had to keep up-to-date. Landscape was moving too fast, constantly reconfiguring (to give you a sense of this: we still refer to a month ago as “old”).
2773−
2774−Historically, Arvo and Landscape were also considered just one object; changes in Landscape would often require refining the layers underneath it as well. We often aimed to use our interface’s requirements to refine Arvo in turn. But as Landscape’s cells continued to split, as it became a proper client _for_ Arvo rather than a subsection _of_ Arvo, it required its own planning and execution cycle that only came to fruition around April of this year.
2775−
2776−The first thing we did was start recurring, six-week product backlogs with designers and engineers to occasionally reassess short-term priorities with a larger roadmap. Once we did that, we began working on opening our process to the public, migrating all tasks, priorities, and current decisions to a [product board](https://github.com/urbit/landscape). By doing this, community members could both suggest features _and_ contribute features, with a centralised, transparent process for getting designer input and Tlon engineer priorities. This has also been a successful effort.
2777−
2778−By adjusting ourselves to a six week rhythm for execution, it’s clearly time to slow down our release schedule and dedicate design and QA time to each release.
2779−
2780−Since Arvo is still quite young, we can’t quite get to all the thornier aspects of instituting a lifecycle. For example, we can’t tackle agent version negotiation in full yet; and mark versioning is still not present. This means modifying the validators for our graph modules (that is, validating the graph structure of a notebook vs. a collection) presents a deployment challenge in a two-stream lifecycle.
2781−
2782−That said, our userspace infrastructure is maturing, so we could at least organise the APIs to those agents; and we could at least slow the development cycle on those agents in favour of the more flexible components of the stack. The front-end specific features, for example, can be deployed on different ships without side effects for other users.
2783−
2784−So now, before we could launch a stable stream, we had some things to do first:
2785−
2786−- **We wanted to provide assurance that the userspace suite is relatively stable.** All our remaining stores (invite-store, metadata-store, and contact-store) needed to be modernised to use the same libraries and utilities inside Arvo as newer userspace applications.
2787−- **We wanted all our applications to be using graph-store.** If we were going to migrate the entire network to a new userspace model, we shouldn’t undermine the new release cycle process and make it more difficult to test and deploy to meet higher user expectations. We needed to migrate everything first.
2788−- **We wanted to release the notification-store**. After the October 2020 groups release, Landscape simply wouldn’t be complete without it.
2789−- Finally, **we wanted all of Landscape to use the [Indigo component library](https://github.com/urbit/indigo-react).** Landscape shipped with each application using its own build with handwritten, bespoke DOM components. Once we moved to a single-page application architecture in June 2020, we wanted the same guaranteed consistency for both back-end and front-end code.
2790−
2791−Most of these are now accomplished; the remaining tasks are awaiting some final tests and UX work. We’re aiming for a stable stream of Landscape to deploy by **January 5, 2021**.
2792−
2793−What does this mean? For everyday users, you can expect Landscape releases every six weeks; the slate of features and any breaking changes will be flagged well in advance for third-party developers; and you can expect a more thoroughly considered user experience with notes and copy for each new release.
2794−
2795−And for intrepid users, you can opt-in to a development stream and help us find and eliminate bugs before release to the wider public. This development stream is much like how we've been deploying Landscape up until now — but now it's optional.
2796−
2797−## Mitosis
2798−
2799−Describing our progress so candidly can feel strange — after all, it sounds so _early_. But to me, it’s exciting. It’s mitosis.
2800−
2801−Take another example. For all of Urbit’s history — all until now — Tlon was playing the role of both parents to the project when it was really just an embryonic corporate vehicle itself, fated to become twins. But in the past few months the burgeoning Urbit Foundation’s interim Director, Josh Lehman (`~wolref-podlex`), has begun to ramp up responsibility, taking increasing stewardship over urbit.org and giving it a physical voice, an Otherness, apart from Tlon’s own goals.
2802−
2803−Now, each day, we stray a little closer to these entities splitting apart, a step closer to the Urbit Foundation and the Tlon Corporation being completely different entities with completely different concerns.
2804−
2805−The same has occurred with Landscape. Previously Landscape was “_the_ interface to Urbit,” the proof that there was more to the project than a Unix executable. And slowly to those of us at Tlon, it became obvious what it was destined to become: a flagship client for an entire network, a tree branch rooting a world beneath clearnet, the first cell by which other clients might be born. Mitosis can be clumsy to watch; it can be nauseating to experience; it can be difficult to make out what will arrive where.
2806−
2807−But this is, after all, how a body forms.
2808−]]></content:encoded>
2809− </item>
2810− <item>
2811− <title><![CDATA[Security and Continuity]]></title>
2812− <link>https://urbit.org/blog/security-and-continuity</link>
2813− <guid>https://urbit.org/blog/security-and-continuity</guid>
2814− <pubDate>Mon, 30 Nov 2020 00:00:00 GMT</pubDate>
2815− <content:encoded><
2817−
2818−## Security and Continuity
2819−
2820−In 2018, when we launched the Urbit ID contracts (also called ‘Azimuth’), we committed to yearly infrastructure goals for 2019 and 2020. This wasn’t an informal commitment — it’s part of the contracts that were published to the blockchain, which you can read [here](https://raw.githubusercontent.com/urbit/azimuth/edf68b8da04806dd5b95994daf14cf1e7e226829/proposals/0xcb1f81e42b5e75f000f94fc71a3ea70cab4bfc6f236b91e717f1b9516e5596b5.txt). At the end of each year, we ratify our accomplishment of these goals with a galaxy vote.
2821−
2822−Since the year is coming close to an end, and this year’s vote is on the horizon, it’s time for an update on our progress.
2823−
2824−For this year, we committed to completing two things: passing a third-party security audit of our networking protocol (Ames) and getting Urbit OS (both Arvo and the interpreter) to the point where we can reasonably expect the Urbit network to continue without any hard forks (which we call ‘breaches’). A world with no network breaches is one where the network should be able to run indefinitely without any interruption. We also call this ‘continuity’.
2825−
2826−We’ve been steadily making progress on these two fronts, and I’m happy to report both are nearly complete. We’ll walk through some of the details here and then follow up in another post soon to report on how the final work turned out.
2827−
2828−## Ames Audit
2829−
2830−Urbit OS is an ‘overlay OS’: it runs on top of (pretty much) any flavor of Unix. Each Urbit OS node communicates with other nodes over UDP using Ames, the Urbit-specific networking protocol.
2831−
2832−There are two things worth worrying about when it comes to Urbit OS security: someone breaking into Urbit from the machine it’s running on, and someone compromising the network protocol itself. As to the first, there are probably ways that we can harden the OS sandbox, but if the machine it’s running on is secure we can feel reasonably safe. Since there’s lots of prior art on how to secure a Unix machine, we can leave hardening the runtime for later and simply encourage everyone to secure the boxes they run their Urbit nodes on.
2833−
2834−Assuming each node on the network can run on a locked-down machine, it’s really important that the protocol for communicating between these nodes is secure. Also, since Ames uses other Urbit nodes for peer discovery, we want to make sure no ‘relay node’ can inspect data not meant for them.
2835−
2836−The question “Is Ames secure?” is too vague for an auditor, of course. The audit was scoped to determine that the following three criteria are met:
2837−
2838−- No one can impersonate another ship on the network
2839−- No one (including relays) can intercept and decrypt messages not meant for them
2840−- Ames messages don’t leak keys that could endanger the sender’s data
2841−
2842−Our goal with this scope is to focus exclusively on the design and implementation of Ames itself. Basically, the crypto should be correct and there should be no flaws in either the protocol design or its implementation. Our interpreter can still be hardened against other potential attacks, which is work we’ll undertake in the future. We asked our auditors to flag all of these potential issues, so we know what needs to be addressed in the future.
2843−
2844−The good thing about an audit scoped in this way is that we can trust the protocol to authenticate people and shuttle packets back and forth safely. We’ve always been reasonably confident about Ames, but having an external stamp of approval will be great.
2845−
2846−As of the end of November 2020, the audit is very nearly complete, and we’ve handled all the important issues that were brought up. We’ll post the results and talk about our mitigation strategies in a future writeup.
2847−
2848−## Continuity
2849−
2850−Urbit is designed to last a long time. What’s the use of a personal computer if it’s gonna disappear along with all the data you put in it? Ideally, you can put your Urbit on a USB stick, forget about it for ten years and have it work again when you plug it in. It’ll need to update for a while, but once our work on continuity is complete, your urbit should be able to upgrade itself through ten years of updates, all over the air.
2851−
2852−While Urbit is designed to upgrade seamlessly over the network we have occasionally run into issues that have caused us to reboot the entire network. Most of the time this is when some incompatibility between the interpreter and the kernel means we have to force everyone to do a hard reset to ensure compatibility between the two. Our current work on continuity addresses this. Soon, your urbit will tell you when your interpreter needs to be upgraded. At first this won’t be that different from an application notifying you to download an update. Eventually, we think we can make this a lot smoother.
2853−
2854−A network reboot isn’t the only way that we can break continuity. Urbit is a general-purpose computer — which means you’re free to attempt to destroy it. If, for any reason, you do manage to screw the system up we want you to be able to get your data out and effectively reset continuity on a single node. We built the affordance for that a while ago, but before the end of the year we’ll also distribute tooling to migrate userspace data between hard resets.
2855−
2856−The combination of version negotiation and data migration should afford us the ability to run the network indefinitely into the future. Unfortunately, to get this change in, we’ll need to reset the network. We’re optimistic that this will be the last time we ever do it. And, given our data migration tooling, this breach won’t involve losing data.
2857−
2858−## Status + conclusion
2859−
2860−We have been working with auditors since this summer and should have a report ready to publish in the next few weeks. Both version negotiation and data migration are in testing and are ready to be deployed.
2861−
2862−Our goal is to have all of this work complete by `~2020.12.10`. This means we should be able to start a galaxy vote right around that time. Galaxy votes (as specified in the contracts) run for a month, which should have this whole process ending on `~2021.1.10`.
2863−
2864−It's going to be an exciting couple of weeks!
2865−]]></content:encoded>
2866− </item>
2867− <item>
2868− <title><![CDATA[An Email from the Archive]]></title>
2869− <link>https://urbit.org/blog/an-email</link>
2870− <guid>https://urbit.org/blog/an-email</guid>
2871− <pubDate>Sun, 29 Nov 2020 00:00:00 GMT</pubDate>
2872− <content:encoded><
2874−
2875−I found this email in my archives recently and thought it might be fun to share publicly.
2876−
2877−```
2878−From: Galen Wolfe-Pauly <galen@tlon.io>
2879−Date: Thu, Jul 2, 2020 at 9:50 AM
2880−Subject: Continuing
2881−To: XXXXXXXXXXXXX
2882−```
2883−
2884−Here are a few things I was thinking about after we chatted. It may be that I'm just reiterating things I already said — but perhaps it's useful:
2885−
2886−1 -
2887−
2888−Our collective desire to depend on digital communication tools vastly exceeds what I would have ever guessed. Even if you somehow factor out what’s addictive about the platforms we use today: they serve a real need. The crux of the problem with our current platforms is that they don’t actually serve the need that we want them to serve. They’re not tools in the way we expect tools to be. For the most part, the platforms we depend on serve the needs of their shareholders or some graph or another that needs to go ‘up’, which makes them compromised in a very deep way.
2889−
2890−In the pre-digital world we enjoyed a few things about the way we communicated, collaborated and did business that are dwindling: simplicity, durability and ownership. I’ll try to give some straightforward examples of what I mean:
2891−
2892−A - When I talk to someone directly, I’m not worried that someone else is listening in. If they go tell someone else what I said to them, that’s something for us to work out between us — they’re not _always_ reporting our conversations back to a third party. The constraints of the interaction and the privacy implications are _simple_ — I don’t think about them at all. Good privacy guarantees flow from a strict focus on simplicity. When two people want to talk to each other: give them a secure channel to talk. Putting a centrally-controlled service between them is just an interim solution because no one could figure out a better way to do it.
2893−
2894−B - When I write something down on paper, or type into a typewriter, I have an intuitive sense of the durability of what I’ve made. I have notes on my shelf I took ten years ago. I don’t worry about them disappearing. This means I can have a very direct, high-resolution relationship with the medium. I can pour myself into my physically-written notes in a way I would never pour myself into a Google Doc. Our digital tools are deeply untrustworthy because we know they can disappear, that they won’t actually last forever.
2895−
2896−C - Around 2008 I started limiting myself to a few specific drawing and writing tools. I use them all the time and can actually refine my relationship to them since I know they’re not going to change out from under me. Perhaps at some point these pens wont be made anymore, but the ones I have are actually _mine_. Similarly, the things I make with them actually belong to me in a way that doesn’t require some ridiculous terms of service. A sense of ownership, when it comes to the medium of communication, determines our level of trust and commitment.
2897−
2898−Our digital tools have to achieve the same level of simplicity, durability and ownership that our pre-digital tools did. Until they do, we’re always going to be in conflict with them, full stop.
2899−
2900−The main thing is that exactly none of our present platform-centric world can survive when you see things this way. The digital world we live in is composed of an insanely complicated, ephemeral set of tools that distinctly _do not_ belong to the people that use them.
2901−
2902−We’re going to be in a constant struggle with technology until it conforms to these three very basic expectations. These are the expectations we try to get Urbit to fall in-line with, of course. Something else could also succeed by satisfying them. But I also don’t really see anything else, aside from Bitcoin and maybe Ethereum, falling in line with these core principles.
2903−
2904−So: while I wish that Urbit was more mature and ready to capture those that are being purged from mainstream social media, are bored with it or are frustrated with the constraints of ‘productivity software’ — I think this conflict is going to drag on until people realize that what we’re in conflict with is the structure of the software we use. Using software that’s managed by other people is always going to cause serious problems all the way up at the user level. For more speculation on how this might play out, watch Black Mirror.
2905−
2906−2 -
2907−
2908−(1) is, in a way, a long-winded way of saying that the state of the world hasn’t changed our direction all that much. In order for Urbit to be approachable to use, it has to be very nicely made and that takes time and iteration. As the system stabilizes, Urbit can evolve in a more traditional way: we, along with others in the ecosystem, release stuff, observe how people use it, and try to make it better. We’re at the point where we’re nearly ready to get into that feedback loop, and we very much need to get there. We’re close.
2909−
2910−Urbit is a distinctly different _kind_ of software than anything we have now. Your Urbit is something you actually own and can do whatever you want with: not unlike your furniture or your kitchen tools. An Urbit is a tool for individual, human-scale computing and our whole approach to designing and making things is completely different. Most computing is about industrial-scale computing: where the software system stores everyone’s data and is managed by the people who build it.
2911−
2912−Urbit is the opposite of industrial-scale. Urbit is much more like something that’s carefully crafted and delivered to you directly. This craftsman-like approach to building software really isn’t a part of most modern software engineering.
2913−
2914−When I think about this from the standpoint of the person using what we make, it’s especially important. Urbit should feel like something that’s purposefully made by hand — not something you picked off the shelf at Wal-Mart. Some of this ethos was present in the early PC movement, but it’s mostly lost today. The care and attention that goes into building the system is also exactly what we make money on. People pay us to own a piece of it, to use it. We’re incentivized to make nice things, in the Urbit model, and we take that responsibility seriously.
2915−
2916−3 -
2917−
2918−Networks are a really important social form that’s only just beginning to come into existence. A network is neither a state nor a company, but something in-between. Bitcoin is a network, Ethereum is network (but it’s still far too centralized). Urbit is a young network.
2919−
2920−(In my view, a real network is always decentralized. Centralized networks are basically just companies.)
2921−
2922−Urbit is controlled by the collective of people who use it — in varying degrees, of course. The main thing is that this collective is bound together only by private keys and a blockchain, not a set of legal documents. The agreements between everyone on the network are in some cases more formalized (in terms of ownership) and looser (in terms of content moderation) than what we’re used to in either a state controlled or company controlled model. This is a very unusual kind of institution.
2923−
2924−On a successful Urbit network, Facebook, Airtable, and Signal are just successful applications. You could probably build companies around them that ship software to Urbit — but they’re more like 5 - 10 people instead of thousands.
2925−
2926−Urbit doesn’t aim to eat away at the government per se. Instead, it’s an important communication tool for institutions of any scale to actually take control of their means of collaboration. The efficiency of inter-government communication and government to populace communication can clearly be improved by _a whole lot_.
2927−
2928−4 -
2929−
2930−The most important thing is that people can generate a vision of the future. This can only emerge from a small collective of motivated people. Our public life is overwhelmed by people shooting from the hip, aiming for likes.
2931−
2932−There are difficult, infrastructural problems _all over the place_ that desperately need the considerate attention of small groups of people. Urbit, as communication tooling, is aimed at improving the quality of the fabric that binds these groups together. Or, to put it another way, before you can solve any specific problem you have to improve the problem solving process overall. Everything is gated on solving the process.
2933−
2934−5 -
2935−
2936−Christopher Alexander is, indeed, probably the biggest influence on my thinking when it comes to paying close attention to making things that both generate a deep sense of connection and are shaped by the people who inhabit them.
2937−
2938−[http://en.bp.ntu.edu.tw/wp-content/uploads/2011/12/06-Alexander-A-city-is-not-a-tree.pdf](http://en.bp.ntu.edu.tw/wp-content/uploads/2011/12/06-Alexander-A-city-is-not-a-tree.pdf) is one of his early, well known essays that’s easy to find online. I think ‘The Nature of Order’ is the thing that had the biggest impact on me, but it’s harder to find. There’s probably a PDF floating around on the internet somewhere. It's also a beautiful (four volume) book. The first volume kind of nails it. This talk is also great: [https://twitter.com/urbit/status/1148030042846326784](https://twitter.com/urbit/status/1148030042846326784)
2939−
2940−The thing that comes to mind lately is Hejduk. He had passed away by the time I was at Cooper, but I feel like I was educated in the ghost of his work. This documentary gives a good impression of his thinking: [https://www.amazon.com/John-Hejduk-Builder-Worlds/dp/B07NKQ72C8](https://www.amazon.com/John-Hejduk-Builder-Worlds/dp/B07NKQ72C8)
2941−
2942−Hejduk was able to see that architecture isn’t about building buildings per se, but something else. That was always quite obvious to me.
2943−
2944−Talk soon!
2945−G
2946−]]></content:encoded>
2947− </item>
2948− <item>
2949− <title><![CDATA[Models of Society]]></title>
2950− <link>https://urbit.org/blog/20201119-models-of-society</link>
2951− <guid>https://urbit.org/blog/20201119-models-of-society</guid>
2952− <pubDate>Wed, 18 Nov 2020 00:00:00 GMT</pubDate>
2953− <content:encoded><
2965−
2966−<br>
2967−
2968−In general, technology serves humanity as a kind of appendage—instead of thinking new thoughts or acting on its own, it does what we command. Technology never creates new social structures—it merely makes existing ones easier, or it facilitates the creation of new ones. We use our tools to expand our capacities, and once we are capable of doing more, we can imagine new things to do. Inventing the wheel did not invent motorized transportation—but it did facilitate it and it was a necessary step, even an inspirational one. Similarly, the invention of writing made new forms of human interaction and new tools for organization possible.
2969−
2970−Consider the following conversational conventions, or modes of messaging: a letter; a dialogue; a book; a meeting; minutes of that meeting. These are each pieces of technology: finely constrained solutions to human problems. Now, we have digital forms of each of these which diverge variously from the original. A letter becomes an email. A dialogue becomes a chat room, or a series of blog posts, or a twitter spat. A book becomes a website or an ebook. Meetings in 2020 have virtually been replaced by their virtual counterparts. Minutes become recordings or transcripts.
2971−
2972−Although we do not have a clear picture of how humanity developed the technology of writing out of the basic capacity for speech, we can imagine that the computerization of writing has many parallels. It does not make the old tools obsolete, nor does it immediately introduce new social structures. It does create the potential, however. On the timeline of human existence, we have only had digitized text for a relatively short time. Because we want to understand how to best use these new forms, we should look at their underlying structure.
2973−
2974−In order to digitize messages well, computers need to reconcile two facts about all modes of messaging. They have:
2975−
2976−1. One basic shape, and
2977−2. An infinite variety of forms.
2978−
2979−1 — The basic shape: all these modes have one common substance: human language. Any conversation is made of words. At first we only had spoken language. Then we discovered writing. Writing allows us to encode our words as glyphs to transmit them over time or distance. The internet extends this capacity. We called this "hypertext"—like good old fashioned text, but one level up. A staggering amount of messaging now takes place over this hypertext transfer protocol (http). In the process of digitizing language, we have learned the basic shape of a message. We can see this in how every social network shares messages in basically the same shape: an author, some content, references, an audience. We can confirm this basic shape by comparing it against our experience of the real world, and the previous comparison between speech and writing. Speech and writing both use the same substance, and take the same basic shape. They all have an author, content, references, and an audience.
2980−
2981−2 — Our experience of this one basic shape takes an infinite number of forms. The examples above (letter, meeting, &c) are just a few. These forms depend on the content of the message, the people involved, and the place they occur. All three aspects contribute significantly to its form, but the one that computerized messaging has not adequately compensated for is the place. Content depends only on the author and their intent. Getting certain people to view that content might be more difficult but most know how to use a computer. The place however, has not yet been adequately compensated for, and I think that has contributed seriously to our lack of civil and serious discourse over the internet. A president would not give an address in a bar, and a prospective lover would not utter his advances on stage. In writing, we can use the different physical forms to distinguish place. You shouldn’t read a book by the pool. You might not read a letter in public. You wouldn’t put a billboard in your bedroom.
2982−
2983−Furthermore, it seems possible that in our eagerness to "connect the world," we focused injudiciously on creating communities around "interests." Evidence suggests that unless the interest has a highly refined focus, these communities devolve into pandering, self-reference, and exploitation. In this way, the internet is something like a convention of conventions, where you wander in a sea of foreigners loosely affiliated by interest and surrounded by advertising booths. In physical space, people do gather by interest but they also gather by physical proximity—they are grounded and bound in place.
2984−
2985−Having an indistinct sense of place makes the form of conversation ambiguous and the participants of the conversation disconnected. Consequently, people are unsure how to interact. One need only know the term "comments section" to understand that.
2986−
2987−## People in Places
2988−
2989−<br>
2990−
2991−
2992−
2993−<br>
2994−
2995−As the internet grew to accommodate new conversation forms using the basic substrate of hypertext, web developers began to conceive of "digital spaces" through analogy—chat "rooms" and "forums,” or the "silo" and the "walled garden." Today, most of our conversation takes place in these walled gardens—privately-owned places which may be beautiful on the inside, but inaccessible from elsewhere. While some of these walled gardens are very large, our conversation is essentially confined to them. There is no roaming from one space to another while keeping one’s identity. We create new identities for new spaces both because we must and because we are afraid of repercussions on one platform for what we say on another. This is because we do not own our identity; we merely have a key—our password. The owners of the walled garden still own the artifacts of our tenure there, and can revoke our access to them at any time.
2996−
2997−The concept of identity and the concept of place are fundamentally linked. We imagine the prince who travels overseas where no one knows his name, or we imagine the old prospect of traveling to a new world to make a fortune. While those both exemplify a dramatic change in identity and place, we usually want to keep our identity consistent. We want to be recognized by friends whichever place we go, and we all strive toward having a good reputation, which is a consistent identity across places. This consistent identity also allows control of that reputation per place. A man is not judged in public by the words he says among friends. And there is no way to search what someone has said except by asking him. With our current system of identity providers (an absurd term, but a real one), we surrender our rights to selectively expose our thoughts, regardless of the place they have been uttered. A data breach or a weak password might lay bare our most private thoughts. We run the real risk of being confronted by an old conversation presented out of context or after we have learned better.
2998−
2999−People need distinct spaces to form conversations in distinct modes, and they need to have a consistent identity that controls how public their words are.
3000−
3001−In theory, we would have a digital city with unique regions, public fora, and sovereign parcels, into which one person might travel at will. In practice, we see this pattern: an app emerges to facilitate a mode of conversation. It gains popularity. Facebook (or Google, or Microsoft) buys and absorbs it. As monolithic empires, they can use the same format for all their messages. This gives them a great amount of power. They use this power to create things like "Sign in with Facebook" (or Google, or Microsoft) that benefit the user by consolidating their identity, but fail to solve the underlying problem. Their problem is that in order to allow people to communicate using the current technology stack, they need to be in control of everything.
3002−
3003−## Urbis ec Bit
3004−
3005−<br>
3006−
3007−
3008−
3009−<br>
3010−
3011−Urbit does solve this underlying problem. At this point the explanation goes so far down the stack that you could spend years tracing it all, but the relevant part is this: Urbit is not an empire; it’s a territory. An empire is an entangling of land and rule: within the bounds of said empire, you agree to be bound by its laws and the penalties for transgression. The laws exist at the whim of a despot or cabal. Your standing as a Roman citizen buys you no favors in Persia. In contrast, a territory imposes only physical laws. For example, in the desert, you will die faster. The only way to change that is to alter the desert. Urbit imposes nothing but the digital equivalent of physical laws. You have an identity which can be said to be truly yours, and you have a piece of software that runs on whatever computer you choose and can do anything you want with the messages sent to your identity. There are no social protocols enforced, because no one can control what software you run on your computer. As long as you agree to communicate using the same basic substrate, you can communicate with anyone using Urbit. This is the digital equivalent of speaking the same language. Whether or not others will accept you into their coalitions is not the technology's concern.
3012−
3013−In the same way that the land provides clay and timber, Urbit also provides the tools and material for building places both public and private. These include the aforementioned consistent message substrate (content), as well as tools for organizing people/audiences, structure for referencing other content, and an identity system that is owned only by you while being verified by all. The places are being built—private rooms with just a few people, meeting halls, club houses, huge public spaces, and countless personal encounters, the contents of which are known to none but the participants.
3014−
3015−The default tools work with messages in a few of the ways with which we've grown familiar: chat, direct messaging, publishing, link-sharing. They map onto existing forms of messaging because as I said earlier, the technology does not create new social structures; it just facilitates them. We have only seen the beginning of what the internet is capable of doing. Within a few decades it replaced the majority of letters, phone calls, and text dissemination—that was just the first phase of getting up to parity with what written text and speech could already do. In order to get to the next phase of creating new social processes, we need our technology to be organic and democratic, in the sense that everyone can participate and shape it. It needs to have a consensual foundation—a common substrate—and infinite possibility for expression. Urbit provides both of those.
3016−
3017−Similar to working undeveloped land, it takes a lot of hard work, which is why Urbit is not ready for mainstream adoption yet, and why I alluded to the idea of settlers in my opening paragraph. Traveling to the new world is not for everyone, but everyone is welcome.
3018−
3019−_How could one do other than submit to Tlön, to the minute and vast evidence of an orderly plant? It is useless to answer that reality is also orderly. Perhaps it is, but in accordance with divine laws—I translate: inhuman laws—which we never quite grasp. Tlön is surely a labyrinth, but it is a labyrinth devised by men, a labyrinth destined to be deciphered by men._
3020−]]></content:encoded>
3021− </item>
3022− <item>
3023− <title><![CDATA[Aesthetic Culture #1]]></title>
3024− <link>https://urbit.org/blog/aesthetic-culture-1</link>
3025− <guid>https://urbit.org/blog/aesthetic-culture-1</guid>
3026− <pubDate>Wed, 11 Nov 2020 00:00:00 GMT</pubDate>
3027− <content:encoded><
3031−
3032−<br>
3033−
3034−_This post is the first in a series of digests centered on art produced within and about Urbit by a member of the community, ~nartes-fasrum. Monthly digests will be available within the Urbit Community group in Landscape, and will occasionally be compiled here on the blog to give you a sneak peek at some of what’s happening on the network. Enjoy! ~wolref-podlex_
3035−
3036−One of the most exciting things about Urbit is the aesthetic and design around it, developed partly by Tlon (through the design of Urbit itself) and partly by the community (by producing great Urbit art). As the community grows, it creates more art, and we have the opportunity to showcase some of the pieces we love. These works can draw curious new users in, and they give existing users ways to communicate their excitement to friends.
3037−
3038−To that end, I wrote [the Art by Urbit proposal](https://grants.urbit.org/proposals/636838408-art-by-urbit), a regular digest for the dissemination of Urbit art and propaganda. We'll bring you the works of both familiar faces and new users, in a variety of media types from image manipulation to 3D models and physical pieces. This first digest will cover some of the art produced in the past year, but will have a focus on the last two months. Future digests will be incremental updates summarizing the artworks of the prior month.
3039−
3040−## ~datnut-pollen
3041−
3042−~datnut- made a physical representation of their sigil from maple wood & epoxy resin, and mentioned the potential to use an Arduino to cause different lighting effects for different statuses of an urbit.
3043−
3044−
3045−
3046−## ~lagrev-nocfep
3047−
3048−~lagrev- [made a thread of Dinosaur Comics](https://twitter.com/sigilante/status/1299101593997127680), using the Urbit Whitepaper as the seed text.
3049−
3050−
3051−
3052−A sweet poem about the potential for Martian felines is theirs as well:
3053−
3054−
3055−
3056−## ~litmus-ritten
3057−
3058−~litmus- produces art full of glowing gases and colourful curves:
3059−
3060−
3061−
3062−~litmus- also drew Urbitan for the release of OS1:
3063−
3064−
3065−
3066−More of their work is available in the notebooks of the Internet Weirdness Research Unit.
3067−
3068−## ~minder-folden
3069−
3070−~minder- stylistically ranges from retrofuturistic memes to flat-out classic 50s retro:
3071−
3072−
3073−
3074−
3075−
3076−More of ~minder-’s work is available in his The New Era notebook.
3077−
3078−## ~naltyc-wornes
3079−
3080−~naltyc-, & by extension ~dasfeb industries, produces content related to the exploration of Urbit on small & unique computers:
3081−
3082−
3083−
3084−
3085−
3086−More of their work is available in the smol computers group.
3087−
3088−## ~nartes-fasrum
3089−
3090−I use GIMP to edit images I pull off various social media platforms, and usually post the results on Twitter at [@nartesfasrum](https://twitter.com/nartesfasrum).
3091−
3092−
3093−
3094−## ~norsyr-torryn
3095−
3096−No discussion of Urbit art would be complete without mentioning [~norsyr-'s Canvas app](https://github.com/yosoyubik/canvas), which won first place in the [Hackathon 2020](https://urbit.org/blog/hackathon-results/) event.
3097−
3098−
3099−
3100−## ~radbur-sivmus
3101−
3102−~radbur- writes poetry on a range of subjects, one of which could be Urbit. Interpretation of ["A Weaver's Regard"](https://t.fust.us/writing/poetry/weavers-regard) and ["Internet Absurdities"](https://t.fust.us/writing/poetry/internet-absurdities) is left as an exercise to the reader.
3103−
3104−## ~sitful-hatred
3105−
3106−~sitful- has a Martian Meme Depository chat in the Networked Subject group, which catalogs a number of the Urbit memes that have been created so far.
3107−
3108−
3109−
3110−## ~tocrex-holpen
3111−
3112−~tocrex- has been drawing the galaxies of Urbit, and uploading results to Twitter at [@tocrexholpen](https://twitter.com/tocrexholpen). Each galaxy has a unique design and outfit, with the galactic sigil proudly displayed as its face.
3113−
3114−
3115−
3116−## Landscape
3117−
3118−Something that's become quickly evident with the addition of background images to Landscape is that people love to customize their ship's appearance and make it feel more like home. To close things out, we're providing a pair of backgrounds — one darker, one lighter — for use on your ship (or your desktop, should you so desire).
3119−
3120−
3121−
3122−
3123−]]></content:encoded>
3124− </item>
3125− <item>
3126− <title><![CDATA[Urbit Events Series]]></title>
3127− <link>https://urbit.org/blog/events-series</link>
3128− <guid>https://urbit.org/blog/events-series</guid>
3129− <pubDate>Thu, 29 Oct 2020 00:00:00 GMT</pubDate>
3130− <content:encoded><
3134−
3135−<br>
3136−
3137−_TL;DR: Urbit is launching a series of community events, the first of which is a developer call taking place on Thursday, November 5 at 9am PT. [Sign up here](https://www.meetup.com/urbit-sf/events/274279522/), and read on for all of the details._
3138−
3139−--
3140−
3141−If you’re familiar with the project, you’ve probably noticed that Urbit folks talk a lot about the fact that [Urbit is for communities](https://urbit.org/blog/urbit-is-for-communities/). This is central to what Urbiteers believe: Urbit is a platform that any group of people should be able to use to build, communicate, and transact in precisely the way that makes sense to them. Today, Urbit is already capable of facilitating many of these activities, and it’s already a big part of the daily workflow for many people. I think we’re off to a pretty good start, and over time Urbit will become accessible to more communities.
3142−
3143−Something we tend to talk less about is the fact that Urbit itself is also a community. If you’ve spent any amount of time hanging out in Landscape in the Urbit Community group, you already know this—but getting to know the community takes time and effort.
3144−
3145−One of the reasons you don’t hear about the Urbit community as much is that community is difficult to pin down: you'd be hard-pressed to put "the community" into a room together. It's a weird, fuzzy notion and doesn't have clear boundaries.
3146−
3147−Other parts of Urbit do have clear boundaries. If you decided to learn more about Urbit, chances are you started by reading the docs. You might learn about [Nock](https://urbit.org/docs/tutorials/nock/), [Hoon](https://urbit.org/docs/glossary/hoon/), and [Arvo](https://urbit.org/docs/glossary/arvo/). You might get an [Urbit ID](https://urbit.org/understanding-urbit/urbit-id/) and [launch your own ship](https://urbit.org/getting-started/). These things are all pretty well documented and, while not necessarily easy, their respective processes are relatively straightforward and [getting easier](https://urbit.org/blog/hosting-the-future/) every day. Community is less well documented. It’s more difficult to document—it’s something you just have to experience.
3148−
3149−We lead with technology because it’s what we’re good at and because it’s easier to write about. But the social side of Urbit is no less important. Since so many of us are working on and contributing to Urbit in order to solve our own problems, and since we’re dogfooding as we go, you could define Urbit as the minimal technological infrastructure needed to sustain the Urbit community. It’s circular, but it’s as good a definition of Urbit as you’re likely to find. For this reason, you can’t really understand Urbit without some degree of exposure to the cultural knowledge of its community. When the Urbit community did fit in a single room together, transmitting cultural knowledge was easy and happened over pizza and beer. As the number and diversity of Urbit stakeholders continue to grow, we need to find ways to scale the transmission of this cultural knowledge.
3150−
3151−One way that seems to work well is getting everyone together once in a while for events. Over the last few years, I and others in the community have collectively attended hundreds of community events, virtually and in person around the world, from small developer chats to massive, global developer conferences with thousands of attendees. Urbit has even hosted [a few of our own](https://www.meetup.com/urbit-sf/).
3152−
3153−As a newcomer to the Urbit community I recently found myself seeking exposure to cultural knowledge. I know from experience attending and organizing events in other communities that regular events are a good way of making this knowledge more accessible, and of helping newcomers like myself onboard. I applied for [a grant](https://grants.urbit.org/proposals/1751024973) to bootstrap a new event series, and I’m excited to announce that this series is launching next week with the support of [urbit.org and the grants program](https://urbit.org/blog/first-steps-towards-urbit-org/).
3154−
3155−The event series has three components. The first is a series of developer calls. These will be shorter and more narrowly focused on the technologies that underpin Urbit, from the top of the stack to the very bottom. They’re an opportunity for the people developing and contributing to Urbit to share their knowledge and expertise, including things that typically don’t make it into the docs, such as how and why Urbit works the way it does. It’s recently become much easier to build applications on top of Urbit, so I hope these events will help developers see what sort of things they can already use Urbit to build, and how to get started. These events are also an opportunity for Urbit contributors to share real-time updates that don’t make it into this blog, and for the community to get to know the contributors (and one another!).
3156−
3157−The first developer call will take place on Thursday, November 5 at 9am PT, and you can [sign up to attend here](https://www.meetup.com/urbit-sf/events/274279522/). The second call will take place two weeks later on Thursday, November 19, and we’ll continue holding these calls about every two weeks.
3158−
3159−The second component is a larger Town Hall event to take place on Thursday, December 17. The Town Hall will feature multiple speakers and will cover topics including technology but also design, community, and our overall progress towards our vision for Urbit. You can think of it as part show and tell, part “State of the Network,” part meet-and-greet.
3160−
3161−The third component is a larger conference, tentatively called UrbitCon, to take place early next year. This event is still in a conceptual phase. It’ll be an opportunity for the global Urbit community to celebrate how far the project has come, to share technical as well as cultural knowledge, and, maybe most importantly, to hang out together and have some fun as well. Watch this space for more information on the Town Hall and UrbitCon.
3162−
3163−Collectively, these events allow the community to achieve several goals. Firstly, they’re a great way for community members to meet one another, exchange cultural knowledge, and share what they’re working on. Events provide excellent motivation to get something that’s a work-in-progress to a state where you can share it with others!
3164−
3165−Secondly, the content from these events will be recorded and published, and will form the cornerstone of a new knowledge base on urbit.org that will augment existing documentation. This will make it much easier for newcomers, even those that can’t attend the events live, to benefit from the wealth of knowledge and expertise of the Urbit community.
3166−
3167−Finally, these events are a great opportunity for community members to contribute things other than code. While Tlon will provide speakers for the first few events of the series, it’s important to emphasize that the initiative is entirely community-led and that we’ll need lots of help to organize and host events. If you’re interested in helping out with any of the events in the series, please find me and others helping out with events on Landscape in the Urbit Community group (the channels called “Events Series”).
3168−
3169−They say that a project’s community has reached critical mass when new things are happening that even the project’s earliest and most active contributors aren’t aware of. By this standard, the Urbit community reached critical mass sometime in the past few months, as even core team members tell me they’re regularly surprised to learn of another new project or initiative launched by a community member.
3170−
3171−Tlon could no longer catalog the Urbit community even if it wanted to. This is a good thing. As Tlon [has also said](https://urbit.org/blog/hosting-the-future/), it’s natural that Tlon and Urbit drift apart a bit over time. Just as Urbit itself is self-hosted, so the community, over time, should become self-hosting: it should play a more active role in shaping the future of the project. A community-run event series can be an important catalyst for this trend. I’m looking forward to the first event, and I hope to see you there, and at many events to come.
3172−
3173−--
3174−
3175−_Sign up to attend [the first event](https://www.meetup.com/urbit-sf/), and join the channels called “Events Series” on Landscape in the Urbit Community group to get involved._
3176−]]></content:encoded>
3177− </item>
3178− <item>
3179− <title><![CDATA[A brief update from Tlon + urbit.org]]></title>
3180− <link>https://urbit.org/updates/2020-10-29-update</link>
3181− <guid>https://urbit.org/updates/2020-10-29-update</guid>
3182− <pubDate>Wed, 28 Oct 2020 00:00:00 GMT</pubDate>
3183− <content:encoded><![CDATA[
3184−Hello!
3185−
3186−We’ve quite a few updates for you this month which are covered in detail below—that said, it’s important that you know that our newsletters are splitting in two: one will continue to come from Urbit, and another from Tlon. Practically, that means that you’ll get another email from Tlon in about two weeks. Read on for more details!
3187−
3188−1 - Developer Calls
3189−
3190−Developer calls are coming (back)! A member of our community, ~naplet-hildec, is leading the charge to reintroduce regular calls for Urbit developers to gather and learn from one another. Each call will feature a different speaker that will present on a specific topic, followed by a Q&A. Calls will last an hour and will be held roughly every two weeks.
3191−
3192−Expect a detailed overview on our blog (https://urbit.org/blog), announcements on https://twitter.com/urbit, and within Urbit Community soon! For now, save the date: the first developer call is on Thursday, November 5th (12PM ET, 9AM PT, 5PM UTC), and will feature a discussion about graph-store by Tlon developer ~tacryt-socryp.
3193−
3194−2 - Weekly Design Streams
3195−
3196−Tlon’s design team will stream for an hour every Friday (5PM ET, 2PM PT, 9PM UTC). Expect discussions on current projects, thoughts on Urbit interface design, live QA sessions, and more.
3197−
3198−Tune in here: https://www.youtube.com/channel/UCyBGqTPD2uj9kbEJsxWnRxQ
3199−
3200−3 - Hoon School
3201−
3202−If you’re interested in learning hoon, check out Hooniversity—the home of Hoon School—at https://hooniversity.org/. If you’re ready to enroll, join the Hooniverse group via public channel ~hiddev-dannut/new-hooniverse. You can also find them on Twitter as hooniversity1 or via email at join@hooniversity.org.
3203−
3204−4 - Tlon + urbit.org Newsletters
3205−
3206−“Ultimately, Urbit presents more possibilities than any one organization can manage.”
3207−~wolref-podlex
3208−
3209−If you’ve been following along with our recent dispatches, you probably know that there are some exciting changes afoot. Tlon, the company building Urbit, has been developing a plan to separate itself from the governance of urbit.org (https://urbit.org/blog/governance-of-urbit/) for quite some time. Over the past few months, we have taken concrete steps to make this separation real. It might be a good idea to revisit ~wolref-podlex’s post (https://urbit.org/blog/first-steps-towards-urbit-org/) from this summer, where he discusses what led us here and why we’re doing this now.
3210−
3211−Urbit has matured to the point that Tlon can become just another entity in the Urbit ecosystem, so we need to separate the updates about Tlon-specific things from Urbit-specific things. Going forward, communications from Tlon and urbit.org will be issued as separate newsletters, with Tlon’s focusing on Landscape and the communities that form there, and urbit.org’s centered on Urbit’s infrastructure and community-led initiatives.
3212−
3213−Thus, this marks the last urbit.org + Tlon newsletter—in a couple of weeks, you will receive a newsletter from Tlon. You can manage your preferences for both of these newsletters independently by unsubscribing with the footer links.
3214−
3215−Getting on Urbit is now a lot simpler: Tlon’s hosting service is live. Join the waitlist at https://tlon.io.
3216−
3217−That’s it for now. See you on the network!
3218−
3219−~roslet-tanner and ~wolref-podlex
3220−
3221−https://twitter.com/urbit
3222−https://github.com/urbit/urbit
3223−]]></content:encoded>
3224− </item>
3225− <item>
3226− <title><![CDATA[A brief update from urbit.org]]></title>
3227− <link>https://urbit.org/updates/2020-12-01-update</link>
3228− <guid>https://urbit.org/updates/2020-12-01-update</guid>
3229− <pubDate>Wed, 28 Oct 2020 00:00:00 GMT</pubDate>
3230− <content:encoded><![CDATA[
3231−Hello!
3232−
3233−As the year of “but wait, there’s more!” draws to a close, we have some big news of our own to share:
3234−
3235−1 - Network Breach
3236−
3237−Easily the biggest and most important news this month is that another network breach is coming at the beginning of next week. For the unfamiliar, this is when the entire network is effectively reset in order to apply a more foundational change than can be done with an OTA. The specific update in question that’s going out is Arvo/Vere version negotiation. This is a big milestone that enables Vere and Arvo to be updated independently without worrying about version incompatibilities.
3238−
3239−Any form of breach, network or personal, means that your ship will be reset to a blank slate. In the past this meant that all of your data would be lost, which usually wasn’t an issue due to the immaturity of user space software.
3240−
3241−Fortunately, big changes in Urbit are becoming less and less catastrophic in 2020: Tlon will be providing a special tool (called “flagday”) that can be used to back up your ship, export your data, and re-import everything into your fresh ship.
3242−
3243−The folks at Tlon are pretty sure that this will be the last time we have to deal with one of these, but it’s hard to say. What’s clear is that the impact of a network breach on the community is being taken seriously, given the work put into tooling for the preservation of user space data.
3244−
3245−Make sure to read the full FAQ here on https://urbit.org/breach, which will be kept updated throughout.
3246−
3247−2 - Urbit Events Series
3248−
3249−In our last newsletter we announced the return of developer calls, and I’m pleased to say that we’ve done two over the past month, both of which have gone very well. Our first call featured Tlon engineer Logan Allen (~tacryt-socryp), with a discussion about graph-store, and our second call featured Mark Staarink (~palfun-foslup), who discussed the BitTorrent tracker and corresponding CLI he built.
3250−
3251−You can find both of the recordings on our YouTube channel at: https://www.youtube.com/channel/UCNYIS9_SktINCC9yqO4CFZw/featured.
3252−
3253−The next developer call (and last of 2020) will be held on Thursday December 10th, which will feature a discussion by ~timluc-miptev, a member of our community who will be discussing the Bitcoin system he’s built to enable ship-to-ship payments within Urbit.
3254−
3255−In January of 2021 we’ll be putting on our first Town Hall. This will be a three hour event with multiple talks that aren’t solely development focused, a keynote presentation, and some other fun stuff. If you’ve got a talk you’d like to give, a project to show off, or something you’d like to see discussed, please reach out to ~wolref-podlex in Urbit or via email at josh@urbit.org.
3256−
3257−3 - Community Content on the Blog
3258−
3259−“In order to get to the next phase of creating new social processes, we need our technology to be organic and democratic, in the sense that everyone can participate and shape it.”
3260−~radbur-sivmus
3261−
3262−In November we saw two posts on the blog from community members.
3263−
3264−Aesthetic Culture (https://urbit.org/blog/aesthetic-culture-1/) was posted by ~nartes-fasrum, who compiled art from all over Landscape into a digest. This is the first in a series, many of which will be exclusive to the Urbit Community group in Landscape.
3265−
3266−Models of Society (https://urbit.org/blog/20201119-models-of-society), an essay by ~radbur-sivmus, explores modes of messaging, the importance of a sense of place in communication, and how Urbit provides the fundamental substrate for facilitating new forms of societal processes.
3267−
3268−Our blog will continue to feature regular updates from the folks at Tlon, but it’s exciting to be able to feature content from our growing community about a broader range of topics.
3269−
3270−4 - Hoon School Hiatus
3271−
3272−Hoon school is going on temporary pause after the conclusion of the current batch.
3273−
3274−I’ll be working with our instructors, ~risruc-habteb and ~rabsef-bicrym, to synthesize their learnings from the many classes given in 2020 and design a new curriculum for 2021.
3275−
3276−We’re pretty excited about what an updated course will look like. I can’t go into details yet, but at a high level we’ll be looking to give a more holistic overview of the system through development of practical, full-stack Urbit applications.
3277−
3278−--
3279−
3280−You would think that a network breach would be a worrisome event. With so much effort having gone into creating groups and the content within them, it’s easy to imagine that a network breach, even with flagday, would pose a serious threat to community engagement.
3281−
3282−Personally, I’m not worried at all. The vibe in the room over at Urbit Community is, as usual, calm. From my perspective the greater Urbit Community is more engaged than it ever has been: between the degree of engagement throughout Landscape groups, the steady stream of new projects being undertaken, to the ongoing commitment shown by many community members to continue building on Urbit, it has become clear that Urbit is indispensable to lots of people.
3283−
3284−That’s all for now. See you on the network!
3285−Josh / ~wolref-podlex
3286−
3287−https://twitter.com/urbit
3288−https://github.com/urbit/urbit
3289−]]></content:encoded>
3290− </item>
3291− <item>
3292− <title><![CDATA[Hosting the Future]]></title>
3293− <link>https://urbit.org/blog/hosting-the-future</link>
3294− <guid>https://urbit.org/blog/hosting-the-future</guid>
3295− <pubDate>Wed, 30 Sep 2020 00:00:00 GMT</pubDate>
3296− <content:encoded><
3300−
3301−<br>
3302−
3303−Urbit users tend to be interesting, creative, and capable people; we’re genuinely impressed with the communities that have formed on the network, and with the quality of discourse there. But for the number of communities to continue to grow, getting on the network has to become dramatically easier. It’s not realistic to expect most people to configure their own Urbit OS node in the command line.
3304−
3305−At the moment, the biggest lever we have here is to help ordinary users get online, so they can participate in communities inside Urbit, and eventually form their own. This means hosting their Urbit nodes and showing them around the network when they first arrive. There are already several businesses overlapping with this space to varying degrees: [planet.market](https://planet.market/), [urth.systems](https://urth.systems/), and [geturbitid](https://www.geturbitid.com/). Now, Tlon is releasing its own hosting offering. For the uninitiated, “Hosting” just means that we run your urbit ship for you, making it easier for you to get onto the network. We’ve been testing our hosting service with friends and family for the past few months, and now we’re ready to bring it to the rest of the world.
3306−
3307−To learn more about Tlon hosting and sign up for the waiting list, check out the new [tlon.io](https://tlon.io/) website. We are officially launching the service on October 9th, with a virtual event and demo; we’ll also show off some of the new features and improvements to Landscape, the Urbit web client.
3308−
3309−To be very clear, hosting isn’t for everyone; if you’re deeply security-conscious or privacy-oriented, you’ll still want to self-host so that nobody else needs to touch your keys. That said, hosting isn’t a walled garden; you’ll get a planet when you sign up for hosting, which you will own 100% and forever. You’ll also always have the option to roll up your data and take it with you if you choose to stop using our service. Your Urbit data is just a single file, and we’ll happily hand it back to you if you ever decide to leave. Nothing will ever stop you from self-hosting.
3310−
3311−We’ve talked for a while about how the ultimate destiny of Urbit is to escape the control of Tlon. For Urbit to really succeed, it has to be managed by its own community. We started Tlon in order to solidify the foundation of this young platform. Now that Urbit is starting to grow up, Tlon and Urbit will naturally drift apart a bit.
3312−
3313−Urbit is meant to be universal, ubiquitous infrastructure. Tlon exists to make that infrastructure useful and usable. We expect Urbit, as a platform, to be cared for by the community in collaboration with the emerging [Urbit Foundation](https://urbit.org/blog/first-steps-towards-urbit-org/). We intend Tlon to become increasingly focussed on providing a great user experience for anyone interested in this new network, so the network can continue to grow and thrive.
3314−
3315−The way we see it, hosting is the most important thing, next to Landscape, that Tlon can do to help Urbit continue toward widespread adoption. We don’t expect to be the only ones providing this service—and look forward to including more contributions from the community here on urbit.org as they continue to mature.
3316−
3317−If you’re curious to keep up with what Tlon is doing here, head to [tlon.io](https://tlon.io) and join the waiting list. We’ll be posting updates to that list as well as to the Tlon Transmissions notebook in the Urbit Community group. Going forward we’ll do our best to keep urbit.org neutral and focussed on the technology itself.
3318−
3319−See you all on the network!
3320−]]></content:encoded>
3321− </item>
3322− <item>
3323− <title><![CDATA[A brief update from Tlon]]></title>
3324− <link>https://urbit.org/updates/2020-09-30-update</link>
3325− <guid>https://urbit.org/updates/2020-09-30-update</guid>
3326− <pubDate>Tue, 29 Sep 2020 00:00:00 GMT</pubDate>
3327− <content:encoded><![CDATA[
3328−Hello!
3329−
3330−And just like that, it’s Autumn. We’ve disappeared into Urbit these past few months and have been hard at work, building great things:
3331−
3332−1 - Tlon Hosting
3333−
3334−Tlon, the company we started to get Urbit off the ground, is now offering hosting. This makes using Urbit about as easy as using any mainstream app. We’ve been enjoying using Urbit ourselves quite a bit, and we’re really excited to be able to more easily invite our friends.
3335−
3336−Sign up for the waitlist: https://tlon.io.
3337−
3338−There’s a secret to moving ahead in the line: reply ‘as if in a still pool’ to the question ‘How’s your day going?’ in our questionnaire. We’d like to make sure everyone on this list can get access as soon as possible.
3339−
3340−We’re going to run a live demo showing off how our hosting service works on the 9th. You can sign up for the event here: https://www.meetup.com/urbit-sf/events/273439025/
3341−
3342−2 - Providers
3343−
3344−We’re not the first ones to offer hosting, it turns out. People in the community have been busy building out the first onramps into Urbit. We heard https://www.geturbitid.com, https://planet.market and https://urth.systems are all starting to come online. It’s still early, but what they have in the works is really cool to see.
3345−
3346−We also caught wind of https://urbit.me the other day, a nice little tool for finding specific sigils.
3347−
3348−(And we can’t forget about https://urbit.live, the first ones to get into this arena.)
3349−
3350−I wrote a little bit about how I see the future of Urbit Providers here: https://urbit.org/blog/providers/
3351−
3352−3 - Update + updates
3353−
3354−There’s too much to cover in a single email, so I wrote a little post about what we’ve been working on over the past few months. Check it out on the blog: https://urbit.org/blog/20200929-state-of-urbit/
3355−
3356−We also updated our roadmap in Understanding Urbit: https://urbit.org/understanding-urbit/roadmap/
3357−
3358−4 - The beginning of urbit.org
3359−
3360−We’re very happy that ~wolref-podlex has formally joined the community as Interim Director of the Urbit Foundation. We expect the foundation to become a separate entity soon, but for now we’re incubating it inside of Tlon.
3361−
3362−Last month he wrote about how we are working to separate the governance of urbit.org from Tlon: https://urbit.org/blog/first-steps-towards-urbit-org/
3363−
3364−Just recently, he announced the recipients of our biannual Gifts program: https://urbit.org/blog/gifts-q3-2020/
3365−
3366−5 - Hooniversity
3367−
3368−If you’re interested in learning Hoon, the next session of the community-run Hooniversity is set to start on October 12th.
3369−
3370−For more information about the course, head over to the Hooniversity site: https://hooniversity.org/ and sign up for the session here: https://hooniversity.org/enroll/.
3371−
3372−If you can't wait for the 12th, join the Hooniverse group on Urbit in advance by joining the ~hiddev-dannut/new-hooniverse group on Urbit or at https://twitter.com/hooniversity1
3373−
3374−We’ve been pretty much living on Urbit as of late. If you’re curious to connect with us (and are up for running your own Urbit node) you can always find us in the Urbit Community group: ~bitbet-bolbel/urbit-community. Instructions on how to install and set up Urbit are here: https://urbit.org/using/install/
3375−
3376−We love getting questions, comments, and replies to these newsletters. One thing we heard loud and clear last time around is that you want to hear more from the team. So much happened in the past few months that we have a glut of things to talk about in the coming weeks. Expect more dispatches in the near future. For the meantime, feel free to reach out via email (support@urbit.org) any time.
3377−
3378−See you on the network,
3379−Galen / ~ravmel-ropdyl
3380−
3381−https://twitter.com/urbit
3382−https://github.com/urbit/urbit
3383−]]></content:encoded>
3384− </item>
3385− <item>
3386− <title><![CDATA[Late 2020 Progress Update: OS 1 -> OS 1.N]]></title>
3387− <link>https://urbit.org/blog/20200929-state-of-urbit</link>
3388− <guid>https://urbit.org/blog/20200929-state-of-urbit</guid>
3389− <pubDate>Mon, 28 Sep 2020 00:00:00 GMT</pubDate>
3390− <content:encoded><
3394−
3395−<br>
3396−
3397−When we announced OS 1, in April, we started to disappear into Urbit. Since then, we’ve been living on Urbit like we never have before. This has been our goal for years: to mature the system we’re building by becoming its first committed users. We knew that critical step toward Urbit’s maturity was being able to depend on it ourselves, but the system itself had to mature to the point that we could do that practically.
3398−
3399−We’ve done this in fits and starts. We’ve _tried_ and failed a few times over the years. We’ve always _used_ Urbit to some extent, but we’ve never _relied_ on it. These past six months have been different. I can’t tell whether it was out of sheer determination and commitment, or that the system was just genuinely ‘there’. Either way, both Tlon and the Urbit Community genuinely live on Urbit now.
3400−
3401−In a way, our ability to use Urbit day to day doesn’t make sense. When we shipped OS 1, it was full of holes. There were serious performance, stability, and reliability issues. Plenty of people showed up and thought, ‘I don’t understand why you think this is useful.’ But, it was good enough that we wanted to use it. And since we wanted to use it, we put our energy into making it better like we hadn’t ever before. Being able to use a system that you can really trust is a wonderful feeling. It’s Computing Without Compromises.
3402−
3403−All of the sudden, it’s Fall. We never found the time to name any of our releases or write announcements. We’ve just been making the system better in every way we can find. We’ve got a lot of exciting things planned for the last few months of the year — but I wanted to recap the progress we’ve made for those following along from the outside. If you haven’t been on the network, it’d be impossible to see.
3404−
3405−The tl;dr is that Urbit is much faster, more reliable, and nicer to use than it was six months ago. Things have gotten much better, across the board. We threw ourselves into OS 1 admittedly underprepared, but we’ve learned a lot and matured the system a lot along the way.
3406−
3407−Anyway, let’s walk through the details. We’ll talk about our infrastructure and interface work independently, since that’s how we organize things internally. Then we’ll talk a bit about what’s going on on the network.
3408−
3409−### Infrastructure
3410−
3411−
3412−
3413−In April, Urbit was slow, fragile, and didn’t always update itself properly. We made enormous progress on all of these.
3414−
3415−First off, Urbit is about 10x faster for most users. With some careful debugging, we were able to locate a few really [high](https://github.com/urbit/urbit/pull/3029) [impact](https://github.com/urbit/urbit/pull/3054) [improvements](https://twitter.com/pcmonk/status/1276327036722704385). There’s still performance work to do, but the effects of this work are widespread. Boot times are faster, local compute is faster, the network is faster. It’s a huge improvement.
3416−
3417−Second, we got our memory usage under control. Urbit still uses a 2GB memory arena. If the state of your Urbit grows to over 2GB things, uh, fall apart. This used to happen regularly, and now it’s pretty much unheard of. We implemented [tooling](https://github.com/urbit/urbit/pull/3235) to compact and deduplicate the memory image when it’s growing too large. We brought the memory usage of the compiler [down ~90%](https://github.com/urbit/urbit/pull/3041). There are areas where we can be more disciplined about how we use memory, but this is more or less a solved problem for the near term.
3418−
3419−Third, we implemented a completely new build system. Well, we actually [got rid of the build system](https://urbit.org/blog/ford-fusion/) altogether and [made it a part of the filesystem](https://github.com/urbit/urbit/pull/3060). This made it possible for us to fix our over the air (OTA) updates and make them both fast and reliable. In April, an OTA could bring down your node and would take hours or even days to apply. Today, we regularly deploy OTAs with no fear of them breaking any nodes — they often go from galaxy → planet in a minute or less.
3420−
3421−We also rewrote a large part of our runtime in Haskell and made overall progress on [network scaling](https://github.com/urbit/urbit/pull/3174). And: we implemented a [principled approach](https://github.com/urbit/urbit/pull/2366) to [error handling](https://github.com/urbit/urbit/pull/3064), making nodes much less likely to become unrecoverable.
3422−
3423−The network is stable, fast, and safe from day to day. We’re pretty confident it can grow quite a bit without serious issues. When we shipped OS 1 we really weren’t sure what we could handle. Now we’re standing on much more solid ground.
3424−
3425−### Interface
3426−
3427−
3428−
3429−When we shipped OS 1 it was a bunch of separate pages (that were slow to load), all with separate ways of storing and processing data. Our interface work over the past six months is all about unification and simplification.
3430−
3431−First, we pulled OS 1 together as a [single page app](https://github.com/urbit/urbit/pull/3025). Using OS 1 involves a good amount of moving around and refreshing the page each time was pretty painful. Now it’s snappy to move between pages and keep up with what’s going on. In tandem, we started using our own component library, [Indigo](https://github.com/urbit/indigo-react). This makes frontend development much cleaner and more efficient.
3432−
3433−Next, we unified the way we store data and compute. It used to be that each individual module (chat, publish, and links) used their own ‘agents’ to store and process data on the Urbit side. (An agent is the Urbit equivalent of a datastore + business logic.) With a lot of moving parts, this approach caused all kinds of synchronization challenges. Rather than a module-per-agent model we’ve started to move toward a type-of-data-per-agent model. The first of these is [graph store](https://github.com/urbit/urbit/pull/3110). We’re presently in the process of migrating all our modules to graph store.
3434−
3435−Those two are by far the most significant, but there’s so much more. We [rewrote](https://github.com/urbit/urbit/pull/2937) the `group-store`, allowing for different roles (admin, moderators, and so on) in a group. We shipped better debugging tools, automatic reconnection, a settings panel, and overall visual polish and refinement.
3436−
3437−
3438−
3439−And I almost forgot [Leap](https://github.com/urbit/urbit/pull/3231): an omnibox for navigating around OS 1 with the keyboard. We have plans to make Leap much more powerful — but it’s a great first start toward making OS 1 keyboard accessible. I almost exclusively use [Leap](https://upload.wikimedia.org/wikipedia/commons/0/06/Canon_Cat_keyboard.jpg) to get around OS 1 these days.
3440−
3441−### Community + network
3442−
3443−
3444−
3445−Our primary goal with OS 1 was to get both Tlon and the Urbit Community living entirely on Urbit. We did that, and in doing so we’ve seen how nice it is to grow a community in a calm, non-invasive environment. We started doing regular [Urbit](https://twitter.com/urbit/status/1308875082312364048) [Dialogues](https://twitter.com/urbit/status/1304139629948329985) with friends and peers in the absence of physical meetups, which have been fun.
3446−
3447−Getting onto Urbit is still relatively challenging. By the standards of software you run yourself, it’s not so bad at all. But by comparison to ordinary consumer software, it’s way too hard. Tlon is [working on that](https://tlon.io) — but these last six months have been only for the brave. That is, those that want to host their own nodes.
3448−
3449−Turns out, there are plenty of people who are up for running Urbit themselves and quite a few small communities have sprouted around the network. Overall the network has a fun, cozy feeling. It’s nice.
3450−
3451−### What’s next
3452−
3453−We’re still more or less flat-out, full speed ahead into an even better Urbit-world. The seeds of change were planted when we made Josh the [interim technical director of urbit.org](https://urbit.org/blog/first-steps-towards-urbit-org/). Urbit itself is getting close to the point where the separation between Urbit and Tlon has to become more real. Urbit is aimed at being an ubiquitous platform, Tlon is aimed at making it as usable and useful as possible.
3454−
3455−We’ll talk about some of this on [October 9th](https://www.meetup.com/urbit-sf/events/273439025/), and you can see a bit of what’s coming on [tlon.io](https://tlon.io) today. If you tried booting Urbit in April and it was tough, try again. We’re easy to find on the network, and we’d love to get reacquainted.
3456−]]></content:encoded>
3457− </item>
3458− <item>
3459− <title><![CDATA[Gifts Q3 2020]]></title>
3460− <link>https://urbit.org/blog/gifts-q3-2020</link>
3461− <guid>https://urbit.org/blog/gifts-q3-2020</guid>
3462− <pubDate>Tue, 22 Sep 2020 00:00:00 GMT</pubDate>
3463− <content:encoded><, so while I won’t rehash the “why” of that here, I’ll reiterate that what we really want is a digital world that's generated by the communities that inhabit it.
3477−
3478−We know that digital communities need better technology with which to generate their world; just as importantly though, they need _people_ to inhabit and develop them.
3479−
3480−Tlon and urbit.org can’t bring the world into Urbit alone—we need community members to help us. By distributing address space to a variety of people that can invite their friends and families, the network can grow faster, more organically, and with a wider range of diversity.
3481−
3482−Currently, the majority of available address space is owned by Tlon and urbit.org, but it won’t stay that way. Instead, we want to give address space to folks that want Urbit to succeed. Because we’re custodians of something valuable it’s important that we are intentional about how we handle it. We treat that responsibility seriously.
3483−
3484−Gifts are one of the ways we invest in the future of the network. We look for others that see Urbit’s value and engage in building the digital home that they want to live in. They ease the learning curve for people new to Urbit, contribute to the technology, and create thriving communities.
3485−
3486−## Recipients
3487−
3488−Gifts are being awarded for a variety of reasons this quarter. As usual, there have been plenty of code and documentation contributions, but this time around we’re also recognizing those who have evangelized Urbit, been active in guiding newcomers to the system, and developed thriving communities within Landscape.
3489−
3490−Gifts are being awarded using the following criteria:
3491−
3492−**Bronze**: one star for continuous contributions over the last six months in at least one of the above areas.
3493−
3494−**Silver**: two stars for creation of something exceptional and/or contributing across many categories.
3495−
3496−**Gold**: three stars awarded to one contributor who has contributed at a volume that indicates a high degree of care and ownership.
3497−
3498−Without further ado, here are the recipients:
3499−
3500−### Gold
3501−
3502−[`~radbur-sivmus`](https://github.com/tylershuster) has more or less become an unofficial member of the interface team by tackling an absolutely [immense](https://github.com/urbit/urbit/pulls?q=is%3Apr+author%3Atylershuster+) amount of Landscape-related work.
3503−
3504−### Silver
3505−
3506−- [`~littel-wolfur`](https://github.com/ryjm): Jake maintains the premier development group in Urbit, The Forge, and has led the way for other developers by authoring [srrs](https://github.com/ryjm/srrs), one of the more popular community-developed applications on Urbit.
3507−- [`~botter-nidnul`](https://github.com/botter-nidnul): `~botter` has been instrumental in furthering [Urbit on ARM](https://botter-nidnul.github.io/), has made contributions across Vere and our documentation, and been highly active in onboarding newcomers on our Discord server.
3508−- [`~timluc-miptev`](https://github.com/timlucmiptev): `~timluc` is highly engaged in many groups and the maintainer of some, wrote the [Nock for Everyday Coders](https://blog.timlucmiptev.space/part1.html) guide, and has gone far above and beyond in teaching the community about developing Landscape applications.
3509−- [`~lanrus-rinfep`](https://github.com/dclelland): Daniel has done extensive development on iOS by writing Swift libraries for interacting with Urbit, and employed all of these towards the development of an [iOS client for chat](https://github.com/dclelland/UrsusChat).
3510−- [`~minder-folden`](https://twitter.com/the_pritchard): Jonathan is a prolific member of the community. His group _The Sanctorium_ is always active, he's always around to help newcomers to the system, is an active evangelist on Twitter, and a creator of much excellent content.
3511−
3512−### Bronze
3513−
3514−- [`~watter-parter`](https://github.com/lukechampine): Luke has made a number of [contributions](https://github.com/urbit/urbit/pulls?q=is%3Apr+is%3Aclosed+author%3Alukechampine) to Arvo, and wrote a great [introductory guide](https://github.com/lukechampine/rote) to developing Gall agents.
3515−- [`~naltyc-wornes`](https://github.com/JohnELester): `~naltyc` runs the popular group “Smol Computers” both inside and outside of Urbit where discussions ensue about various forms of computing on small devices like Android and ARM, and actively evangelizes the project.
3516−- [`~nartes-fasrum`](https://twitter.com/nartesfasrum): `~nartes` evangelizes Urbit on Twitter by creating artwork, and maintains the popular food-centric group “Urbytes.”
3517−- [`~fonnyx-nopmer`](https://twitter.com/fonnyx_nopmer): `~fonnyx` maintains an active presence throughout many groups on Urbit and runs the first Urbit-centric podcast, [Hooked on fonnyx](https://www.twitch.tv/fonnyx).
3518−- `~libhut-samwes`: `~libhut` started and maintains one of the most popular groups on Urbit centered on crypto and investing, and contributes to conversations throughout Urbit.
3519−- `~salmus-master`: In addition to embodying the quality of high-level, respectful debate we like to see, `~salmus` created the group: “The Tribal Network,” where he maintains one of the most active long-form notebooks on Urbit.
3520−- [`~fostyr-solfyr`](https://github.com/cmarcelo): `~fostyr` has submitted a number of PRs against Arvo, including a much-requested feature to reset the web login code.
3521−- [`~sarpen-laplux`](https://github.com/xiphiness): `~sarpen` has done a significant amount of research and work on Ethereum ABI parsing and other Ethereum-related topics in addition to being an active participant in dialogues throughout Urbit.
3522−- `~mister-todteg`: `~mister` is a top evangelist of Urbit on Twitter, has brought many newcomers onto the network, and has even made several hires for his company from within the network.
3523−
3524−Thank you to all who contributed to making Urbit what it is today!
3525−]]></content:encoded>
3526− </item>
3527− <item>
3528− <title><![CDATA[Providers]]></title>
3529− <link>https://urbit.org/blog/providers</link>
3530− <guid>https://urbit.org/blog/providers</guid>
3531− <pubDate>Mon, 17 Aug 2020 00:00:00 GMT</pubDate>
3532− <content:encoded><![CDATA[
3533−<br>
3534−
3535−<img class="ba" src="https://storage.googleapis.com/media.urbit.org/site/posts/essays/providers.png">
3536−
3537−<br>
3538−
3539−We look forward to a future where your Urbit is an always-on, always-available service. You should be able to pick up any device and conjure up your whole digital life immediately.
3540−
3541−Sounds good—but how does this actually come to pass? Urbit has to be technically robust and have a nice interface. Assuming we can deliver both of those things, your Urbit node also has to be safe, secure, and running somewhere with a network connection.
3542−
3543−Urbit has been getting nicer to use and more stable every day. We use it constantly, both as a company (Tlon) and for the broader Urbit community. From what we can tell, people are using Urbit to start communities of their own here and there. The problem is: to use our platform, you’ve got to run it yourself. This limits our audience _a lot_. Setting up a VPS and running an Urbit OS node is pretty easy if you’re comfortable in the command line, which makes it completely impossible for most people.
3544−
3545−We hear from people regularly who want to be able to sign up for Urbit like it was any cloud service. What they want is what we’ve been calling a _provider_: a service to provide easy onboarding and hosting. Given a good provider, we’d be pretty close to our long-term vision: Urbit would feel like a ubiquitous, easily accessible service.
3546−
3547−We’ve always assumed that providers would have to come into existence sooner or later. By the look of it, that time is now. Tlon and a few others have provider-like services in the works. We’ll talk about the specifics of what Tlon is planning to do in a future post. In this one, we’ll talk about what a provider is, why anyone would start one, and give a few examples of what they might look like.
3548−
3549−## What is a provider?
3550−
3551−A provider is anyone (company, DAO, a group of friends) that provides easy onboarding and hosting.
3552−
3553−From a user perspective, signing up with a provider should be as simple as picking a planet and hosting plan, paying, and getting connected to a running Urbit OS node. This should be able to be done entirely in a browser or a standalone app and feel more or less like signing up for a conventional service.
3554−
3555−From a technical perspective, this means a provider needs to create an Ethereum wallet for the user (client-side, of course), deliver an Urbit ID to it, and boot an Urbit OS node for them. And, at some point in the process, collect payment.
3556−
3557−As a user, your provider is somewhere between your ISP and your WordPress host. Your provider both runs the star that sponsors your planet (and provides peer discovery) as well as potentially providing both access to communities and even provider-specific software. We don’t really expect providers to be terribly generic—quite the opposite. Providers are likely to differentiate themselves on price, available software, and available communities. We’ll get into some examples later.
3558−
3559−The utility that a provider offers involves quite a lot of trust on behalf of the user. While the provider never actually holds the keys to your Urbit ID, they do run your node and, in turn, can access its contents. Unlike giant cloud services, your data isn’t in an easily searchable database. Inspecting your data should be something explicitly protected by a good provider ToS.
3560−
3561−If a strongly worded ToS isn’t enough for you, you can always host yourself. And, given the way Urbit works, downloading your Urbit from a provider and running it elsewhere should be both really simple and something a provider will _always_ let you do. It’s perfectly fine to run Urbit in your closet—which means that providers are really competing on ease of use and price.
3562−
3563−Let’s move on and talk a bit about why starting a provider makes sense to begin with.
3564−
3565−## Why would anyone start a provider?
3566−
3567−Our aim is to make Urbit OS so obviously nice to use that it’s well worth paying for. Today, a planet goes for about $10–$20 and, once you buy one, you’ve got to figure out how to really put it to use. Which takes some work.
3568−
3569−Any large holder of address space should immediately see the opportunity here: the more useful Urbit is, the more value can be captured by starting a provider. Providers make it possible to actually capture the value in address space, both by selling it and by operating nodes.
3570−
3571−Let’s say the base cost of running an Urbit OS node, in a hosted environment, is $10 / node / month. If you can sell hosting for $200 / year, you’re making back the ‘cost’ of the planet when someone signs up. Given that it’s more desirable to buy a planet when you know the star is online and you can put it to good use, this seems like a pretty good proposition: both for the provider and the customer.
3572−
3573−Starting a provider doesn’t _have_ to be done by address-space holders. You could start a provider with no address space of your own by custodying the address space of others. Then, you could take a cut of the address space sales and all of the hosting revenue. With a market of people looking to use Urbit, the crux of success with this approach is simply whether you can compete on user experience.
3574−
3575−Providers are, in a way, like the miners of Urbit. They’re incentivized to run fleets of very specific VMs for profit. The profit motive, in Urbit’s case, is just a bit more conventional than a bitcoin miner. An Urbit provider is just offering a service in exchange for money.
3576−
3577−## What are some examples of providers?
3578−
3579−If you think of a provider simply as a business, its most basic incentive is to attract as many customers as possible. You can do that by competing on price or performance, or by competing on aesthetics and community—there are lots of ways that providers can compete.
3580−
3581−As a roughly similar ecosystem, the world of webhosting is a great comparison. There are lots of small webhosts that all have very specific services: Dreamhost, MediaTemple, prgmr.com, and Linode all come to mind. Then there are the more generic, large-scale, performance-oriented options: AWS, GCP, Azure. It’s not quite time for an AWS-scale Urbit provider, but perhaps the AWS of Urbit will start as something much smaller.
3582−
3583−Let’s walk through a few examples to get a feel for what’s possible:
3584−
3585−Communities -
3586−
3587−A provider could easily curate community content like news, events, and discussion that it only delivers to its customers. Think of it as a bit like the days of sharing a server among friends—only in this case it could be hundreds or thousands of people who form a collective to run infrastructure and share information.
3588−
3589−Custom software -
3590−
3591−There are so many ways that providers can offer custom software. Urbit isn’t ready for third party software distribution. When it is, subscribers to a specific provider could get unique modules and applications synced directly to their Urbit nodes along with their membership.
3592−
3593−Aside from Urbit-specific software, providers could provide custom software services to their subscribers. A straightforward example of this could come in the form of Bitcoin or Ethereum nodes for processing transactions. Sign up with a provider and get the ability to send transactions to the chain quickly and reliably.
3594−
3595−Security -
3596−
3597−Let’s say our base cost of $10 / month / planet from above is correct (it’s probably high, but it’s a simple number). Would someone pay $100 / month for a planet hosted in a bunker or in the pylon of an abandoned oil rig? Maybe.
3598−
3599−## What about Tlon?
3600−
3601−Before there can be an ecosystem of providers, there has to be _one_ provider. While we’ve heard of a few other people working on things, we expect Tlon to be the first to try to really get into the provider business in earnest.
3602−
3603−I’ll save the details of what we’re going to do for a future post. Launching Tlon as a separate business will be the beginning of the separation of Tlon and Urbit. I’m really quite excited about it. Tlon is only able to consider becoming a business of its own because Urbit is mature enough that we can actually do it.
3604−
3605−For now, I’ll just say that Tlon will pick the low-hanging fruit first. Our goal is to make onboarding a group into Urbit incredibly simple. We want people to be able to go from email invite to running Urbit in a few minutes without ever knowing anything about Ethereum, Unix, or what a private key is.
3606−
3607−Once we’ve laid the groundwork with something that _just works_, we plan to open-source some of our components. Scaling up Urbit isn’t going to be easy. We hope that others will help us, and will help explore what’s possible in supporting Urbit users in the future.
3608−]]></content:encoded>
3609− </item>
3610− <item>
3611− <title><![CDATA[First Steps Towards urbit.org]]></title>
3612− <link>https://urbit.org/blog/first-steps-towards-urbit-org</link>
3613− <guid>https://urbit.org/blog/first-steps-towards-urbit-org</guid>
3614− <pubDate>Tue, 11 Aug 2020 00:00:00 GMT</pubDate>
3615− <content:encoded>< from Tlon. In the last few weeks, we’ve taken steps to make such a separation real. In this update we’ll discuss the background that led us here, why we’re doing this now, and what this means for Urbit.
3623−
3624−## Background
3625−
3626−At present Urbit is an open-source project developed primarily by the company Tlon. Urbit is an ambitious project with a long roadmap, which has required both careful guidance and resources to sustain its development. These resources have been Urbit’s address space, which have value in direct proportion to the value of Urbit as a platform. Naturally, Tlon has been focused thus far on making Urbit into a platform that people want to use.
3627−
3628−Ultimately, Urbit presents more possibilities than any one organization can manage. We anticipated this, and set aside address space for urbit.org, which we’ve often thought of as some type of software foundation. As Urbit matures to the point where Tlon can shift from developing the platform to developing products _on_ the platform, urbit.org is meant to continue to improve and maintain the parts of Urbit that many will come to rely upon.
3629−
3630−When we last discussed this, in early 2019, we weren’t quite ready to pull the trigger on setting up urbit.org. We weren’t sure if a software foundation would be the right structure, didn’t have the resources to tackle the overhead, and Urbit wasn’t yet stable enough for Tlon to focus on anything _but_ platform development.
3631−
3632−## The Present
3633−
3634−Urbit is really starting to look like a platform. Tlon has put tons of work into making Urbit stable and performant, we’ve launched OS1, and hosting services are on the horizon. Meanwhile, the grants program and Hoon School were initiated, and community members have been [contributing](https://github.com/natareo/hooncard/blob/master/hooncard.pdf) [learning](https://github.com/timlucmiptev/gall-guide/blob/master/guide-docs/overview.md) [materials](https://github.com/lukechampine/rote/blob/master/urbit/app/rote.hoon), [issuing](https://github.com/urbit/urbit/pull/2885) [patches](https://github.com/urbit/urbit/pull/3202) [to](https://github.com/urbit/urbit/pull/3238) [Urbit](https://github.com/urbit/urbit/pull/2867), and [building](https://github.com/ryjm/srrs) [new](https://github.com/dclelland/UrsusChat) [applications](https://github.com/yosoyubik/canvas) [in](https://github.com/yosoyubik/urbitcoin) [userspace](https://github.com/taalhavras/ucal).
3635−
3636−With a stable platform taking shape and a strong community forming that wants to help build Urbit, it’s time to make urbit.org real. We’ve had plenty of time to think about what it should look like, how it should work, and who should lead it.
3637−
3638−Our plan is to run urbit.org as a protocol—we’ll treat it like a real entity, but instead of dealing with the administrative details of setting up such an organization, we’ll incubate it within Tlon and give it a mandate: To competently distribute address space as a means of improving Urbit.
3639−
3640−## Moving Forward
3641−
3642−On that note, allow me to introduce myself: I’m Josh[^1], the new Interim Director of urbit.org. I’ve been a follower of this project for several years now and more recently a fairly active community member. I first became fascinated by Urbit as a programmer that saw the potential in a clean-slate OS; I later became compelled by a future in which social computing becomes small, friendly, and human-scale again.
3643−
3644−My background is predominantly in building software, companies, and teams—most notably [Starcity](https://starcity.com), where I am a co-founder and CTO. Starcity[^2], like Tlon, is focused on enabling communities to flourish. While the approaches couldn’t be more different, the goal of bringing people together in fundamentally human ways is shared.
3645−
3646−My goal is to leverage urbit.org to ensure Urbit’s success. I want to see a world in which Urbit is used by my friends, family, colleagues, everyone I know. To get there, much is left to build.
3647−
3648−To that end, the first objective of urbit.org is to recruit builders and give them the tools to succeed. I’ll be focusing heavily on providing technical support to developers that engage with us via Grants, outreach to the wider developer community, supporting the efforts of those that are creating educational courses and documentation, and enlarging the contribution surface by exposing it to other programming languages[^3].
3649−
3650−The product work that Tlon is doing is crucial to Urbit’s long-term success, so I’ll also be leveraging bounties to more directly accelerate their development efforts. Landscape represents the clearest example of a cohesive vision for Urbit’s use. The existence of a polished product built on Urbit demonstrates to the world that the platform is robust and capable, and the growing community seems eager to help. You can expect more bounties very soon that provide a direct connection to the Landscape roadmap.
3651−
3652−As I’m only just getting started, I’d love to hear your thoughts. If you’re working on any grants you’ll hear from me soon, and if you have an idea that you want to pursue, I’m here to help you make it happen. You can reach me directly via Urbit as `~wolref-podlex` or by email at josh@urbit.org.
3653−
3654−I look forward to working with you.
3655−
3656−[^1]: But my friends call me ~wolref-podlex.
3657−[^2]: We’re also really into the idea of being the first builder of housing on Mars. Just saying...
3658−[^3]: We call this project Airlock. You’ll hear more about it soon.
3659−]]></content:encoded>
3660− </item>
3661− <item>
3662− <title><![CDATA[A brief update from Tlon]]></title>
3663− <link>https://urbit.org/updates/2020-07-27-update</link>
3664− <guid>https://urbit.org/updates/2020-07-27-update</guid>
3665− <pubDate>Sun, 26 Jul 2020 00:00:00 GMT</pubDate>
3666− <content:encoded><
3668−
3669−Hello, friends. Today we’re highlighting an update on Landscape from `~haddef-sigwen`:
3670−
3671−In the past few months Landscape has gotten a lot of upgrades for users and developers: it now functions as a single-page application instead of a bunch of separate applications, which lets us start to tackle previously trickier features, like notifications, while also being much, much faster to use and navigate. It also allowed us to reinvent the build process to be much simpler.
3672−
3673−We’ve started deploying Landscape using a content-delivery network; each OTA, your ship will now receive a hash, and with it download and store Landscape. We want to prioritise, in the mid-term, the ability to move quickly to patch issues and provide a better experience using Urbit, while still leaving the door open for improving the system in the longer term. For now this should help improve performance and stability considerably, as previously the Landscape delivery over the air could easily lead to memory problems and sink ships.
3674−
3675−Last week we wrapped up our current slate of work by shipping a new Groups experience: including publicly joinable groups, multiple admins and moderators, and a simplified back-end for developers. This update also included some user experience changes:
3676−
3677−- All publicly joinable chats will instead be joined via publicly available groups
3678−- All other chats are direct messages between ships, and invite-only
3679−
3680−This means instead of using paths to join chats, or notebooks, you will use paths to join groups. This also lets us restore the feature to easily create linkable paths to your public groups inside any chat. The labyrinth returns.
3681−
3682−We’re also working on delivering a new, keyboard-oriented, searchable navigation bar -- alongside new controls and settings for Landscape users. With both improvements we want to provide the ability to use Landscape primarily by keyboard if you so choose.
3683−
3684−We’re also beginning to plan our next slate of work: we are preparing to make the leap to the OS2 codebase, and it involves quite a bit of research, but it’ll arrive sooner than you think…
3685−
3686−<br>
3687−
3688−Reminder: Hoon School begins August 1
3689−
3690−[Hooniversity](https://hooniversity.org/) is the new home of Hoon School run by `~rabsef-bicrym` and `~risruc-habteb`. To enroll, visit hooniversity.org or email join@hooniversity.org
3691−
3692−You can also join the Hooniverse group via public channel `~/~hiddev-dannut/hooniverse`and follow them on Twitter @hooniversity1
3693−
3694−That’s all for now!
3695−]]></content:encoded>
3696− </item>
3697− <item>
3698− <title><![CDATA[Ford Fusion]]></title>
3699− <link>https://urbit.org/blog/ford-fusion</link>
3700− <guid>https://urbit.org/blog/ford-fusion</guid>
3701− <pubDate>Tue, 14 Jul 2020 00:00:00 GMT</pubDate>
3702− <content:encoded>< are, can only perform certain limited kinds of patches to the kernel.
3716−
3717−Urbit isn't exactly a traditional operating system, so the comparison is somewhat unfair, but the purpose of better architecture is to create unfair comparisons. In this case, because the Nock layer is frozen, upgrading everything above that layer is easier. Upgrades are also facilitated by pure-functional semantics, transactional event processing, a type system oriented toward concrete data, and orthogonal persistence. These features make it feasible for Urbit to upgrade
3718−itself in the general case, not just some special cases.
3719−
3720−Ford Fusion has fixed the major upgrade issues of the past by guaranteeing three properties that in retrospect are obvious requirements, but, like much of Urbit, took many years and rewrites to identify as such:
3721−
3722−- Atomic: the update should complete or fail in one transaction. If it
3723− fails, the system shouldn't get stuck.
3724−- Self-contained: there must be no implicit dependencies or hysteresis
3725− (dependence on previous system states) when building the new software
3726− from source.
3727−- Ordered: updates must be monotonically sequenced from the system's
3728− lowest layer to highest.
3729−
3730−Let’s walk through them one by one.
3731−
3732−### Atomic
3733−
3734−In previous versions of Urbit, updates failed atomicity by deferring parts of the update to later events, which are separate transactions that can fail independently. Generally, each deferral causes an exponential increase in the number of failure states that needed to be handled.
3735−
3736−We've learned that asynchronicity is an entropic state. A system will tend toward more asynchronicity over time unless effort is put into keeping it synchronous. [As Jonathan Blow has noted](https://youtu.be/pW-SOdj4Kkk?t=2547), the language server protocol has turned every editor plugin into a distributed system, since now it has to communicate asynchronously with the main editor process.
3737−
3738−Consider an update system that took multiple Arvo events to complete. An ad-hoc higher-level transaction system would need to be built to roll back the effects of the first few events in case of failure. It’s important for various parts of the system to be able to emit effects on upgrade; since those effects would need to be rolled back if a later event in this upgrade fails, the system would need to maintain a queue of those events and only apply them once all the other upgrade events have completed.
3739−
3740−Note that the asynchronicity has now spread. Some effects that would normally be guaranteed to be processed synchronously might now be asynchronous. Entropy has begun to take hold, chipping away at the set of invariants the system is capable of guaranteeing.
3741−
3742−This observation is not purely theoretical. False modularity was the cause of internal asynchronicity in Clay where it had to wait for responses in a complex dance with Ford, which was another vane (Arvo kernel module); moving Ford into Clay allowed function calls that were synchronous from Clay’s perspective, which allowed further simplifications, culminating in about a twenty percent reduction of source code size of the Arvo kernelspace.
3743−
3744−[Steve Yegge's "platform
3745−rant"](https://gist.github.com/chitchcock/1281611) describes a Bezosian
3746−edict prohibiting synchronous communication among modules through direct
3747−linking. This can be seen as an acknowledgment of the difficulty Amazon
3748−was going to have when it needed to turn internal services external. If
3749−your software needs to run in hell, build it that way from the start.
3750−
3751−An Urbit ship is not an enterprise SaaS product and does not need to run in this hell; it exists for just one person, with natural pressure pushing it in the opposite direction from Amazon’s web services. Instead of needing a ship’s state and functionality sharded into microservices strewn across multiple clusters, an Urbit instance is easiest to manage as a single server with all its state unified into one data structure and its event log stored as one totally ordered sequence of state updates -- the antithesis of a distributed system.
3752−
3753−### Self-Contained
3754−
3755−Before Ford Fusion, each commit to the Clay filesystem validated its files using filetypes (called “marks”) defined by files in the previous commit. This could cause bugs if the filetype definitions had changed in a backward-incompatible manner. It also meant a commit could not add both a new filetype and new files of that type; instead, you needed two commits: one to define the filetypes, and a second to add files of that new type. More theoretically, it caused history-dependence. The validated contents of files in a commit could vary based on the history of commits that led to this one.
3756−
3757−Another way source code failed to be self-contained was that it had access to symmetry-breaking information at build-time, namely ship, desk (Urbit's answer to a git branch), and (faked) date. A build recipe should be able to shared, cached, and rerun without dependence on local conditions, so user code now no longer learns its ship, desk, or date until runtime.
3758−
3759−Source code also had build-time access to Urbit's immutable global namespace, called the “scry namespace”, which the kernel makes available as an implicit argument to userspace Hoon code. The scry namespace is immutable and referentially transparent, i.e. a request must always yield the same result for all time, but if an agent asks the kernel for a resource that’s from the future, hosted on another ship, or to which that agent doesn’t have permission, the kernel will deny the request.
3760−
3761−If the kernel denies a scry request that user code made during the build process, the build system has no choice but to treat it as a nondeterministic error. Nondeterministic errors can never be fully eradicated, if for no other reason than that the user always has the option to defenestrate the machine—there's nothing deterministic about that. But we try to minimize them, and especially to minimize uncertainty as to under what conditions they might occur.
3762−
3763−No build should be killed by the absence of files outside the desk, so as of this update, user code can no longer scry at build time. Once built, userspace programs can scry if run in a context with a scry handler; a Gall agent's runtime scry requests still work just fine.
3764−
3765−### Ordered
3766−
3767−The final kind of failure fixed by Ford Fusion was the lack of ordered layering during a software update. The most common form of this failure was that old Ford had a tendency to try to build userspace code using the previous version's standard library. This didn't work too well, unsurprisingly.
3768−
3769−Emerging from this underworld required making a number of changes to the Arvo kernel, Clay, Gall, and the procedure for kernel updates. To avoid turning into a pillar of salt, I'll skip the details of how the old system worked and instead describe the new update procedure.
3770−
3771−## How Updates Work Now
3772−
3773−These are the layers of the stack that update themselves on the fly, from lowest to highest:
3774−
3775−- hoon: the hoon language definition and compiler, defined in `/sys/hoon/hoon`
3776−- arvo: the arvo kernel proper and related type definitions, in `/sys/arvo/hoon`
3777−- zuse: the standard library, in `/sys/zuse/hoon`
3778−- vanes: arvo kernel modules, including clay itself, in folder `/sys/vane`
3779−- userspace: apps, marks, ancillary source code like libraries, and user data
3780−
3781−An update to one layer necessitates a reload of all layers above it; e.g. a change to Zuse should trigger updates to the vanes and userspace. Conversely, an update to a higher layer should not cause a spurious reload of lower layers, which should not be affected by the change; for example, an update to just userspace should not cause any reloads of system code.
3782−
3783−Clay is responsible for enforcing the layering of updates. An update to a module is triggered when an attempt is made to commit a change to Clay that affects one or more files needed to build the module. For example, if the 'foo' agent's source, defined in `/app/foo/hoon`, imports the 'bar' library from `/lib/bar/hoon`, then a modification to `/lib/bar/hoon` triggers an update to the 'foo' agent. All vanes and userspace files depend on Zuse, which depends on the Arvo and Hoon sources, so a change to the Hoon, Arvo, or Zuse sources will trigger updates to all vanes and userspace files.
3784−
3785−When asked to perform a commit, Clay determines which layers need to be updated based on which files have changed and which modules depend on those files. For now, all running programs load their source from the `%home` desk, so only changes to `%home` trigger stateful updates. Files in other desks can be built, but not installed into the system. This might be relaxed in the future.
3786−
3787−The process of updating varies by layer. The Hoon and Zuse layers are stateless, so their newly rebuilt cores (Nock executables) must be stored (somewhere in the system’s Nock tree, in memory; remember, Urbit is a single-level store), but they have no state that would need to be migrated. The Arvo kernel, vanes, and userspace agents are all live, stateful programs, so in order to update one of those, the system must extract the state from the old program, pass that data into the newly built program, then discard the old program and store the new one. Arvo and agent state injection routines can emit effects, but vane updates cannot.
3788−
3789−To work around this limitation, Gall has a two-phase update process. First it enters a dormant “pupal” phase that stores not running agent cores, but only the agent states that the old Gall had extracted from its agents. When Clay notifies Gall that its agents have been rebuilt, Gall “molts” back into normal functionality by loading the agent cores from Clay and then running their `+on-load` routines to inject the old state.
3790−
3791−If there's a change to files in `/sys` on the `%home` desk, Clay asks Arvo to update kernelspace. Clay sends a sequence of moves (effects) to Arvo to ask Arvo to perform any necessary updates to hoon, the kernel, Zuse, and vanes. This sequence is terminated by an extra move back to Clay itself, which will be received by the updated version of Clay after migrating its state. The rebuilt Clay can then use the newly rebuilt version of Zuse to rebuild userspace and notify clients of the update. One client is Gall, which molts when Clay notifies it.
3792−
3793−Clay triggers updates, but the Arvo kernel is responsible for performing updates to all kernelspace layers, and Gall is responsible for updating userspace agents. Agents are stored in Gall's state, but all other layers are stored directly in the Arvo core's state, so the Arvo kernel contains the routines that reload Hoon, the kernel itself, Zuse, and the vanes.
3794−
3795−The Arvo kernel reloads itself by receiving its new source code as a `%lyra` move from Clay, compiling this source into a core with empty state, then calling the new core's `+load` routine with the relevant parts of the old state. The state passed to the new Arvo now includes not just the vane cores and their states, but also the Arvo "duct" call `stack`, which maintains a stack of queues of moves to be passed from one vane to another, and a list of effects to emit to Unix at the end of the current Arvo event. If needed, Arvo could migrate the outstanding moves themselves -- if, say, the duct datatype changes.
3796−
3797−Passing the Arvo call stack state to new Arvo allows a kernel update to happen in the middle of a more complex event without disturbing other sequences of processing steps happening concurrently in the vanes.
3798−
3799−This entire update process happens in one Arvo event and doesn’t break event-dispatching semantics. This not only provides atomic rollback, but allows the update to be combined with other actions into a larger transaction -- for example, to stage complex changes, user code could trigger two kernel updates in a row, both in the same event.
3800−
3801−Note that this is the opposite situation from the entropically leaking asynchronicity described earlier. Now the guarantees don’t deteriorate; they can be composed into stronger guarantees.
3802−
3803−## How Clay Validates a Desk
3804−
3805−A desk is Urbit's answer to a git branch. It's almost identical, except all files are typed and validated, and whenever a commit becomes the equivalent of git’s ‘HEAD’, it’s assigned a semantically meaningful revision number, and all files are typed and validated.
3806−
3807−If Clay has been asked to perform a commit, it needs to validate all the files in this desk and notify all subscribers to live queries of this desk's data. Gall, for example, maintains live queries on builds of its live agents. Validation uses the Ford build system, which as of this update is no longer a standalone vane but a core within Clay.
3808−
3809−A Clay commit, like a git commit, is specified as the current value of all its changed files (and, separately, references its parent commits by hash), not as the diff from a parent commit. Unlike git, Clay is typed, and every file must be validated according to its "mark". A mark is named like a file extension, e.g. `%txt`, `%png`, or `%noun`, and Clay maintains a mapping from that name to behaviors of values of that type under various operations. The last segment of any Clay path specifies the mark to use for operations on that file, including validation.
3810−
3811−Mark operations include conversion to and from other marks (such as converting `%json` to `%txt`), revision control operations (diff, patch, and merge), and validating an untyped noun. Operations for mark `%foo-bar` are defined by a core built using the source code at `/mar/foo-bar/hoon`, or if that doesn't exist, at `/mar/foo/bar/hoon`.
3812−
3813−Consider a file at `/web/foo/json`. In order to validate this file, Clay must load the mark definition core and use its validation routine to ensure the untyped value of `/web/foo/json` is in fact valid JSON. To obtain this core, Clay must build the file at `/mar/json/hoon` from source and then process the resulting raw mark core using some mild metaprogramming to get a standard interface core for dealing with marks, called a `$dais`, whose type is defined in Zuse.
3814−
3815−Since building a source file only makes sense if the file has been validated as a `%hoon` file, but mark definitions themselves must be built from source, there's a logical dependency cycle -- who validates the validators? To break this cycle, Clay hard-codes the validation of `%hoon` files. This allows mark definitions to be built from source, and in fact any file can depend on any other file of any mark as long as there are no cycles. As of Ford Fusion, Ford performs a cycle check to ensure acyclicity.
3816−
3817−Since building a file is a pure function, Clay memoizes the results of all builds, including builds of marks, mark conversions, and hoon source files. These memoization results are stored along with the desk and are used by later revisions of that desk. Future work should allow merge commits to pull memoized builds from all parents, but for now only the previous revision of the current desk is used. This is a major simplification of previous Ford architectures, which maintained much more complex caches with less clear eviction semantics. Now on every commit, we just throw away any unused memoized builds from the previous revision's Ford cache.
3818−
3819−Once Clay has validated every file in this new revision of a desk, it constructs and sends updates to any subscriptions that other vanes or agents have requested. More Ford builds may be run to fulfill these requests, including builds for any running agents whose dependencies changed in this commit.
3820−
3821−When Gall receives a newly rebuilt agent from Clay, it calls the gate produced by the `+on-load` arm of the new agent with the state extracted from the old agent. If there is a crash in any `+on-load` calls or in the handling of any effects they emit (which can include more agent activations), then the whole event crashes, canceling the commit. This effectively gives any agent the ability to abort a commit by crashing.
3822−
3823−It is a bit counterintuitive that an app reload failure could prevent a kernel update. The reason is that we don't want the system to update itself into a broken state. An Urbit can be rendered practically unusable by the presence of broken agents, even if the kernel hasn't lost integrity,
3824−so it's kinder to the user not to break their agents by installing an incompatible kernel update. This also puts virtuous pressure on kernel developers not to "break userspace", the importance of which has been insisted on for decades by Linus Torvalds, among others.
3825−
3826−If an agent does crash a commit event that included a kernel update, the attempted commit is now trivially rolled back, and the system can deliver an error message to the user. This does not leave the system in an inconsistent or stuck state, so the user could modify the failing agent and try the kernel update again later. Supporting better workflows for keeping third-party agents up-to-date will be an important aspect of Urbit’s upcoming software distribution work.
3827−
3828−## Ford Build Semantics
3829−
3830−### The Three Types of Ford Builds: Files, Marks, and Casts
3831−
3832−The Ford build semantics have been simplified. There are now three kinds of builds that Ford can perform: files, marks, and casts, all of which happen synchronously as function calls inside Clay and are available (without memoization) as scry interfaces.
3833−
3834−#### File Builds
3835−
3836−A file build takes in a filepath containing Ford runes and Hoon source, runs the Ford runes to perform imports, and then compiles the source, producing a `$vase`, a noun tagged with its Hoon type.
3837−
3838−Clay exposes file builds into the scry namespace with `%ca`: as an example, `.^(vase %ca /~zod/home/3/lib/sole/hoon)` will build the `sole` library.
3839−
3840−#### Mark Builds
3841−
3842−A mark build produces a `$dais` mark-interface core. It first performs a file build on the Hoon file in `/mar` that defines the mark core, then it does some metaprogramming to make the operations more convenient to use. If the raw mark core delegated revision control operations to another mark core, the mark build will also load the delegate mark core and resolve the result into the `$dais`.
3843−
3844−Clay exposes mark builds into the scry namespace with `%cb`: as an example, `.^(dais:clay %cb /~zod/home/3/mar/foo/hoon)` builds a `$dais` for the `%foo` mark.
3845−
3846−#### Cast Builds
3847−
3848−A cast build produces a `$tube`: a gate that takes a value of one mark as input and converts it to a valid value of another mark or crashes. To convert from mark `%foo` to mark `%bar`, Clay tries the following operations, in order:
3849−
3850−- direct grow from `%foo`
3851−- direct grab from `%bar`
3852−- indirect jump from `%foo` through `%qux`
3853−- indirect grab from `%bar` through `%qux`
3854−
3855−The `%foo` mark can “grow to” `%bar` by providing an arm in its `+grow` core named `+bar`. `%bar` can convert from `%foo` using a `+foo` arm in its `+grab` core. `%foo` can also chain a conversion through an intermediary using an arm in its `+jump` core, and `%bar` can specify an “indirect grab” by having a `+grab` arm produce a delegate mark instead of directly defining a conversion gate.
3856−
3857−Clay exposes cast builds into the scry namespace with `%cc`: as an example, `.^(tube:clay %cc /~zod/home/3/foo/bar)` builds a `$tube` conversion gate from `%foo` to `%bar`.
3858−
3859−### Ford Runes
3860−
3861−There are now only four Ford runes. A file can contain zero, one, or many of each, but each Ford expression can only be one line, and they must be in the standard order of `/-`s, `/+`s, `/=`s, and then `/*`s.
3862−
3863−```
3864−/- foo, *bar, baz=qux
3865−```
3866−
3867−The `/-` rune imports a structures file from `/sur`. You can import it as just `foo`, in which case the build result of that file (usually a core with mold definitions) will be pinned into the compilation subject with the face `foo`. If you prefix it with a `*` as in `*bar`, the result will be pinned into the subject with no face; if the structures file compiled to a core, this exposes all the arms into the namespace of the compilation subject. Finally, if you import it as `baz=qux`, the `baz` face will be applied instead of `qux`. This is similar to "import as" in other languages.
3868−
3869−```
3870−/+ foo, *bar, baz=qux
3871−```
3872−
3873−The `/+` rune imports a library file from `/lib`. Aside from the different source folder, the syntax and semantics are the same as for `/-`.
3874−
3875−```
3876−/= clay-raw /sys/vane/clay
3877−```
3878−
3879−The `/=` rune imports the result of building a hoon file from a user-specified path (the second argument), wrapping it in a face specified by the first argument. The final `/hoon` at the end of the path must be omitted. This is mostly useful for importing a file for testing. The file at the specified path will be built as a normal userspace hoon file; i.e. its compilation subject will be Zuse augmented with the results of any Ford runes it has at the top of the file.
3880−
3881−```
3882−/* hello-gen %hoon /gen/hello/hoon
3883−```
3884−
3885−The `/*` rune imports the contents of a file in the desk, specified as the third argument with the full path including the trailing mark, converted to the mark specified by the second argument, and pinned into the compilation subject wrapped in the face specified by the first argument. This can be used to import static data at build-time, such as a data file, a media file, or, in the case of this example, a hoon file as source text rather than already built.
3886−
3887−A valid userspace hoon file must contain a nonempty list of hoons (hoon source expressions) below the Ford runes, separated by gap (more than one space, or at least one newline). The system wraps this list of hoons in a `=~` expression so that the result of the previous hoon is used as the subject of the next hoon. The result of the Ford runes is used as the compilation subject for this `=~` hoon; informally, the shape of the compilation subject can be thought of as:
3888−
3889−```
3890−:* fastar-2 fastar-1
3891− fastis-2 fastis-1
3892− faslus-2 faslus-1
3893− fashep-2 fashep-1
3894− <zuse>
3895−==
3896−```
3897−
3898−## Future Work
3899−
3900−Urbit still needs to make better use of desks other than `%home` and the development process should be adjusted given the tighter coupling between source code and kernel and tighter criteria for accepting an update.
3901−
3902−This work also hopefully provides a good foundation of a package management and software distribution system for Urbit. As `~wicdev-wisryt` has said, a user should be able to run `|install ~norsyr-torryn/canvas` to load and build remote source. No one should experience dependency hell on Urbit, but we're not there yet.
3903−
3904−At least now, building a desk has no dependencies, other than a Ford with a compatible Hoon compiler. No decisions have been made on this yet, but
3905−Ford might get moved to inside the desk, possibly by making Zuse callable. This could allow a desk to expose a Nock interface in addition to a typed Hoon interface, which could even let a desk be used as a "pill" bootloader.
3906−
3907−## Conclusion
3908−
3909−`~littel-ponnys` and I spent most of 2018 rewriting Ford with the intent of improving its performance. Compared to its predecessor, its result was better in some ways but worse in others. The caching system was labyrinthine and poorly factored, making the system difficult to debug or prove correct, even informally. Some things were faster, but the caching and dependency tracking were actually complex enough that a number of common operations, like mark conversion, were too slow.
3910−
3911−In early 2020, `~master-morzod` suggested moving Ford into Clay to reduce asynchronicity. It seemed absurd at first, but at some point I realized I could combine that idea with a simpler build-caching scheme and self-contained desk builds, and `~wicdev-wisryt` realized he could use that to further simplify Clay’s commit and merge code, which he did as part of this project.
3912−
3913−The first time I rewrote Ford, it took me six months, with help from `~littel-ponnys`, and it weighed in at 6,000 lines of code. The second time, in late 2018, took a few weeks. The third time, in January 2020, took a week. I wrote `+ford` in Ford Fusion in one long day, and it’s about 500 lines of synchronous, functional code.
3914−
3915−It has taken me two or three years to understand this problem as well as I do, and I expect there are parts of it I still don’t understand. The code itself isn’t the issue; it’s finding the right answer to ontological and teleological questions. What _is_ Ford? What will it be in a hundred years? I’m confident Ford Fusion is more similar than its predecessor to the Ford of 2120, because it’s smaller, more functional, and easier to understand and administer.
3916−
3917−As an engineering discipline and organizational practice, working on a system intended to be frozen yields surprising simplifications like this every so often. Urbit is now reaching the point where we’re starting to see more of the obsidian edges of the frozen future system emerge from the lava.
3918−]]></content:encoded>
3919− </item>
3920− <item>
3921− <title><![CDATA[The Value of Urbit Address Space (3 of 3)]]></title>
3922− <link>https://urbit.org/blog/value-of-address-space-pt3</link>
3923− <guid>https://urbit.org/blog/value-of-address-space-pt3</guid>
3924− <pubDate>Thu, 09 Jul 2020 00:00:00 GMT</pubDate>
3925− <content:encoded><
3929−
3930−_This is the third in a series of three posts on Urbit address space. See also [part 1](https://urbit.org/blog/value-of-address-space-pt1/) and [part 2](https://urbit.org/blog/value-of-address-space-pt2/)._
3931−
3932−It has been some time since we revisited this series of posts, so let’s start with a summary.
3933−
3934−Our framework for understanding the value of Urbit address space is that it’s useful, it’s rare, it’s easy to exchange, and the more that people use it, the more useful it becomes. Let’s briefly review each concept in a little more detail.
3935−
3936−First, utility. Urbit address space was designed for logging into Urbit OS, but Urbit ID can be used as an identity primitive for any internet service. That means it’s vastly extensible. Perhaps more importantly, because Urbit IDs at the star and galaxy level represent network infrastructure for the Urbit network, users have already begun to build a range of business models upon them, from hosting providers to community hubs. We explored several of these possibilities in detail in the [first post](https://urbit.org/blog/value-of-address-space-pt1/) in the series, and we also provide a primer on Urbit ID itself.
3937−
3938−Second, Urbit address space is finite, and that means it’s scarce. This design, which we explained in more detail in the [second post](https://urbit.org/blog/value-of-address-space-pt2/) in the series, was intended to promote good behavior and to limit spam. So far, that has worked. Scarcity is also impacted by availability of supply, which we’ll explore in this post.
3939−
3940−Third, network effects, also described in the second post in this series, have the potential to build upon themselves quite rapidly within the Urbit ecosystem. Urbit is essentially a network of other networks, each owned and controlled by their individual users. For this reason, Urbit’s network effect is best described by Reed’s law, which argues that the value of a network increases with the number of groups that can be built on the network. In Urbit’s case, this number is essentially bounded only by the amount of data that can be stored in Urbit itself, which today is 2GB. That size is already enough to support vastly more groups than anyone has tried to launch, and we plan to grow beyond that limit in the coming year.
3941−
3942−Also in Part 2, we explored trading of Urbit address space. We look at the current price of stars and planets as denominated in both BTC, and USD, and we see that the price of Urbit address space has remained fairly constant since its launch on-chain, while volume has been steadily increasing. The market is continually developing, with more ways to buy and sell Urbit address space cropping up.
3943−
3944−So, to recap: our view is that the value of Urbit address space is a function of its utility, scarcity, network effects, and ease of trade.
3945−
3946−In this post, we don’t expand that framework, but rather explore two elements that are important to actually using the framework. We’ll explain lockups, since they impact scarcity, and we’ll discuss usage metrics — including why we don’t (and in most cases can’t) track them.
3947−
3948−## Lockups and spawning limits
3949−
3950−One way to think about galaxies, stars, and planets is that they’re different-sized buckets of Urbit IDs. A star contains 2<sup>16</sup> (~65K) planets, a galaxy contains 2<sup>8</sup> (256) stars and, in turn, 2<sup>24</sup> planets (16,777,216). Beyond this nesting pattern, there are three further considerations to note: booted versus unbooted addresses, locked versus unlocked addresses, and planet spawning limits.
3951−
3952−Booted and Unbooted Addresses –
3953−
3954−A booted address is one that has actually been used to boot Urbit OS. By convention, booted addresses are expected to have some existing reputation outside of their name alone, since they’ve been used on the network. Reputation, good and bad, comes in many forms. Did the address operate any useful infrastructure? Did it get placed on any blacklists for spam or abuse? Did it simply send and receive messages? The ability to programatically track reputation is still in its infancy, but we expect the tooling to develop as Urbit grows.
3955−
3956−Unbooted addresses, on the other hand, have no reputation. Both booted and unbooted addresses can be transferred between owners, but booted addresses will likely vary widely in price depending on the reputation each of them has acquired, and how they’ve been used.
3957−
3958−For the purposes of this discussion, we’re primarily referring to unbooted addresses, as they have no reputation, and so are more similar to one another. We anticipate that booted addresses will trade infrequently — and likely via broker or auction, since users will prefer to control the reputation of the ID they’ve developed, rather than transfer that reputation to another.
3959−
3960−Locked vs. Unlocked Addresses –
3961−
3962−At present, the majority of Urbit address space is locked by smart contracts. When Urbit address space was first registered on the Ethereum blockchain, this unlocking mechanism was put in place to prevent the network from being flooded with users. A young Urbit network in which all of the address space had been unlocked would be exposed to attacks by bots and spammers. Scarcity, on the other hand, encourages good behavior as it increases the cost to spam.
3963−
3964−A locked star is held in a contract and can neither be booted nor issue planets. The lockup contracts can be examined on [GitHub](https://github.com/urbit/azimuth).
3965−
3966−In practice, the only Urbit IDs that are ‘locked’ are stars. A galaxy that is said to be locked is simply a galaxy whose stars are currently held by a lockup contract. A locked galaxy can be transferred (i.e. sold or simply moved to a new key) and booted (importantly, any galaxy—booted or not—can vote), but it can’t issue stars until the lockup contract expires.
3967−
3968−
3969−
3970−
3971−
3972−These lockups all began to release at varying linear rates in January 2019 (specifically on Tue Jan 08 23:34:41 2019 UTC).
3973−
3974−The various linear unlocking schedules are grouped as follows:
3975−
3976−- The urbit.org addresses, and early prize winners unlock linearly from 2019-2021.
3977−- Tlon, its founders, employees, and most purchasers from Tlon were frozen for a year, and now unlock linearly from 2020-2024.
3978−- 2018 private buyers were frozen for a year, and then began to unlock linearly over the course of one or three years, depending on the terms of their respective contracts.
3979−- Earlier private buyer addresses—including those in our first two crowdsales—were unlocked right away.
3980−
3981−As of January 2020, 17,283 stars were unlocked and tradeable. By January 2021, 33,355 will be available. On January 9, 2024, all 65,536 stars will be unlocked and available for trading.
3982−
3983−Being unlocked does not necessarily mean that a star can spawn all of its planets. For that calculation, we must turn to spawning limits.
3984−
3985−Spawning Limits –
3986−
3987−Unlocked stars are further gated by the number of planets they’re able to spawn. Every unlocked star was immediately able to spawn 1024 planets from the moment Urbit went live on the blockchain in January 2019—we wanted everyone to be able to invite some friends to their communities right away. From that date forward, the spawnable amount doubles every year (365 days), maxing out at 65,535 spawnable planets after 6 years.
3988−
3989−
3990−
3991−When we layer the spawning limits over the various lockup contracts, we find that all Urbit address space is both unlocked and spawnable by January 9, 2025.
3992−
3993−## Address space distribution
3994−
3995−Address space has continued to change hands since we put Urbit on-chain in January 2019. At that time, we had a fairly granular understanding of who owned what. Today we only have precise numbers for the Tlon and urbit.org owned address space. Galaxies change hands quite infrequently, so we know more about that ownership than stars and planets. We know next to nothing about the distribution of planets.
3996−
3997−We consider the opacity of our understanding about transactions on the network to be a privacy feature rather than a bug. To be specific about the information we can collect here: first, we don’t know anything about users beyond their ETH address, and second, we can’t tell the difference between a transfer of an address, and the re-keying of an address. This means we’re never entirely sure if a transfer has in fact occurred; we only know that the address has changed.
3998−
3999−The chart below is an estimate (as of January 2020) based on our general understanding of how galaxies are distributed. Much of this is anecdotal, and it’s largely based on the very few transactions we’ve observed within the galaxy table since Urbit went on chain in 2019. This chart should therefore be understood as incomplete, and an estimate only.
4000−
4001−
4002−
4003−Address space distribution is best understood in terms of galaxies and stars independently, as they’re distinct assets. The chart above only illustrates galaxy distribution, but describes Tlon’s “naked” galaxy holdings, which are galaxies empty of their stars. These galaxies are empty because the stars they once contained have been distributed, primarily to Tlon contractors, employees, and to certain private buyers.
4004−
4005−We believe that wide distribution is important to the health of the network and the growth of Urbit as a whole. Our own distribution efforts are focused on disbursing Urbit address space ownership as broadly as possible to those interested in using and developing the network.
4006−
4007−We intend to further distribute Tlon’s address space over the coming years through private sales, employee compensation, grants, bounties, and gifts. It’s worth noting that the grants and bounties program specifically is set to increase in coming years. We’re very much interested in putting address space in the hands of people interested in helping develop the network; we see grants as the perfect mechanism for doing so.
4008−
4009−## Usage data and composition
4010−
4011−Usage data is an obvious missing piece of the puzzle in this discussion. We understand this, and yet we don’t actively capture usage data, for two important reasons: it’s premature, and Urbit is privacy-focused by design.
4012−
4013−First, it’s too early. Urbit’s current users are a fanbase of pioneers who are willing to put up with the challenges of a young network. This fanbase grows on its own, but Tlon doesn’t actively encourage that growth yet. For the vast majority of potential users, the barriers to entry are still high enough that an invitation would risk losing them permanently. You can think of Urbit today as being a developer alpha.
4014−
4015−We’re laying the groundwork so that we can, in earnest, invite our friends and communities to a network they will love. That means we’re designing smooth onboarding, an elegant user interface, and increasing the stability of both the system and network. Tlon’s forthcoming hosting services will vastly reduce barriers to entry, and will be our first major push into the public sphere.
4016−
4017−Second, and perhaps more importantly, capturing data about traction on the network is difficult by design. Due to Urbit's privacy-forward architecture, there’s quite a lot we will never know. Once an Urbit ID is up and running, we don’t know how often it operates, where it’s hosted, or what it’s doing. This makes capturing usage metrics challenging, but we think this is the right problem to have.
4018−
4019−The Network Explorer –
4020−
4021−In the next several months we plan to roll out the first iteration of a network explorer that will allow users to visualize the structure and composition of the network as well as some basic activity data. Our first version of the network explorer will include representations of how the various layers of address space fit together, the finiteness of address space, historical uptime for nodes, and the various unlocking schedules.
4022−The network explorer will also allow users to zoom in on various nodes to learn more about them and what they offer.
4023−Urbit’s privacy-forward design makes collection of data appropriately impossible in many cases. That said, the network explorer should begin to collect all the elements of the value framework we’ve laid out here in one dynamic visualization.
4024−
4025−Closing –
4026−
4027−We have long said that Urbit address space had value because it was both useful and scarce. Taking a deeper look, we found that some limited liquidity, and network effect also play an important role in the value framework.
4028−
4029−All of the factors that make up our framework are, in turn, impacted by availability of supply and by user growth. In the Urbit ecosystem, supply is effectively gated—as described above—in order to prevent flooding of the network.
4030−
4031−User growth, on the other hand, is something we simply have not yet pursued in earnest. Instead, our development efforts have been focused on enhancing usability and stability of the platform. Our focus on user growth will begin as we roll out hosting. Once that happens, usage metrics will become both more interesting and more relevant.
4032−
4033−This concludes the final installment of our series on the value of Urbit address space. Though the explanation was long, the framework is quite simple: value in Urbit is derived from its use, scarcity, some liquidity, and network effect. Let us know if you’d like us to dig deeper into any of these elements—we’re always happy to opine about Urbit.
4034−]]></content:encoded>
4035− </item>
4036− <item>
4037− <title><![CDATA[~2020.6.15 Update]]></title>
4038− <link>https://urbit.org/updates/2020-06-15-update</link>
4039− <guid>https://urbit.org/updates/2020-06-15-update</guid>
4040− <pubDate>Sun, 14 Jun 2020 00:00:00 GMT</pubDate>
4041− <content:encoded><
4043−
4044−Hello, friends. I hope you’re all staying safe and healthy. We at Tlon are still working from home, and we have a lot to report. Here’s a brief update:
4045−
4046−1 -
4047−
4048−The results of the first-ever Urbit Hackathon are in and we’re really excited about them. You can read more about the winning projects [on the blog](https://urbit.org/blog/hackathon-results/).
4049−
4050−We decided to keep this first one just to Hoon School graduates, but we’re already planning another one that will be open to everyone later this year.
4051−
4052−2 -
4053−
4054−We’ve got two exciting lines of work coming together right now. The first is “Ford Fusion,” the next step in the evolution of our build system. This new design will alleviate a lot of the pain around OTAs (over the air updates), allowing us to upgrade ships more seamlessly. The second is a new version of our runtime daemon, this time implemented in Haskell. Moving to Haskell will create more surface area for contributions (versus our current, idiosyncratic C implementation). Shipping along with this latter will be improvements to our IPC protocol, the cause of many subtle runtime headaches.
4055−
4056−3 -
4057−
4058−The Urbit Community group has been fun and engaging lately. If you’ve booted your Urbit and haven’t joined, we encourage it. We’re there talking about the future of Urbit, core development, and all things Urbit adjacent and related. Ask for an invite in /urbit-help once you’ve gotten [set up](https://urbit.org/getting-started).
4059−
4060−4 -
4061−
4062−The Hoon School project is now in the capable hands of Urbit community members and they’re doing a fantastic job.
4063−
4064−[Hooniversity](https://hooniversity.org/), the new home of Hoon School, is run by `~rabsef-bicrym` and `~risruc-habteb`. Session 5 is now underway and session 6 is set to begin on August 1.
4065−
4066−If you’re interested in learning more and enrolling in the course, join the Hooniverse group via public channel `~/~hiddev-dannut/hooniverse`. You can also find them on Twitter as [hooniversity1](https://twitter.com/hooniversity1) or via email at join@hooniversity.org.
4067−
4068−5 -
4069−
4070−In case you missed it, we’ve been writing quite a bit in the past few months. Here’s the latest collection of posts:
4071−
4072−- `~fabled-faster`’s [meditation](https://urbit.org/blog/infrastructural/) on OS1’s form development.
4073−- `~haddef-sigwen` asked what it means to shape one’s own [digital environment](https://urbit.org/blog/tools-of-our-own/).
4074−- `~simfur-ritwed` discussed [platform decay](https://urbit.org/blog/platform-decay/) and explored how Urbit stars can facilitate a [flexible continuum](https://urbit.org/blog/the-missing-middle/) of community norms.
4075−- `~patnes-rigtyn` and `~ravmel-ropdyl` are writing a three-part series on the value of Urbit address space. Parts [1](https://urbit.org/blog/value-of-address-space-pt1/) and [2](https://urbit.org/blog/value-of-address-space-pt2/) are available now.
4076−
4077−6 -
4078−
4079−We’re always happy to give contributors address space to work on Urbit projects. Find a [Bounty](https://grants.urbit.org/bounties) to claim, or pitch a [Proposal](https://grants.urbit.org/proposals) of your own.
4080−
4081−Until next time!
4082−]]></content:encoded>
4083− </item>
4084− <item>
4085− <title><![CDATA[Hackathon Results]]></title>
4086− <link>https://urbit.org/blog/hackathon-results</link>
4087− <guid>https://urbit.org/blog/hackathon-results</guid>
4088− <pubDate>Thu, 11 Jun 2020 00:00:00 GMT</pubDate>
4089− <content:encoded>< of Canvas, and view [the code](https://github.com/yosoyubik/canvas).
4111−
4112−Jose wins eight stars, and he also wins [le internet for the day](https://news.ycombinator.com/item?id=23228058). Bravo!
4113−
4114−### Second Place: Four Stars Each
4115−
4116−Luke Champine’s (`~watter-parter`) flashcard app for Landscape, Rote, has been awarded one of two second-place prizes.
4117−
4118−Rote users write decks in udon, review them, and share them with other ships. His immaculate backend code-style and documentation secured his high placement in the Hackathon—his Hoon code also functions as a full-blown walkthrough. If you’re a Gall novice and you’re looking to learn, take a look at his [code](https://github.com/lukechampine/rote). Luke also kept a Notebook documenting his experience at `~watter-parter/hackathon`.
4119−
4120−Luke also included example decks for flashcards on Hoon runes and their irregular forms. So, all said and done, everything about Rote is an excellent resource to the eager Hoon neophyte.
4121−
4122−Pyry Kovanen (`~dinleb-rambep`) was also awarded second prize for his reading-list-sharing app, Books. Also a Landscape tile, and it’s pretty darn useful, with the ability to import books from Goodreads. Check out [the code](https://github.com/pkova/urbit/tree/books/pkg/interface/books) and the [video demo](https://youtu.be/Spy7FoPdfx8).
4123−
4124−### Third Place: Two Stars Each
4125−
4126−N E Davis (`~lagrev-nocfep`) brought the heavy infrastructural artillery with Roessler, and won third prize. Roessler is actually three related Hoon tools:
4127−`roessler` proper, a library for solving the differential equations producing the [Roessler attractor](https://en.wikipedia.org/wiki/R%C3%B6ssler_attractor).
4128−`lazytrig`, a library for transcendental functions.
4129−`proj-3d`, a generator that takes the 3D coordinates produced by `Roessler`.
4130−
4131−The Roessler project is full of cool, novel features. You might enjoy taking a look at the [GitHub repo](https://github.com/sigilante/roessler) ...if your brain is big enough.
4132−
4133−John Franklin (`~dirwex-dosrev`) also secured third place for his Notes application. True to its name, it’s a Landscape tile that allows the user to create and search notes by keyword. Look at the [code](https://github.com/jfranklin9000/notes/) and the [demo video](https://www.youtube.com/watch?v=7DurNjCFOmA).
4134−
4135−Jon (`~ribnes-fonbex`) was awarded third prize for his Quadratic Voting project. It implements for Urbit ships a [quadratic voting system](https://en.wikipedia.org/wiki/Quadratic_voting), which is sort of like ranked-choice voting but allows people to express their stronger preferences.
4136−
4137−Congratulations to the winners and to everyone who submitted—nice work!
4138−
4139−### The Future
4140−
4141−We were thoroughly impressed with all of the projects from this inaugural Hackathon. Not only did this Hackathon demonstrate the talent and dedication of our community members, it’s an encouraging sign about the maturity of the Urbit system. We’re going to hold more Hackathons in the future, with one big change: they will be open to anyone who applies.
4142−]]></content:encoded>
4143− </item>
4144− <item>
4145− <title><![CDATA[The Missing Middle]]></title>
4146− <link>https://urbit.org/blog/the-missing-middle</link>
4147− <guid>https://urbit.org/blog/the-missing-middle</guid>
4148− <pubDate>Mon, 25 May 2020 00:00:00 GMT</pubDate>
4149− <content:encoded><![CDATA[
4150−<br>
4151−
4152−<img class="ba" src="https://media.urbit.org/site/posts/essays/missing-middle.png">
4153−
4154−<br>
4155−
4156−The promise of social technology is that we can discover more friends; _specifically, people more similar to us_ than we previously had access to. The means by which we do so, the methods of collaboration, the quality of connected experiences; these factors matter, but they are marginal considerations compared to the basic offering of an expanded choice of connections.
4157−
4158−The wilder-eyed, utopian end of early computing drew greatly from this promise; such unprecedented connection could bring about world peace, intellectual serendipity, higher consciousness. We didn’t get world peace, but we did get a genuine revolution in collaborative information-sharing and rapid communication. That ability to refactor our social preferences gave birth to an uncountable universe of online communities and subcultures that would be unimaginable to anyone who didn’t see it happen.
4159−
4160−We didn’t get a million friends either. Dunbar’s number, which posits an upper bound of ~150 trusted relationships per person, put the lie to dreams of a ‘global community.’ Better social tools give us more choice in who to fill those slots with, but not the ability to expand the personal spheres where we actually spend most of our time and forge most of our familiarity and trust with others.
4161−
4162−We know this, and the social networks know it. To combat a slump in user activity, Facebook jettisoned promises of boundless discovery and started promoting Groups. The success of Discord and Slack happened precisely because they promised tools for gated communities, not open commons.
4163−
4164−One of those early promises came true in spades, though: while we still live in Dunbar communities, we’ve sped up the sorting process. We can find people like us at astonishing speed, and the diversity of options for what ‘people like us’ means has expanded exponentially. The ‘Big Sort’ of modern society is rapid, unprecedented, and utterly reliant on social technology. The problem is that for all of our freedom to find each other and make mutual agreements, the underlying technologies used for all of this sorting and trusting don’t actually reflect the diversity of expectations, norms, or approaches we might want to try. One major reason for this status quo is the underlying structure of the client-server Internet. Unlike in the physical world, where cities, religious groups, and professional associations both own real assets and collectively determine rules and norms, there is no median level of civic compromise on the Internet; just massive technical providers and platform companies, and dispossessed Dunbar communities and individuals unable to determine such rules and norms for themselves.
4165−
4166−Both internal norms (‘how do we act’) and external perceptions (‘who are we?’) get yanked around by the dictates of platform owners, routing infrastructure providers, and the societal consensus that governs both, at levels far above our Dunbar phyles. Privacy is contradicted by the need to surveil internal activity in order to target ads. The current model of social connection technology sets the bar for self-determination so high as to prevent it from adapting to external circumstances. The technical realities of the situation are due to client-server technology and its institutional history. The social aspect is a holdover from the 20th-century media paradigm of mass consensus cultures.
4167−
4168−The ‘long 20th century’ of mass institutions and broad consensus realities is over. Contrary to impressions, it was not the inevitable or final result of moral and civil progress. Rather, it arose from pragmatic external incentives of mass advertising and great-power ideological rivalries.
4169−
4170−The assumption that we must inevitably play by the same rules of discourse, given the autonomy granted by wealth, technology, and knowledge, is rapidly degrading. This status quo is a leftover from a time when mass education prepared workers for mass jobs, where mass communication hammered the same messages over the factory loudspeaker and advertised the same small number of products over the few television channels available. Yet we still assume that the shape and function of the tools and spaces for dialogue we inherited from that era are immutable and inevitable; this outdated belief cuts us off from new methods of choice and collaboration.
4171−
4172−Without the external political and economic pressures which created our mass culture, inclusion in or acceptance by it becomes just another sinecure for sale, the outcome of a zero-sum auction to benefit from and utilize for further gain, the power accumulated by the legacy institutions safeguarding it. The ‘objective’ model has become a straightjacket on human ingenuity and community self-determination. The fact that it is ‘supposed to exist’ means that it is the ultimate prize. Inclusion in the mainstream Discourse grants scalable exploitation of any idea and prestige to its proponents. But it is a booby prize. No serious and nuanced idea, no dedicated community can withstand its flattening effects or the ways that it commercializes and cargo-cults its subject into an artificial shape. The resulting conversations are lackluster in form as well as subject.
4173−
4174−The stiffer the Discourse is; the less input it deems useful, the more fragile it becomes. The inside becomes a stultifying garden party of outdated, anodyne official narratives; the outside a stew of paranoid, enraged rump factions shut out of any path to respectability or good-faith engagement with their perspective.
4175−
4176−The same dynamic wreaks havoc inside Dunbar groups as well; when there are fewer gradations of acceptable difference, internal schisms take on a stark tinge of zero-sum loyalty versus betrayal, rather than consensual drift. Savvy users, knowing the stakes, migrate quickly, leaving behind wastelands of the obstinate and clueless, who are in turn preyed upon by grifters and demagogues. Only when external events force a ‘tectonic shift’ in official understanding do these standards change. The problem is that the usual result of a ‘tectonic shift’ is a sudden, destructive earthquake. If networked culture is going to survive dramatic events out in the real world, we’re going to need a middle structural layer that allows norms and agreements to shift and negotiate based on observed reality and the wishes of ordinary participants.
4177−
4178−This omission of a ‘middle layer’ of technical governance directly informs our vision for the Urbit network. In an Urbit-based world, we envision stars will be consensus hubs. There are 256 Urbit galaxies, each able to spawn 255 stars for a total of 65,280 potential stars. Each star, in turn, can spawn 65,535 planets—far above the Dunbar number of an intimate community, but also far below the ratios of authoritarian control under which current platform regimes operate. Stars and galaxies perform the essential routing and peer discovery functions of the Urbit network; planets represent distinct individual identities.
4179−
4180−Although every star is spawned by a particular galaxy, it can move to any other galaxy which agrees to host it. Similarly, planets may migrate between stars. Many imagine the extreme ramifications of such a system, projecting a Darwinian competition of starkly diverse political models encoded in governance. When we think about the future of Urbit, though, we don’t see a chaotic universe of iconoclastic outposts. We don’t doubt there will be diversity among stars (driven by the wishes of their owners and resident planet users/customers), but the real value is in the antifragility allowed by far more subtle gradations of difference in rules and structures decided upon by stars. Each star will have much, but not all, in common with its immediate neighbors, across a constellation which contains a great overall diversity of norms. Changes in policy or alignment will resemble ripples across a pond more than a buildup of tectonic force against a brittle fault.
4181−
4182−Stars are Schelling points for such gradations precisely because they are discrete cogs in the overall technical infrastructure of Urbit. Technical responsibility and any bounds of ownership will always mark such points. Their designation in the case of Urbit or any other system is necessarily somewhat arbitrary. Our vision is orders of magnitude less centralized than the status quo, but not devolved so far towards the individual that community formation demands massive amounts of _individual_ technical knowledge and maintenance tasks. There will always be a need for routing infrastructure, ergo power (the power to set community norms and external relations) will always accrue to the points of control over that infrastructure.
4183−
4184−Urbit simplifies much of this infrastructure but, just as importantly, it makes those technical locations, and the conditions of ownership and control, explicit. It allows for them to be owned and controlled by anyone who purchases them, rather than controlled by network-level overlords and unelected government regulators. Stars are somewhere between ISPs and consumer hosting platforms (like Geocities an eon ago, or Wordpress today); independent enough to set their own policies, but generally subject to the realities of running a profitable business. The decisions made by service providers inevitably have a great influence on the norms of any network, and Urbit is no different. The advantage of the Urbit model is that there are far more stars than ISPs, they are easier to run, they are fungible properties with clear ownership, and they are not burdened with technical and regulatory debt which ties them to the status quo. These qualities allow them to be purchased and maintained by a far wider range of people than might be able to control an ISP today; the massive decentralization of routing infrastructure also seems a likely antidote to the current state of regulatory overreach and centralized snooping which ISPs are subject to.
4185−
4186−The Internet gave us an unprecedented flowering of diverse cultures; it gave communities the option to pursue a vast number of paths and goals. And we _should_ have the ability, granted by wealth, free time, and communications technology, to arrange the rules of our collaboration as we wish. The structural design of the Urbit network is an effort to provide that power, encoded in a digital asset with private keys that can be held both by individuals and (via multisig arrangements) by groups. The lower price and complexity of stars compared to current ISPs also makes a lot more room for innovation in business models; star owners can make their own judgments about how to prioritize commercial revenue versus cooperative ownership, anonymity versus identity, short-term versus long-term contracts.
4187−
4188−We see stars as an opportunity to incubate community hubs, to plant a flag in the wilderness, declare values and alignments, and see who shows up. This process can be varied; some stars might advertise widely, others might quietly and slowly invite other communities on board. That’s the point. There’s a nice juxtaposition between first mover-effect and overall availability here; early adopters will have an opportunity to shape discourse, but the supply is not so constrained that they’ll capture all of it. Early adopters will likely have an immense and permanent value of voice, infrastructural ownership, and ongoing revenue over their shorter-term speculative one.
4189−
4190−The diversity and non-discoverability of Urbit are already showing themselves: we hear whisperings of insular communities that we not only _don’t_ know about but by our express intentions _can’t_ know about unless they make themselves known.
4191−
4192−Regardless of whether we or anyone else know about them, star owners already possess legible chunks of the ‘missing middle’’—large enough to affect the map of the Urbit universe, small enough to allow a wide array of voices—in a way that the ownership models of the current Internet can’t come anywhere close to providing. Not every neighborhood poker club needs an Urbit star. But the institution-founders, tastemakers, and social connectors of today and tomorrow, those who want to build opera houses on the digital prairie, should consider the advantages of building on a star.
4193−]]></content:encoded>
4194− </item>
4195− <item>
4196− <title><![CDATA[Tools of Our Own]]></title>
4197− <link>https://urbit.org/blog/tools-of-our-own</link>
4198− <guid>https://urbit.org/blog/tools-of-our-own</guid>
4199− <pubDate>Tue, 12 May 2020 00:00:00 GMT</pubDate>
4200− <content:encoded><. Of course, like many of our definitions, it requires some background to really contextualize the claim. When I describe this particular statement to people, they often ask, "What does that _mean_, though? What is a digital environment, and why would I need Urbit to do it?"
4212−
4213−After all, we think of our slate of tools as our entire toolbox. This makes sense for physical tools. And for a lot of people in the real world (at least, I think), their tools remain physical notebooks and paper. I, however, left those tools behind ages ago, and found myself in a world that used my habits, my memory, to loosely organize a wide array of online tools, that were themselves shaped according to the values of their creators.
4214−
4215−The [Rube Goldberg machine](https://en.wikipedia.org/wiki/Rube_Goldberg_machine) made out of aligning these tools in increasingly virtuosic, but also increasingly restrained and mechanical ways, felt like constructing an exoskeleton out of prefab parts. The person in my social group closest to constructing the full range of human movement became a legend. But let's be honest: none of us came even close.
4216−
4217−And it's nobody's distinct fault that the experience of aligning all these disparate services into a workflow is a skill in itself. It's a collective restriction that comes from the systems beneath.
4218−
4219−<br>
4220−
4221−<img class="ba" src="https://media.urbit.org/site/posts/essays/tools-of-our-own-2.png">
4222−
4223−### Systems as masters
4224−
4225−> If you don't understand a system you're using, you don't control it. If nobody understands the system, the system is in control.
4226−>
4227−> <cite>Philip Monk, <a href="https://urbit.org/blog/precepts/">Precepts</a></cite>
4228−
4229−If you asked any of the creators of the social tools we use today what their mission was, it would seem neutral, a public good. To "bring the world closer," to "make a more open and connected world," to "easily see what's happening in the world." Ignore the fact that the net effects of their products are far more mixed than their mission suggests: for many users, the tools themselves come second to the power the tools have in capturing their social graph.
4230−
4231−We just want to be where our friends are, to see who knows whom, to see a new friend vouched for by our common connections.
4232−
4233−Why is the social graph even a consideration when choosing a tool? Why do I have to know who has accounts where, how they choose to assemble their digital body, so that I can see that it exists?
4234−
4235−For a tool like a microblog—a bunch of entries in a database with metadata, usually threaded—the attachment of the social graph capture becomes not only an underlying appeal to us when choosing to use it, but also to the tool’s creators when trying to justify its existence.
4236−
4237−In this example, you could say that every social Internet product is trying to make up for its missing ability to connect coherent identities underneath. The battle becomes a matter between the stagnant empire of who owns the graph versus the various attempts to create a secure identity primitive as a layer of the Internet.
4238−
4239−But this is crazy: for decades, an aspect of the Internet stack that necessitated the creation of platforms—the ability to talk to other computers directly and to, privately, opt in, organize an array of devices as belonging to an identity—has driven not only the financial incentives of every product, but the use case for every person in the equation. A practically unrelated problem emerged that was too hard to wrangle and solve, and so it became the master.
4240−
4241−And for productivity tools—for the personal activities we do every day—the same problem ultimately applies. Either you wrangle more and more single-use "products" into a framework, wrangling combinatorial explosion, or you punt the problem to the user's brain, remembering the relation between tools.
4242−
4243−This is why hybrid products are born _and_ why massive enterprises are shifting toward subscription models for office software. With the [clearnet](<https://en.wikipedia.org/wiki/Clearnet_(networking)>), using our own computers for everyday tasks that extend outside themselves is not easy. It's way easier to sign into an enterprise's server farm for your persistent data storage and manipulation. In 2020, the prefab parts for the exoskeleton only come in "left arm, right leg" pairs, or you can just give up and plug straight into SkyNet.
4244−
4245−<br>
4246−
4247−<img class="ba" src="https://media.urbit.org/site/posts/essays/tools-of-our-own-3.png">
4248−
4249−### The collective body
4250−
4251−> “Autonomy” means that we make the **worlds that we are** grow.
4252−>
4253−> <cite>Tiqqun, <em>The Cybernetic Hypothesis</em>
4254−
4255−So why does this matter for us? Me and you and everyone we know? We put up with the cost all the time. But the limitations of our tools—on the vulnerable side of a power dynamic that, unbeknownst to everyone involved, functions as a catalyzed and increasingly accelerated system bringing out the worst in all of us—range from the everyday annoyances to a pervasive alienation, an information malaise.
4256−
4257−You have to ask yourself, "Why are we doing this again?"
4258−
4259−These days I find myself away from broadcast tools and more in the insular channels of my friend groups. What I want from technology is to share life with my friends; to be given the opportunity, and the power, to share that life, and all it includes… showing them care, or sharing the bits of knowledge that seem important to us as a group.
4260−
4261−To reinforce the fulfilment of collective potential in whatever direction our groups take off in. Some of my friends watch stuff together; some of my friends remark on goings-on; some of my friends research together; all communicate entirely differently. Not all of them belong on "IRC, but for gamers," or "IRC, but for highly productive and extremely important teams." And yet, that's where we are.
4262−
4263−Forget the prefab parts: a proper exoskeleton for our collective body evaporates; and we face the sunlight in whatever direction we choose. The ability to extend our shared spaces collectively, with each of our groups of friends and collaborators, using our own computers: that's Urbit.
4264−]]></content:encoded>
4265− </item>
4266− <item>
4267− <title><![CDATA[Platform Decay, Decentralized Marketplaces, and Urbit]]></title>
4268− <link>https://urbit.org/blog/platform-decay</link>
4269− <guid>https://urbit.org/blog/platform-decay</guid>
4270− <pubDate>Thu, 07 May 2020 00:00:00 GMT</pubDate>
4271− <content:encoded>< about the future of decentralized commercial protocols, presents an S-curve whereby a platform business transitions between serving its users in order to grow and achieve market dominance, and eventually exploiting those users once it has achieved that dominance. In particular, early-stage e-commerce platforms do anything they can to benefit vendors willing to sell on their platform. Vendor presence is vital to attracting customers, but once those customers have been captured, the vendors become the [competition](https://www.wsj.com/articles/amazon-scooped-up-data-from-its-own-sellers-to-launch-competing-products-11587650015?mod=searchresults&page=1&pos=1). Customer eyeballs and dollars are a finite resource, and platforms carefully calculate the potential profit to be made from showing customers one product or another. The lack of platform-agnostic reputation systems also aids vendor capture by platforms. Rather than optimize for a system in which any buyer or seller with good external credibility (measured by, for example, credit scores or relevant business licenses) can use their platforms as a commercial intermediary, eBay and Amazon use seniority and internal transaction records to determine vendor permissions. Since sui generis internal reputation scores can’t be taken to other platforms, these policies create a sunk cost of effort and reputation which traps vendors within specific marketplaces, without an easy exit.
4293−
4294−Market consolidation and bureaucratic pressures for legibility also work against maintaining a square deal with vendors and users. The midpoint on Dixon’s S-curve, when exploitation of vendors begins to occur, can also be seen as the point where a customer base is solid enough to be marketed to advertisers and major brands who can pay for favorable search placement. Such large, legible deals are easier to negotiate, easier for individual executives to take credit for, and are useful in meeting arbitrary investor benchmarks and buoying quarterly revenue statistics; but they privilege larger brands with larger ad budgets over ordinary sellers in a niche. Another major downside of large, centralized e-commerce platforms is that, like any large bureaucracy, they have PR and regulatory concerns that provide an attack surface for regulators, activists, litigious brands, and monopolists seeking to crush competition—almost invariably at the expense of vendors and customers.
4295−
4296−Even more subtle and worrying effects come when e-commerce platforms realize that the actual products being shown do not have equal chances of being purchased, therefore delivering revenue to the platform itself. This applies even when the products being compared have nothing in common: apples to oranges; cat food to hiking boots. Accuracy of internal search engine results, and a comprehensive spread of offerings, are regularly sacrificed to the aim of placing a ‘sticky,’ lowest-common-denominator product in front of the customer. I recently ordered vegetable seeds on Amazon; after a few searches for different kinds of seeds, I started having to wade through ‘premium placement’ ads for farmer-themed romance novels before I could view, and choose from, the actual seeds on offer. This deprecation of niche products is ongoing and makes the interface of such platforms less and less navigable. It’s also worth mentioning that, frequently, such deprecation has very little to do with durable consumer interest or a free-market determination of product value. Rather, they come from a ‘thumb on the scale’ of large advertising campaigns that seek to convert a wide range of consumer curiosity into sales for a particular product at a particular time.
4297−
4298−The manufacturing of consumer desire in this way feels creepy. It’s frustrating to have your tastes dictated to you by whoever has the biggest ad spend. It also spells the end of small business on the Internet—you can spend years mastering knowledge of a profitable niche, but if Amazon profiles your customers and decides they’re more likely to spend their money on the latest Pixar DVD, your listings will be shoved below the fold. Pixar paid for placement and you didn’t; the Pixar ad placement deal made a splash in the quarterly report, your fees didn’t. In cultural terms, this threatens to create a winner-take-all situation that will prevent new and niche artists and thinkers from gaining attention at the expense of explicitly placed, ‘premium’ content.
4299−
4300−Again, this is all accelerated by the way that ad sales function; platforms like broadly popular content and products because the larger number of customers searching for and purchasing them creates more granular data and increased opportunities for micro-targeting ads. This incentive leads to the increasing invisibility of long-tail, niche content or products whose appeal has less to do with lowest-common-denominator addictive virality, whether it’s the repair manual for your ‘85 Toyota or a copy of Plato’s _Republic_. It also accelerates the stampede toward a ‘sharing’ and ‘renting’ economy; when ad impressions are a sizable part of company revenue, forcing customers to return to ad-infested platforms to continue renting objects or content, rather than making one-time purchases, is a no-brainer.
4301−
4302−There’s a nightmare scenario here, a kind of hybrid, zombie brainchild of Jean Baudrillard’s concerns about the simulation of common meaning and Peter Thiel’s arguments about the stealthy hollowing-out of industrial capacity. In this nightmare future, financial and legal regulation strangle the viability of anything like a real industry, and we’re left with a handful of incumbent platforms which have concluded that the smartest move is to just sell vaporware ‘content,’ collectible bobbleheads, and sugar water. The supposed niche of any platform business is academic at this level; Amazon, Spotify, and Patreon are simply machines for converting user attention into the highest-margin purchases possible. The ‘high-velocity trash economy’ (h/t Pierre Rochard) increasingly shows itself as a network of funnels by which insider prognostications about government and central bank policy are turned into profits, with the illusion of productive activity serving only as window dressing. This deforming process extends all the way down to the vagaries of the consumer economy. If there is no financial reason for available consumer offerings to be anything we actually need, they can and will be deprecated and displaced; useful goods and services will be sidelined by literal trash that has the ‘financial’ logic of maintaining an unbroken, upward metric by virtue of direct parasitism upon the human brainstem.
4303−
4304−The implications are obvious: if we can’t make markets obey a representation of factual reality, we won’t be able to build stuff we need in the factual world. The damage which has been done by our replacement of infrastructural capacity with nebulous thematic concerns that happen to feed our dopamine receptors is becoming rapidly apparent to anyone paying attention. If our search results for ‘hammer’ algorithmically default to pro wrestling merchandise, that changes our real, physical lives. Our ability to go out and build things with a hammer is diminished, and so is, implicitly, the importance placed on that act of building by the culture that surrounds us. The physical world of technology, no less than the informational, is a slippery pile of patches and detours. When JPL scientists reestablished contact with an early satellite after decades of inactivity, they relied on vintage computer parts from eBay to communicate with it. In some areas (cars, hand tools, some analog electronics) the present consumer offerings have generally declined, in terms of reliability and user serviceability, from a zenith some twenty or forty years ago. Forty-year-old Toyota trucks often fetch more, in equivalent value, than they did when new, because regulations and planned obsolescence have prevented the ongoing production of trucks that meet the same standards of reliability and fuel economy. The failings of our just-in-time supply chain have likewise been made blatantly obvious by the disruptions of COVID-19. Both argue in the strongest terms against allowing consumer-facing e-commerce to be captured by what are rapidly becoming payola-driven entertainment platforms rather than marketplaces for essential goods, whether car parts, beef jerky, or N95 masks.
4305−
4306−So what’s the solution? Many prescient observers envision decentralized protocols to safeguard the data of vendors and buyers, and algorithmic representation of their offerings. Any new ‘deal’ between vendors, buyers, and platforms must be rooted in data ownership and neutral code if it is to avoid a repeat of the current paradigm. Personal ownership of browsing, buying, and selling data is necessary so that search results and boosted listings aren’t distorted for each customer in order to ‘nudge’ them into consumptive patterns, and so that value is retained in useful, niche items which don’t lend themselves to dopamine addiction and manipulative marketing campaigns. The hope is that widespread personal control of data would lead to the emergence of protocols and marketplaces which have realistic economic models based on fees; the ‘square deal’ originally promised by ‘Web 2.0’ platforms. Such marketplace businesses wouldn’t be exponential unicorns; they’d be steady, stable infrastructure companies like those that built the foundational technologies of the 20th century and made a secure, middle-class lifestyle possible for millions of people. Data ownership wouldn’t prevent platforms from incorporating advertising, but it would shift the balance of power to an opt-in basis. By reducing the ability to target such ads, it would prevent the lopsided reliance on ad revenue which leads to smaller vendors being neglected. Big companies wouldn’t go away; they’d make their margins by focusing on economies of scale in the real world: logistics, fulfillment, and redundant inventory for commodity goods.
4307−
4308−We need decentralized, robust reputation systems to combat monopolistic platform lock-in and its attendant abuses, but also so that smaller, more private marketplaces can create their own rules, and still be functional and secure. Right now, reputation data is siloed by the same companies that built large marketplace platforms, which means that anyone who moves outside of their walls loses access to it, and thus loses protection from bad actors. The ability of users to run their own reputation scans, or to pay for a separate layer of reputation data which is marketplace-agnostic, is essential to breaking the hold that large marketplaces currently have on e-commerce. If a local community wanted to trade in homegrown food, for example, they could restrict access, while also making sure that their members didn’t have a previous, external track record of fraud in other markets.
4309−
4310−Where does Urbit fit into this? We think that the basic infrastructure and alignment of the Urbit system has two major advantages to offer those who will build these new protocols. The first is the simplicity of running one’s personal server of data and locally hosted processes. Any attempt to reimagine privacy-focused e-commerce under current client–server models quickly runs into complexity problems—Web 2.0 platforms require reams of legacy code and armies of SREs to keep them running. The second is the ability to maintain a semi-private but reliable digital identity among different platforms and communities, including commercial ones. Most current conceptions of autonomous marketplaces rightly focus on the potential of cryptocurrency as a decentralized payment system. But wallet and exchange problems, the work-in-progress state of micropayment infrastructure, and price fluctuations among different currencies (crypto or fiat) clearly show the need for a decentralized reputation system which is not simply a crypto wallet address, but is likewise more secure than a PHP forum profile. We think that Urbit ID can provide such a holistic, yet pseudonymous, reputation system without being tied to a particular currency, wallet, or commerce platform.
4311−
4312−Right now, Urbit is a communication system for communities and individuals. We aim to create spaces where human conversations can take place with a minimum of distractions. We believe that commerce, too, is best achieved in such a space; think of your local hardware store rather than a carnival with barkers at every turn. We also see this as a priority deeply in keeping with the underlying ethos of Urbit. We frequently speak of Urbit as a tool, and reference classic principles of tool design when considering how to expand it. The test of any tool is in its ability to shape the world; if that function isn’t well matched to both the actual world, and the hands and desires of those who will wield it, usability will suffer. Open marketplaces should function as magnifying glasses, to hand buyers and sellers a tool to see the shape of supply and demand, rather than distorting the actual terrain of the marketplace in order to create its own desires. Soon we’ll have BTC integration tied to Urbit ID, and independent security audits of the Urbit system. We want Urbit to become the foundation on which users can build simple, decentralized protocols that enable us to safely and easily buy and sell goods and content that we actually want and need. Urbit is calm computing. Calm commerce follows naturally.
4313−]]></content:encoded>
4314− </item>
4315− <item>
4316− <title><![CDATA[Introducing OS 1]]></title>
4317− <link>https://urbit.org/blog/introducing-os1</link>
4318− <guid>https://urbit.org/blog/introducing-os1</guid>
4319− <pubDate>Wed, 29 Apr 2020 00:00:00 GMT</pubDate>
4320− <content:encoded><: a short, memorable name that you own with a private key (and belongs to you completely). Each group is private and requires an invite. Groups aren’t discoverable. They’re meant to be high-trust communities of people. More like a commune than a public event.
4358−
4359−Let’s walk through each module and talk about what they can do.
4360−
4361−### Chat
4362−
4363−<img class="ba" src="https://media.urbit.org/site/posts/essays/intro-os1-chat.png">
4364−
4365−Chat is chat: a sequential list of messages meant for synchronous communication. There are already a million ways to chat — but Urbit chat differs in a few important ways.
4366−
4367−First, each chat channel is only shared between the host and the members of a chat. When you DM with people, messages are sent peer to peer. The system is, in fact, decentralized and pseudonymous by default. No one knows anything about you outside of your Urbit ID.
4368−
4369−Second, each chat message is encrypted and signed by your Urbit ID. Again, we don’t call Urbit ‘secure’ yet since it’s unaudited — but we’re working to have Urbit audited this year.
4370−
4371−Third, chat in Urbit OS is a protocol for sending messages between computers on the network (known as “[ships](https://urbit.org/docs/glossary/ship/)” and identified by their Urbit IDs). It’s easy to imagine extending chat in all kinds of fun and interesting directions: chats that only accept certain message types, chats that have disappearing history, chats that you can only post to during certain times of day, and so on.
4372−
4373−(If you’re curious to try one of these things, or have an idea about something you’d like to experiment with — consider submitting a proposal in our [grants program](https://grants.urbit.org/). We regularly reward contributor work with address space.)
4374−
4375−We think of chat as a primitive, not simply a ‘better IRC’. But even in the rudimentary form it’s in today, chat is essential to delivering a feeling of being at home. There’s no way to deliver a complete interface for groups without chat.
4376−
4377−Anyway, not everything can happen in a chat. Let’s keep moving.
4378−
4379−### Links
4380−
4381−<img class="ba" src="https://media.urbit.org/site/posts/essays/intro-os1-links.png">
4382−
4383−Links is a bit like Hacker News or Reddit. It’s just a collection of links with comments. There’s no upvoting or sorting. We decided that with a small group it’s more about collecting references than deciding what’s most exciting — but permutations of Links could be a great area for contributors to experiment with.
4384−
4385−We use links to collect external references and track things we’re thinking about. We’re always looking at things going on outside our small digital universe and talking about them. Links lets us keep an archive of those discussions.
4386−
4387−We originally imagined links as evolving into more of a general-purpose ‘collection creation’ interface. One where you can pull together images, video, URLs, maybe even runnable code and so on into a single channel. We’ll get there.
4388−
4389−### Publishing
4390−
4391−<img class="ba" src="https://media.urbit.org/site/posts/essays/intro-os1-publish1.png">
4392−
4393−Publishing is somewhere between a blog and a note-taking system. A Publish notebook is a list of markdown files with optional comments. A private Publish notebook is like a journal, a group notebook can be like a forum (with comments on) or a collaborative blog.
4394−
4395−We use publish for both long-form discussion and one-way communication about what we’re working on in its current form. The editor is calm and simple. In distraction-free mode, it’s a nice place to put a note together.
4396−
4397−Publish, like all our other modules, is an interface to a generalized protocol for storing text. We have high hopes for how Publish can evolve into a flexible tool for notetaking and discussion with richer content types and better controls over structuring discussion.
4398−
4399−### Modules
4400−
4401−<img class="ba" src="https://media.urbit.org/site/posts/essays/intro-os1-home.png">
4402−
4403−You’ll find a few other things on the home screen: a clock, the weather, and a simple command-line that we call the Dojo. These are system-wide utilities that aren’t group-specific.
4404−
4405−The clock and weather tiles are simple indications of the state of the outside world. We built them because they’re things we wanted to be able to check in on often. When you’re spending much of the day in front of a computer, it’s nice to know if you have enough daylight left to get some exercise in.
4406−
4407−### Dojo
4408−
4409−<img class="ba" src="https://media.urbit.org/site/posts/essays/intro-os1-dojo.png">
4410−
4411−The Dojo gives you a quick way to see that, under the hood, Urbit OS is a powerful general-purpose system. The system hasn’t evolved to the point that our libraries, frameworks, and modules are polished to our standards. Since it’s still early, we can’t claim that it’s easy to develop on top of this platform. But we want it to become much easier.
4412−
4413−## Why we made OS 1
4414−
4415−We made OS 1 because we wanted to begin the process of re-centralizing our digital lives on a platform we actually control. Replacing all the services we use all at once is impossible — so we picked a suite that we felt would work nicely together. We’ve always felt that one of the most exciting things about Urbit is in bringing your digital life together in a way that feels like home.
4416−
4417−The digital home, we think, is what our computers are meant to be but simply can’t be in a world of cloud services. Once upon a time, thirty years ago, your personal computer was an open-ended tool that was reasonably simple to understand and use, lasted a pretty long time, and belonged to you in every way.
4418−
4419−OS 1 is a first step down the road back to a system that’s simple, durable, and belongs to you in every way. It’s a long road, and we feel like we’ve made a very significant step forward.
4420−
4421−One really critical thing about OS 1 is the pattern of ‘groups sharing modules’. This pattern makes it perfectly clear how a virtual computer can outcompete a bunch of different services. As the collection of modules in OS 1 → N grows, we make it easier for others to contribute modules, and we increase the flexibility of connecting modules our system quickly outruns the messy, disconnected world we’re currently stuck in.
4422−
4423−OS 1 isn’t mature enough to be _easy_ for outside contributors to add modules — but it is [open source](https://github.com/urbit/urbit), and anyone is welcome to tinker and experiment with modifying it. We run a [grants program](https://grants.urbit.org/) to reward contributors for improving any part of Urbit OS. As the system matures we expect this program to expand and accelerate.
4424−
4425−## Looking ahead
4426−
4427−By using OS 1 you inherit all the benefits of running Urbit OS. Each user runs their own node completely independently. Everyone using Urbit OS owns their own identity and data. And every Urbit OS node communicates over an encrypted and authenticated network. (Again, We don’t yet call Urbit OS ‘secure’ because it hasn’t been audited.)
4428−
4429−OS 1 is just a client for Urbit OS, of course. Other people could write their own clients that are completely different — like different windowing systems for Linux. Our hope is to build a client that includes interface components and frameworks that make it exceptionally easy to build modules for groups of people to share. Other clients could potentially invent entirely new ways of interacting with the underlying system.
4430−
4431−There are two threads by which OS 1 evolves into OS 2 and beyond. First, by becoming a more powerful system and second, by adding modules to expand our supported modes for interacting.
4432−
4433−In its current form, OS 1 by no means exposes all the power of the underlying system. Our approach to building OS 1 was to focus on the quality of the UI, and accept that it will feel like a monolithic app. We’re already working to evolve our interface into something that feels flexible to an ordinary user and developers can easily extend and build on top of.
4434−
4435−Specifically, we want better affordances for putting multiple streams of data on the screen at once, better keyboard shortcuts and navigation affordances, better libraries and frameworks for building modules. We want a standalone client and a single login system. These are some of the things currently on the drawing board.
4436−
4437−As far as modules are concerned, there are too many things we’d like to build to list them all. We’d really like to have threaded conversations; short, Twitter-style messages; biometric and status tracking; an e-book reader and annotations system — and that’s just to name a few we see in the near term.
4438−
4439−We’ve long since felt that the most powerful thing about Urbit is that it’s a general-purpose system. OS 1 puts us on the road to giving people an actual material sense of what using a general-purpose networked computer feels like.
4440−
4441−As we expand the affordances of the system and add modules over the course of OS 1, 2, and beyond we expect to deliver a system that can foster everyday creativity. There’s a long road ahead, in the best possible sense. We’re really excited about what the future holds.
4442−
4443−### Becoming a homesteader
4444−
4445−<img class="ba" src="https://media.urbit.org/site/posts/essays/intro-os1-landscape.png">
4446−
4447−As a distributed team trying to stay connected, we like using OS 1 from day to day. We’d really like to hand-onboard a small group of like-minded groups of people who want to experiment with living on the fringe of the digital world. Toward this end, we started the community grants program.
4448−
4449−Each community that’s selected will get a block of address space to share, direct support, and (in the near future) free hosting.
4450−
4451−Please tell us a bit about yourselves [here](https://urbit.org/community/community-grants/).
4452−]]></content:encoded>
4453− </item>
4454− <item>
4455− <title><![CDATA[The Value of Urbit Address Space (2 of 3)]]></title>
4456− <link>https://urbit.org/blog/value-of-address-space-pt2</link>
4457− <guid>https://urbit.org/blog/value-of-address-space-pt2</guid>
4458− <pubDate>Sun, 12 Apr 2020 00:00:00 GMT</pubDate>
4459− <content:encoded><
4461−
4462−_This is the second in a series of three posts on Urbit address space. See also [part 1](https://urbit.org/blog/value-of-address-space-pt1/) and [part 3](https://urbit.org/blog/value-of-address-space-pt3/)._
4463−
4464−## Measuring value
4465−
4466−Value and price are distinct concepts that often get conflated. In our view, Urbit address space has value for four fundamental reasons: it’s scarce; it has utility; it has some limited liquidity; and it has network effect. Price, on the other hand, is always a function of supply and demand, and it's not something we – as builders – concern ourselves with very much. Let’s take a look at these fundamentals within the Urbit ecosystem.
4467−
4468−## Scarcity
4469−
4470−256 galaxies, ~65,000 stars, ~4B planets.
4471−
4472−
4473−
4474−A foundational design principle of the Urbit network is that the address space is limited. This rarity helps qualify Urbit as a [collectible](https://nakamotoinstitute.org/shelling-out/), and thus creates a non-zero acquisition cost for an address. This cost discourages abuses like spam and bot-net attacks. Traditionally, these attacks are made with quasi-unlimited access to IP addresses. The unit economics of acquiring planets for these nefarious purposes is a strong deterrent.
4475−
4476−There are 256 galaxies on the network. Each galaxy is initialized with ownership of 255 stars. Galaxies act as root nodes for peer discovery and packet routing within the Urbit network, and they are each also entitled to vote on updates to the smart contracts which govern the network. To date, galaxies trade primarily on OTC (over the counter) desks, and rarely appear on the open market.
4477−
4478−There are 65,280 total stars on the network. In turn, each star is initialized with ownership of 65,535 planets. Stars currently trade on platforms independent of Tlon, such as [urbit.live](https://urbit.live/) and [opensea.io](https://opensea.io/). The current price range can easily be ascertained on those sites, but as of the time of this writing, stars are selling at a price that greatly discounts their planet holdings.
4479−
4480−One would expect that in an efficient market the relative pricing of stars on one hand, and planets on the other hand would eventually align (so to speak). This may come to pass as the Urbit community increases education about Urbit, and as additional planet sellers and hosting providers enter the space.
4481−
4482−Finally, there are 4,294,901,760 (or ~2<sup>32</sup>) planets on the network. Planets currently trade largely in a range of $10 to $15. We expect planet prices to fluctuate from provider to provider as described in the previous post, based on the quality of services various providers offer. That said, it's worth noting that the cost to configure addresses for distribution is fairly static and this may act as something of a lower bound.
4483−
4484−That said, we also anticipate that planet prices will be abstracted away from most purchasers, and will be included in bundled annual packages of hosting and data routing services. For this reason, infrastructure service providers (i.e. hosting providers) will likely be the best positioned parties to capture value from planet distribution.
4485−
4486−While an increase in the supply of Urbit address space is a technical possibility, it would run counter to the economic incentives of Urbit address space owners. This is why we view a galaxy vote to dilute address space as improbable.
4487−
4488−Scarcity may be sufficient alone to drive value, but it’s much more impactful when the unit has some underlying purpose, which brings us to utility.
4489−
4490−## Utility
4491−
4492−Utility (i.e. what Urbit addresses can be used for) has largely been addressed in the previous installation of this series. Briefly, our view is that stars and galaxies are useful for more than simply selling their subsidiary address space. Their use value encompasses their unique functionality on the network and the business models that functionality represents.
4493−
4494−As a refresher, this use value falls in five broad categories.
4495−
4496−1. Authentication technology is broadly useful. All Urbit identities — planets, stars, and galaxies — can be used for authenticating one’s Urbit computer, and for authentication in general. Urbit ID was designed for Urbit-specific authentication, but a lot of general functionality can be built on top of this infrastructure. Urbit ID is simple, extensible, and easy to use, making PGP style claims much more useful than they are today.
4497−2. Network infrastructure services represent a potential revenue stream. Stars and galaxies specifically should be understood as providing their owners the opportunity to develop and use network infrastructure. We anticipate that stars and galaxies will eventually charge for infrastructure related services, like hosting and packet routing, and will distinguish themselves on quality and service.
4498−3. Stars and galaxies are well positioned to offer additional services. Because of their role as high level network nodes, stars and galaxies are uniquely positioned to offer additional services, including content delivery networks (CDNs), Bitcoin and other blockchain-related nodes, 0x relays, and Tor exit nodes.
4499−4. Schelling points have value. Because stars and galaxies hold a certain authority on the network (by dint of their relationship to their subsidiary nodes), they act as [Schelling points](https://nav.al/schelling-point), or default hubs, for various activities that will arise as the network grows. Already various groups and communities are beginning to collect around stars. This gravity has value and will eventually be priced.
4500−5. Voting has value. Galaxies exclusively hold a vote on the network. This voting right can be separated from the galaxy itself and transferred, and we anticipate that this will happen eventually. The value of this right has not and may never be priced into the market, though as Urbit adoption grows, the value of a vote may emerge.
4501−
4502−Utility is only one component of a value calculation. To further develop the inquiry into value, let’s move on to trading factors.
4503−
4504−## Trading, volume, and liquidity
4505−
4506−Urbit IDs are individually represented by non-fungible ERC-721 tokens, and can therefore be sold by any platform that supports this token standard. Currently there are three known Urbit-exclusive sales platforms and one generalized ERC-721 platform that list Urbit IDs. Prices for stars and planets are readily available. Volume is low, as no effort has been made to promote the fact of availability, yet the number of [total transactions](https://azimuth.network/stats/events.txt) has increased steadily since the network was launched to Ethereum in 2019, even absent public messaging.
4507−
4508−
4509−
4510−
4511−
4512−Buying non-fungible tokens like Urbit IDs is rather different than trading quasi-fungible tokens like Bitcoin (even setting aside the issue of volume). Each Urbit ID is unique, and so they tend to be purchased by end users for their specific characteristics, rather than generically. As an example, the planet `~parret-barret` sold for about $1,000 at a time when most planets were selling for $10-20, perhaps due to its rhyming name. Planets with circular sigils also often sell for significantly more than other planets — we’re not entirely sure why this is the case.
4513−
4514−## Planet Sales
4515−
4516−
4517−
4518−
4519−
4520−## Star Sales
4521−
4522−
4523−
4524−This ID-specific trading pattern is generally appropriate in our view: Urbit ID isn’t designed to be rapidly traded at high volume. Urbit is more like a house than a fungible good like a currency.
4525−
4526−For the time being buying and selling of Urbit IDs happens through auctions on specific platforms, and via person-to-person transactions, because each transaction is for a _specific_ Urbit ID. Again, Urbit ID is designed in the spirit of property titles, rather than currencies, so this makes sense.
4527−
4528−Strictly speaking, liquidity is a measure of the degree to which a given asset will change in value due to a given transaction. In that sense, Urbit address space is likely fairly illiquid. But liquidity can’t be properly understood without volume. As noted above, the volume of transactions on the network has been steadily increasing since inception, and yet the price has remained fairly constant. This seems to indicate a healthy ratio.
4529−
4530−
4531−
4532−A further impact on liquidity and volume is that of available supply. At present, the majority of Urbit address space is locked by smart contracts. These lockups began to release at varying linear rates in January 2019. All address space will be completely unlocked and tradeable by January 2025. Eventually as both understanding and demand increase, we anticipate that planets will find an equilibrium price, and stars will be repriced accordingly.
4533−
4534−We’ll discuss lockups and spawning limits in more detail in the third installment of this series.
4535−
4536−In our view, this combination of scarcity, utility, and the above trading factors is a useful description of existing market dynamics for Urbit address space. A further description of why Urbit has value lies not just in its trading characteristics, but in the utility of human interaction. This brings us to network effect.
4537−
4538−## Network effect
4539−
4540−Much is made of the concept of network effect and its impact on network valuations generally. The concept is fairly straightforward so long as numbers aren’t applied. Broadly speaking, networks are interconnected systems of people or things. Network effects are mechanisms wherein every new user of a given system makes the system more valuable to every other user.
4541−
4542−Urbit is a network of networks, and it’s designed specifically for communities — for communication and collaboration. The more people who use Urbit, the more communities get started by design. The more communities there are, the more likely outsiders get pulled in to join them, and so the virtuous network effect cycle continues.
4543−
4544−Digging deeper, Urbit is unusual as a network for the following interrelated reasons:
4545−
4546−1. Urbit is a platform in the true sense; wherein
4547−2. connections are peer-to-peer;
4548−3. privacy is high;
4549−4. discoverability is low;
4550−5. customization and autonomy are nearly limitless; and yet
4551−6. the number of possible groups and node connections is essentially unbounded.
4552−
4553−The upshot is that Urbit can serve as the meta-network for many different kinds of individual networks, each with their own value. Urbit is much more akin to the internet itself than it is to, say, Facebook. Reed’s and Metcalf’s laws therefore apply to Urbit in some very interesting ways.
4554−
4555−## Network laws
4556−
4557−Before diving into a discussion of network effect, it's worth noting that although individual tokens and users of those tokens benefit in various ways from a thriving network, the structure of the Urbit network does not grant token holders any rights to profits or losses "generated by the network" as a whole. In fact the very notion is counter to the intent of Urbit's ethos of decentralization. Individuals on the network may profit by their own activities, but there is no central authority profiting off activity in the aggregate; there is no ownership of the network as a whole, and so there are no centralized profits and losses to share. Address space tokens represent one's ownership of their own parcel of land as it were.
4558−
4559−That said, an entire continent may have aggregate value even though it is distributed. To explore this notion with regards to Urbit, it's worth reviewing the three laws typically cited to express the value of a network as a whole:
4560−
4561−- Sarnoff’s law states that the value of a network increases proportionally to its size. This is widely understood to understate the value of most modern networks.
4562−- Metcalf’s law states that the value of a network is the square of the number of users (n^2).
4563−- Reed’s law states that the value of a network increases with the number of groups that can be built on the network. This is expressed as 2^n, where n is the number of groups.
4564−
4565−Reed’s law captures the notion that groups vastly increase the density of connections on a network and so scale value more quickly.
4566−
4567−Urbit is a network of networks, and so is best described by Reed’s law.
4568−
4569−Urbit’s unique approach to groups also helps resolve two other problems which lead to value loss in many networks: Urbit’s design significantly reduces both network pollution (i.e. irrelevant feeds) and network congestion (clogged bandwidth), as individual clusters can easily separate their activity from other networks on the platform.
4570−
4571−## Urbit is a platform network
4572−
4573−It’s important to note that Urbit has utility absent the network, as Urbit OS is in fact a Turing-complete virtual computer. Though the system is designed around communities, individuals can use Urbit to create personal documents, archive data, and write code for the system. This is how Urbit’s total network size can be relatively small and still provide value for individual users and clusters. However, Urbit already has users, and for many of these, critical mass — the point at which the network is more valuable than its cost — has already been reached. In addition, as each of these individual clusters writes code for the platform, positive indirect network effects increase (more utility arises from these individual development efforts).
4574−
4575−This combination of effects makes Urbit significantly more robust than non-platform networks which can’t rely on this intrinsic utility.
4576−
4577−That said, we do not intend to ever rely simply on this individuated computing utility alone. Urbit is for communities, and Tlon’s primary focus is to increase adoption of the system as a whole, including the network. To this end we’re working steadily to increase functionality of the system, improve messaging, and actively onboard communities.
4578−
4579−## Network identity
4580−
4581−Another distinguishing characteristic of Urbit is that identities are pseudonymous but can easily be de-pseudonymized by users at will (though not by outside authorities). This flexibility combined with identity reputation accrual means people can behave in different ways depending on the social context. People can communicate privately, publicly, or in small groups, and they can do it anonymously or otherwise. This natural and extensible approach to social engagement results in personal comfort and drives adoption.
4582−
4583−## Extensibility
4584−
4585−Because Urbit is vastly customizable, and because it’s a network platform for other networks, it can and should grow in ways we can’t predict. Each new use case that develops creates a new market, new communities, and new hubs. Each of these contributes to the diversity of the overall ecosystem, making it vastly more interesting and diverse than anything we might create alone. We expect this extensibility to contribute greatly to retention as users are able to build the world they want to inhabit.
4586−
4587−Urbit is a deeply extensible platform for communities: it’s a network of networks. Users join to be part of communities, then launch communities of their own, further driving growth and engagement in a virtuous cycle.
4588−
4589−In the next installment of this series, we’ll describe lockups and availability in more detail and will share the data we’ve managed to compile about address space distribution.
4590−]]></content:encoded>
4591− </item>
4592− <item>
4593− <title><![CDATA[Infrastructural]]></title>
4594− <link>https://urbit.org/blog/infrastructural</link>
4595− <guid>https://urbit.org/blog/infrastructural</guid>
4596− <pubDate>Thu, 09 Apr 2020 00:00:00 GMT</pubDate>
4597− <content:encoded>< (The first interface in Urbit’s evolutionary chain) and OS 2 (Urbit’s eventual departure from the web browser context). In its service as a “bridge”, we designed OS 1 to extend from the baseline app-like “module” experience first defined in OS 0, while granting it new affordances that gesture towards nascent conceptions of “communal computing” we have planned for OS 2 onward.
4609−
4610−This year, as the warmer seasons give way to chillier ones, we plan on further demonstrating our vision of what new computers and networks can be and how they feel to use. Until then, we'll be building upon OS 1, our foundation and initial take on what we deem "human-shaped infrastructure."
4611−
4612−This post serves as a reflection–meditation on OS 1’s initial form development and the attitude we brought to bear in designing it. I will be highlighting a few disparate-yet-interconnected themes we encountered in our design work, and how we materially began to address them.
4613−
4614−## Products
4615−
4616−Urbit’s interfaces, and the process by which we build them, are resolutely not projections of the world’s current conception of digital design—that of mass digital product design. Products are sold, bought, and discarded as they are in their physical sense. Digital products are slotted into the [vending machines](https://urcad.es/writing/personal-computer-vending-machine/) we call our phones and are mass produced as candy is produced. Candy is _essentially_ free, and contemporary digital products are _absolutely_ free of cost. If you’re reading this, you probably already have a good idea of what free corporate digital products mean for your privacy.
4617−
4618−Urbit is distinctly _not_ free (as in freely offered as a service via a corporate entity), and your urbit is distinctly _not_ a product. As we trace over the interfaces we design with our cursors, we’re not building a product, we’re not selling a product, we’re not painting a product, and we’re certainly not decorating a product.
4619−
4620−Here at Tlon, we’re assembling thoughtful infrastructure you can spend your life using, learning, and extending. We’re attempting to assemble spaces you can one day pass on to friends, close collaborators, or possibly your grandchildren. We are resolute in our practice and stay our hands to the greatest degree possible as a result of this mindset.
4621−
4622−## Beautiful Infrastructure
4623−
4624−OS 1, while incremental in its initial expression from OS 0, serves to outline our stance of what sublimely beautiful, useful, and durable digital infrastructure should feel like to inhabit. For the purposes of OS 1, we can imagine “Beautiful Infrastructure” to form the spirit of what we’re building:
4625−
4626−**Beautiful infrastructure is inhabitable**. You’re not floating in an infinite feed of content streams. You are situated in a defined space with edges you can shift at-will, as your needs deem fit. Our model for inhabitable computing is new and in limited flux, but our vision is long.
4627−
4628−**Beautiful infrastructure is a gravitational force**. Even if you can’t feel it or directly experience it, well-designed infrastructure is a cohering force. One is grounded with respect to the infrastructure they live alongside.
4629−
4630−**Beautiful infrastructure is like a [shell](https://en.wikipedia.org/wiki/Shell)**. Well-considered infrastructural projects provide durable, generalized, reusable, and most importantly, _self-designed_ containers around otherwise formless flows of information.
4631−The current state of mass software design has gotten many of the “reusable” elements of design down pat, but these structures are optimized to pump ads and information into your brain, algorithmically-sorted-linear-feed style.
4632−In Urbit, I can take the conceptual container of "temporal linearity" and use this to shape communication data as I see fit. I should be able to shape once-linear communication and cast it into a nodal communication model: My DM is now a MUD.
4633−
4634−Truly beautiful infrastructure undergirds the daily exchanges people actually care about—I don’t drink plumbing, I drink the water it carries and protects.
4635−
4636−Another way of thinking about “Infrastructure” (here defined loosely as “the _truly_ essential structures that allow society at varying scales to operate”) is to think about it in terms of interpersonal support structure.
4637−
4638−We deeply hope that Urbit can form a support structure for you and your community.
4639−
4640−These self-evident statements underlie the core problems we sought to address in designing a userspace for OS 1: How do we design an _actually_ personal digital infrastructure? What does infrastructure look like when shared with immediate friends? With a cooperative organization? How can we impress upon Urbit's earliest adopters that once they've obtained an Urbit ID, their computer is at that moment _literally_ entirely theirs?
4641−
4642−<br>
4643−
4644−<br>
4645−
4646−<img class="ba" src="https://media.urbit.org/site/posts/essays/infrastructural-2.jpg">
4647−
4648−## Expressing Infrastructure
4649−
4650−OS 1 was optimized from an interface design standpoint to ensure that a new inhabitant viscerally felt like there was a “space to inhabit”, or a “canvas to be painted”, or a set of simple and fundamental digital structures they could arrange to make their computer their own.
4651−
4652−Counterintuitively, designing around this notion of a "rich blank slate” required OS 1 to be designed in a manner that _almost_ results in it feeling incomplete, or on the verge of appearing deeply unremarkable.
4653−
4654−A few key design decisions emphasized the above gestalt we sought to express:
4655−
4656−- We decided very early on to revert the colorful presentation of Modulo to a literal blank slate—OS 1 is much like a sheet of graph paper now.
4657−- All typography and typographic representation was severely flattened. This decision was one of our more drastic ones, and granted OS 1 a sense of being somewhat more "undirected" in terms of its form. We hope that as our system becomes more robust, users can decide which elements of their systems require emphasizing, to feel most at home with their information.
4658−- The majority of graphics used throughout the system were rendered into black and white line drawings. As architectural schematics and orthographic projections flatten their representation of reality so an architect can “see structure” easier, we made the decision to express a visual foundation that felt more like a diagram than an ergonomic user interface.
4659−- In its visual simplicity, OS 1 was essentially arranged to emanate the quality that modifying the underlying system was a simple task. Rather than present Urbit's first users with beautiful artistry and a sense that our infrastructure was to remain untouched and sacred, we decided to present a visual face to the project that felt nearly rudimentary, nothing outside the realm of editorial capability for the average person.
4660−
4661−Many other small constraints have been set into place to build what we truly believe to be simple, durable, personal, digital infrastructure.
4662−
4663−While visually primitive, OS 1 has managed to manifest a rich systematic expressiveness based on how it seems to be currently inhabited. We've been enjoying witnessing the ways people are beginning to interpret and make use of the faculties provided to create communal computing experiences of their own.
4664−
4665−What's most wonderful to observe is the fun people are having in striking out on their own in this collective endeavor. More than anything, we hope Urbit’s inhabitants are having a good time and learning to enjoy computers again.
4666−]]></content:encoded>
4667− </item>
4668− <item>
4669− <title><![CDATA[The Value of Urbit Address Space (1 of 3)]]></title>
4670− <link>https://urbit.org/blog/value-of-address-space-pt1</link>
4671− <guid>https://urbit.org/blog/value-of-address-space-pt1</guid>
4672− <pubDate>Mon, 06 Apr 2020 00:00:00 GMT</pubDate>
4673− <content:encoded><
4675−
4676−_This is the first in a series of three posts on Urbit address space. See also [part 2](https://urbit.org/blog/value-of-address-space-pt2/) and [part 3](https://urbit.org/blog/value-of-address-space-pt3/)._
4677−
4678−## Part One – What/why, a history, and some analogies
4679−
4680−Does Urbit address space have value?
4681−
4682−The short — but perhaps not very useful — answer to this question is that yes, the market appears to believe that it does have value. This series of posts digs a bit deeper into why.
4683−
4684−As developers, we at Tlon tend to focus on building functionality rather than valuation models – possibly to our detriment. When we discuss Urbit address space, it’s typically about the technical elements, or the use cases.
4685−
4686−Now that people are using Urbit on a daily basis, we want to make sure that Urbit IDs (collectively “Urbit address space”) are well-understood. We thought it would be useful to explain our thinking about value, and to provide some of the building blocks that others can use to create their own valuation models.
4687−
4688−There’s a lot to discuss, so we’re breaking this discussion into three posts. The first explores what Urbit ID is, shares some history, and provides a few analogies that can help in understanding value on the network. The second looks at scarcity, utility, liquidity, and network effect. The third post explains lockups and availability.
4689−
4690−For a refresher about what we’re doing, check out our [introductory materials](https://urbit.org/understanding-urbit/) or [Urbit for Normies](https://urbit.org/blog/urbit-for-normies/).
4691−
4692−## Urbit ID basics
4693−
4694−In order to explore why Urbit IDs have value, we’ll start by explaining the basics of how they function.
4695−
4696−From one perspective, Urbit ID is simply a means of logging into Urbit OS. From another, Urbit IDs represent a new class of digital asset.
4697−
4698−From the standpoint of an ordinary Urbit user, Urbit ID is designed to be simple: it’s a login system for a new OS, but with one or two unusual qualities. Under the hood, your Urbit ID is your network address, your username, and a digital asset wallet. Anyone can use your Urbit ID to locate you on the network, and then send you messages (i.e. packets), or digital assets.
4699−
4700−We say that Urbit IDs represent a new form of digital asset for three reasons.
4701−
4702−1. Urbit ID is designed such that the user actually _owns_ their name. This means that Urbit IDs are transferable and tradeable. Conventional username and password schemes are merely claims to a bit of data on another party’s server. An Urbit ID, on the other hand, is a piece of cryptographic property on a public key infrastructure.
4703−2. Urbit IDs have utility: they’re currently useful in the Urbit ecosystem, but beyond that they’re vastly extensible and they can be used for many more purposes. Owning an Urbit ID is a bit like holding a self-authenticating property title. If Bitcoin is money and smart contracts are law, Urbit ID is land.
4704−3. Urbit IDs are scarce in order to discourage spam and abuse.
4705−
4706−We’ve often said that Urbit IDs have value because they’re useful and scarce. The fact that they’re being traded on platforms independent of Tlon seems to bear this out.
4707−
4708−## Urbit network structure
4709−
4710−The network of IDs is structured as a sponsorship tree consisting of 256 galaxies, ~65,000 stars, ~4B planets.
4711−
4712−Galaxies are the root nodes on the network. They each have a vote on upgrades to the rules that govern the network, they provide packet-routing and peer-discovery services, and they spawn stars. Each galaxy has 256 (2<sup>8</sup>) stars to spawn.
4713−
4714−Stars similarly provide packet-routing and peer-discovery services, and spawn planets. Each unbooted star contains ~65,000 planets (2<sup>16</sup>).
4715−
4716−Planets are the individual IDs that most people use on the network. There are a total of ~4B (2<sup>32</sup>) planets all combined. Planets can also each spawn ~4B ‘moons,’ which are Urbit IDs intended to be used for IoT and other devices. Moons are permanently locked to their planets for security and to protect the network from sybil attacks.
4717−
4718−Stars and planets can leave their sponsors (i.e. the star or galaxy currently providing peer discovery and packet routing) if they wish, and sponsors can choose to stop servicing any given star or planet. This is intended to prevent lock-in and to encourage good behavior from both parties. This mutual accountability is important in a network of finite identities that accrue reputation.
4719−
4720−Essentially Urbit ID is 2<sup>32</sup> individual names that are bundled into blocks that are larger and larger in size. You might think of a planet like an individual house, a star like a town or a city, and a galaxy like a county or a state.
4721−
4722−The Urbit ID registry and its rules are built on a set of smart contracts called [Azimuth](https://github.com/urbit/azimuth). These contracts are registered on the Ethereum blockchain. Galaxies can upgrade the mechanics of Azimuth by majority vote.
4723−
4724−Today, Urbit ID is live and deployed. Each Urbit ID is represented by an ERC-721 non-fungible token. People buy and sell Urbit IDs every day and the number of transactions has been steadily increasing.
4725−
4726−So, fundamentally, Urbit ID is just a finite set of names and a system for assigning them. We’ve left out a few technical details here, but if you’re curious you can read our [introductory](https://urbit.org/understanding-urbit/urbit-id/) materials or, to go deeper, read the [docs](https://urbit.org/docs/) or the [source](https://github.com/urbit/azimuth).
4727−
4728−## Why we need a new address space
4729−
4730−In our view, the short history of the Internet has been a lesson in centralization and consolidation. DNS is a cabal of root servers. IP is essentially controlled by a single entity. All of our naming schemes have been more or less centralized. Certificate-signing is a mess of competing authorities. Search is Google. Hosting is AWS. And don’t even get us started on social networks.
4731−
4732−Centralization on its own isn’t bad, but it certainly has some negative implications, privacy being the most obvious. Beyond that, the naming schemes we have on the Internet today aren’t _personal;_ they’re not controlled by their users.
4733−
4734−Simultaneously working against this trend are a variety of decentralized web projects, various digital currencies, and dozens of protocols that are all focused on individual use and distributed ownership. But how do any of those actually surface to the mainstream? How do people identify themselves in this new digital world? Where do they call home? Where’s the Schelling point when they want to connect and work together?
4735−
4736−Urbit ID is the missing piece. It’s the minimally viable substrate for the digital world that’s been sketched out by Bitcoin, Ethereum, and all of their decentralized kin. From our perspective, the kit of decentralized technologies that exist today is designed for a world that’s only just coming into existence. That new world shouldn’t be owned by any one entity; it should be distributed. We believe that Urbit OS and Urbit ID are the right foundation for interacting in that world.
4737−
4738−The ownership structure of a new territory has a huge impact on its future shape. While most of Urbit ID remains an uninhabited grid, we see it as most likely to become a varied array of neighborhoods and cities. Not because this is a nice outcome, but because it’s the most economically likely one. More on the concept of neighborhoods below.
4739−
4740−## History and distribution
4741−
4742−So how did these ~4B names get initialized and distributed? Urbit address space was created _ex nihilo_ — from nothing but an idea — and then distributed directly to project contributors who helped develop the system.
4743−
4744−Now that the system is up and running, Urbit address space has steadily become more distributed. This arguably follows the distribution patterns of the Bitcoin UTXO set, and even historical distribution patterns of physical land.
4745−
4746−Let’s take a look at how this came to be.
4747−
4748−Urbit was originally an experimental personal project. The original Urbit address space registry was just a text file in the source code at that time. At the very beginning, all of the address space was owned by Curtis — its creator — and it was all pretty much worthless. In the years leading up to 2013, Curtis gave away galaxies to anyone who would help or contribute to the project, and to several people who were simply in the right place at the right time.
4749−
4750−Once Urbit became a working prototype, in mid 2013, a company (Tlon) got off the ground to help develop Urbit and a number of other developers joined. At this point, Tlon bought half the address space from Curtis for what now looks like an exceptionally good deal. Then Curtis and Tlon each earmarked a significant chunk of address space for infrastructure and community development — we refer to this as the urbit.org address space, and it’s held by Tlon.
4751−
4752−From 2014-2018 Tlon and Curtis both gave away address space to individual contributors who were helping with the project. In 2016 and 2017, Tlon sold some of its address space in two crowdsales to fund the development of Urbit (which formatted the Urbit address space as a user-facing system). These sales were focused on getting address space into the custody of users with an interest in the technology and developing the network.
4753−
4754−It was then decided that a public key infrastructure was the most logical way to instantiate ownership of Urbit address space. Thus, after much [consideration](https://urbit.org/blog/urbit-and-the-blockchain/), Urbit ID was deployed to Ethereum in January 2019 under a set of contracts called Azimuth. At this point, there were about 2000 star holders and around 80 galaxy holders. We can’t be sure how many independent holders there are now — the address space is entirely out of our hands — but the distribution has been steadily increasing. Addresses trade regularly on urbit.live and Opensea, and are sold by a few other smaller outlets like planet.market and Urbit Marketplace, all of which are independent of Tlon.
4755−
4756−## Analogues and the intrinsic value of address space
4757−
4758−We’ve often said that Urbit address space, particularly stars and galaxies, have intrinsic value that should be understood beyond simply the price of the planets they contain. Another way of putting this is that, because stars and galaxies are infrastructure nodes, they’re uniquely positioned to generate cash flow from activities on the network beyond simply selling their planets.
4759−
4760−This cash flow won't likely come from passive activity, but from actively working to develop businesses located on stars and galaxies. Let’s dig a bit deeper into these activities through the lens of some analogues to the existing world.
4761−
4762−### DNS
4763−
4764−We’ve often compared Urbit ID to the IPv4 and IPv6 systems. In this scheme, galaxies are much like [/8 blocks](https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_address_blocks) of IPv4 addresses, while planets are much like individual IP addresses. The difference is that IP addresses are rarely owned by end users, and they’re typically assigned dynamically, so they tend to change. This is why IP addresses can’t be used to accrue reputation for end users or to prevent spam. It’s worth noting that while most of us don’t own our IP addresses; they are currently [traded](https://auctions.ipv4.global/) on the open market. As of the time of this writing, individual addresses are selling for ~$20. /8 blocks are extremely valuable, and none are currently on the market.
4765−
4766−### ISPs
4767−
4768−Another analogy that we often use is that of ISPs (Internet service providers). Stars in the Urbit network are the closest approximation here in that they help planets connect to the network. Ultimately, connections on Urbit are peer-to-peer, but stars provide initial connections, distribute software updates, and route packets when peer-to-peer connections don’t yet exist. These services all represent a cost, and we believe they’ll eventually be metered and priced.
4769−
4770−### CDNs
4771−
4772−CDNs (content delivery networks) are another useful comparison. Stars are perfectly positioned to play this role in the Urbit ecosystem. Because stars are designed as packet-routing infrastructure, they’re able to easily spin up greater bandwidth to service high-demand content, or to aggregate content. Stars can also act as content curators and providers, or as content filters for those who want a more narrow range of access. On the other end of that spectrum, stars could easily function as something similar to VPNs (virtual private networks) for any type of content.
4773−
4774−### Software distribution
4775−
4776−An infrastructure innovation that’s relevant here is that Urbit OS is specifically designed to make over-the-air (OTA) updates to the system — meaning software and updates are distributed automatically with no effort on the part of the end user. By default, planets and stars get their system updates from their sponsors. As the system evolves, we expect stars and galaxies to not only provide core system (kernel) updates, but also to act as software distribution hubs. Stars will distinguish themselves from one another by the quality of their service. Some might focus on speed of distrubtion; others on assesing the quality of the code they distribute. All of this represents effort on behalf of the star, and could act as a profit center for the star operator.
4777−
4778−### Payments and transactions
4779−
4780−On top of routing and software distribution, there are likely other worthwhile services for stars and galaxies to provide. A payments-focused star could run Bitcoin, Lightning or Ethereum nodes exclusively for sponsored planets. A trading-focused star could run a 0x relayer and provide an order book for sponsored planets. It’s easy to imagine machine learning or compute services being offered as a service; for example, a star could bolt on a TensorFlow chip and allow its sponsored planets to run computer functions for a fee.
4781−
4782−### Land
4783−
4784−We often use land as an analogy to describe Urbit address space. This is not simply because Urbit address space is finite or because IDs act as addresses on the network. It’s because Urbit is designed to be extremely extensible. Once you take possession of your Urbit — whether it’s a galaxy, star, or planet — you have immense flexibility: you can use it as-is out of the box, you can rearrange your environment, or you can go as far as writing code to create new functionality. Urbit address space is meant to be used productively. Urbit is very much territory for homesteaders.
4785−
4786−We expect that certain groups of Urbit IDs will be more valuable than other groups. There is no unit price for physical land — rather, price depends on location and a host of other factors. Similarly, we expect a range of prices to develop for Urbit IDs. We’ve already seen price variation around specific names and [sigil](https://urbit.org/blog/creating-sigils/) shapes.
4787−
4788−In the long term, the real value of an infrastructure node (a star or galaxy) is not simply in trading on the unit price of planets, but in developing and improving the real estate.
4789−
4790−### Dealer-operators
4791−
4792−Another approach to developing the value of address space that is already emerging is that of the dealer-operator. The most convenient way for an ordinary person to use Urbit is to have a planet hosted in the cloud so they can log in from any device. Because the long-term value of a star or galaxy is in providing services, and because most planets and stars need to be hosted, providers of these services have begun to emerge.
4793−
4794−These providers sell users a planet, host it for them, and deliver related services through their stars and galaxies. This means that with a couple of clicks an ordinary user could buy a planet, sign up for a hosting/routing bundle, get access to a set of services, and be immediately ready to interact with the community of their choice.
4795−
4796−There are plenty of other examples that we haven’t even imagined yet. The important thing is that stars will likely distinguish themselves through the services they provide. Since planets and stars can always change sponsors, a large part of the long-term monetization of a star or galaxy lies in the quality of service that a given star operator provides.
4797−
4798−This independent ecosystem has a secondary benefit of creating a varied tapestry of digital environments on Urbit, since every community and every dealer-operator can customize as they see fit. That variety will make the landscape much more interesting and ripe for exploration than anything we might create with the top-down approach found on centralized services. That variety will also likely cause a range of values for planets depending on their sponsor or “location”.
4799−
4800−This ecosystem has already begun to emerge. Both Tlon and urbit.live are working on developing services along these lines, and we’ve heard from several other entrepreneurs considering similar offerings. This is emerging not simply because it serves a user need, but because it’s the directional flow of the system. In other words, it’s the simplest way to monetize address space while avoiding the oligarchic, surveillance-based, advertising-oriented systems we’re stuck with today.
4801−
4802−To summarize, our view is that Urbit address space is valuable because it’s useful and it’s scarce (and it has network effect, but more on that later). What’s more, while the use case has already begun to take shape, it will grow in directions we can’t yet imagine because the system is designed to be extensible — Urbit is a homestead, not a hotel.
4803−
4804−We’re looking forward to seeing what the world builds with Urbit.
4805−
4806−In the next post in this series, we’ll explore the issues of scarcity, utility, liquidity, and network effect.
4807−]]></content:encoded>
4808− </item>
4809− <item>
4810− <title><![CDATA[~2020.4.4 Update]]></title>
4811− <link>https://urbit.org/updates/2020-04-04-update</link>
4812− <guid>https://urbit.org/updates/2020-04-04-update</guid>
4813− <pubDate>Fri, 03 Apr 2020 00:00:00 GMT</pubDate>
4814− <content:encoded><
4816−
4817−We’ve had a big week. On Friday, we presented OS1 to the world. The event included both an interactive demo, and a panel of Tlon developers and designers talking about the thinking, and the deep roots of computing history, that lead up to this moment. Lots of you attended online and asked great questions; thanks for coming! If you missed our livestream of the OS1 release event, a video can be found [here](https://www.youtube.com/watch?v=71ViyftPkGk).
4818−
4819−Urbit OS1 is designed as a flexible, user-owned tool for creating and living in communities. To that end, we’re giving out sets of Urbit address space to communities who’d like to use Urbit. [You can apply here.](https://urbit.org/community/community-grants/)
4820−
4821−If you’re a Hoon School graduate, we’ve got a big announcement: The inaugural Hoon School Hackathon, a free-form competition in which participants will have a month to create the coolest Urbit-related projects they can, runs from Friday, April 3 to Monday, May 4. A total of 22 stars are being given away to those who submit the best projects in this timespan. The Hackathon is only available to those who have graduated from a session of Hoon School. We’ll be sending an email out to everyone who is eligible.
4822−
4823−Haven’t done Hoon School? Don’t worry! We will be running more hackathons in the future, at least two a year. The next Hoon School session begins on Monday the 6th, so there’s still time to sign up. Go to [urbit.org/community/hoonschool/](https://urbit.org/community/hoonschool/) to enroll.
4824−
4825−OS1 is for [homesteaders and tinkerers](https://urbit.org/understanding-urbit/roadmap/). It’s profoundly new. It’s not our final destination, but it’s an important and foundational tool for getting there. And it’s a big leap towards allowing individuals and communities to use it for their needs. There’s already a growing constellation of public communities on Urbit. When you’re ready to launch OS1, check out our [install guide](https://urbit.org/getting-started/).
4826−
4827−If you need a planet, you can buy one from [Urbit Live](https://urbit.live).
4828−
4829−For updates on OS1 and the Urbit project in general, we encourage you to follow us on [GitHub](https://github.com/urbit) and [Twitter](https://twitter.com/urbit)!
4830−]]></content:encoded>
4831− </item>
4832− <item>
4833− <title><![CDATA[The Understanding Urbit Podcast]]></title>
4834− <link>https://urbit.org/blog/the-understanding-urbit-podcast</link>
4835− <guid>https://urbit.org/blog/the-understanding-urbit-podcast</guid>
4836− <pubDate>Thu, 02 Apr 2020 00:00:00 GMT</pubDate>
4837− <content:encoded><![CDATA[
4838−<br>
4839−
4840−<img class="ba" src="https://media.urbit.org/site/posts/essays/uu-podcast.png">
4841−
4842−At the end of January, the team at Tlon invited me to spend some time at their San Francisco office and to create a podcast series about Urbit. The idea was to produce an interview-based series about the project told in the words of those working on it. In this modest goal, I think we were very successful. Beyond a transactional description, however, we captured a range of perspectives of the flaws in our current computing landscape and visions for how Urbit will alter it.
4843−
4844−Over the course of seven episodes, the interviews explore subjects ranging from the philosophy of technology to the performance optimization of Nock execution. Most are non-technical, but even the technical ones will be understandable and entertaining to a non-technical audience. That latter fact is the result of just how much fun the Tlon team is to be around.
4845−
4846−The series can be found on iTunes, Spotify, and most other streaming platforms.
4847−
4848−<iframe style="border: none" src="//html5-player.libsyn.com/embed/episode/id/13669184/height/90/theme/custom/thumbnail/yes/direction/backward/render-playlist/no/custom-color/000000/" height="90" width="100%" scrolling="no" allowfullscreen webkitallowfullscreen mozallowfullscreen oallowfullscreen msallowfullscreen></iframe>
4849−
4850−We begin our journey with Urbit veteran Galen Wolfe-Pauly, who introduces the project and its design principles while reflecting on the collective Stockholm syndrome we suffer in the grasp of existing computing models. We learn a bit about Galen’s background in architecture, and the importance of invisible technology.
4851−]]></content:encoded>
4852− </item>
4853− <item>
4854− <title><![CDATA[Urbit is for Communities]]></title>
4855− <link>https://urbit.org/blog/urbit-is-for-communities</link>
4856− <guid>https://urbit.org/blog/urbit-is-for-communities</guid>
4857− <pubDate>Sun, 22 Mar 2020 00:00:00 GMT</pubDate>
4858− <content:encoded>< about becoming a ‘digital prepper’. It feels like it has already happened to me, too. I’ve seen enough centralized services shut down and disappear (often with my data) that I’m reluctant to try new ones. No matter how friendly and cozy their branding.
4888−
4889−I find myself vetting every new app or service to figure out whether they have the potential to survive far into the future. The giant services I’ve become dependent on all seem somewhat worrisome. How long can these free services possibly stick around? Certainly not forever.
4890−
4891−The incentives in the current structure are totally misaligned. Let’s walk through them:
4892−
4893−I want to keep my data forever, but most companies are beholden to growth. If they can’t produce that growth and die, my data either disappears or becomes unusable without their software.
4894−I don’t want my data to be sold or for anyone to spy on me, but ad-funded companies have to engage in these practices to stay alive.
4895−I don’t want a piece of software to go away if a company dies, but apps and services require maintenance that’s complicated and expensive to do. Without the company around, their software is useless.
4896−
4897−The simple fact is, I let companies run my software because it’s too much work for me to run it myself. Most people can’t be their own sysadmin — and those that can have other things to do.
4898−
4899−This is more or less the entire technical value proposition of Urbit: to build a system that’s simple enough that it requires almost no maintenance. Our approach to building software makes all of the above problems easily solvable.
4900−
4901−Perhaps more importantly, we have a direct incentive to solve these problems. Tlon funds Urbit’s development by selling addresses and providing hosting. And the only reason anyone pays us for these things is because we make Urbit as directly useful for you as possible.
4902−
4903−That means we have to solve the problems inherent to the legacy internet. There can’t be any sense of suspicion or uncertainty in our new system. Your Urbit has to be something you can really trust and attach to. This is why your Urbit lets you run or write whatever code you like, and why we’re focused on making sure the data you put into your Urbit lasts forever: it won’t disappear when some company dies.
4904−
4905−But even with a system that fixes all of these issues by default, it only matters if the system is usable and understandable. What we really want is a digital world that’s generated by the communities that inhabit it — which means it has to be generated by people with no technical knowledge.
4906−
4907−## Communities are built by people
4908−
4909−In the physical world, you can arrange the furniture in your house, or go to Ikea, or build your own furniture, or figure out how to build a house from scratch. By taking your preferred approach to design, you contribute to the shape of your city. The world around us is a wonderfully loose collaboration between the more technically oriented architects and planners, and the everyday homeowners and residents.
4910−
4911−The digital world is, of course, nothing like this. Even software developers are stuck with the current system. None of our existing apps or services can connect to one another, so whether you’re a user or a developer, you’re faced with the daunting task of replacing everything all at once if you want a better system. But nobody can do that.
4912−
4913−Urbit provides an experience with less distance between ordinary use and total customization. To start, we’ve created Ikea-like, Lego-like and woodshop-like levels of usability. What we’ve built isn’t nearly as complex as the physical world, of course, but it’s a start.
4914−
4915−For most people, customizing your Urbit should be a matter of picking from an available suite of modules. Not unlike going to Ikea. For some people, recombining interfaces and data sources within Ubit should feel like playing with Legos. And for others, who want to dive in and write code, it’s the same as going into a shop full of high-quality tools.
4916−
4917−We’re not quite to this level of sophistication, but we’re on the path. Let’s talk about where we are and where we’re going.
4918−
4919−## OS 1
4920−
4921−Our rough attempt to satisfy this goal is hovering on the horizon. We call it OS 1.
4922−
4923−In OS 1, you bring a group of people together to share a set of channels. A channel can be a chat, a notebook, or a collection of links. We built an interface for doing this, but you could just as well build your own. Inside OS1, data and interface aren’t stuck together like they are with apps in the default web. Nor are the people you’re connected with locked into any given Urbit app. App, data, and social graph are always separate in Urbit; they’re modular and always under your control.
4924−
4925−OS 1 is designed to make it easy to start a group. Everyone in the group runs their own instance — so everything is only shared with the people you’re connecting with. Light customization of this experience is easy for an ordinary user.
4926−
4927−If you want to go deeper, anyone can build a new protocol for storing data and transferring it around Urbit without too much difficulty, but you do have to write some code. If you really want to dive all the way in, you can modify the system all the way through to the kernel.
4928−
4929−Currently, our Ikea experience is pretty limited, there are only a few Legos to play with, and the shop is still quite rudimentary — but it’s a good start and, for the first time, it exists as one complete system.
4930−
4931−The system is ripe for experimentation, customization, and exploration. It’s ready for earnest homesteading. Come build.
4932−
4933−## → N
4934−
4935−OS 1 is really just the beginning. There are so many more modules and means of communicating and collaborating to add. There is so much we can do to make the system more customizable.
4936−
4937−But OS 1 actually passes the bar of being both usable and futureproof. Urbit is something you can put energy into, in earnest, even as a digital prepper. It’s both safe enough and customizable enough that high trust communities can begin to take root. Urbit isn’t ready for you to build Rome — but it is ready for you to start a commune, salon, or reading group.
4938−
4939−The point, in the long term, is to let the technology fade into the background. We want people not to be ruled by their software, but the opposite: for our software to grow to suit us. Our hope is for Urbit to be as invisible, calm, and reliable as possible — and for people to be at the center, in control.
4940−
4941−If you want to explore this new world with us, let us know. We’re going to give away a limited number of hosted OS 1 communities.
4942−]]></content:encoded>
4943− </item>
4944− <item>
4945− <title><![CDATA[Precepts: Discussion]]></title>
4946− <link>https://urbit.org/blog/precepts-discussion</link>
4947− <guid>https://urbit.org/blog/precepts-discussion</guid>
4948− <pubDate>Tue, 17 Mar 2020 00:00:00 GMT</pubDate>
4949− <content:encoded><.)
5337−
5338−A dynamic type system tells you neither of these ahead of time. Instead, you end up with type errors at runtime. Errors at runtime must be handled at runtime, when the programmer is not present. Errors at compile time are handled at compile time, when the programmer is present.
5339−
5340−There's a hybrid, which is "static type checks at run time". In other words, you load the code and run the type checks at run time. This is better than pure dynamic checking because as long as the code compiles, you get the guarantees of a static type system. But the later in the process that the code is compiled, or the more it's changed before compiling, the less guarantee you have that the type checker will pass. If a static type checker gives an error at a time when the programmer is not present (because it's run at runtime), that's worse than a dynamic type system — at least that would give it a chance of executing correctly!
5341−
5342−> B5: Anything with business logic speaks one paradigm; anything that
5343−> translates paradigms has no business logic.
5344−
5345−Translating between paradigms with significant impedance mismatch is usually convoluted code. The state machines are often hard to see, and it tends to be quite cluttered.
5346−
5347−You want your business logic to be as clean and short as possible. This way the interesting algorithms are laid bare.
5348−
5349−> B6: Functionally enforced semantic rules are better security primitives
5350−> than memory access restrictions.
5351−
5352−Memory access restrictions are blunt tools. Blunt tools are nice in simple systems, and if all you have is nails, then a hammer is perfect. But in practice you punch all sorts of holes in these restrictions, because you need more granularity and flexibility.
5353−
5354−Better to define rules in a more powerful language. This allows you to follow A6 and A8. It also lets you use all the correctness tools, like type systems, that you've developed for the rest of your code.
5355−
5356−<br>
5357−
5358−<img class="ba" src="https://media.urbit.org/site/posts/essays/discuss-04.jpg">
5359−
5360−### C: Attitude
5361−
5362−Good code is the result of people approaching the act of engineering with the right attitude.
5363−
5364−> C1: Code courageously.
5365−
5366−If you avoid changing a section of code for fear of awakening the
5367−demons therein, you are living in fear. If you stay in the
5368−comfortable confines of the small section of the code you wrote or
5369−know well, you will never write legendary code. All code was
5370−written by humans and can be mastered by humans.
5371−
5372−It's natural to feel fear of code; however, you must act as though
5373−you are able to master and change any part of it. To code
5374−courageously is to walk into any abyss, bring light, and make it
5375−right.
5376−
5377−The unix/internet stack is a giant ball of mud. It's so big that when you're standing on it, it looks like a bog, and it's not clear that there is a bottom to it. You know there must be, but it doesn't matter because you learned long ago that the best solution is to not dig too deep. Build a strong structure by spreading out your weight and using strong construction materials. If there's something useful deep in the mud, it's probably not worth diving in to pull it out. That's dangerous and prone to failure, and you know many people who have gotten stuck down there.
5378−
5379−This is an appropriate reaction to the unix/internet stack. It's also self-perpetuating. The bog is filled — even _composed_ of — countless predecessors who did that same thing. If you ever find yourself on solid ground, protect that with your life. Learn how it works and how to use it well. Then build a strong structure on top of that. Don't let it decompose into a layer of mud.
5380−
5381−Urbit is small enough that, while there's definitely some construction-related dirt and muck covering it, the solid metallic core is not very deep — not more than waist deep in most places. The feeling of always being in contact with the bottom is very different than flailing about in a bog.
5382−
5383−This property is worth fighting for. It's the whole reason Urbit was written. New Urbit programmers are instinctively distrustful of anything below them and code defensively and fearfully. They must learn that it's all drastically simpler and more legible than they're used to. It's still hard, but you can actually make progress. To do so, you have to stand up straight, so you can get a firm footing on the ground. Keep your chin up and your shoulders back, and adopt the posture of a conqueror. When something doesn't work right, don't retreat into your shell of safety and control — fix it. The forces of chaos are always lurking, but their victory isn't inevitable. It's all on the line, so code with abandon.
5384−
5385−> C2: No time for lazy people.
5386−
5387−If there's clearly a right way to do something and a wrong way, do
5388−it the right way. Coding requires incredible discipline. Always
5389−follow conventions, and fire anyone who won't. Anything that can
5390−be solved by discipline is not a real problem.
5391−
5392−> "To him who knows to do good and does not do it, to him it is
5393−> sin."
5394−
5395−Preserving the property of solid ground requires perpetual discipline. Once lost, it's often impossible to reacquire. Don't compromise your standards.
5396−
5397−Call people out when they're being lazy. And when someone calls you out, recognize it and fix it. Sometimes it's just a question on a code review — "why did you do it this way?" Upon reflection, you determine that you did it that way because you couldn't be bothered to do it right. Maybe that was a reasonable choice at the time you were coding so you wouldn't be distracted, but if it's been called out in a code review, now's the time to fix it, not make excuses.
5398−
5399−> C3: When a smart person makes an obviously stupid suggestion, before
5400−> responding take a full 60 seconds to envision how you would implement
5401−> it and what the effects would be.
5402−
5403−Once you've determined that someone understands a situation well, if they earnestly make a suggestion that you haven't thought of, or that you immediately dismissed as impractical, stop and consciously consider it. This is one of the best ways of countering the natural echo chamber
5404−of your own mind.
5405−
5406−This is also one of the best ways to build stuff correctly. Very often, you will be tempted to cut a corner, and someone will point out that it should be done correctly. You should consider why you immediately rejected it. Was it because you were afraid of the relevant piece of code? If so, you should learn more about that code to determine if it's actually a good idea. Did you reject it because you felt it would distract you from working on what you thought was more important?
5407−Consider carefully whether this particular piece of technical debt is worth taking on. It's worth 60 seconds of thinking about how you could solve it correctly right now — often it would be quite easy to do correctly and you'd be paying interest on the incorrectness for a long time.
5408−
5409−<br>
5410−
5411−<img class="ba" src="https://media.urbit.org/site/posts/essays/discuss-05.jpg">
5412−
5413−### D: Theory
5414−
5415−The eternal tension between theory and practice must not simply be acknowledged, but dealt with.
5416−
5417−> D1: Academia is a succubus.
5418−
5419−The results from academia are useful to take advantage of, but the process of academia is a deadly sin for a project as ambitious as Urbit.
5420−
5421−Academia usually gets the right answer, but it's slow, and it often cycles through a large number of wrong answers before it gets to the right one. It's also unconcerned with many things that a real project must consider. For example, it's generally more concerned with mathematical simplicity than mechanical simplicity, contradicting A21.
5422−
5423−> D3: Not being qualified to solve a problem is no reason not to solve it.
5424−>
5425−> D4: The best way to get the right answer is to try it the wrong way.
5426−>
5427−> D6: Everyone must regularly alternate between theory and practice.
5428−
5429−One common failure mode for academia is to get bogged down in optimally solving a particular part of a problem such that it fails to solve the whole problem.
5430−
5431−There's a sense of "if I don't know how to do it, I must discover the correct answer before I can do it". This will get you the right answer if it terminates, which is the sort of algorithm mathematicians like. Engineers like algorithms that do in fact terminate.
5432−
5433−The fastest way to build a good system is to build it as well as you know how, then iterate on it. You have to be disciplined about actually iterating over time as you learn about the problem, but often the way to learn more about the problem is to move beyond it and work on adjacent
5434−problems. Hindsight is 20/20, so get the problem in your rearview mirror as fast as possible. Then while you're driving somewhere else, you'll see what you should have done. Then turn around and go do it. This only works if you or someone else is willing to go back and fix it
5435−(C2).
5436−
5437−> D2: Never fear math.
5438−
5439−You can spend years working on a problem that you're able to solve in a few days with the right theoretical grounding. There's no excuse for being ignorant of theory; or rather, being ignorant of theory is an excuse to learn it.
5440−
5441−Many engineers fear theory the same way they fear a complex piece of code deep in the stack (C1). But they shouldn't, because theory is rarely muddy. The same characteristics that make theory impractical also make it clean and learnable. It's also pretty permanent, so a one-time investment will pay dividends for a long time.
5442−
5443−Of course, if you look deep down, you may find laziness is what's keeping you from learning theory. If that's the case, you need to decide how much you want to design good software. Because there's no room for laziness (C2).
5444−
5445−> D5: Practice tells you that things are good or bad; theory tells you why.
5446−
5447−You can never tell whether a system is good or bad without using it (see discussion on A21). Theory has great explanatory power, but only limited exploratory power. The best it can do is point out areas of the idea maze you haven't explored and suggest correlations between
5448−objective properties and your subjective judgment of the quality of the system.
5449−
5450−However, that explanatory power is indeed powerful, and the exploratory suggestions are often able to break you out of a rut (attractor basin). Respect the tension.
5451−
5452−<img class="ba" src="https://media.urbit.org/site/posts/essays/discuss-06.jpg">
5453−
5454−<br>
5455−
5456−### E: Text Style
5457−
5458−Code form matters. Code that is hard to read is hard to maintain. Code that is inconsistently formatted is hard to read, but consistency isn't the end of the story. Some formats are simply hard to read.
5459−
5460−Formatting also isn't the end of the story. Naming and commenting conventions are even more important to clarity. The human brain is quite good at taking stuff that's in an unexpected form and interpreting it.
5461−
5462−This is why the diversity of accents and handwriting rarely causes issues, while the diversity of languages requires specialized translators. For someone used to typing on a QWERTY keyboard, it takes some time to get used to typing on a Dvorak keyboard because you have to rewrite your muscle memory. But it's nothing like how hard it is to learn another language. Russian script is roughly as different from English script as Russian grammar is from English's, but it's drastically easier to learn to read, handwrite, and type Cyrillic than it is to learn Russian grammar.
5463−
5464−So, uniformity of style is good, but it's not sufficient. The style must be readily readable and writable.
5465−
5466−### Formatting
5467−
5468−> E1: No code should extend beyond 80 characters, most within 55.
5469−
5470−Very wide code is unreadable. Even before you get to the readability threshold, it's useful to keep your code relatively narrow. Too narrow of code, on the other hand, results in too tall of code. What these two have in common is that they make it hard to navigate the code.
5471−
5472−Code navigability is the ability to find the part of the code you're looking for. This has several inputs:
5473−
5474−- how far away is what you're looking for?
5475−- how many distinct places in the code can you have on screen?
5476−- how much code can you have on screen?
5477−- how fast can you recognize that you're in the correct place?
5478−
5479−Some of these are strongly affected by workflows. We can't force a developer to have an effective workflow, but we can support those who do. If your workflow is deficient in one of these areas, consider improving it.
5480−
5481−One of the primary inputs to code navigability is how much of it you can have on your screen. Code that is too wide limits the number of columns of code. Some people keep only one column on their screen, so they don't see a problem with long lines of code. The most efficient navigation is to already be there (i.e. to only have to move your eyes). If you only have one column of code open, you can only be in one place, which eliminates the best form of navigation.
5482−
5483−Dually, code that is too narrow limits the number of lines you can have on a screen (this isn't a separate precept simply because we've never had to tell someone to write _wider_ code). This suggests there is some happy medium. This is dependent on the language, but in Hoon we've
5484−found that up to 55 columns is a pretty good number for most code. However, there are plenty of legitimate reasons to go a bit longer than that. 70 columns is rare, but not surprising. There is essentially never a reason to extend beyond 80 columns.
5485−
5486−> E2: Tabs aren't real.
5487−
5488−Code is a text file, and text files are WYSIWYG. The reader should view the file exactly the same as the author wrote it. This is a low-overhead way of avoiding editor-dependence in code, which is as bad as browser-dependence in javascript. Sure, tabs aren't as big a deal as the hell that front-end devs have to deal with, but there's no reason to give an inch to the forces of platform-dependence.
5489−
5490−Some argue in favor of "customization". Customization is inconsistency.
5491−There can be good reason for inconsistency in some areas, but not in
5492−code formatting, which is such an intensely communicative action.
5493−
5494−> E3: A text file is a series of lines, each ending with a newline
5495−
5496− character.
5497−
5498−There are several competing definitions of text files, but most commonly-used software uses this one. It's simple and consistent.
5499−
5500−Its disadvantage relative to "a text files is a series of characters, possibly including newlines" is that there are some arrangements of characters that are not valid text files (ie non-empty and not ending in a newline). However, some series of characters were already not valid
5501−in a text file — eg those including control characters or other nonrepresentable characters.
5502−
5503−In return, we get the advantage that we can treat a text file as having a more complex and useful structure — a list of lists of characters, rather than simply a list of characters.
5504−
5505−These are theoretical concerns — the real answer is that it's the way it's always been done, and deviating from that without a good reason is asking for trouble.
5506−
5507−### Names and comments
5508−
5509−> E4: One block comment is better than interleaved comments on every line.
5510−
5511−Interleaved comments are easy to write because you can just paraphrase the code. This is also why they're generally useless. In the micro, code should always be immediately understandable. In the macro, it's often helpful to give context as to the purpose or constraints of the function. Sometimes it's good to even give the algorithm line-by-line in pseudocode, but mixing the pseudocode with the real code obfuscates both.
5512−
5513−> E5: Don't name anything you don't have to.
5514−
5515−> E6: If it's the same thing, give it the same name.
5516−
5517−It is often said that there are two hard things in computer science: cache invalidation and naming things. This is a good aphorism. As often, someone will respond with "There are two hard things in CS: cache invalidation, naming things, and off-by-one errors". This is a weak
5518−joke because off-by-one errors are not hard at all. They're mostly a matter of discipline, and there's a couple of conventions that help. If you're looping on a zero-indexed variable, use `i < num_loops`. If you're looping on a one-indexed variable, use `i <= num_loops`.
5519−
5520−However, cache invalidation and naming things are genuinely hard because they must be solved ad hoc. There is no one-size-fits-all cache invalidation strategy, and possibly there never will be. Similar for naming. So you must actually comprehend and work within each individual
5521−context.
5522−
5523−You shouldn't solve hard problems if you don't need to, so don't name anything you don't have to. Giving unique names to things is tiring, and it reduces readability. A consistent pattern for naming things makes it easy to keep track of what is what and reduces the number of
5524−decisions you must make.
5525−
5526−Examples:
5527−
5528−- If the only difference between three things is that they're not the
5529− same, consider naming them `thing-1`, `thing-2`, and `thing-3`.
5530−
5531−- Use agglutinative morphology. If `a` is to `b` as `c` is to `d`, then
5532− find an affix which describes this distinction (say `-suf`) and rename
5533− them to `a`, `a-suf`, `c`, and `c-suf`.
5534−
5535−- A corollary of the above is that if one variable represents the "same"
5536− thing with a different type, that type should be the morpheme added.
5537− For example, if `a-set` is a set, then `~(tap in a)` should be called
5538− `a-list`.
5539−
5540−- Don't abbreviate (E8) — everyone abbreviates differently, and bits are
5541− cheap. If it takes you a long time to type the name, consider (1)
5542− finding a more succinct name (good any time you can do it), (2)
5543− becoming a faster typer, or (3) learning autocomplete tools, such as
5544− snippets.
5545−
5546−- Especially don't abbreviate or otherwise change the word when adding
5547− affixes. Inflectional morphology is bad in such an ad hoc context as
5548− code.
5549−
5550−> E7: Humans are good at memorizing.
5551−
5552−We're really good at memorizing sets of things, like runes. We're also good at inferring structure from patterns. We're bad at memorizing structure in apparently unrelated names, though, and once we see a pattern, we assume it's densely populated.
5553−
5554−So don't be afraid to use new names for new concepts. If concepts are siblings, they needn't necessarily have a direct connection in their name, but if they're hierarchical, then something should suggest that. This can be syntactic or semantic.
5555−
5556−<br>
5557−
5558−<img class="ba" src="https://media.urbit.org/site/posts/essays/discuss-07.jpg">
5559−
5560−### F: Real Software
5561−
5562−Not all software matters. Or at least, not all software comes within
5563−the scope of "Urbit". Urbit cares about "Martian software".
5564−
5565−> F9: Timeless software is good software.
5566−
5567−There's different sorts of software. A lot of software is inherently ephemeral, and can really only be run in one place. A SAAS company runs bespoke software on a particular set of servers, and that software has no future. It will never be run on anyone else's servers, and it will eventually stop being run even there. It won't even have any direct descendents. It's a genetic dead end.
5568−
5569−However, not all software is this way. Urbit is interested in software that can live forever. This is what we call "real" software.
5570−
5571−This is the most important passage in all that has ever been written
5572−about Urbit:
5573−
5574−> What is Martian code actually like? There are two possibilities.
5575−>
5576−> One: since Earth code is fifty years old, and Martian code is fifty
5577−> million years old, Martian code has been evolving into a big ball of mud
5578−> for a million times longer than Earth software. (And two million times
5579−> longer than Windows.)
5580−>
5581−> This hypothesis strikes me as possible, but implausible. Since the _big
5582−> ball of mud_ expands indefinitely, Martian code would therefore be so
5583−> large and horrible that, despite its underground installed base, the
5584−> server room bulged into space like a termite mound, intercepting
5585−> low-flying asteroids and stinking up the solar system all the way to
5586−> Pluto. Our latest space telescopes would surely have detected this
5587−> abominable structure - if not, in fact, collided with it.
5588−>
5589−> Two: therefore, at some point in Martian history, some abject fsck of a
5590−> Martian code-monkey must have said: _fsck_ this entire fscking ball of
5591−> mud. For _lo_, its defects cannot be summarized; for they exceed the
5592−> global supply of bullet points; for numerous as the fishes in the sea,
5593−> like the fishes in the sea they fsck, making more little fscking fishes.
5594−> For lo, it is _fscked_, and a big ball of mud. And there is only one thing
5595−> to do with it: _obliterate_ the trunk, _fire_ the developers, and hire a
5596−> whole new fscking _army_ of Martian code-monkeys to rewrite the _entire
5597−> fscking thing_.
5598−>
5599−> This is such an obvious and essential response to the _big ball of mud_
5600−> pattern that, despite the fact that we know nothing about Mars, we can
5601−> deduce that it must have happened on Mars. Probably several times.
5602−> Probably several hundred. For each of these attempts but the last, of
5603−> course, the result was either (a) abject failure, (b) another _big ball
5604−> of mud_, or (c) both.
5605−>
5606−> But the last, by definition, succeeded. This is the crucial inference we
5607−> can draw about Mars: since the Martians had 50 million years to try, in
5608−> the end they must have succeeded. The result: Martian code, as we know
5609−> it today. Not enormous and horrible — _tiny and diamond-perfect_.
5610−> Moreover, because it is tiny and diamond-perfect, it is perfectly stable
5611−> and never changes or decays. It neither is a _big ball of mud_, nor tends
5612−> to become one. It has achieved its final, permanent and excellent state.
5613−
5614−We don't know that Urbit will achieve this final form, but Urbit is an attempt to make progress in that direction. Any software that isn't a candidate for "tiny and diamond-perfect" is either a prototype or scaffolding.
5615−
5616−Here's some characteristics of real software:
5617−
5618−> F1: If it's not deterministic, it isn't real.
5619−
5620−If you do the same thing twice, your computer should react the same way. This is comforting. This is also what makes it easy to reason about and use effectively. If you're not sure what your computer will do, you'll be afraid of it and act defensively toward it. This inevitably leads to a big ball of mud.
5621−
5622−Diamonds are extremely hard, and they wear very slowly. A diamond surface will support you every time; a mud surface will shift out from under you exactly when you put weight on it.
5623−
5624−> F2: If it's centralized, it isn't real.
5625−
5626−Code that depends on a central authority or has a single point of failure is fundamentally brittle. No authority lasts forever, no company lasts forever, no server lasts forever. Under certain
5627−circumstances, bones and the like can be preserved for a long time — but not alive. The remains of buildings sometimes last for thousands of years, but the cities are gone.
5628−
5629−The only things that last forever in their useful form are big hunks of rock (like the pyramids at Giza) and ideas, through writing and transcription. So, if you depend on the sun existing, this is
5630−acceptable. If you depend on a piece of source code to be kept forever, copied and re-copied, you're fine. If you depend on a 20-year-old company existing and being easily accessible, this is brittle.
5631−
5632−Another way to look at this is to say that anything that wouldn't work on a spaceship is architecturally flawed. Maybe it requires many sequential round-trips to a central server because it doesn't have all the relevant information. See discussion of A7.
5633−
5634−> F3: If it's owned by someone else, it isn't yours.
5635−>
5636−> F4: If it's managed by someone else and you can't change who that is, it
5637−> isn't yours.
5638−>
5639−> F5: If it's not yours, it isn't permanent.
5640−>
5641−> F6: If it's not permanent, it isn't real.
5642−
5643−Nobody is as aligned with your values as you are. If you don't control the software, then you can't guarantee you'll always have access to it. Whoever does control the software may destroy it, move away, or simply revoke your access to it.
5644−
5645−Control has some nuance. If it's physically controlled by a company and you can't get your data and the software that makes it useful, you definitely don't have control. If you have physical control of it, you do have control. But if you're hosting the data and software on a commodity cloud server, you still mostly have control of it. Your privacy has been reduced, sure. However, as long as you keep regular backups of the data and software, if the hosting provider disappears you just need to find another host, or host it yourself. Any particular host is likely to disappear, but the situation where _every_ host disappears and you can't even host it yourself is much less likely. Brands are mortal, commodities are not.
5646−
5647−Some branded hosts allow you to download a zip file of your data. This gives you a little more control over your data, but it's much closer to "no control" than "total control". This is because your online world is data plus code, and without the code that makes it useful, data is only good for scrapbooking. The scrapbook will remind you of the good old days, but you won't be able to live them again.
5648−
5649−> F16: Sovereignty necessitates understanding.
5650−
5651−Not everyone cares to understand the software they're using. But if you want to compute sovereignly, you must understand what your computer is doing. If it regularly surprises you, you're not in control of it. You must tame it. The current paradigm is a wild monster which cannot be tamed by mere humans — only megacorporations even attempt to do so, and it's always temporary. So, your software needs to be simple enough that it can be understood.
5652−
5653−> F10: System modules should be designed to be frozen permanently;
5654−> conversely, Urbit consists of that system software which admits of a
5655−> Kelvin version.
5656−
5657−"Kelvin versioning" is a versioning scheme where your current version is a natural number, and new versions count down. Once you hit version 0, no more changes should be necessary.
5658−
5659−This is the opposite of the usual way of developing software, where there is no defined endpoint. This paradigm suggests that you're building something specific. Most current software builds higher and higher in a vain attempt to reach the heavens, until all available effort is expended just to keep this tower from falling over. Kelvin versioned software cuts away until you reach a strong bedrock. Not every piece of software should have a Kelvin version, but infrastructure should.
5660−
5661−> F11: The two procedures for achieving timelessness are distillation and
5662−> generalization.
5663−
5664−When building a timeless system, you start by building whatever you need to make it work. Then as you continue on, you may find some of the features are no longer necessary. Often, they're only needed when you're using them for user-facing work, but you've already moved on to building user-facing stuff somewhere else. You don't need the niceties anymore, so you should remove them.
5665−
5666−Other times, you find that you want something similar to a feature you already have, but not exactly the same. When this happens often enough with the same feature, you may discover what is the essential nature of the feature and what are simply ornaments of the original use of the feature. Then, you can generalize the feature so that each of the desired use cases is well served.
5667−
5668−> F13: That which cannot be Kelvin-versioned should update fluidly and
5669−> automatically.
5670−
5671−Not everything should be Kelvin versioned. Much user-facing code is in a continual process of discovery, and it must react to changing userbases and their needs. These should update without user interaction. You should be able to turn off your ship for years at a time, then turn it back on. After a few minutes or hours of catching up, you should be ready to go.
5672−
5673−This means you need upgrade paths to be permanent, and they must not lose information. Anything that stops being able to upgrade is not permanent, since it will succumb to bit rot.
5674−
5675−> F14: Humans are interactive and temporal; technology is permanent and
5676−> exhaustive.
5677−
5678−This is why the software humans touch directly should not be Kelvin
5679−versioned but the infrastructure that makes it work should be.
5680−
5681−> F7: The way it is isn't always the way it ought to be.
5682−
5683−You should presume that there's a good reason for why things are done a certain way because what works best tends to win in a market in the long term, but markets are rarely efficient. Markets become more efficient over time, if they become more liquid, and as they become larger. Software is young, the cost of switching technologies is often large, and the space of software paradigms yet to be explored dwarfs those we've exhausted. So don't be surprised if you find ways to improve the situation drastically.
5684−
5685−> F8: The way it ought to be isn't always the way it is.
5686−
5687−On the other hand, sometimes the elegant solution just isn't right. The ultimate test of the quality of software is whether it's useful to humans. Humans don't fit nice equations, so the timeless truths of mathematics are often mismatched with human convenience. Never sacrifice real utility for the sake of making the code more elegant.
5688−
5689−> F12: Standardization is better than perfection.
5690−
5691−Coordination problems are some of the most difficult. When given a choice between compatibility and improvement, carefully consider whether the problem solved by the improvement is weightier than the problem caused by the incompatibility.
5692−
5693−> F15: Communities are autonomous.
5694−
5695−This is both a positive statement and a normative one. Communities are in fact a thing separate from their platform, but sometimes changes in the platform can kill them. That's bad. It's slightly different from freedom of association, since that's a freedom that applies to individuals, not the communities themselves.
5696−
5697−Communities are the basic building blocks of society. We are each a member of some number of communities, and most power is held by these communities. Some communities coincide with family ties, some with common goals, beliefs, or interests. Some may be freely joined by just showing up — others are nearly impossible to join without having been born into them.
5698−
5699−Throughout civilization society has had many forms. Governments have ranged from police states to feudal societies to democracies to informal tribes of people. In each of these, the fundamental unit is the community. Humans don't live on their own, and they don't live in one
5700−universal society. They are a part of some communities and not of others.
5701−
5702−Technology shouldn't force us into a single global community. Discoverability isn't an unmitigated good. Most communities should be closed off from each other — that's what makes them a community. This allows them to develop their own ideas and norms. These bleed into
5703−other communities and may spread if they provide some benefit.
5704−
5705−Many technologies today combine us into a single community, or at least a single set of norms. If many communities are hosted by a single entity, there will be pressure from some of those communities toward the entity to pressure other communities to follow certain of their norms.
5706−This crosstalk isn't all bad, but there must be an equilibrium. All too often the lines between the communities are so permeable as to be inconsequential. In this case, the communities will converge in a single large community, at the cost of the memetic diversity of the original communities.
5707−
5708−Technology should mirror human interaction, and humans interact in communities.
5709−]]></content:encoded>
5710− </item>
5711− <item>
5712− <title><![CDATA[Precepts]]></title>
5713− <link>https://urbit.org/blog/precepts</link>
5714− <guid>https://urbit.org/blog/precepts</guid>
5715− <pubDate>Tue, 17 Mar 2020 00:00:00 GMT</pubDate>
5716− <content:encoded><![CDATA[
5717−<br>
5718−
5719−<img class="ba" src="https://media.urbit.org/site/posts/essays/pre-01.jpg">
5720−
5721−Urbit is a principled approach to system design and programming, but it's often not obvious what those principles are. We have many specific terms for the different parts of the project: Arvo is the OS, Hoon is the language, Tlon is the company, Azimuth is the identity system, Ames is the network. But the word most associated with the project is "Urbit", and it's not clear what technically it refers to. It's only a small stretch to say that "Urbit" _is_ this set of principles, and that if anybody follows these principles strictly they will create a system that is isomorphic to the Urbit.
5722−
5723−Some of these are commonly held among many software projects, and some are not. Some are only debatably better than the alternatives, but Urbit exclusively chooses them.
5724−
5725−We’ll start with a brief description of many principles, then we’ll go into a long-form justification.
5726−
5727−<br>
5728−
5729−<img class="ba" src="https://media.urbit.org/site/posts/essays/pre-02.jpg">
5730−
5731−### A: General Design
5732−
5733−1. Data is better than code.
5734−
5735− Store data in your state, send data over the wire, dispatch based
5736− on data.
5737−
5738−2. Everything should be CQRS.
5739−
5740−3. (Almost) Everything should be pubsub.
5741−
5742−4. A subscriber shouldn't affect a publisher.
5743−
5744−5. Communication between nodes should be communication between
5745− independent actors.
5746−
5747− Each message should do one complete thing, and there shouldn't
5748− need to be a sequence of coupled messages.
5749−
5750−6. Represent your data as closely as possible to the essential structure
5751− of the problem.
5752−
5753−7. A client's representation of data should be as close as possible to
5754− that of the server.
5755−
5756− This blurs the distinction between client and server. It allows
5757− offline-mode, reduces communication to syncing, and decentralizes.
5758−
5759−8. When mating different paradigms, build one cleanly on top of the
5760− other.
5761−
5762− Never try to make them work on some of the same primitives. Never
5763− abuse one to make the other work. For example, ducts in
5764− themselves are very general - if you want to do pubsub, that can
5765− easily be built on top of ducts, but don't pretend that pubsub is
5766− a _part_ of the duct system.
5767−
5768−9. Never misuse an abstraction.
5769−
5770− An abstraction provides a certain set of tools; use them and only
5771− them.
5772−
5773−10. Correctness is more important than performance.
5774−
5775−11. Be simple and uncompromising in defining what's correct; go crazy
5776− with optimizations.
5777−
5778− Nock is a great example of this. It contains the character of the
5779− virtual machine, but its asymptotics are bad. Add jets to fix the
5780− asymptotics.
5781−
5782− Another example is the ACID nature of Arvo. Arvo is a pure
5783− function f(logs) of its event log, so formally Arvo is just a
5784− function run against an event log. A naive implementation has
5785− very bad asymptotics; processing each new event is O(n) in the
5786− number of historical events. Choose the function g(state,log)
5787− such that f(logs ++ log) = g(f(logs),log). Then, as long as you
5788− keep the state in memory, processing each new event is constant in
5789− the number of previous events. This still requires O(n) restart
5790− from disk, but you can also periodically (and non-blockingly)
5791− write a checkpoint of the state to disk, so that restart from disk
5792− is only linear in the number of events since the last checkpoint.
5793−
5794−12. Correctness is more important than optimality.
5795−
5796−13. If you don't completely understand your code and the semantics of
5797− all the code it depends on, your code is wrong.
5798−
5799−14. Deterministic beats heuristic.
5800−
5801− Heuristics are evil and should only be used where determinism is
5802− infeasible, such as in cache reclamation.
5803−
5804−15. Stateless is better than stateful.
5805−
5806−16. Explicit state is better than implicit state.
5807−
5808−17. Referential transparency is honesty and stability.
5809−
5810− Lack of referential transparency and other forms of
5811− disingenuousness are some of the world's big problems. Only
5812− deviate from referential transparency if absolutely necessary.
5813−
5814−18. Responsibilities should be clearly separated.
5815−
5816− This applies from kernel modules through network citizens.
5817−
5818−19. Dualities must be faced head-on and analyzed differently at
5819− different layers.
5820−
5821− Statically typed vs. dynamically typed, imperative vs. functional,
5822− code vs. data, and effectful vs. pure can all be a matter of
5823− perspective, and all relevant perspectives must have coherent
5824− answers.
5825−
5826−20. One hundred lines of simplicity is better than twenty lines of
5827− complexity.
5828−
5829− It's not enough for an abstraction to reduce code duplication; it
5830− must actually make the code simpler.
5831−
5832−21. Prefer mechanical simplicity to mathematical simplicity.
5833−
5834− Often mechanical simplicity and mathematical simplicity go
5835− together.
5836−
5837−22. The Law of Leaky Abstractions is a lie; abstract airtightly.
5838−
5839− If your abstractions are leaking, it's not due to some law of the
5840− universe; you just suck at abstracting. Usually, you didn't
5841− specify the abstraction narrowly enough.
5842−
5843−23. Some cliches are repeated because they are true; others must be
5844− repeated because they are not.
5845−
5846−<br>
5847−
5848−<img class="ba" src="https://media.urbit.org/site/posts/essays/pre-03.jpg">
5849−
5850−### B: Specific Design
5851−
5852−1. Always ack a dupe; never ack an ack.
5853−
5854− It's okay to ack a nack as long as you never nack a nack.
5855−
5856−2. Never construct or deconstruct a duct.
5857−
5858−3. Route on wire before sign, never sign before wire.
5859−
5860−4. Only go from statically typed to dynamically typed if you must.
5861−
5862− Once you go into a dynamically typed world, it's hard to go back.
5863− Statically typed is better than dynamically typed, so if something
5864− can be made static, it should be.
5865−
5866− Each timeless data structure is a brick in the foundation of
5867− digital civilization.
5868−
5869−5. Anything with business logic speaks one paradigm; anything that
5870− translates paradigms has no business logic.
5871−
5872−6. Functionally enforced semantic rules are better security primitives
5873− than memory access restrictions.
5874−
5875− A compiler can use type safety as an effective tool to enforce
5876− some classes of security guarantees.
5877−
5878−<br>
5879−
5880−<img class="ba" src="https://media.urbit.org/site/posts/essays/pre-04.jpg">
5881−
5882−### C: Attitude
5883−
5884−1. Code courageously.
5885−
5886− If you avoid changing a section of code for fear of awakening the
5887− demons therein, you are living in fear. If you stay in the
5888− comfortable confines of the small section of the code you wrote or
5889− know well, you will never write legendary code. All code was
5890− written by humans and can be mastered by humans.
5891−
5892− It's natural to feel fear of code; however, you must act as though
5893− you are able to master and change any part of it. To code
5894− courageously is to walk into any abyss, bring light, and make it
5895− right.
5896−
5897−2. No time for lazy people.
5898−
5899− If there's clearly a right way to do something and a wrong way, do
5900− it the right way. Coding requires incredible discipline. Always
5901− follow conventions, and fire anyone who won't. Anything that can
5902− be solved by discipline is not a real problem.
5903−
5904− > "To him who knows to do good and does not do it, to him it is
5905− > sin."
5906−
5907−3. When a smart person makes an obviously stupid suggestion, before
5908− responding take a full 60 seconds to envision how you would implement
5909− it and what the effects would be.
5910−
5911−<br>
5912−
5913−<img class="ba" src="https://media.urbit.org/site/posts/essays/pre-05.jpg">
5914−
5915−### D: Theory
5916−
5917−1. Academia is a succubus.
5918−
5919− Academia has a really high ratio of smart people to useful
5920− products. Academia has many genuinely smart and interesting
5921− ideas, but always remember that pursuing them whole-heartedly will
5922− never result in a useful product.
5923−
5924−2. Never fear math.
5925−
5926− Academia is inefficient, but it's also correct. Those people
5927− wasted a lot of time finding the right answer, but now that
5928− they've done it, you must exploit it. If you don't know the
5929− theory, learn it. No excuse for being "bad at math". Most who
5930− are "bad at math" are simply lazy or fearful. Be strong and of
5931− good courage. If you're truly so bad at math that you cannot
5932− learn it, you should not design systems.
5933−
5934−3. Not being qualified to solve a problem is no reason not to solve it.
5935−
5936− If you don't know how to do it, do it anyway. "We are too young
5937− to realize that certain things are impossible. So, we will do
5938− them anyway."
5939−
5940−4. The best way to get the right answer is to try it the wrong way.
5941−
5942− You cannot design a good system without spending most of your time
5943− in contact with the problem. The bad parts about systems are
5944− rarely obvious in theory, but often in practice.
5945−
5946−5. Practice tells you that things are good or bad; theory tells you why.
5947−
5948− Never use theory to design a good system from scratch; only
5949− practice can tell whether the system is good.
5950−
5951−6. Everyone must regularly alternate between theory and practice.
5952−
5953− There is an eternal wheel of system design. Given a system, use
5954− practice to discover what is bad, missing, or unnecessary. Then,
5955− use theory to fix the bad, add the missing, and remove the
5956− unnecessary. Repeat.
5957−
5958−<br>
5959−
5960−<img class="ba" src="https://media.urbit.org/site/posts/essays/pre-06.jpg">
5961−
5962−### E: Text Style
5963−
5964−1. No code should extend beyond 80 characters, most within 55.
5965−
5966−2. Tabs aren't real.
5967−
5968−3. A text file is a series of lines, each ending with a newline
5969− character.
5970−
5971− Corollary: all non-empty text files end with a newline (often
5972− hidden by editors). An empty text file does not end with a
5973− newline.
5974−
5975−4. One block comment is better than interleaved comments on every line.
5976−
5977−5. Don't name anything you don't have to.
5978−
5979− This includes conventional names for variables of particular
5980− types. For example, the conventional name for a variable of type
5981− `path` is `pax`. You should have a good reason for using any
5982− other name for a `path`.
5983−
5984− A more recent convention that follows the same principle is to
5985− give the variable the same name as its type.
5986−
5987−6. If it's the same thing, give it the same name.
5988−
5989−7. Humans are good at memorizing.
5990−
5991−8. Abbreviations aren't worth it.
5992−
5993−<br>
5994−
5995−<img class="ba" src="https://media.urbit.org/site/posts/essays/pre-07.jpg">
5996−
5997−### F: Real Software
5998−
5999−1. If it's not deterministic, it isn't real.
6000−
6001−2. If it's centralized, it isn't real.
6002−
6003−3. If it's owned by someone else, it isn't yours.
6004−
6005−4. If it's managed by someone else and you can't change who that is, it
6006− isn't yours.
6007−
6008−5. If it's not yours, it isn't permanent.
6009−
6010−6. If it's not permanent, it isn't real.
6011−
6012−7. The way it is isn't always the way it ought to be.
6013−
6014− If you can make it the way it ought to be, do so.
6015−
6016−8. The way it ought to be isn't always the way it is.
6017−
6018− Some things can't be made more elegant.
6019−
6020− For every ailment under the sun
6021− There is a remedy, or there is none;
6022− If there be one, try to find it;
6023− If there be none, never mind it.
6024−
6025−9. Timeless software is good software.
6026−
6027−10. System modules should be designed to be frozen permanently;
6028− conversely, Urbit consists of that system software which admits of a
6029− Kelvin version.
6030−
6031−11. The two procedures for achieving timelessness are distillation and
6032− generalization.
6033−
6034− Every temporary or contingent feature in a system module should
6035− eventually either be removed (distillation) or relaxed into
6036− timelessness (generalization). For an example of the result of
6037− both procedures, consider the abstraction of the core in Nock and
6038− Hoon.
6039−
6040−12. Standardization is better than perfection.
6041−
6042− Kelvin versioning stops when we run out of versions, not when
6043− every defect has been rectified.
6044−
6045−13. That which cannot be Kelvin-versioned should update fluidly and
6046− automatically.
6047−
6048− All incompatible upgrades should provide permanent and automatic
6049− upgrade paths. This is principled permanent backward
6050− compatibility.
6051−
6052−14. Humans are interactive and temporal; technology is permanent and
6053− exhaustive.
6054−
6055−15. Communities are autonomous.
6056−
6057−16. Sovereignty necessitates understanding.
6058−
6059− If you don't understand a system you're using, you don't control
6060− it. If nobody understands the system, the system is in control.
6061−]]></content:encoded>
6062− </item>
6063− <item>
6064− <title><![CDATA[Urbit for Normies]]></title>
6065− <link>https://urbit.org/blog/urbit-for-normies</link>
6066− <guid>https://urbit.org/blog/urbit-for-normies</guid>
6067− <pubDate>Tue, 11 Feb 2020 00:00:00 GMT</pubDate>
6068− <content:encoded><.)
6116−
6117−Today Urbit’s interface looks like a tab in your web browser that has some limited functionality (chat, a weather app, a notebook, link sharing). Soon, you won’t even need the web browser — you’ll be able to access or run Urbit directly in its own window. Inside will be a super clean interface with all the functionality you might want from your computer, in one place and with one login (think document creation, email, social media access, accounting) — but it will run on your virtual Urbit computer, so it will be safe from corporate prying and data leaks, available on any device, and all inside one simple interface.
6118−
6119−## What it’s for
6120−
6121−Fundamentally, Urbit is neutral open-source infrastructure, so it can be for many things. From our highest level perspective Urbit is computing for real communities and normal people, not for corporations. To make that real, Urbit focuses on delivering a computing experience that is secure, private, durable, and calm.
6122−
6123−For me, Urbit’s core purpose is to give us all back our privacy and our autonomy. It’s time for humanity to control its tools rather than the other way around.
6124−
6125−## Key elements
6126−
6127−One potential barrier to understanding Urbit is that we’re building out multiple layers of this new internet simultaneously, and each has its own explanations and value propositions. Remember, what sets Urbit apart is that we’re building of all these elements at once to work together as a system.
6128−
6129−I’ll try to explain the most important of these without straying too deep into the technical weeds.
6130−
6131−1. **A peer-to-peer network**
6132−
6133− Peer-to-peer networking is a really big deal. On the current internet, essentially all of our communications and activities go through centralized servers owned by corporations (Facebook, Google, etc.) — and those corporations can’t help but use all that information to make money. They’re capitalists, after all, and so we get constant privacy violations and interfaces built for maximum dopamine addiction.
6134−
6135− In an Urbit world, all those communications go directly between users (i.e. peer-to-peer) with nobody in the middle. That means there’s no data capture by any megacorp, less intrusion into your life online, and communications go back to the semi-private one-to-one or small group format that is most comfortable for humans. It’s more like real life.
6136−
6137−2. **Your own server**
6138−
6139− Servers are complicated. Too complicated. Have you ever tried to use a command line? Exactly. It’s a terrible way to work, and that’s just a hint at how complex servers are to operate. To hide that complexity, we let corporations run our servers for us — they can afford teams of engineers. The problem is that today most of our computing is handled by these corporate servers — and that means we’re giving up control because of complexity.
6140−
6141− As an example, every time you use Siri, your message is sent to Apple’s servers, where it is processed, and the response is sent back to you (which is admittedly amazing). Unfortunately that’s why it never works if you’re offline, and it’s also why Apple knows what you’re saying to Siri. And this applies to all the apps we use: The actual computing happens on corporate servers. The problem is that we consumers aren’t in control and, again, the corporate entities watch, record, and gate-keep all of our activity.
6142−
6143− Fundamentally, Urbit is a super simple server. That means Urbit can run those computations and hold all that data for you, eliminating the need for a corporate intermediary.
6144−
6145−3. **Permanent, personal ownership of your digital identity and all your data**
6146−
6147− Urbit IDs are permanently ownable — and that ownership is backed by cryptography, not some corporate database. Once you take possession of your Urbit ID, no central authority can ever take it away from you. Sure, if you start spamming people on the network, word could get around and you might get blocked by other users, but none of them can prevent you from using your ID or accessing your Urbit computer. Compare that to the current internet where Facebook owns your Facebook profile, Google owns your Gmail account, Twitter owns your Twitter handle, etc. At any time and for any reason, those services can arbitrarily shut off your access, and you have little to no recourse — all that data, all those followers, and all that reputation is wiped out instantly. Your Urbit, on the other hand — both the identity, and all the data inside your Urbit computer — is yours permanently, so long as you know your secret key.
6148−
6149− A secure decentralized identity system like the one we’ve built leads to some very interesting use cases that are otherwise insurmountable. For example: decentralized Uber, decentralized delivery services, and a solid solution to the problem of fake reviews. To build any of these services, the problem of permanent identity needs to be solved first, and we’ve done that as part of our overall system. I’ll spend more time on use cases below.
6150−
6151− It’s worth noting that this problem has never been solved before. All of our communication channels on the internet today rely on someone else to authenticate our identity. Urbit is — to my knowledge — the first practical application of a decentralized ID system that actually works.
6152−
6153−4. **An incentive for good behavior**
6154−
6155− On the Urbit network, identities are finite, and they accrue reputation. Compare that to the current internet where identity is infinite (anyone can create as many email addresses or social media profiles as they want, essentially for free) and so spam, scams, and DoS attacks (“denial-of-service”: when many disposable identities ‘attack’ a server at the same time) are rampant. On the Urbit network, there are just over 4 billion total IDs (2<sup>32</sup> to be exact). Scarcity creates value. That scarcity, combined with reputation accrual, means there's an incentive for good behavior.
6156−
6157− You might think 4 billion IDs sounds like too few given how many humans we have on the planet. I won’t go into the technical details here, but if we ever get to the point where that’s a problem (which would be a great problem to have), we’ve outlined several solutions that allow everyone alive to get on the network. We don’t intend to lock anyone out.
6158−
6159−5. **Tools anyone can learn and use**
6160−
6161− Urbit is a system that anyone with patience can understand completely from top to bottom, from the integers of byte code to the complete OS and everything in between. Urbit in its entirety is just over 50,000 lines of code. That is tiny. Compare that to Linux (the open-source OS that most modern computing is built upon), which is tens of millions of lines of code, and you start to see how important this is for efficiency. Apple’s and Windows’ codebases are similarly massive. In our current computing system, nobody can understand the entire thing completely, and that means there are innumerable security holes. With Urbit, while it may demand something of you, any reasonably intelligent developer can grasp the whole thing. We’ve worked very hard to keep our system simple at each level. That makes it more efficient, more durable, and much more secure.
6162−
6163−6. **Lessons from the last half century**
6164−
6165− Bear with me — this is where some jargon kicks in. In many ways, Urbit is an attempt to apply lessons learned from the failures of 20th century computer development. From an engineer’s perspective, Urbit solves a series of problems that we end users rarely notice, but which cause extraordinary amounts of complexity and waste. The list of applied lessons is long, but rather than bullet them all, I’ll explain the one that surprised me the most.
6166−
6167− Urbit is deterministic. That is, a given sequence of inputs always produces the same output. When I first heard that, I thought, “Wait, isn’t that what all operating systems do? Give you the same result every time?” Weirdly, the answer is no. Normal operating systems don’t work this way. Normal modern operating systems actually get varying results when they compute things. This is a deep problem that causes programmers countless hours of frustration. The most common implication of this that you’ve probably experienced is having to reboot your computer — either because it’s locked up, or because it simply won’t do something that it was totally doing a second ago. What’s annoying to a regular user, though, is absolutely crazy-making to developers.
6168−
6169− This determinism makes programming on an Urbit immensely more efficient than other environments.
6170−
6171− Urbit applies this and a whole list of other lessons from the past half-century of systems software to increase reliability and security in everything from file storage to networking to user-facing apps. All this adds up to more security and reliability and less service-lock-in with Urbit than with our current systems.
6172−
6173−7. **Private, human-sized, and efficient**
6174−
6175− Because Urbit isn’t centralized or owned by any one company, there’s no incentive for it to dominate your life. Your Urbit isn’t designed to spy on you, get you addicted to clicking its buttons, manipulate your emotions to gain attention, or nudge you to buy something. Your Urbit is a simple, customizable, permanent place for you to do all your computer-based tasks with your friends in absolute privacy.
6176−
6177− This is so much the case, in fact, that it presents a bit of a problem for Tlon. We don’t know how many people use Urbit every day, who they talk to, or what they’re doing. While we think this is how things should be, it puts us in a bind when a VC wants to know about our user base; we can only make educated guesses. That said, we think this is the right problem to have.
6178−
6179− What all this adds up to is that the Urbit network is immensely more resource efficient, secure, easier to customize, and smaller in size than any other computing system in the world. If you care about data security, privacy, durability, or even just elegance, Urbit has the best design going.
6180−
6181− <br></br>
6182−
6183−<img class="ba" src="https://media.urbit.org/site/posts/essays/normies-2.png">
6184−
6185−## How it compares
6186−
6187−A final way to understand Urbit is to make comparisons between Urbit and current products we use today. This is limited, because ultimately Urbit will grow in directions we can’t predict, but comparisons are a useful starting place.
6188−
6189−Again, on the current internet, we all access megacorp software using our web browsers and app interfaces. This means that we each exist as a line in a megacorp database, and those megacorps use that data to make money, which results in rampant privacy violations and addictive interfaces. Urbit is the alternative to all that: it’s decentralized, private, and secure. And it’s yours.
6190−
6191−Let’s get to some real-world examples.
6192−
6193−## Urbit vs. Reddit
6194−
6195−Imagine you’d like to discuss a certain research topic with a group of friends. Say, Canadian small cap equities or the best cookie recipes. You’ll need a chat interface for live discussion, a notebook to record concepts, and a way to share links for discussion. You can do this in the default web if you want: use Reddit for the links (but make sure it’s a private group), use Google Docs for the notebook (but make sure everyone has Gmail), and use iMessage for the chat (but everyone needs a Mac). And don’t forget, each service has their own login and security holes, and they’re all mining your data.
6196−
6197−The alternative is spin up a group on Urbit. All of that functionality is available today in one clean, simple interface. It’s private, you own the data, there’s only one login, and you can even learn to build apps for your group.
6198−
6199−## Urbit vs. Facebook, Twitter, etc.
6200−
6201−Or let’s say you want to share pictures with your friends, post micro-messages to the world, write a blog, or share a podcast. There’s simply no reason you should use some centralized company (one that then owns your content) to broadcast any of those things. Instead, send it out from your Urbit. You’ll own the content, you’ll control the data, no company will spy on you, and nobody can ever take your ID from you. With Urbit we all finally own the tools, and that means we own the data by default.
6202−
6203−## Urbit vs. Nest
6204−
6205−Imagine, as I do, that you want a connected video camera in your house, but don’t want the Nest corporation (which is now owned by Google) to be able to spy on you. Or perhaps you just don’t want to have to sign up for yet another duplicative service in order to use the camera you just bought. If any of that is the case, you can run your camera through your Urbit instead. The video feed will never leave your control, because it no longer has to live on Nest’s servers. Your camera will talk over a secure channel only to your Urbit. Your Urbit is the server.
6206−
6207−You can apply this same concept to smart speakers, a Ring doorbell, connected baby monitor, smart fridge, or any of the innumerable connected devices that give someone else access to your personal life. Why should anyone else have access to that information?
6208−
6209−## Urbit vs. Google Docs
6210−
6211−Imagine you want to write a screenplay with a small group of friends, but you don’t want Google mining the content of your shared doc for advertising keywords, and you won’t want to use multiple services for chat, document sharing, email, etc. In that case, simply create an Urbit group with your friends and write together using Urbit’s writing tools. Your content will stay completely private to the team until you decide to release it to the world, and you’ll communicate using one simple interface. Even better, the archive of your multimodal work lives in one place, so looking back at your process doesn’t require reconstructing it from dozens of different apps. And everything is stored on your respective Urbit computers, not Google’s servers.
6212−
6213−## Urbit for your protected health information
6214−
6215−Imagine, as is already becoming the case, that it becomes highly valuable to have your genome sequenced in order to make good healthcare decisions. In that scenario, most of us would want our health care providers to be able to make precise assessments of parts of our genome, but we wouldn’t want insurance companies or other third parties to have access without our permission. In the current paradigm, once you share the information, it’s out there and can be leaked or sold. So much so that we all sort of assume that leaks are the default. In the Urbit paradigm, that information lives on your Urbit computer and nowhere else, and any software necessary to process it can be run on your Urbit as well. In other words, there’s never any need to share the raw data with anyone; instead, you can download a small program, run it on your Urbit, and share the final analyses only without ever exposing your data.
6216−
6217−Some of these cases are, admittedly, a bit speculative since we haven’t built all the functionality yet. But it’s coming, and quite soon.
6218−
6219−For now, if you like the way this sounds you can [get yourself an Urbit ID](https://urbit.org/getting-started/#id) and start learning about how to safely store cryptographic keys (it’s really not that hard, and we give you suggestions). If you’re feeling technical or adventurous, you can try booting our beta OS interface to see what it looks like. It’s fussy, but it exists. Soon it will be less fussy. You can check out our [roadmap](https://urbit.org/understanding-urbit/roadmap/) if you’d like to know when.
6220−
6221−## Why we need Urbit
6222−
6223−We humans haven’t evolved enough to manage the firehose of information that modern technology blasts us with. There’s too much news, too many connections, too many opinions, and more agendas out there than any of us can mindfully comprehend. We’re designed for much smaller communities, one-to-one connections, and slower idea assimilation than our modern infrastructure allows. The pace of change is increasing, and we don’t know how to manage it.
6224−
6225−We’re scared, and to manage that fear we’re becoming more insular, more entrenched. Layer on top of all that the incentives that big business and big politics have to manipulate our emotions, and we’re headed in a very dangerous direction.
6226−
6227−We can’t turn back the technological clock; humanity can only ever press onward. This is where Urbit comes in. Urbit is a forward-looking solution to this particular set of problems around human-scale computing and personal autonomy. Urbit provides a means by which groups can live peacefully in parallel.
6228−
6229−Urbit is a computing environment that allows humans to do everything they want on computers, but in communities of their choosing, in a way that feels direct and natural, and in a way that allows true personal freedom. Urbit is calm, secure, and private in its most fundamental architecture. No spying corporations. No manipulative politicians.
6230−
6231−And that is what we need. Humans need a way to at once take advantage of our vast technological advances but not be dominated by them. Urbit is an open-source tool that we all own, that anyone can understand down to its roots, that’s fully under its user’s control. It is human-scale computing for human-scale communities. Simple, durable, yours.
6232−
6233−For me, this first iteration of Urbit is more than enough, and it’s exactly the sort of peaceful future I want to work towards.
6234−]]></content:encoded>
6235− </item>
6236− <item>
6237− <title><![CDATA[~2020.2.6 Update]]></title>
6238− <link>https://urbit.org/updates/2020-02-06-update</link>
6239− <guid>https://urbit.org/updates/2020-02-06-update</guid>
6240− <pubDate>Wed, 05 Feb 2020 00:00:00 GMT</pubDate>
6241− <content:encoded><
6243−
6244−It’s been a busy 2020 already, and we’re excited about everything that’s going live this year. Here’s the latest from the Tlon team:
6245−
6246−1. Last month’s updates to Arvo and Bridge included:
6247− Fixes related to the network stability vote.
6248− [Updates](https://github.com/urbit/urbit/pull/1996) to both Gall and Ames (our application sandbox and networking module, respectively).
6249− [Support in Bridge](https://github.com/urbit/bridge/pull/335) for withdrawing stars from the linear release contracts.
6250−
6251−2. Gavin (`~ridlur-figbud`) wrote about how we created sigils, the visual representation of Urbit IDs. Read the post [here](https://urbit.org/blog/creating-sigils/).
6252−
6253−3. We’re pleased to announce the latest round of our semiannual gifts to Urbit contributors. It’s our way of rewarding the hard work of contributors to the project over the last six months. To see all the contributions we’ve recognized, take a look at the [History](https://grants.urbit.org/history) section on the Grants website.
6254−
6255− - `~bannum-magtus` has been tireless in their efforts as a community Guide in the #ship-starting-support channel on our [Discord server](https://discord.gg/C9ENTt3), and as an Urbit evangelizer.
6256− - `~nolmeg-hobdyn` could also be found nearly every day volunteering as a Guide in #ship-starting-support.
6257− - `~minder-folden` was a deep font of Urbit-related content, outreach, and support.
6258− - `~risruc-habteb` provided invaluable, consistent support in urbit-help.
6259− - `~rabsef-bicrym` for their efforts to teach Hoon to the community.
6260− - [`~dinleb-rambep`](https://github.com/pkova) brought a steady stream of useful contributions to the [urbit repository](https://github.com/urbit/urbit/pulls?utf8=%E2%9C%93&q=author%3Apkova).
6261−
6262−4. Looking for a more formal way to contribute and get rewarded? Look for a [Bounty](https://grants.urbit.org/bounties) to claim, or pitch a [Proposal](https://grants.urbit.org/proposals) of your own. We’re always on the lookout for community members who distinguish themselves through their contributions.
6263−
6264−5. Community member Reid is hosting a Dallas-Fort Worth meetup on February 12. [RSVP](https://www.meetup.com/Urbit-DFW/events/268194997/?rv=ea1_v2&_xtd=gatlbWFpbF9jbGlja9oAJGUwMGVjNGVmLTM3YTMtNDI1Yy05MDY1LTMyZGNiZjIxNDc2MA) to join.
6265−
6266−6. `~rabsef-bicrym` is coordinating a Denver meetup on February 13 during [ETHDenver](https://www.ethdenver.com/). Come say hi to other community members and folks from Tlon. For more details and to RSVP contact `~rabsef-bicrym` at [denver.urbit.meetup@protonmail.com](mailto:denver.urbit.meetup@protonmail.com).
6267−
6268−7. The next SF meetup will be on February 28 at our offices. Join us for a drink and a chat about all things Urbit. [RSVP](https://www.meetup.com/urbit-sf/events/268519069/?rv=co1&_xtd=gatlbWFpbF9jbGlja9oAJDYzNTAyYWNhLTBlYWQtNDAwNC1iODNlLTljMDk0NzQyNTE3NQ) and bring a friend.
6269−
6270−We’ve also scheduled a meetup in SF for [March 27](https://www.meetup.com/urbit-sf/events/268519156/). We hope to see you at one of these events!
6271−
6272−Until next time.
6273−]]></content:encoded>
6274− </item>
6275− <item>
6276− <title><![CDATA[Creating Sigils]]></title>
6277− <link>https://urbit.org/blog/creating-sigils</link>
6278− <guid>https://urbit.org/blog/creating-sigils</guid>
6279− <pubDate>Mon, 03 Feb 2020 00:00:00 GMT</pubDate>
6280− <content:encoded>< -->
6282−
6283−
6284−
6285−One of the basic building blocks of Urbit is Urbit ID, our naming and identity system. Your Urbit ID is a short, recognizable name that’s also a network address for your Urbit OS instance. (You can find a complete, high level description of Urbit ID [here](https://urbit.org/understanding-urbit/urbit-id/).)
6286−
6287−Your Urbit ID is meant to feel a bit like a secret code name. It doesn’t leak any information about the real you — but it’s still memorable and recognizable. Getting an Urbit ID should feel exciting, like getting a brand new identity in a new world.
6288−
6289−From a design standpoint, some of this is accomplished simply by having a system for the names themselves. Under the hood, Urbit IDs are actually just numbers. There has always been an algorithm for turning these numbers into pronounceable names like `~tacryt-socryp` (13,304,832) or `~litzod` (1,280) or `~nes` (212).
6290−
6291−While the names are great, they’re not quite enough, especially in a rich interface. Each Urbit ID really needed some form of visual representation, image, or crest. A digital identity needs to be something you can really attach to, both yours and those that belong to your friends.
6292−
6293−There are 2<sup>32</sup> or 4.2 billion unique Urbit IDs. Clearly there’s no way that we were going to do this by hand. And purely algorithmic solutions can often produce disappointing, undifferentiated output.
6294−
6295−Regardless, we set out to tackle this problem. By the end of this process, every Urbit ID got its very own ‘sigil.’
6296−
6297−In this post we’ll walk through how we thought about the problem, iterated through possible solutions, and the toolchain we used to arrive at the final result.
6298−
6299−## Background
6300−
6301−What are the basic primitives of a visual language? There aren’t any completely authoritative answers to this question, of course. But we knew that to produce such a large number of visually distinct items we’d need some way to reason about form that’s closer to letterforms.
6302−
6303−So we started by collecting influences.
6304−
6305−<iframe class="arena-iframe" width="100%" src="https://www.are.na/tlon/seal-zp3irwad52y/embed"></iframe>
6306−
6307−The ‘chop’ or [seal](<https://en.wikipedia.org/wiki/Seal_(East_Asia)>) is conceptually pretty close to what we wanted to get to.
6308−
6309−<br /><br />
6310−
6311−<iframe class="arena-iframe" width="100%" src="https://www.are.na/tlon/kamon/embed"></iframe>
6312−
6313−[Kamon](<https://en.wikipedia.org/wiki/Mon_(emblem)>) are even closer — especially since they have very little visual complexity.
6314−
6315−<br /><br />
6316−
6317−<iframe class="arena-iframe" width="100%" src="https://www.are.na/tlon/grids-jd_xbmspxkm/embed"></iframe>
6318−
6319−We also spent a good amount of time with both Anni Albers and Agnes Martin. Both of these painters had an incredible mastery of the grid as a means of creating engaging visual work. These paintings all have a wonderful tension between an underlying system and their specific expression.
6320−
6321−<br /><br />
6322−
6323−<iframe class="arena-iframe" width="100%" src="https://www.are.na/tlon/stella-xfroicotm_4/embed"></iframe>
6324−
6325−Frank Stella is a master at producing incredibly dynamic work from only a few elements. His ability to create a sense of depth from simple overlapping elements is fantastic.
6326−
6327−<br /><br />
6328−
6329−<iframe class="arena-iframe" width="100%" src="https://www.are.na/tlon/ledoux-palladio/embed"></iframe>
6330−
6331−The plans of both Ledoux and Palladio are incredibly dynamic. They’re mostly gridded, use only a few elements, and use lots of symmetry — but they’re at once distinct, engaging, and fresh.
6332−
6333−<br /><br />
6334−
6335−<iframe class="arena-iframe" width="100%" src="https://www.are.na/tlon/flags-k9moxiayuvq/embed"></iframe>
6336−
6337−Another influence: international maritime signal flags. We like these not only because of their striking visual qualities, but also because they correspond with a letter system, just like our sigils. Each one conveys useful information; for example, “Keep clear of me; I am maneuvering with difficulty,” a flag we all feel like raising from time to time. This influence was key to the idea that pairing symbol to phoneme was a possibility.
6338−
6339−You can see the whole collection of our visual research [here](https://www.are.na/tlon/2019-sigils-research).
6340−
6341−Ultimately, we didn’t specifically draw on any of these influences very consciously. The goal of visual research is to get a sense of the territory, what has been tried, and what works. We think these threads of prior work are evident in the final result — you can _feel_ them, but it’s tough to point to them individually.
6342−
6343−## What’s in a name?
6344−
6345−> _“Lev’s sigil appeared, strobing, as Netherton was getting out of the cab in Henrietta Street. “Yes?” Netherton asked.”_
6346−>
6347−> <cite>— William Gibson, The Peripheral</cite>
6348−
6349−Before we get to how we worked through the problem of actually designing these things, let’s talk about the problem of naming.
6350−
6351−We went through so many names for these things. Crest, symbol, seal, tag, pictograph, stamp, emblem, signet, icon, glyph, holomark, visage, radigy, pattern, the list goes on for an incredibly (embarrassingly) long time. We argued about this, we went back and forth about it.
6352−
6353−Sigil won, ultimately, because of the way that it’s personified in William Gibson’s _The Peripheral_. In the far future, characters talk to each other by some kind of telepresence. When a call comes in from someone else, they first appear as a ‘sigil.’ It’s a strange word, but we were imagining a similar use-case.
6354−
6355−While we can’t point to any specific parts of our visual research that reappear directly, sigil is lovingly borrowed.
6356−
6357−## Experiments + iterations
6358−
6359−So, how did we actually end up making these things?
6360−
6361−We iterated through plenty of possibilities before landing on our final approach. Let’s walk through the two we remember best.
6362−
6363−<br /><br />
6364−
6365−
6366−
6367−The first attempt was a series of images in the style of Karel Martens. Overall this technique was just too cluttered and sometimes difficult to parameterize in a predictable way. We kept iterating.
6368−
6369−<br /><br />
6370−
6371−
6372−
6373−Just like the previous example, the main idea was that we could take a set of geometric primitives, combine them, then alter their appearance along a set of parameters, like color, rotation, and size.
6374−
6375−But also just like the previous attempt, the technique of overlapping symbols made the images too difficult to read and differentiate. We wanted to create sigils that were not only great to look at, but visually ordered. Since overlapping elements didn’t seem to quite hit the mark, on we went.
6376−
6377−## Closing in
6378−
6379−Eventually, we realized: tiles! With tile designs there are no overlaps, which in early experiments immediately started to take on the consistent, legible appearance we were after. Each element is discrete and clearly visible. Tile designs were also easier to create and control from an implementation standpoint.
6380−
6381−Best of all, tiles made it clear that we should be thinking in terms of creating representations of individual syllables rather than entire names. Urbit IDs are constructed from two sets of 256 three-letter syllables. `~fallyn-balfus` is `fal` `lyn` `bal` `fus`, for example. (There are two syllable sets in order to prevent duplicates — we always alternate between the two when composing names.)
6382−
6383−Thinking in terms of syllables greatly reduced the complexity of the problem, but there was still some work to do.
6384−
6385−<br /><br />
6386−
6387−
6388−
6389−At first, we thought about using a 4 x 4 tile grid, as shown here. These designs were tricky to implement because of the detailed lines and arcs spanning across individual tiles. In order to generate a result that matched these mockups, a program would have to generate a data model that knew about which tiles touched which other tiles.
6390−
6391−We felt this was too complicated and had an unknown performance profile. Plus, they proposed a deterministic color scheme and we felt strongly that color is personal, not to mention hard to parameterize. In the end we thought it better to create something that had the potential for user customization.
6392−
6393−<br /><br />
6394−
6395−
6396−
6397−Around this stage, we were thinking a lot about how architectural plans aren’t unduly constrained by the fact that they’re only one color. We had a feeling we could make the grid smaller and assign details to the tiles individually.
6398−
6399−<br /><br />
6400−
6401−
6402−
6403−So, we scaled it down to a 2 x 2 grid and stuck with it. It’s simple to implement, visually unique, consistent, and the color scheme is black and white, leaving room for user customization. We felt we had reached a semblance of a final result. Now all we had to do was manually draw 512 unique but consistent individual ‘phonemes’.
6404−
6405−<br /><br />
6406−
6407−
6408−
6409−As it turns out, drawing 512 consistent, abstract elements by hand isn’t easy. We had to strike a balance between authorship and automation — we wanted each tile to look well-made, but not too authored. To do so, we took advantage of Figma’s web API which helped us design in SVG but iterate programmatically.
6410−
6411−## Final process
6412−
6413−
6414−
6415−We took a look at our hand drawn mockups and drew each individual visual building block of the tiles separately. Then we loaded the SVG elements into a script that programmatically combined them to create trillions of layered symbols. This way, we were able to easily select candidate phoneme symbols that worked visually.
6416−
6417−We eventually added a rule system to find higher quality phoneme symbols — but this combination of programmatic generation and hand selection was working pretty well.
6418−
6419−<br /><br />
6420−
6421−
6422−
6423−The final step, using the tool we built, was to hand select individual phoneme symbols and create a complete index.
6424−
6425−<br /><br />
6426−
6427−
6428−
6429−This allowed us to start looking at possible combinations and selecting phoneme symbols based on their interplay with others.
6430−
6431−Once we had selected the final set, we went about compiling the `sigil-js` library that’s now publicly available. This turned out to be fairly technically complex due to the different ways SVG is handled between browsers and Figma — but the end result is a single Javascript library you can use to embed an SVG in almost any context on a web page. See it in action and browse the available sigils [here](https://sigil.azimuth.network). If you're technically inclined, the [source](https://github.com/urbit/sigil-js) can be found on GitHub.
6432−
6433−<br /><br />
6434−
6435−
6436−
6437−We think sigils are pretty successful. They look nice in our native Urbit interfaces, people have made them into shirts and posters and cards, even laser-cut them to make stamps.
6438−
6439−Urbit ID and the sigils are components of Urbit that are totally separate from the OS — you can use them on their own and potentially even extend their functionality. We’re happy with what we’ve done with them so far, and hope that people will experiment with what’s possible with this naming and identity system.
6440−
6441−
6442−]]></content:encoded>
6443− </item>
6444− <item>
6445− <title><![CDATA[~2019.12.6 Weekly Web Update]]></title>
6446− <link>https://urbit.org/updates/2019-12-06-update</link>
6447− <guid>https://urbit.org/updates/2019-12-06-update</guid>
6448− <pubDate>Thu, 05 Dec 2019 00:00:00 GMT</pubDate>
6449− <content:encoded><
6451−
6452−Wishing everyone a festive holiday season. Here are some updates from the Tlon team:
6453−
6454−1 -
6455−We recently released urbit v0.10.0. This continuity-breaching release contains both Arvo and Vere changes, so users should update their binaries. After upgrading, users should create new piers. Find the release binary for [macOS](https://github.com/urbit/urbit/releases/download/v0.10.0/urbit-darwin-v0.10.0.tgz) and [linux64](https://github.com/urbit/urbit/releases/download/v0.10.0/urbit-linux64-v0.10.0.tgz).
6456−
6457−A few release highlights:
6458−
6459−- Our networking vane, Ames, has been completely rewritten. Its protocol has been simplified, and several new features have been added to it. We expect Ames to be much more reliable and easy to upgrade.
6460−
6461−- Perhaps most importantly, Ames now supports arbitrary-length negative acks, which was one of the primary networking bugs on our old network.
6462−
6463−- Gall, our application sandbox, has also been significantly changed. This has also been a long-running project at Tlon that we’re really excited to get out on the live network. Gall itself is about a thousand lines shorter.
6464−
6465−- The concept of "threads" is introduced. These are temporary processes for operations whose state is transient, like an http request-response.
6466−
6467−- Includes a full redesign of the Landscape chat interface, plus adds additional features for mobile use and easier join flows.
6468−
6469−Check out the full release notes [here](https://github.com/urbit/urbit/releases/tag/v0.10.0).
6470−
6471−2 -
6472−This year we set out to get Arvo to a point that we can credibly call ‘stable.' ~poldec-tonteg wrote about the details of how we accomplished stability [here](https://urbit.org/blog/stable-arvo/).
6473−
6474−3 -
6475−The final San Francisco meetup of the year is on December 13th. We hope to see you – [RSVP here](https://www.meetup.com/urbit-sf/events/266904108/?rv=ea1_v2&_xtd=gatlbWFpbF9jbGlja9oAJDA0YTUxZjZlLWU1ZGQtNGJkYS1hN2JlLWQwZTc0MDA0ZTAwZA).
6476−
6477−4 -
6478−The Seattle Urbit group is hosting a meetup on December 18th. [RSVP](https://www.meetup.com/Urbit-Seattle/events/266619060/) for tech and holiday cheer.
6479−
6480−Talk to you soon!
6481−]]></content:encoded>
6482− </item>
6483− <item>
6484− <title><![CDATA[Designing a Permanent Personal Identity]]></title>
6485− <link>https://urbit.org/blog/pki-maze</link>
6486− <guid>https://urbit.org/blog/pki-maze</guid>
6487− <pubDate>Tue, 26 Nov 2019 00:00:00 GMT</pubDate>
6488− <content:encoded><
6490−
6491−A public key infrastructure (PKI) is a system for binding a set of keys to a name. Sometimes a small amount of metadata is included.
6492−
6493−Existing PKIs include PGP-style ["web of trust"](https://en.wikipedia.org/wiki/Web_of_trust), [SSL certificates](https://en.wikipedia.org/wiki/Certificate_authority), [ZeroTier](https://www.zerotier.com/lf-announcement/), [Keybase](https://keybase.io/), [OpenID](https://openid.net/what-is-openid/), [Mozilla Persona](https://developer.mozilla.org/en-US/docs/Archive/Mozilla/Persona), and [Login with Google](https://developers.google.com/identity). These take unique approaches to the problem and have achieved some degree of success, but none provide globally consistent, permanent, and completely self-owned identities. Exhaustive exploration and categorization is unfortunately out of scope for this post, so we'll just describe Urbit's approach to achieving these properties in our PKI.
6494−
6495−In Urbit, a "name" is often called a "ship" or an "address" because we use the metadata in the PKI to make names routable. The total data is two 256-bit asymmetric keys, a cryptographic suite number (to allow changing crypto algorithms), the revision number of the key, and the name of a ship that will route for it. This sums to less than 128 bytes of data.
6496−
6497−Each PKI trades off various properties. We chose a tripartite system so that appropriate choices can be made for different use cases. Here, we explore the various properties we chose by following a series of binary choices -- the idea maze.
6498−
6499−There are two sorts of PKI: either you can change your keys or not. If you cannot, then your name is impermanent, for no one can keep a set of keys secure forever. Even if your opsec never fails, eventually your crypto algorithms may be compromised.
6500−
6501−However, if you sacrifice the ability to change your keys, you can have a very nice property: self-attesting keys. If your name is a hash of your public key information, then no other source of information is required to verify you are who you say you are. This is a useful property since it requires no coordination at all. Many things are impermanent, especially during development. It also provides a way to try out the network without obtaining a permanent address.
6502−
6503−This is our first stop in the idea maze. We call this sort of name a "comet". A comet's name is the 128-bit hash of its public keys.
6504−
6505−However, Urbit is yours and it's forever. You shouldn't have to change your name every time you change your keys. So, we go back and take the other choice: you must be able to change your keys.
6506−
6507−To change keys, you must sign a message with the old keys revoking them and supplying the new ones[^0]. The question is what happens if the old keys also sign a second set of new keys. This could happen if an attacker obtained your old keys after the fact. This is important because one of the reasons to be able to change your keys is to invalidate the old ones so that they have no power.
6508−
6509−We have two options again: the PKI may be globally consistent or not. To be globally consistent means that if you believe a name is bound to a set of keys, then nobody on the network will disagree.
6510−
6511−If you don't require global consistency, you may sign this message and send it to all your neighbors, and they pass it on, and hopefully it gets to most of the network quickly. However, if one of those ships receives two contradictory versions of this message, the only thing it can do is trust the first one it heard, which may be different than what someone else heard. Thus, this is pairwise consistent but globally inconsistent. This is essentially how the pre-blockchain Ames network worked, though key changes were not actually implemented. Because global consistency is a valuable property, we looked at other options.
6512−
6513−For a globally consistent PKI that allows you to revoke keys, you need to be able to distinguish between two cryptographically valid messages to determine which was signed first. The dual problem could be solved easily — you can prove a message is signed after another by including the signature of the first in the second. This is equivalent to reading out a newspaper headline to prove a message was recorded after a given day.
6514−
6515−However, the problem of proving one message was sent before any later ones inverts the problem. You can solve this with newspapers by placing the message in the text of the newspaper. However, while reading a newspaper requires no central party, writing one does. For a long time, this sort of message was always handled by a central party. SSL revocations are managed by a few central parties. When you buy property, it's not sufficient to have the previous owner sign the title — this must be entered into a central land registry. Otherwise, the owner may sell their property to multiple people and there would be no way to determine who is the new owner. With the land registry, all you need to do is ask the registry which sale happened first, and that's the one that counts.
6516−
6517−However, Urbit is yours and it's forever. Trusting central registries jeopardizes both. The keen reader will notice that the problem of determining which key rotation happened first is exactly the double-spend problem that Satoshi solved with his proof of work algorithm for Bitcoin. His first block famously includes a newspaper headline to prove he didn't mine the block before that date. In a beautiful duality, his own algorithm proves that he didn't mine it after that date.[^1]
6518−
6519−Some argue that blockchain is only good for money. This is myopic and is generally based on the experience that its most valuable application so far has been money. However, blockchain is a cryptographic primitive to do what was previously impossible: prove that one message was signed before another without a central party. Blockchain was discovered by someone trying to create digital money, and he needed that primitive, but that doesn't mean that's all it's good for.
6520−
6521−Thus, we store our PKI data on a blockchain for our second kind of name: planets. A planet is a 32-bit address which has key information stored on the blockchain.[^2] The owner of a planet may broadcast new PKI data by adding it to the blockchain. Any later messages by the old keys will be rejected, and everyone on the network will listen to the blockchain for key data. Thus, we have global consistency, permanence, and self sovereignty. We know of no other solution that can provide these properties.
6522−
6523−However, while small individually, the aggregate PKI data for all nodes on the network may become very large. This is not an issue for comets because nobody needs to store comet keys except for those which they're talking with, and even those can be garbage-collected and re-requested and verified. For planets, there is a canonical set of keys, and somebody must store that. There are about 2<sup>32</sup>, or 4 billion planets. If the PKI data is about 100 bytes for each planet, this is about 400 GB of data. This may be more than most users wish to store, but it's small enough that it would be very cheap for someone to host this data for many users[^3].
6524−
6525−This information is currently stored directly on the Ethereum 1.0 blockchain, but as is well understood in blockchain circles this approach will not scale beyond a certain point. Many chains are pursing designs that allow the users of the smart contracts to store locally the data associated with the contracts they care about and only commit hashes to the chain. We expect there to be several viable options for this by the time our scaling needs exceed what's provided by Ethereum 1.0. This will free us from the cost of hosting the PKI data on all Ethereum nodes, but the data must still be stored somewhere. Any service that could handle such a large amount of data would inherently centralize the network.
6526−
6527−However, 4 billion is not enough addresses for every device on the planet today, much less in a few decades. So, we apply our maxim of re-examining our choices at each level for each use case. Examining the idea maze above, we cannot use the blockchain option for everything since the data is too big. However, it's not actually necessary for each of your devices to have its own self-sovereign identity separate from your planet. So we choose the option of using a central registry: your own planet.
6528−
6529−We allocate 4 billion "moons" to each of those planets. A moon is a 64-bit address whose 32-bit suffix is its planet. Your planet can easily store the keys for its own moons, and anyone who needs to talk to your moons can ask you for the keys.
6530−
6531−This is the sense in which moons are true ships: they're permanent names and you own them completely, as long as you own the planet. However, they're not independent ships — their keys can always be revoked by their planet.
6532−
6533−To create a sane network, we require global consistency for all our names. There are three other properties; pick any two:
6534−
6535−- Comets are impermanent, self sovereign, and plentiful.
6536−
6537−- Planets are permanent, self sovereign, and not plentiful.
6538−
6539−- Moons are permanent, not self sovereign, and plentiful.
6540−
6541−Fancifully, comets are wayward celestial bodies that are great for testing and miscellaneous low-value things that won't last for long. Planets are where you can build a home and shape it into anything you want it to be. People can always find your planet; it's not going anywhere. Moons are useful for special purposes, like storage, heavy industry, and anything else you might want to do off-planet.[^4]
6542−
6543−[^0]: Or the equivalent with a hierarchical key structure. In practice, you want to have a master key which signs a junior key for everyday use. You use the master key to rotate the junior key.
6544−[^1]: More strictly: it proves that he didn't mine it after the other blocks currently on the Bitcoin blockchain. It only gives an ordering within the chain, not a literal timestamp.
6545−[^2]: In addition to planets, there are stars and galaxies. From a PKI perspective they're treated exactly like planets, but on the network they provide infrastructure services like routing.
6546−[^3]: In practice, this will likely be an included service by your sponsoring star. It could be a separate service, but it will be very cheap because it's a commodity and the "cost of production" is very cheap. At any rate, it should never rise above the capital cost of a 400GB hard drive.
6547−[^4]: To extend the metaphor, stars are a neighborhood to live in -- they're easier for other planets to see, so when they want to send you a message they look for your star first. If they don't even know where your star is, they can certainly find your star's galaxy, and that will be enough to locate the star. Of course, if your star is not providing satisfactory service, you can take your planet and move to another star.
6548−]]></content:encoded>
6549− </item>
6550− <item>
6551− <title><![CDATA[Stable Arvo]]></title>
6552− <link>https://urbit.org/blog/stable-arvo</link>
6553− <guid>https://urbit.org/blog/stable-arvo</guid>
6554− <pubDate>Tue, 19 Nov 2019 00:00:00 GMT</pubDate>
6555− <content:encoded><
6557−
6558−### A contract by which Arvo evolves
6559−
6560−We want your Urbit to last forever. We want an ordinary Urbit user to never worry about their Urbit breaking, going away or failing unexpectedly. We don’t just want this — we think this is one of the most incredible things Urbit can actually deliver.
6561−
6562−In order to get closer to an Urbit that can last forever, we set for ourselves the goal of getting Arvo (the kernel of what we’ve been calling ‘Urbit OS’) to a point that we can credibly call ‘stable’ by the end of 2019.
6563−
6564−But what do we mean exactly by ‘stable’? For something meant to last far into the future, stability really means _resilience_. Arvo has to both run and upgrade itself without ever breaking or falling into an unrecoverable state.
6565−
6566−Getting Arvo to this point doesn’t quite achieve the user-level goal we’re hoping to achieve. But if you’re comfortable doing a bit of system administration, Arvo itself should need almost no maintenance.
6567−
6568−To achieve stability in practice Arvo needs three things:
6569−
6570−- The Arvo network (Ames) has to be stable
6571−- Arvo can’t easily fall into an unrecoverable state
6572−- Arvo has to have a clear and formalized upgrade mechanic
6573−
6574−All of these are actively being worked on, and are mostly near completion. Let’s walk through them one by one.
6575−
6576−### A new Ames
6577−
6578−To ensure that Arvo can upgrade itself forever, it needs a network to deliver the updates. Toward this end we’ve put a lot of work into making Ames, the Urbit networking protocol, as reliable as possible.
6579−
6580−Ames is a big part of what makes Urbit Urbit. It guarantees exactly once message delivery, it’s encrypted and authenticated. The original Ames design is pretty good. But it’s also incredibly difficult to maintain and had a few really painful edge case bugs. When the network has fallen over in the past, it has been far too hard to debug the original Ames code.
6581−
6582−We managed to update this original Ames code to use Ethereum as the source of truth for keys and key updates. We also made significant changes by introducing a new version of Jael, our kernel module for managing keys and signing inside of Urbit. While this change was significant, Ames still had some pretty nasty occasional bugs related to subscriptions and subscription updates. In order to get Ames to be truly reliable, it needed a rewrite.
6583−
6584−We’ve been working on that rewrite, codenamed Alef, for a few months now. Alef doesn’t aim to add any new functionality — it’s simply a drop-in replacement that’s cleaner and more reliable. We currently have Alef running on a testnet and sending packets with an industry-standard congestion control algorithm. There’s still some work to do, but it’s coming along nicely. Some early tests even show it to be faster, which is great.
6585−
6586−We expect to switch to Alef in a continuity breach (network reset) during this quarter. This will be a huge step toward resilience. A networking protocol we can trust to deliver updates is essential for a computer that will last a long time.
6587−
6588−### Recoverability
6589−
6590−Another barrier to stability with existing Urbit is that a ship can, under specific conditions, fall into a terminal state. If part of your ship’s state relies on event in the future and this event crashes, then that part of the state can become unrecoverable. Consider, for example, an event that is set to be triggered by a timer. If this timer crashes, that event will never happen. This is a huge problem.
6591−
6592−In order to understand the difficulties with error handling and how we’re dealing with it, we have to understand the Arvo operating system. Arvo is responsible for coordinating messages being sent from the outside world (Unix in our case) and messages sent from one vane, or kernel module, to another. Both Arvo and the vanes are explicit state machines, meaning that they must specify every possible state and the transitions between them. These properties make it possible for the system to be fully updated (we’ll discuss such upgrades below).
6593−
6594−This architecture means that errors have to be considered not simply as an exception, but as a possible state in the explicit state machine. In practice, we have to account for both deterministic errors like semantically invalid formulas and non-deterministic errors like running out of memory or a plug getting pulled.
6595−
6596−Deterministic errors are currently handled within the virtual interpreter, Mock, and result in a “bail: exit.” They can be handled “within” Arvo and are never written to the event log. The real difficulty lies with non-deterministic errors, specifically ones can potentially cause other events.
6597−
6598−An obvious case of causally-connected events is a timer; any code that sets a timer eventually suspends itself, waiting to be awoken. And yet, if the subsequent timer event were to crash, the state machine awaiting it would remain suspended, expecting a transition that can and will not
6599−occur.
6600−
6601−We believe that we have a general scheme that accounts for both classes of error. We’ve formalized this and will use it going forward to avoid falling into inconsistent states.
6602−
6603−Our solution to this problem is simple: if Arvo or one of its vanes crashes while processing an event, the fact of the failed event itself becomes a new event. The runtime injects an error notification in the event log, named, as is befitting of a failed event: %crud.
6604−
6605−In the case of a failed timer event, the error notification is routed back to the code that set the timer and communicates the following: you were expecting to be woken up, but, when you were, you crashed. The code in question could then consider the logical operation of which the timer was a part to have failed, or perhaps it could try again. In any case, it must not crash when handling the error notification, and it must not continue to expect to be woken up.
6606−
6607−This quarter, building on previous work, we’ve built on the %crud pattern and mapped the protocols between the vanes and between arvo and vere. This allows us to make sure that %cruds are all handled (so as to avoid the crash discussed above) and, in future iterations of the vanes, know what conditions need to be accommodated to avoid introducing regressions.
6608−
6609−By adopting this pattern and virtualizing userspace, we can make completely sure that code running in the kernel or an app can’t cause your ship to get into an inconsistent state.
6610−
6611−### Telescoping Kelvins
6612−
6613−Finally, in order for a ship to reliably receive and apply upgrades, we need to formalize and enforce a versioning scheme inside the system.
6614−
6615−Most software simply increases its version number on each release. Nock (our VM spec) and Hoon, on the other hand, uses kelvin versioning. Kelvin versioning doesn’t infinitely increase version numbers. Instead, we decrease the version number on each significant change in the hope that our software will eventually not need to change at all. Infrastructure, if it’s going to be truly reliable, should eventually reach absolute zero.
6616−
6617−Nock is already nearly frozen at 4K. A change to Nock is a major event.
6618−
6619−At the level of the kernel (including Arvo proper, Zuse, and the Vanes), we’ve never fully followed a kelvin versioning scheme. The bottom of the stack always had to freeze first. But now the system is starting to stabilize such that we need a path toward a ‘cool’ system all the way up in the vanes. Versioning the kernel is a different challenge than the VM or language since the vanes interoperate with one another.
6620−
6621−We have a formalized scheme for how we think kelvin versioning should work at the Arvo level in process now. This year we’ll start tagging each version of the kernel with an appropriate kelvin. This scheme means not only applying a version tag to each kernel, but also making sure there are transition functions written between versions. Additionally, it will include a versioning mechanism for the interface between the kernel and the runtime.
6622−
6623−Let’s dive into the details, but just a bit:
6624−
6625−The mechanism for the kernel is pretty simple. In short, we’ll enforce that everything above a particular layer must ‘cool’ (or upgrade, by shedding a version number) when something underneath drops a version number. This ensures that the system can’t fall into an incorrect state due to simple incompatibility. For example, if Hoon changes, all of the Arvo kernel must similarly drop a kelvin to ensure compatibility.
6626−
6627−The versioning scheme between the runtime and Arvo is similarly straightforward. We’ll build in an affordance for notifying the user if we need them to manually upgrade the interpreter. This ensures that API changes between interpreter and kernel can always be non-breaking. Someday interpreter changes can be done over the air (like your browser downloading its own upgrades), but we’re not there yet.
6628−
6629−What’s important about these two things is that they let us take continuity seriously. "Continuity" or "permanence" is arguably Urbit's killer feature: you start your ship, it just works, forever. Back it up on a USB drive, throw it in a drawer for forty years, and upon reconnecting to the network in 2059 (and pulling down all the updates you've missed) you're back in the game.
6630−
6631−With the recent 0.9.0 release we’ve gotten to the point where we can make almost all our upgrades over the air. Even the language is now upgradeable over the wire.
6632−
6633−But — in order for that scene in 2059 to actually work, these upgrade mechanisms have to be in place. As your ship upgrades itself, the system needs a way to ensure that each upgrade gets applied in a compatible way. Right now we’re careful about deploying over the air updates such that they don’t break, but that’s obviously not sustainable.
6634−
6635−Once this versioning scheme gets released later this year, there’s nothing technically preventing you from starting a late-2019 Urbit in 2039. We hope you’ll use it a lot in the interim — but this is an essential feature for a decentralized system that claims to upgrade itself. We’re really excited to get it implemented.
6636−
6637−These three areas of work are all due to complete later this quarter. This gets us something that’s much more resilient than what we’ve ever had before. Given a stable system, we can actually start to put some serious weight on it.
6638−]]></content:encoded>
6639− </item>
6640− <item>
6641− <title><![CDATA[Why Hoon?]]></title>
6642− <link>https://urbit.org/blog/why-hoon</link>
6643− <guid>https://urbit.org/blog/why-hoon</guid>
6644− <pubDate>Wed, 13 Nov 2019 00:00:00 GMT</pubDate>
6645− <content:encoded><
6647−
6648−### What can Hoon do that other languages can't?
6649−
6650−The short answer is: implement a purely functional operating system.
6651−Try to do this in a principled way in Haskell, and the problems you'll
6652−run into will make design decisions in Hoon and Nock make a lot more
6653−sense.
6654−
6655−In particular, the problems Hoon solves that aren't solved by other
6656−functional languages are:
6657−
6658−- Compile and run other code in a typesafe manner at full speed,
6659−- Typesafe metaprogramming, and
6660−- Hot code reload and online data migration.
6661−
6662−### What is Hoon good at?
6663−
6664−Hoon is mostly good at compiling and running other Hoon code. Urbit
6665−consists of many layers of bootstrapping. Several of these layers lean
6666−heavily on this feature, including the Gall application runner, the Ford
6667−build system, the Dojo shell, and the Arvo kernel itself. Even Urbit's
6668−chat application lets you run Hoon expressions and share the results
6669−with your friends.
6670−
6671−### Why did we write the OS in Hoon?
6672−
6673−The chain of reasoning goes something like this:
6674−
6675−Software complexity leads to monopolies and lack of individual digital
6676−sovereignty, in addition to bugs and security vulnerabilities. One of
6677−the best ways to reduce software complexity is to restrict oneself to
6678−pure mathematical functions — no side effects, no implicit arguments.
6679−This makes the system deterministic. So we want a deterministic,
6680−functional operating system for individuals to run.
6681−
6682−This operating system should also be axiomatic; we don't want it to
6683−depend on various idiosyncrasies of whatever the current hardware is
6684−like. Hardware changes over time, and we want people to be able to pass
6685−their computers on to their grandchildren, so we should have a virtual
6686−machine that runs this functional operating system.
6687−
6688−As hardware changes, people need to move their virtual machines to new
6689−hosts. This means there needs to be a standard way to serialize and
6690−deserialize the VM state at any time. The easiest way to do this is by
6691−storing an event log, just like a database, and writing each event to
6692−that before emitting effects caused by it. Since we also need state
6693−snapshots, every piece of data in the system, including runtime state,
6694−needs to be serializable to a standardized format.
6695−
6696−Because the VM will likely move from host to host many times, it needs
6697−to be tractable to actually implement a VM correctly. This means the
6698−system specification needs to be simple enough that it's clear whether a
6699−VM is in fact correct. The x86_64 instruction set that runs most
6700−servers has somewhere between 1300 and 4000 opcodes, depending on how
6701−you count. Nock has 12.
6702−
6703−Since Urbit is an operating system, its main purpose is to load and run
6704−programs on behalf of the user. This means the system needs to be
6705−really good at hot code reloading, self-hosting, metacircularity, and
6706−virtualization.
6707−
6708−There aren't any other languages out there that are purely functional,
6709−purely axiomatic, performant enough for practical personal use,
6710−universally serializable, and good at runtime metaprogramming. Nock is
6711−Urbit's solution to these design constraints. Some Lisps come close to
6712−meeting these criteria — and Nock is very Lisp-like — but no practical
6713−Lisp dialects are nearly as pure or axiomatic as Nock.
6714−
6715−### What is special about Hoon?
6716−
6717−It's a purely functional systems language. Calling it a functional
6718−analog of C is not too far off in several ways. Almost all code
6719−throughout Urbit's kernelspace and userspace is written in Hoon.
6720−
6721−### What properties does Hoon have? What type of language is it?
6722−
6723−Hoon is a statically typed, purely functional, strictly evaluated
6724−programming language.
6725−
6726−Hoon and Nock have several unusual properties:
6727−
6728−- **Axiomatic**. Nock is a fully axiomatic computing system — no
6729− dependencies, no builtins, no hardware dependence — just pure math.
6730− The jet system gives this a practical level of performance.
6731−
6732−- **Layered**. Nock is machine code designed for machines to run; Hoon is a
6733− programming language designed for people to use. Hoon layers over
6734− Nock in a very similar way to how C layers over machine code. Nock
6735− has no symbols; all programmer-facing variable names live in Hoon
6736− types. You can use raw Nock from Hoon, much like dropping down to
6737− assembly from within C. Hoon compiles to Nock with no "runtime
6738− system" — aside from subtree lookups, you could pretty easily compile
6739− most Hoon expressions by hand.
6740−
6741−- **Minimal**. Urbit is ruthlessly minimalistic throughout the stack. Nock
6742− has only twelve opcodes, and Hoon's semantics are a very thin layer
6743− over Nock's. The only fundamental datatype in Urbit is the noun:
6744− either an arbitrarily large natural number, called an atom, or a pair
6745− of nouns, called a cell. This forms a binary tree with atoms at the
6746− leaves. Lists, sets, maps, queues, executable code, closures, ASTs,
6747− buffers, strings, floating-point numbers, and everything else in the
6748− whole programming environment are represented using just this data
6749− structure.
6750−
6751−- **Acyclic**. There are no cycles in nouns, since they're always trees, so
6752− there are no cycles in Nock's memory model. Pointer equality is not
6753− exposed to the programmer. In practical Nock implementations, all
6754− data structures are what are elsewhere called "functional" or
6755− "persistent" data structures, meaning they're immutable and share
6756− structure wherever possible.
6757−
6758−- **Homoiconic**. Code and data are represented the same way and can be
6759− converted to each other. Lisp dialects are also homoiconic, but Hoon
6760− and Nock are arguably even more so, since things like closures and the
6761− environment are just Nock trees. We even have a statically typed
6762− metacircular interpreter called <code>+mule</code>. We run userspace code
6763− metacircularly with negligible performance overhead because of Urbit's
6764− jet system. In Lisp, "eval is evil" is a common saying, but in Urbit,
6765− eval is a first-class feature.
6766−
6767−- **Universally serializable**. There's one serialization format, called
6768− "jam", for any piece of code or data in the system. This makes it so
6769− that deserialization has just one function, a few hundred lines of C,
6770− as its security attack surface. It also facilitates portability of
6771− the virtual machine state, since this function can be called on the
6772− top-level VM state itself to generate a portable snapshot.
6773−
6774−- **Jetted**. A jet is a piece of code that the Nock interpreter has that
6775− reimplements a Nock function in some other, faster language. The `+dec`
6776− decrement function in Hoon's standard library is defined axiomatically
6777− using recursion, but is run as a jet written in C that makes use of
6778− the processor's ALU for performance. When calling a Nock function, if
6779− the runtime has a matching jet, it will use that instead of the Nock
6780− implementation. Nock isn't as slow as you might think, especially
6781− considering it's a minimal, dynamic, axiomatic language.
6782− <br/><br/>
6783− This arrangement has the deeper implication that all code written in
6784− Nock is best considered as a specification for a program, which can be
6785− executed directly but might never run at all due to being jetted.
6786− Cryptographic functions, for example, should all have jets with
6787− constant-time implementations to prevent timing attacks. Most jets,
6788− though, just take advantage of hardware acceleration for things like
6789− floating point arithmetic.
6790−
6791−- The amount of Hoon syntax is unusually large, but also **unusually
6792− regular**. Hoon is a "runic" language, meaning expressions generally
6793− begin with a digraph "rune" corresponding to the type of expression.
6794− Runes are used in place of keywords and Lisp's "special forms".
6795− Hoon's syntax makes better use of screen real estate than Haskell or
6796− Lisp by having a mostly vertical "backbone" of runes that prevents
6797− long functions from indenting repeatedly and helps quickly identify
6798− control flow. Hoon does not allow syntactic abstraction, so you
6799− always know exactly what you're looking at when reading Hoon. The
6800− similarity of Hoon's syntax to its abstract syntax tree makes
6801− metaprogramming easier and can be thought of as another layer of
6802− homoiconicity on top of Nock's.
6803−
6804−- **Subject-oriented**. There is no implicit environment; a Hoon expression
6805− compiles down to a Nock formula, which is interpreted as a function
6806− that runs with the "subject" as the argument. The subject can be any
6807− Nock tree, but it contains everything that's in scope. It usually
6808− consists of the Hoon compiler and standard library as a stack of
6809− cores, along with whatever functions and variables have been defined
6810− in the lexical scope.
6811−
6812−- **Cores**. A core is a pair of code and data. The core is the underlying
6813− representation of a function (a lambda with implicit fixed point), a
6814− library or module, an OOP-style object, and an OOP-style "interface"
6815− or "protocol". The code consists of a set of Nock formulas that can
6816− each be run against the whole core as a subject. This means there's
6817− always an implicit fixed point when running a function, and mutual
6818− recursion can occur among a core's formulas. A core's data usually
6819− consists of the standard library (itself a stack of cores), and
6820− possibly a "sample" (function argument).
6821−
6822−- **The type system has several unusual features**. It's intensional, in
6823− the sense that all constructs are first-class and can be up-cast to
6824− `noun`, Hoon's "any" or "top" type that matches all Nock nouns. Types
6825− are also used as scopes, so they store all of Hoon's variable names
6826− and docstrings. The type system uses an unusual macro-like feature
6827− called "wetness" to implement parametric polymorphism. The type
6828− system can also auto-generate coercion functions that validate and
6829− lift raw nouns into structural types, such as lists or cells. This is
6830− used to validate untrusted data, such as from the network.
6831−
6832−- **Reflective**. The type of type is just a normal datatype in Hoon, and a
6833− lot of the system manipulates types. In particular, the `!>` rune, when
6834− applied to a piece of data, uses compile-time type reflection to
6835− produce something called a "vase": a pair of type and data, similar to
6836− a <code>Data.Dynamic</code> in Haskell, or a limited form of a dependent pair.
6837− Since the Arvo kernel does a lot of dynamic compilation, it uses vases
6838− to implement something akin to a dynamically typed language using
6839− Hoon. This allows for type-safe dynamic program loading, program
6840− execution, and data migration.
6841−
6842−- **Inert**. Because Nock is purely functional, Hoon compiles to it so
6843− directly, everything is homoiconic, and Hoon is intensional, there's a
6844− very nice feeling that everything is just a stationary tree. There
6845− are no special objects that can't be manipulated; everything in your
6846− environment is just a subtree, and you could grab it and print it out
6847− if you wanted to. There's nothing like a "database handle",
6848− "websocket connection object", or other mystical constructs. The
6849− calmness of working with such inert building blocks is addictive, as
6850− many Hoon programmers will attest.
6851−
6852−### Why is Hoon the way it is?
6853−
6854−Minimalism, mostly.
6855−
6856−Urbit's principled minimalism simplifies all kinds of things at many
6857−layers of the stack; for example, Urbit's linker, which is part of the
6858−Ford build system, just conses together multiple libraries into a tuple
6859−to form the compile-time environment for a source file. Universal
6860−serialization means we can safely send arbitrary pieces of data to apps
6861−on other ships without any more work than sending them to a local app.
6862−Using an app called Aquarium that's about three hundred lines of code,
6863−Arvo can run a whole fleet of other Arvos inside itself at full speed,
6864−just like Docker, and perform a suite of deterministic end-to-end tests
6865−on the OS as a whole.
6866−
6867−Even Hoon's seemingly baroque syntax is extremely regular and an
6868−unusually thin layer over the abstract syntax tree. It's designed to be
6869−a power tool; learning the syntax takes some time, but you only have to
6870−learn it once, and then it's not hard to read. It's like an English
6871−speaker learning Hiragana or Cyrillic. This heaping spoonful of syntactic sugar
6872−(along with jets for performance) is enough to take Nock from a Turing
6873−tarpit to a practical, ergonomic programming tool.
6874−
6875−Subject orientation in Nock and Hoon stems partly from minimalism
6876−(there's just one subject, which serves as state, lexical scope,
6877−environment, and function argument), partly from a desire to simplify
6878−compilation (the type of the subject is a full specification of the
6879−compile-time environment for a source file), and partly in order to give
6880−the language a more imperative feel.
6881−
6882−You program Hoon as if you have a mutable environment, but you're
6883−embedded in a purely functional, immutable context. While Hoon is a
6884−purely functional language, many of its runes create a mutant copy of
6885−the subject for manipulation by future runes (similar to Forth's stack
6886−operations), which makes it feel more like an expression is "doing
6887−something" rather than just calculating something.
6888−
6889−Everything about a scope, including name bindings, aliases, and
6890−docstrings, is stored in the subject's type. This allows Hoon's
6891−compilation discipline to be similarly minimal: the compiler is a
6892−function from subject type and Hoon source to product type and compiled
6893−Nock. Running this Nock against a value of the subject type produces a
6894−vase of the result. It's hard to imagine a more streamlined formalism for compilation.
6895−
6896−The compilation discipline gets applied recursively to build the layers
6897−of the Arvo stack. The Arvo kernel is compiled using the Hoon compiler
6898−as subject, the Zuse standard library is compiled using the Arvo kernel
6899−as the subject, and apps and vanes (kernel modules) are compiled using
6900−Zuse as the subject.
6901−
6902−The promise of Urbit lies in its reimagination of the digital world
6903−using components that are as constrained and limited as possible. By
6904−adhering firmly to principle and doubling down on minimalism at every
6905−turn, we get an OS that provides far stronger guarantees than Unix with
6906−a thousand times less code. Given the complexity of modern software,
6907−this is what's required to put personal computing back into the hands of
6908−people.
6909−]]></content:encoded>
6910− </item>
6911− <item>
6912− <title><![CDATA[~2019.11.06 Update]]></title>
6913− <link>https://urbit.org/updates/2019-11-06-update</link>
6914− <guid>https://urbit.org/updates/2019-11-06-update</guid>
6915− <pubDate>Tue, 05 Nov 2019 00:00:00 GMT</pubDate>
6916− <content:encoded><
6918−
6919−Hello from San Francisco!
6920−
6921−We’re thinking of everyone in the North Bay and elsewhere who were affected by the recent fires. While we’ve had a few days of poor air quality in SF, we’re grateful that it hasn’t been as bad as last year.
6922−
6923−Here are some updates from the Tlon team:
6924−
6925−1 -
6926−Tlon has been on tour! We just got back from Berlin where we gave a talk at the Lightning Conference. [Check it out](https://youtu.be/vVIt06w3IbM?t=2030). While we were there, we [talked](https://www.youtube.com/watch?v=775vmOKxwSY) to the World Crypto Network.
6927−
6928−2 -
6929−If you’re wondering what all this Bitcoin stuff is about, we summed it up [here](https://urbit.org/blog/urbit-and-bitcoin/).
6930−
6931−3 -
6932−We’re offering a free, introductory-level online course on Hoon, the programming language that’s designed for use with Urbit. Hoon 101 begins on November 11th and runs for six weeks. Sign up [here](https://urbit.org/hoonschool/).
6933−
6934−4 -
6935−We’ve got a new version of Ames (the Urbit OS / Arvo networking protocol) compiling and up to date with master. `~pilfer-pandex` also wrote some compiler documentation that is getting rave reviews around the office. `~wicdev-wisryt` was so inspired that he added tab completion to the Dojo and built [a language server](https://github.com/urbit/urbit/pull/1910).
6936−
6937−5 -
6938−Kenny, a long time community member, is hosting the first-ever Urbit meetup in Seattle on November 12th. Details [here](http://meetu.ps/c/4tZGf/c0Pdg/a).
6939−
6940−6 -
6941−The next San Francisco meetup is on November 15th. [RSVP here](https://www.meetup.com/urbit-sf/events/266146513/).
6942−
6943−Until next time.
6944−]]></content:encoded>
6945− </item>
6946− <item>
6947− <title><![CDATA[Simple, Durable, Yours]]></title>
6948− <link>https://urbit.org/blog/simple-durable-yours</link>
6949− <guid>https://urbit.org/blog/simple-durable-yours</guid>
6950− <pubDate>Wed, 16 Oct 2019 00:00:00 GMT</pubDate>
6951− <content:encoded><![CDATA[
6952−We live in a world dense with digital services. We see the world through them, we depend on them completely, and they’re not going away. They’re only becoming more ubiquitous.
6953−
6954−But computers are a mess.
6955−
6956−<img class="ba mv5 w-100" src="https://media.urbit.org/site/understanding-urbit/simple-durable-yours/simple-durable-yours-notifications.svg">
6957−
6958−We spend all our time switching between services, juggling logins and different interfaces. And once we’re logged in, the services we use harvest our data, spy on us, and often shut down with little warning.
6959−
6960−If computers are going to be a part of our lives for generations to come, we need a sound foundation for them. We need a _system_, not a grab bag of apps and services. Urbit is that system.
6961−
6962−<img class="ba mv5 w-100" src="https://media.urbit.org/site/understanding-urbit/simple-durable-yours/simple-durable-yours-rock%402x.png">
6963−
6964−We built Urbit from scratch to be a system that’s simple, durable, and yours. Everything that computing today is not — but should be.
6965−
6966−What do we mean by simple, durable, and yours? Let’s walk through it one by one.
6967−
6968−<br /><br />
6969−
6970−## Simple
6971−
6972−Urbit is designed to be incredibly simple for ordinary users. Your data, applications, and connections all live in a single, unified operating system that belongs to you. Your Urbit requires no system administration and gets all its updates over the air. For developers, Urbit is incredibly compact and efficient. It’s about 50K lines of code — smaller than your average webapp. The entire OS can be understood by a single person and is designed to make building decentralized apps straightforward.
6973−
6974−<br /><br />
6975−
6976−## Durable
6977−
6978−Your Urbit is designed to be durable: both to store your data across generations and to be resilient against crashes. You can't really trust a computer that could disappear or become obsolete. We’ve become accustomed to this distrust, but it’s not the way things should be. Your Urbit is meant to be a permanent digital home. At its foundation, Urbit is designed a bit like a blockchain — making reliability and permanence a priority for the individual.
6979−
6980−<br /><br />
6981−
6982−## Yours
6983−
6984−Finally, your Urbit belongs to you in every possible way. You own it with a private key, control it completely, and can inspect its source code. We want your Urbit to be your digital home. A home you don’t own is just a hotel room.
6985−
6986−<img class="ba mv5 w-100" src="https://media.urbit.org/site/understanding-urbit/simple-durable-yours/simple-durable-yours-evolution.svg">
6987−
6988−Urbit began as a sketch, driven from a basic intuition that a better platform could be built. Today, Urbit is two components: Urbit ID, an identity system that’s already live on Ethereum; and Urbit OS, a decentralized network and OS stack that’s young but working well.
6989−
6990−Over time we’ve quietly evolved Urbit into a carefully engineered, compact system. Urbit isn’t done — but it’s well on its way. The network has been live since 2013 and the interface is coming along nicely. You can own a piece of Urbit today if you can find an invite from a friend, or by buying an Urbit ID. We’re ready for people to begin homesteading this new territory we created with new communities and new software.
6991−
6992−We think it’s possible to leave today’s technology behind and build something better. Something more humane, calm, and collectively owned. Our vision of the future isn’t one where technology intrudes in every corner of our lives. It’s one where technology is mostly invisible.
6993−]]></content:encoded>
6994− </item>
6995− <item>
6996− <title><![CDATA[Urbit and Bitcoin]]></title>
6997− <link>https://urbit.org/blog/urbit-and-bitcoin</link>
6998− <guid>https://urbit.org/blog/urbit-and-bitcoin</guid>
6999− <pubDate>Wed, 16 Oct 2019 00:00:00 GMT</pubDate>
7000− <content:encoded><.
7012−]]></content:encoded>
7013− </item>
7014− <item>
7015− <title><![CDATA[Your Last Computer]]></title>
7016− <link>https://urbit.org/blog/your-last-computer</link>
7017− <guid>https://urbit.org/blog/your-last-computer</guid>
7018− <pubDate>Wed, 16 Oct 2019 00:00:00 GMT</pubDate>
7019− <content:encoded><![CDATA[
7020−This whole ‘simple, durable, yours’ thing may sound good, but what does it add up to? What does it feel like?
7021−
7022−First, let’s talk about what it should feel like in the future.
7023−
7024−<img class="mv5 w-100" src="https://media.urbit.org/site/understanding-urbit/your-last-computer/your-last-computer-waves%402x.png">
7025−
7026−Imagine that you can log in from anywhere with one simple, memorable name and password. And when you do, an entire OS appears for you. Inside is your whole digital life. Every conversation you’ve ever had, all your biometric data — every step and heartbeat. Your personal mesh of devices: your doors, your car, your irrigation. All of your communities, every message you’ve shared with friends and family. Every connection you’ve made and every archival piece of data, in one place. Secure and private, forever.
7027−
7028−You own and control this OS completely. Your system doesn’t live on someone else’s server, so there’s no risk of leaking it in a mass data breach or losing it when a service shuts down. Your Urbit is a sealed, secure, and durable system.
7029−
7030−<img class="ba mv5 w-100" src="https://media.urbit.org/site/understanding-urbit/your-last-computer/your-last-computer-is-rock%402x.png">
7031−
7032−We’re on our way to this future, building it step by step, but we’re not there yet. The Urbit of today is much more stripped down.
7033−
7034−The stripped-down Urbit – Urbit OS 1 – starts out as a new kind of social network.
7035−
7036−Today, each of our social tools does one thing. And so each of our communities ends up spanning multiple services. Urbit OS 1 gives you the tools to bring these together into one place.
7037−
7038−In Urbit OS 1, a community shares a set of modules. (Think of a module like an app without the data lock-in.) One community may choose to chat and share a forum. Another may choose to chat and watch the crypto markets. And yet another may chat, share links, ebooks, and a to-do list. Anyone can develop a module, and anyone can create a community.
7039−
7040−It’s a simple system for intentional digital communities. A first step away from the ill-formed digital world of today. We like to call it ‘social computing’ — on the surface it feels like a new kind of app, but under the hood it’s an OS. It’s customizable all the way down.
7041−
7042−We think that a new system like this, even in a simple form, will be a relief from the chaos of the current web. Think of it as a “back to the land” computing movement. If we’re ever going to build new digital cities, they’ll have to start as a few colonies on the frontier.
7043−
7044−<img class="mv5 w-100" src="https://media.urbit.org/site/understanding-urbit/your-last-computer/your-last-computer-ocean%402x.png">
7045−
7046−Your Urbit is a simpler computer, a quieter computer, a more private computer. We want it to feel predictable, safe, and reliable — things only a complete, sealed system can do. This, we hope, can get us a world where technology keeps us connected, but doesn’t dominate our lives.
7047−]]></content:encoded>
7048− </item>
7049− <item>
7050− <title><![CDATA[~2019.10 Roadmap]]></title>
7051− <link>https://urbit.org/blog/2019-10-3-roadmap</link>
7052− <guid>https://urbit.org/blog/2019-10-3-roadmap</guid>
7053− <pubDate>Wed, 02 Oct 2019 00:00:00 GMT</pubDate>
7054− <content:encoded><
7056−
7057−The daily work of building a new OS from scratch is so engaging and exciting that we habitually forget to even take stock of what we’ve accomplished. We’re fixated on the prospect of moving the world on to Urbit, starting with ourselves.
7058−
7059−It’s a good thing I have a recurring reminder to write these updates. While our focus is on the future, it’s good to get a sense of the rate that we’re moving forward, and to let everyone know what’s been going on. We’ve made great progress over the past few months.
7060−
7061−We’ve got a new interface, Urbit 0.8.0, Hoon School, and a grants program among lots of other updates. We’ll go into detail about all of these, and talk a bit about where we’re headed next. The system is improving at a really good pace. We intend to keep it up.
7062−
7063−## Identity (Azimuth)
7064−
7065−The other day I got an email, clicked a link, and got a planet. A real, live, piece of cryptographic property with paper wallets and everything. It took about two minutes. And at the end, I could have easily sent invites to my friends.
7066−
7067−This experience is part of a completely new Bridge, the interface for interacting with your Urbit identity. The beta experience we’re testing today is quite stripped down, but it’s a huge improvement over the last Bridge release. Clicking a link is a lot easier than downloading source code, running it from the command-line, and probably running into a python-related error.
7068−
7069−Getting to this point involved rewriting Bridge from scratch, figuring out how to host it securely, building infrastructure to fund the requisite transactions involved in registering a new identity, and setting up a service to send emails (and dispose of them afterward). We've also redesigned our paper wallets to make them simpler and clearer.
7070−
7071−We still want to get this new version of Bridge a bit further along before releasing it to everyone — but we’re excited about it. We didn’t quite get to the point of building an affordance for payments, which we had hoped to do, but that’s coming later.
7072−
7073−We want everyone to have an Urbit identity. And we want it to be incredibly easy to get one, so we’ll get Bridge out this month with a new urbit.org (more on that below).
7074−
7075−The other area of identity-related work was Sigils — the algorithmically generated images that go with every Urbit identity. (We’ve got a blog post in the works that covers how we created these, which is a good story that needs to be told.) The original version of Sigils didn’t look very good at small sizes and a few collisions were found (thanks to [urbit.live](https://urbit.live) for helping to discover the collisions). The [new, improved sigils](https://github.com/urbit/sigil-js) have no collisions and look great at small sizes.
7076−
7077−**Q4 2019**
7078−
7079−- Release Bridge to the public
7080−- Get Bridge working well on mobile
7081−- Add payments support, hopefully including BTC
7082−- Add a network explorer
7083−
7084−**Q1 2020**
7085−
7086−- Integrate Bridge with a native app for Arvo
7087−
7088−## OS (Arvo)
7089−
7090−As a team, we want Urbit to be our primary computer, our last computer, our permanent computer. And we want this now — or at least as soon as we possibly can. We’re both ambitious and impatient.
7091−
7092−The frustration that we can’t move onto Urbit today propels us forward. The system saw major updates over the past few months all the way through the stack. On the Arvo side, we divide our work into Infrastructure (everything in the kernel and interpreter) and Interface (everything in userspace and the front-end). We’ll start with Infrastructure progress first.
7093−
7094−We’re very nearly to the point that all the kernel-level code in the system has been written by our current team. The one remaining vane that deserves a rewrite (Gall) has had a major cleanup by Jared just recently. The [Ship of Theseus](https://en.wikipedia.org/wiki/Ship_of_Theseus) approach does appear to be working. The infrastructure team is doing fantastic work and has really deepened their ownership of the system. The Urbit of today is on the road to becoming a great piece of system software.
7095−
7096−The biggest infrastructure-level milestone was the release of [Urbit 0.8.0](https://github.com/urbit/urbit/releases/tag/v0.8.0). We introduced a new process-separation architecture, implemented the correct bootstrap sequence, moved to LMDB for persistence, replaced our http vane (%eyre) and moved to Nix for our build system.
7097−
7098−To put it simply, Arvo is now much more stable and durable. During the beginning of the year we were seeing bugs and instability that were frustrating and unacceptable. While there are still issues on the live network, none of them terrify us much. We also implemented the ability for users to ‘individually breach’, which means that you can now reset your Urbit without waiting for us to reset the network.
7099−
7100−### Landscape (Arvo UI)
7101−
7102−We don’t just build infrastructure for others to develop on top of. We build interfaces too. At the top of the stack, we released a completely new Landscape, the interface for Arvo. This new interface makes it possible to build other ‘modules’ for Arvo that go beyond chat and publishing.
7103−
7104−This new Landscape is a complete departure from the last direction. Your Urbit now has a simple home screen that launches individual modules and it’s [relatively easy](https://github.com/urbit/create-landscape-app) to create new ones. We’re all enjoying using Landscape around the office. It’s still a bit of a prototype — but it’s quite a good one, I think.
7105−
7106−In moving to this new model we decided to narrow our focus to desktop only for now. We’ll return to mobile again next year — but first we want to get the desktop experience right. We’ve pulled the iOS app from the app store for the time being. I’m personally sad to see it go, since I enjoyed using it. But our prior iteration of Landscape just wasn’t quite right.
7107−
7108−This version of Landscape is, I think, the last one that we’ll call a prototype. Over the past few weeks, since shipping this, some amazing work has been happening on the interface front. We have a systematic approach to building interfaces on top of Urbit that’s very promising, albeit just getting started. We’ve already put out [one post](https://urbit.org/posts/landscape-a-portrait/) about Landscape's future, with more posts to come.
7109−
7110−**Q4 2019**
7111−
7112−- Improved Arvo-level error handling
7113−- Implementation plan for ‘telescoping kelvins’ — or [how we plan to future proof Arvo](https://groups.google.com/a/urbit.org/forum/#!topic/dev/6Mwn6TQFVwc)
7114−- Versioning scheme between Arvo and Vere
7115−- A new Haskell implementation of the daemon
7116−- A native client (instead of just a browser tab)
7117−- A [new user-space architecture](https://docs.google.com/document/d/1hS_UuResG1S4j49_H-aSshoTOROKBnGoJAaRgOipf54/edit)
7118−- Hoon.hoon that’s OTA upgradeable
7119−- Working Jacque prototype, a graal-truffle-based implementation of vere
7120−
7121−**Q1 2020**
7122−
7123−- Integrated client with Bridge and Arvo
7124−- New interface framework, codenamed ‘Widescreen’
7125−
7126−## Docs + Community
7127−
7128−We had quite a bit of interest in our second session of Hoon School. We ended up with 150 people enrolled in Hoon 101, and 42 in 201. The 101 session just ended, with a lot of positive responses and feedback from the participants. We learned a lot doing it and got quite a bit of interesting new example code.
7129−
7130−Hoon 101 started with students with little to no programming experience. Hoon 201, which is just getting underway, covers more advanced topics. We’re quite curious to see what comes out of it.
7131−
7132−We’re also adding features to Landscape to make it more amenable to use by Hoon Schoolers. Good examples include code evaluation within Chat (for office hours), and the ability to pin posts in Publish. The next crop of Hoon learners will be able to use Urbit to learn about Urbit.
7133−
7134−Aside from Hoon School we’re always updating our documentation. Most notably, we added search to the docs (finally). This was a much needed feature that makes the docs much more usable.
7135−
7136−We also launched our [grants program](https://grants.urbit.org/) quietly, but all of our available bounties were quickly claimed nonetheless. We’re ready to give away more address space to contributors and are excited by how quickly people got involved.
7137−
7138−We also did some experimentation with holding events on Arvo. We held weekly AMAs for while, and hosted a few meetings with the community. With the new UI out, our public channels have been a lot more active. We’ll surely be holding more on-urbit events in the future — but for the time being the conversation in urbit-help is a lot of fun.
7139−
7140−**Q4 2019**
7141−
7142−- Vane level documentation
7143−- An active grant program
7144−
7145−## urbit.org
7146−
7147−Urbit.org is about ready for a refresh — so we’re in the process of rebuilding it. We have, for a long time, told the story of Urbit by describing the system technically. We think Urbit can be explained much more simply and much more concisely. We’re working to put together a new set of materials in this direction.
7148−
7149−We’d also like to populate urbit.org with a lot more content about what we’re working on and thinking about. We do a reasonable job of writing updates, but many of our projects get released without any background info. Tlon and the Urbit community are full of smart, thoughtful people — and we’d like to do a lot more to surface their work. We plan to close out the year with both a new website and a lot of writing about what we’ve been building. Not everyone wants to read the source code!
7150−
7151−That covers it for now. If you have questions or want to chat — find us in `~dopzod/urbit-help`. See you online!
7152−]]></content:encoded>
7153− </item>
7154− <item>
7155− <title><![CDATA[Landscape: A Portrait]]></title>
7156− <link>https://urbit.org/blog/landscape-a-portrait</link>
7157− <guid>https://urbit.org/blog/landscape-a-portrait</guid>
7158− <pubDate>Mon, 02 Sep 2019 00:00:00 GMT</pubDate>
7159− <content:encoded><
7161−
7162−Alongside [the v0.8.0 launch](https://urbit.org/posts/2019-7-25-update/) we released the latest version of Landscape – Urbit's prototype user interface. Codenamed “Modulo,” it's our vision of an Urbit UI designed for everyday use. Most importantly, it’s the beginning of an interface that has access to the entire Arvo OS, rather than just one facet. Previous iterations of Landscape solely made use of the [Hall](https://urbit.org/docs/learn/arvo/hall/) messaging protocol.
7163−
7164−Served after installation on your ship’s HTTPS port, it allows you to interact with Arvo through a web interface built with [Indigo](https://github.com/urbit/indigo), our new UI design language. It has a home screen, which exposes ‘tiles’ for each Landscape application – each able to integrate and customise information from elsewhere in the system and from the broader internet – and connects them to full-screen, graphical applications.
7165−
7166−The first set of application includes Chat, a new, streamlined chat client, a basic Weather information tile, an analog clock, and Publish, a place for publishing, subscribing, and commenting on ‘notebooks’ – invite-oriented blogs hosted on your ship.
7167−
7168−
7169−
7170−
7171−
7172−Our unofficial mantra – “it’s not finished yet” – is performed yet again, but we're _close_. We can now talk with the broader community about both our inspirations, our visions for its future and our plan to enact that future.
7173−
7174−## Entering userspace
7175−
7176−Urbit has been in “research mode” for most of its history, but the system has now made extensive progress and our kernelspace engineers are the opinionated, confident veterans of the long war you’d expect from an operating system’s early history. The spoils of that war, after rewriting and refactoring all of the system's components several times over, are beginning to really speak for themselves.
7177−
7178−Urbit’s kernel is graduating from its rebellious period, however its _userspace_ has remained embryonic for most of its history. The project of building an application model has been restarted and rescoped into _aspects_ that could weather the chaotic growth of the kernel, but it would never quite serve as an interface to the entire operating system. Due to one of our latest vane refactors, it’s becoming possible to start that work in earnest.
7179−
7180−Alongside the latest release of Landscape came the rewrite of the [`%eyre`](https://urbit.org/docs/learn/arvo/eyre/) vane, which serves a ship’s files and applications over HTTP. Among the improvements came the decision to move from serving from one ‘/web’ folder by default to an application-specific endpoint.
7181−
7182−That is, a Hoon application, upon being started, now tells Eyre it wants to serve _these files_ at _this endpoint_ over HTTP and Eyre facilitates that.
7183−
7184−Landscape, with this in mind, serves at the root endpoint (you know, at `/`). It pre-authenticates the user and provides an API to your ship for applications (and their tiles) to access and _poke_, _peer_ and _scry_ the ship with.
7185−
7186−
7187−
7188−Whereas, before, a ship had a web server that was good at serving text, but was more obscure for complex (or graphical) applications that made use of the Arvo OS and network, now a ship launches with a web-based interface that makes applications much simpler to experiment with and develop.
7189−
7190−If you want, you can just serve files at any endpoint with [a boilerplate](https://github.com/matildepark/urbit-static-page).
7191−
7192−What's more? Arvo access and Hoon logic are now, by default, inside their own application on the ship itself rather than served as inline code on the front-end. This allows for better separation of concerns and more complex and performant applications.
7193−
7194−(If you want to play around, there’s an [experimental tool](https://github.com/urbit/create-landscape-app) you can use to get a full-stack boilerplate running in about 40 seconds.)
7195−
7196−All of this is fantastic news; and while Landscape-oriented userspace development is now _possible_, it’s still not all the way to being an interface to _an operating system_. For that, we’ve started drawing up specifications and proposals.
7197−
7198−## Rethinking interfaces
7199−
7200−Among the inspirations for our team are [the tales of Andy Hertzfeld](https://www.folklore.org/StoryView.py?project=Macintosh&story=Were_Not_Hackers!.txt), working on the Macintosh, and ongoing [discussions](http://doc.cat-v.org/plan_9/4th_edition/papers/812/) and [decisions](https://research.swtch.com/help.pdf) that went into Plan 9 from Bell Labs. (Sometimes, for fun, we also watch videos about [the Xerox Alto](https://www.youtube.com/watch?v=tngrLvyiNEI).)
7201−
7202−These inspirations share that their creators were dealing with really primordial stuff – the font of human-computer interface had really just sprung and they were _seeing things no one had seen before_ because they _had to_.
7203−
7204−Doing that now, after a lifetime of reflexive familiarity with the dominant solutions – from Apple’s macOS to Google’s Material Design – we have to do the work of _unseeing_. By engaging with what it was like to see for the first time, we get closer to seeing with fresh eyes. We work to avoid implicitly categorising the new territory as simply, well, comparative to the old one.
7205−
7206−So, while it’s not the same to simply _read_ these dialogues, it can get us pretty close.
7207−
7208−One reason this iteration of Landscape isn’t the last is because – we must emphasise – this is not the only interface Urbit will have. We aren’t creating a web platform. It should be possible to use _just_ the command-line, and ideally it should be possible to serve windowed interfaces from Arvo itself. It should be possible to SSH into _and_ SMS with your ship, should you want to.
7209−
7210−After all, we’re creating a decentralised platform of personal servers with an entirely new stack from the bytecode up. Most of the world’s computers descend from Unix, and Unix was based on [timesharing](https://en.wikipedia.org/wiki/Time-sharing) — multiple users in one computer, all pretending it was theirs. Everything since hasn’t left that mindset.
7211−
7212−So what do we think that new platform needs from its interface?
7213−
7214−- **Landscape, and all of Urbit’s future interfaces, need a standardised way to view and edit the filesystem.** We had circumnavigated this by mounting to Unix, but it’s now time to confront that issue.
7215−
7216−- **Landscape, and all of Urbit’s future interfaces, need a way to easily organise around _cohorts_ of ships, or _groups_,** with shared applications or files and a socially-oriented computing experience in turn — [something always in the vision](https://urbit.org/posts/azimuth-is-on-chain/#aegean), but not quite implemented yet.
7217−
7218−- Lastly, **Landscape, and all of Urbit’s future interfaces, need a userspace-specific, software design pattern** to integrate all of this: access to the file system, permissioning shared sets of files, and tying it together, an underlying representation of both data and interface amongst many computers.
7219−
7220−No more siloed input/output in applications on a ‘timeshared computer’ with your redundant data always belonging to someone else.
7221−
7222−## Into the future
7223−
7224−Right now, Landscape applications are still _monolithic_ and geared exclusively toward _single-person computing_. We hope to change that, and keep communication open with developers so it’s easy for their own development to keep pace with ours.
7225−
7226−It should be easy to share whatever data with your friends as you like; to permission files programmatically on a server that is permanently, irrevocably _yours_.
7227−
7228−It should also be easy to read, annotate and discuss a shared book with a specific set of friends; or only allow another set of people to see files in a specific directory if they meet specified requirements.
7229−
7230−We will backport these exploratory developments into Landscape as they continue and evolve. This, of course, includes kernel work, as we refactor [Gall](https://urbit.org/docs/learn/arvo/gall/), the userspace handler vane, and in the process, standardise streamlined practices for writing Hoon in user applications. Take, for example, the [async monad](https://groups.google.com/a/urbit.org/forum/#!topic/dev/DDG6gHSG1Lc), which allows you to avoid dealing with moves or handling each response in separate parts of the application. User applications and Hoon should be both laconic and accessible, and we’re reifying that.
7231−
7232−Most importantly, we’ll continue to iterate on how we onboard new developers. [Hoon School](https://urbit.org/hoonschool) continues to evolve; its first cohort is thriving and friendly. We have a dedicated cast of teachers and ongoing access to much of the Urbit team through this stream.
7233−
7234−If you’d like to join us here, you’ll discover a computer that you can learn and master from the bottom up. Right now, it is a labyrinth for the intrepid; but for the future, and forever, it is _mappable_. A landscape, after all, doesn’t show a single leaf, but the earth and the horizon ahead.
7235−]]></content:encoded>
7236− </item>
7237− <item>
7238− <title><![CDATA[Announcing: Urbit Grants Program]]></title>
7239− <link>https://urbit.org/blog/announcing-urbit-grants</link>
7240− <guid>https://urbit.org/blog/announcing-urbit-grants</guid>
7241− <pubDate>Mon, 05 Aug 2019 00:00:00 GMT</pubDate>
7242− <content:encoded><.
7244−
7245−The Grants program will reward valuable contributions with Azimuth stars in one of three ways: Gifts, Bounties, and Proposals.
7246−
7247−### Gifts
7248−
7249−We’ve periodically announced gifts for important contributions to the project – like in [2018](https://urbit.org/posts/2018-2-17-update/) and [2019](https://urbit.org/posts/urbit-grants-and-mid-2019-gifts/) – but we wanted to make this more formal.
7250−
7251−Not everyone always works on structured projects, so the lack of formal criteria for receiving a gift is meant to reward contributors who work outside of the bounty and grant system.
7252−
7253−Going forward, gifts will be awarded semi-annually (every six months). They’ll retain the informal and arbitrary nature of the awards that came before: Tlon will determine who gets what. We’ll work hard to make sure these payouts are fair.
7254−
7255−To see the gifts that have been awarded so far, check out the [History section](https://grants.urbit.org/history) of the Grants website.
7256−
7257−### Bounties
7258−
7259−Bounties are discrete projects in search of a champion. Tlon will define a clear deliverable, and some number of stars as their reward. Larger bounties will often have their star reward spread across multiple milestones.
7260−
7261−Contributors can apply to claim a bounty by clicking the “Request to work on this” button. Once a contributor is selected to work on a bounty, nobody else will be able to apply.
7262−
7263−Bounties are listed in the [Bounties explorer](https://grants.urbit.org/rfws). Play around with the explorer by filtering bounties using the Tag and Category features.
7264−
7265−### Proposals
7266−
7267−Proposals are a way for contributors to pitch their own ideas, with a targeted number of stars. Proposals can be accepted, rejected, or accepted with changes. Unlike bounties, a proposal can only be completed by the individual or group who submitted it.
7268−
7269−Proposals don’t need to be fleshed out like a bounty does, at least not initially. Submit an idea and Tlon will work with you to refine it.
7270−
7271−You can see the list of accepted proposals in the [Proposals explorer](https://grants.urbit.org/proposals).
7272−
7273−### What can you do?
7274−
7275−[Sign up](https://grants.urbit.org/auth/sign-up) on our Grants website page, then set up your profile so we know who you are, linking your GitHub, Twitter, and your Azimuth point: reputation is a factor in determining eligibility for a grant.
7276−
7277−Also, check out the [Grants section](https://urbit.org/faq/#grants-1) of the new Urbit FAQ for more information.
7278−]]></content:encoded>
7279− </item>
7280− <item>
7281− <title><![CDATA[~2019.7.25 Update]]></title>
7282− <link>https://urbit.org/updates/2019-7-25-update</link>
7283− <guid>https://urbit.org/updates/2019-7-25-update</guid>
7284− <pubDate>Wed, 24 Jul 2019 00:00:00 GMT</pubDate>
7285− <content:encoded><
7287−
7288−We released Urbit `v0.8.0` this week and breached the network. See the [release notes](https://github.com/urbit/urbit/releases/tag/v0.8.0). The Arvo sourcecode – previously in its own repository – has been merged into the [Urbit repository](https://github.com/urbit/urbit), and Urbit now builds with [Nix](https://nixos.org/nix/).
7289−
7290−Amongst many exciting improvements and overall greater network stability, `v0.8.0` comes with a [new version of Landscape](https://github.com/urbit/urbit/tree/master/pkg/interface), which provides a framework for writing new apps and feels much more like using the operating system Urbit is.
7291−
7292−We ran into a slew of issues with the network after launch, which were fixed in part thanks to a modification to Vere that allows [direct event injection](https://github.com/urbit/urbit/pull/1389), thanks to **Philip** `~wicdev-wisryt`. You can find `~zod.2019.7.23` relase notes [here](https://github.com/urbit/urbit/releases/tag/zod.2019.7.23).
7293−
7294−**Jared** `~nidsut-tomdun` now the maintainer and release-manager of [Urbit](https://github.com/urbit/urbit), spent much of the past few weeks testing and then shepherding `v0.8.0` out the door.
7295−
7296−**Joe** `~master-morzod` has also been preparing `v0.8.0` for release, fixing numerous bugs, and simplifying Urbit's automagic DNS (`*.arvo.network`). He's also been looking into integrating [Jaque](https://github.com/frodwith/jaque) – a Graal/Truffle Nock interpreter intended to replace much of Vere – and an [`:acme`](https://github.com/urbit/urbit/blob/master/pkg/arvo/app/acme.hoon) rewrite.
7297−
7298−**Philip** `~wicdev-wisryt` has been working on replacing `%jael` with [`%kale`](https://github.com/urbit/urbit/tree/philip/kale) and `:eth-watcher` with [azimuth-tracker](https://github.com/urbit/urbit/pull/1320).
7299−
7300−**Ted** `~rovnys-ricfer` has made great progress integrating new `%ames` ["alef"](https://github.com/urbit/urbit/tree/alef-breach). It can nearly say `|hi` to itself.
7301−
7302−**Elliot** `~littel-ponnys` has been working on an example social application that makes use of ring signatures in Arvo, called ["Safe"](https://github.com/urbit/urbit/tree/safe-prototype).
7303−
7304−**Ben** `~pitmug-roptec` has been [rewriting](https://github.com/urbit/urbit/tree/bs/uterm/pkg/hs-urbit/lib) Vere's 'daemon' process – the part that interfaces with the host system – in Haskell toward improved maintainability. He's also working on a new language, called [Conq](https://github.com/urbit/urbit/blob/bs/conq-attila-hoon/pkg/hs-conq/lib/Language/Conq.hs).
7305−
7306−**Mark** `~palfun-foslup` has been working on next-gen [Bridge](https://github.com/urbit/bridge/tree/mino) with **Matt** `@shrugs`, and [Peerlist](https://github.com/urbit/urbit/pull/1309), a mechanism for peer-discovery on the network.
7307−
7308−**Isaac** `~novlud-padtyv` and **Logan** `~tacryt-socryp` shipped the [new Landscape](https://github.com/urbit/urbit/tree/master/pkg/interface), which features a brand-new interface designed around an OS-like home screen and the ability to integrate new applications. Landscape too [has been merged](https://github.com/urbit/urbit/pull/1367) into the Urbit monorepo.
7309−
7310−Until next time.
7311−]]></content:encoded>
7312− </item>
7313− <item>
7314− <title><![CDATA[Azimuth Security Bounty Program]]></title>
7315− <link>https://urbit.org/blog/azimuth-security-bounty-program</link>
7316− <guid>https://urbit.org/blog/azimuth-security-bounty-program</guid>
7317− <pubDate>Sun, 21 Jul 2019 00:00:00 GMT</pubDate>
7318− <content:encoded><
7320−
7321−Since launching [Azimuth](https://urbit.org/posts/azimuth-is-on-chain/), we’ve been running a private bounty program with [HackerOne](https://hackerone.com/). We’re now taking the program public and inviting you (and your friends) to help us make Azimuth as secure as possible.
7322−
7323−[Go here](https://hackerone.com/tlon) to see the live program on HackerOne.
7324−
7325−## What is Azimuth again?
7326−
7327−Azimuth is [the Urbit public key infrastructure](https://urbit.org/posts/azimuth-is-on-chain/). It’s a set of Ethereum smart contracts that allow for cryptographic ownership and management of Urbit identities. It also provides a governance mechanism whereby galaxy owners are able to propose and vote on improvements.
7328−
7329−People already [use Azimuth](https://github.com/urbit/bridge) to boot Arvo ships, spawn stars and planets for others and transfer points. But Azimuth is a general identity system, with great potential to be used beyond Arvo: there are primitives for reputation, payments and securing communication channels.
7330−
7331−## Security program details
7332−
7333−We had the Azimuth contracts audited by [Open Zeppelin](https://openzeppelin.org/), [Blockchain at Berkeley](https://blockchain.berkeley.edu/) and [Bloctrax](https://www.bloctrax.com/), but we don’t want to take any chances. We’re hoping that the HackerOne program will help us get more eyes on the contracts, identify vulnerabilities and get out in front of any problems. You can find more information about the program at [our page](https://hackerone.com/tlon) on HackerOne.
7334−
7335−We’re interested in any vulnerability in the Azimuth contracts that would allow an attacker to either seize other user’s points, impersonate points or that would result in the platform becoming unusable.
7336−
7337−The program page has links and instructions on how to set up a development version of Bridge and point it at either the Ropsten deployment of the contracts or at a local network to play with the contracts and look for vulnerabilities.
7338−
7339−## Arvo is out of scope for now
7340−
7341−We’re intentionally focusing our security efforts on Azimuth for now. Since Azimuth serves as our PKI layer, it’s the most crucial for the time being: it’s the source of truth for who owns what. We don’t want to have even a shred of a doubt that these cryptographic properties are secure.
7342−
7343−Of course, we’re working toward a future where you have a computer connected to this Azimuth point, and the computer has to be as secure as its identity. To achieve this, we have some more hard work to do on Arvo and our interpreter, Vere. When the time comes, we’ll also reach out for help testing vulnerabilities throughout the entire stack.
7344−]]></content:encoded>
7345− </item>
7346− <item>
7347− <title><![CDATA[~2019.6.14 Update]]></title>
7348− <link>https://urbit.org/updates/2019-6-14-update</link>
7349− <guid>https://urbit.org/updates/2019-6-14-update</guid>
7350− <pubDate>Thu, 13 Jun 2019 00:00:00 GMT</pubDate>
7351− <content:encoded><
7353−
7354−**Jared** `~nidsut-tomdun` has been putting final touches on the Urbit `0.8.0` (formerly "cc-release") and pushed new versions of [azimuth-js](https://github.com/urbit/azimuth-js/releases) and [urbit-key-generation](https://github.com/urbit/urbit-key-generation/releases).
7355−
7356−**Philip** `~wicdev-wisryt` improved his new async monad and its example apps. Read more about that [here](https://groups.google.com/a/urbit.org/forum/#!topic/dev/DDG6gHSG1Lc) and in the [original PR](https://github.com/urbit/arvo/pull/1183).
7357−
7358−**Ted** `~rovnys-ricfer`, with **Philip**, made progress on new `%ames` architecture and implementation. Follow along with some of the recent discussion in [this post](https://groups.google.com/a/urbit.org/forum/#!topic/dev/y_gaSpn9mxM).
7359−
7360−**Elliot** `~littel-ponnys` finished an initial implementation of ring signatures in Arvo, including a basic voting app, described in a [post](https://groups.google.com/a/urbit.org/forum/#!topic/dev/IG-FdVpEGX0) to urbit-dev. He also worked on a forthcoming Haskell rewrite of Vere with `~pitmug-roptec` and his multi-process Urbit "Nuevo" design.
7361−
7362−**Joe** `~master-morzod` worked on some Hoon bugs, reviewed the `lighter-than-eyre` branch – which won't be released in 0.8.0 – and has been working to simplify the DNS magic that makes ship.arvo.network work.
7363−
7364−`~rigdyn-sondur` is on the home stretch with [64-bit Vere](https://github.com/BernardoDeLaPlaz/urbit/commits/vere_64).
7365−
7366−Until next time.
7367−]]></content:encoded>
7368− </item>
7369− <item>
7370− <title><![CDATA[Urbit Grants and mid-2019 Gifts]]></title>
7371− <link>https://urbit.org/blog/urbit-grants-and-mid-2019-gifts</link>
7372− <guid>https://urbit.org/blog/urbit-grants-and-mid-2019-gifts</guid>
7373− <pubDate>Sun, 09 Jun 2019 00:00:00 GMT</pubDate>
7374− <content:encoded><
7376−
7377−We are excited to announce the first developer star gifts of 2019. It’s been far too long since we last awarded our contributors. We got so busy working on things ourselves that we let this program languish — but we’ve got plans to make it much more organized going forward. More on that after the important part.
7378−
7379−That is, our winners from the past nine months:
7380−
7381−**Gold: 8 stars**
7382−
7383−- Ben `~mirfet-hocbyt` [@bencalder](https://github.com/bencalder)
7384−- Max `~ladres-forfex` [@max19](https://github.com/max19)
7385−
7386−**Ben** discovered the bug in our @p rendering algorithm, nicknamed “the @pocalypse” around the office, and led to a few nights of lost sleep. It was a fantastic find, which was then resolved by **Max** with one of the greatest GitHub comments of all time: “[curious if this works](https://github.com/urbit/arvo/issues/1105#issuecomment-472585937).”
7387−
7388−**Bronze: 1 star**
7389−
7390−- Pyry `~dinleb-rambep` [@pkova](https://github.com/pkova)
7391−- John `~dirwex-dosrev` [@jfranklin9000](https://github.com/jfranklin9000)
7392−- Assaf `~rophex-hashes` [@asssaf](https://github.com/asssaf)
7393−
7394−**Pyry** has been a [regular contributor](https://github.com/urbit/bridge/pulls?utf8=%E2%9C%93&q=author%3Apkova) to Bridge over the past few months, **John** has been consistently picking up changes [all](https://github.com/urbit/urbit/pulls?utf8=%E2%9C%93&q=author%3Ajfranklin9000) [over](https://github.com/urbit/arvo/pulls?utf8=%E2%9C%93&q=author%3Ajfranklin9000) [the place](https://github.com/urbit/docs/pulls?utf8=%E2%9C%93&q=author%3Ajfranklin9000), and **Assaf** found a [security issue](https://github.com/urbit/urbit-key-generation/issues/55) with our hierarchical wallet.
7395−
7396−Thanks to all of you for helping bring Urbit to life. We don’t make it nearly easy enough to contribute, but all of you clawed your way in and made the system better. Thank you!
7397−
7398−## Coming soon: Our new grant program
7399−
7400−As always, we much prefer to talk about working code as opposed to unfinished work – however:
7401−
7402−Making the process of rewarding contributors is something we’ve thought a lot about over the past few months. We’ve come up with a system that we like, and are hoping to put it up later this summer. It’s probably not perfect, but it’s a step in the right direction. We’ll be able to properly engage in a grant proposal process, post bounties as well as reward people directly with prizes.
7403−
7404−Please [subscribe to our newsletter](http://eepurl.com/b7x7hj) to make sure you receive future announcements.
7405−]]></content:encoded>
7406− </item>
7407− <item>
7408− <title><![CDATA[~2019.5.31 Update]]></title>
7409− <link>https://urbit.org/updates/2019-5-31-update</link>
7410− <guid>https://urbit.org/updates/2019-5-31-update</guid>
7411− <pubDate>Thu, 30 May 2019 00:00:00 GMT</pubDate>
7412− <content:encoded><
7414−
7415−**Logan** `~tacryt-socryp` has been working with **Isaac** `~novlud-padtyv` on a new chat interface to replace Landscape and recently finished a chat wrapper API on top of Hall that enables significant performance gains, simplifies the API, and enables fine-grained unread counts per chatroom.
7416−
7417−**Ted** `~rovnys-ricfer` published [an initial new Ames proposal](https://groups.google.com/a/urbit.org/forum/#!topic/dev/91oMaUwtVzE) to [urbit-dev](https://groups.google.com/a/urbit.org/forum/#!forum/dev) and abandoned the `aloe` branch for [`alef`](https://github.com/urbit/arvo/tree/alef), where the initial few thousand lines of code have now been checked in.
7418−
7419−**Joe** `~master-morzod` worked on the DNS magic behind `arvo.network`, jet compilers with `~pilfer-pandex`, `cc-release` argument parsing, and rewrites of cue and mug.
7420−
7421−**Elliot** `~littel-ponnys` finished a draft design of his multi-process Arvo "nuevo" design.
7422−
7423−**Mark** `~palfun-foslup` [merged](https://github.com/urbit/azimuth/pull/17) support for delegated sending from arbitrary stars in Azimuth.
7424−
7425−**Jared** `~nidsut-tomdun` released azimuth-js `v0.14.0`, pushed azimuth-solidity `v1.2.0` to NPM, continued work on `%gall`, and has been readying `cc-release`.
7426−
7427−**Morgan** `~hidrel-fabtel` has been reaching out to community members. If you're interested in talking with us about your experience with Urbit so far and what you'd like to see in the future, please let us know at [support@urbit.org](mailto:support@urbit.org).
7428−
7429−In other news, the [urbit-dev](https://groups.google.com/a/urbit.org/forum/#!forum/dev) mailing list has been lively, [urbit.org](https://github.com/urbit/urbit.org) now deploys automatically thanks to Netlify, and we're getting ready to breach the network for [cc-release](https://github.com/urbit/urbit/tree/cc-release) next week. Follow [@zodisok](https://twitter.com/zodisok) for updates.
7430−
7431−Until next time.
7432−]]></content:encoded>
7433− </item>
7434− <item>
7435− <title><![CDATA[~2019.5.17 Update]]></title>
7436− <link>https://urbit.org/updates/2019-5-17-update</link>
7437− <guid>https://urbit.org/updates/2019-5-17-update</guid>
7438− <pubDate>Thu, 16 May 2019 00:00:00 GMT</pubDate>
7439− <content:encoded><
7441−
7442−— from [Marabu](https://hundredrabbits.itch.io/marabu) by [Rekka & Devine](https://hundredrabbits.itch.io/)
7443−
7444−**Ted** `~rovnys-ricfer` and **Philip** `~wicdev-wisryt` continued work on new `%ames` in the [aloe](https://github.com/urbit/arvo/tree/aloe) branch, **Elliot** `~littel-ponnys` has been designing a new, multi-process Arvo, known as "nuevo," and implementing primitives for ring signatures in Arvo, **Joe** `~master-morzod` finalized cc-release and started toward finishing new `%eyre`, ongoing in the [lighter-than-eyre](https://github.com/urbit/urbit/tree/lighter-than-eyre) branch, and **Mark** `~palfun-foslup` pushed [Bridge v1.4.1](https://github.com/urbit/bridge/releases).
7445−
7446−In other news, the **Interface Team** started a [Twitter account](https://twitter.com/urbitwip) to share work in progress, there's been lively discussion on [urbit-dev](https://groups.google.com/a/urbit.org/forum/#!forum/dev), and we published [a roadmap](https://urbit.org/posts/2019-5-roadmap/).
7447−
7448−Until next time.
7449−]]></content:encoded>
7450− </item>
7451− <item>
7452− <title><![CDATA[~2019.5 Roadmap]]></title>
7453− <link>https://urbit.org/blog/2019-5-roadmap</link>
7454− <guid>https://urbit.org/blog/2019-5-roadmap</guid>
7455− <pubDate>Wed, 15 May 2019 00:00:00 GMT</pubDate>
7456− <content:encoded><
7458−
7459−We often get so busy that we forget to tell you what we’ve been up to. Here’s an update on what we’re doing and where we’re headed with each layer of the stack.
7460−
7461−At a very high level we have two goals for 2019: make Azimuth easier to use, and get Arvo to a 1.0.
7462−
7463−Next year we’ll begin to move away from some of the MEGACORP software we use in the office, and replace it with our own tooling. There’s some exciting work happening in that department, but we’ll cover that in a future post.
7464−
7465−For some related recent thinking on all of this, see [The 100 Year Computer](/posts/essays/the-100-year-computer/), [The State of Landscape](/posts/essays/the-state-of-landscape/) and [Azimuth as MultiPass](/posts/essays/azimuth-as-multipass/).
7466−
7467−For now, let’s just look at what’s on the immediate horizon:
7468−
7469−## Azimuth
7470−
7471−At lunch the other day someone on our team said something like, ‘We built a complete and working public key infrastructure, but we haven’t told anyone.’
7472−
7473−It’s true. Azimuth is operational, secure, and well tested. It’s a pretty cool piece of technology and it’s out there in the world for anyone to use. It also doesn’t require that you use Arvo — Arvo happens to make use of Azimuth, but Azimuth itself is a completely separate system.
7474−
7475−So the question is why haven’t we told the world about it?
7476−
7477−I tend to think that in order for a technology to succeed it has to not only be an important technical innovation, it also has to be easy to understand as a product. And that’s our answer: we’ve undersold Azimuth because we want it to be easier to understand by _using_, not just by reading the code. Azimuth is quite an elegant piece of technology — but that doesn’t matter until it has a great user experience to match.
7478−
7479−That’s why, in the near term, we’re focused on building on top of Azimuth ourselves. We can’t ask others to go down roads if we haven’t already been down them.
7480−
7481−Here’s what we’re building first:
7482−
7483−### Q2 2019
7484−
7485−- A simplified onboarding flow for getting an Azimuth point that’s simple to share with friends over email, text or as a URL.
7486−- A redesigned and improved Bridge for managing your points.
7487−- An interface that allows you to easily send money between Azimuth points without running Arvo.
7488−
7489−### Q3 2019
7490−
7491−- Expanded Azimuth-centric example modules, documentation and developer tooling.
7492−
7493−Still under consideration:
7494−
7495−- An OAuth server or JWT flow for logging into any service with an Azimuth point.
7496−- A mobile app for point to point payments using Azimuth.
7497−
7498−### 2020
7499−
7500−Azimuth is beginning to feel like [multipass](/posts/essays/azimuth-as-multipass/), with a variety of ways to use Azimuth points without ever booting Arvo
7501−
7502−## Arvo
7503−
7504−The Arvo interface has always been held back by Arvo’s technical immaturity. This is still true to some degree. The system has not stabilized completely.
7505−
7506−But! We’ve been using Landscape quite a lot lately. I use it daily, in fact — even [on my phone](https://itunes.apple.com/us/app/landscape-urbit/id1393148862). An encrypted (although not audited — so let’s not call it ‘secure’), authenticated chat where I own the keys and can read the source code feels really nice to use. The interface isn’t as good as we’d like, but it’s not bad. Landscape is a great preview of where we’re going: a simple, permanent, self-sovereign computer.
7507−
7508−There are still rough edges, and Landscape is not nearly general purpose enough, but we have plans:
7509−
7510−### Q2 2019
7511−
7512−- A new update to the Arvo interface that we’re calling Modulo. Modulo expands beyond chat and longform discussion to make your Arvo interface feel much more like the computer it actually is.
7513−- Upgrades to our event persistence, networking, and DNS integration aimed at much better stability. Arvo instances don’t crash that often, but with these changes it should be very rare.
7514−- Significant improvements to testing with a new simulation testing framework and integration testing pipelines.
7515−
7516−### Q3 2019
7517−
7518−- A significant overhaul to Gall, our application model, making it much simpler for users to write apps or ‘agents’ in Arvo.
7519−- A new version of the compiler that makes us less reliant on jets. This will eliminate a major obstacle to achieving network continuity, or the ability for ships to upgrade themselves totally over-the-air, forever.
7520−- A significant overhaul and stability update to Clay, our filesystem, making it possible for us to trust it for self-hosting, search it easily, and depend on it for long-term data storage.
7521−- Tooling for hosting and hopefully a beta program for hosted Arvo instances run by Tlon.
7522−
7523−### 2020
7524−
7525−- A completely overhauled Arvo interface, Daigo, with a complete but simple set of messaging and collaboration tools. Modulo is meant to be fun to experiment with, but we aim to make Daigo part of our daily workflow.
7526−- We come to work every day, use Arvo, go home.
7527−
7528−## Community
7529−
7530−We’ve often felt like it was far too early to invite others in to the system.
7531−
7532−As long as we’re up front about the state of this 100 year computer -- that it’s live, but incomplete — I think it’s a good thing to welcome people on board. There’s plenty to play with, experiment with and explore.
7533−
7534−Hoon school was the first effort in this direction. We intend to do a lot more:
7535−
7536−### Q2 2019
7537−
7538−- Scaling Hoon school up to include both a track for experts and for beginners, and allowing many more participants.
7539−- Holding more meetings and events on Landscape, experimenting with Arvo-native discussion.
7540−- A clear program for address space grants for developers + contributors.
7541−- New documentation site with searchable library docs.
7542−
7543−### Q3 2019
7544−
7545−- Hoon School participants understand clearly how to build a Modulo agent, and invite others into it.
7546−- The road toward building an Azimuth module is well understood, paved, and clear.
7547−- We have clear instructions and tutorials for building Azimuth modules and using Azimuth as a login or reputation primitive.
7548−]]></content:encoded>
7549− </item>
7550− <item>
7551− <title><![CDATA[Azimuth as Multipass]]></title>
7552− <link>https://urbit.org/blog/azimuth-as-multipass</link>
7553− <guid>https://urbit.org/blog/azimuth-as-multipass</guid>
7554− <pubDate>Wed, 15 May 2019 00:00:00 GMT</pubDate>
7555− <content:encoded><
7557−
7558−Why can’t I just walk up to a door and have it open for me? Why can’t I simply arrive at a restaurant and have them know I’m there? Shouldn’t I be able to buy a ticket to a show with my Multipass then scan it at the entrance and use it to buy drinks?
7559−
7560−Why should I have to log in with MEGACORP? Today, in most cases, it’s a different MEGACORP for every single context. It’s a MEGAMESS.
7561−
7562−Why not just use one? Forget about how we get there for a moment: just imagine how simple it could be.
7563−
7564−An Azimuth point is an identity and a wallet. Both a driver’s license and a credit card. Identity and money. Think about it as a ‘civilizational key’ for a new society. Concretely, it’s nice to imagine it as a physical object. A slick, card sized object with an e-ink screen. You can tap it to pay, tap it to enter, and plug it into a computer to boot your Arvo OS.
7565−
7566−Worried about losing it? Just remember your ticket. If you use our wallet system, all you need to remember is something like `~ravmel-ropdyl` and `~habpem-sondem-pidbyt-solbyn`. A point and a ticket. That’s it.
7567−
7568−Woke up in the desert, no idea how you got there, but can still remember your point and ticket? Great! Just get to an internet connection and re-ticket – you’ll be fine. Although probably dehydrated.
7569−
7570−If you’re someone who’s worried about getting kidnapped, just use a child identity. Your Azimuth planet has ~4B of them, so you can always invalidate one if you lose it.
7571−
7572−Perhaps part of how we ended up in the world we’re in is that we didn’t have something like Azimuth to begin with. Today, it’s backwards: everyone has an address on the network, but no one has an identity.
7573−
7574−We think everyone needs an identity that can hold money and have packets routed to it. Start there, and it’s quite fun to imagine where you end up. A civilized digital society might even be possible after all.
7575−]]></content:encoded>
7576− </item>
7577− <item>
7578− <title><![CDATA[The State of Landscape]]></title>
7579− <link>https://urbit.org/blog/the-state-of-landscape</link>
7580− <guid>https://urbit.org/blog/the-state-of-landscape</guid>
7581− <pubDate>Wed, 15 May 2019 00:00:00 GMT</pubDate>
7582− <content:encoded><
7584−
7585−The TL;DR is: if you’re really excited about living on Mars, Landscape is fun to try out. Come join `~dopzod/urbit-help`, experiment with creating your own chats and collections (did anyone find that easter egg, yet?), and see what you can do with the thing.
7586−
7587−Landscape today is for the intrepid adventurer. So is much of the system. If you want to read about what we’re doing to make it more welcoming, [check out the 2019 roadmap](/posts/essays/2019-5-roadmap/).
7588−
7589−## The Broad View
7590−
7591−We thought a lot last year about how to avoid the pitfalls of modern social networks. The services we all use today each feel like _one place_. It’s as if everyone on MEGANET is living together in the same city.
7592−
7593−In the real world, cities have their own cultures. So we thought: there must be some way to build more granular communities online. Living in a single world-city is kind of a bummer, honestly.
7594−
7595−Landscape was our first experiment in this direction. It’s a ruthlessly simple interface for chat and discussion that runs on top of Arvo. You can connect to Landscape in a browser or in an app on your iOS device. All communication is pseudonymous and authenticated (as with everything in Arvo) with your Azimuth point.
7596−
7597−Over the past few months, we’ve been running small experiments, experimenting with ways to support our own work and finding the limits of what we can do on the network. Originally, we built Landscape out of our desire to get away from using MEGACORP communication tools in our daily work. We thought: if we’re trying to build a whole new network and society, we had better go live there first.
7598−
7599−Landscape is an experiment — it’s supposed to be fun, above all, and a good way to help focus our efforts on maturing the platform.
7600−
7601−Anyway, let’s show off some of the specifics, and give an update on this experiment so far.
7602−
7603−## A Quick Tour
7604−
7605−Landscape is pretty simple. It lets you subscribe to chats, in the spirit of IRC, and ‘collections’, which are effectively forums or blogs with comments. You can also direct message with other running ‘ships’ or Arvo nodes.
7606−
7607−For the most part, this happens through a web interface that you can access at `https://ship.arvo.network` or via `localhost:80`.
7608−
7609−There’s also an iOS app, [available in the app store](https://itunes.apple.com/us/app/landscape-urbit/id1393148862), that you link to your ship the same way you log in through a browser.
7610−
7611−## Landscape: The Bad Parts
7612−
7613−What’s keeping us from asking others to use this thing more aggressively? Let’s walk through the reasons (while keeping in mind, they’re all [things we’re working on](/posts/essays/2019-5-roadmap/)):
7614−
7615−### 1 - Arvo has rough spots
7616−
7617−They have gotten a lot better, but there are still a few things that can crash your Arvo ship. This, of course, has nothing to do with your Azimuth point, which is completely separate and, as far as we know, secure.
7618−
7619−The first (and most severe) is a bug in our event persistence that occurs very rarely. Basically, there are conditions under which you can cause events not to be properly written to disk and corrupt your event log. It’s pretty unlikely, but it’s unacceptable for a real product since it basically causes you to have to wait out the current network era.
7620−
7621−The second is that Ames (our network protocol) has occasional connectivity problems. Originally, we thought we had found this issue as being related to [a timer bug](https://github.com/urbit/arvo/pull/1072). It may be, but the networking is in the process of a major overhaul — so we’ve implemented a few bandaids to make the situation workable. `|bonk` sometimes needs to be used to reset connections between peers, and `:ethmanage` sometimes need to be used to re-synchronize with the blockchain. It’s an ugly fix, but it usually works.
7622−
7623−Relatedly, we have occasionally been seeing errors caused by the Arvo network being slow to register keys from the blockchain. If you’re a newly registered Azimuth point, and your keys were just put on-chain, it can take some time for that change to propagate. This can result in a confusing situation for new ships.
7624−
7625−### 2 - There’s no ‘individual continuity breach’
7626−
7627−One great thing about the Arvo network is that it’s more like a giant single computer than a network. When you talk to another ship, use remote files or sync data it’s almost the same as working with local data.
7628−
7629−The main thing underlying this is _sequence numbers_. Your Arvo ship keeps track of every message it has exchanged with every other ship, and it never breaks that sequence. If our ships are talking, and we’re on packet `83910` but you reset and try to start again at `0` my ship just thinks you’ve lost your mind and won’t talk to you anymore.
7630−
7631−We’d like individual resets to work, and we’re [working on it](https://github.com/urbit/arvo/pull/1169). But, for the time being, if you have any fatal error on your ship, it means you’ve got to sit this era out.
7632−
7633−This is another unacceptable bug for anything we truly rely on.
7634−
7635−### 3 - There are no push notifications, yet
7636−
7637−What’s one thing that a chat application needs to do? Notify you of new messages. What does Landscape notify you about? Well, at the moment, basically nothing.
7638−
7639−We implemented and tested a push notifications server for iOS, which is slated for release in the next few months (it depends on things in our `cc-release` branch). We’d also love to work on having your ship connect to your email provider and send you alerts over email. We’re thinking about how to do that.
7640−
7641−## What We’ve Learned and What We’re Doing
7642−
7643−Many of us spend all day on Landscape, use it from our phones, and find it really fun. The bugs above bite less than you might think and, in many cases, the experience is quite nice. It’s a passive, distraction-free way to interact with others around the office.
7644−
7645−We operate one public channel, `~dopzod/urbit-help` for answering any of your questions about the system. And, from time to time, we have been creating topic-centric channels and announcing them publicly. This has been a lot of fun. Come join us if you’re feeling brave.
7646−]]></content:encoded>
7647− </item>
7648− <item>
7649− <title><![CDATA[The 100-Year Computer]]></title>
7650− <link>https://urbit.org/blog/the-100-year-computer</link>
7651− <guid>https://urbit.org/blog/the-100-year-computer</guid>
7652− <pubDate>Mon, 13 May 2019 00:00:00 GMT</pubDate>
7653− <content:encoded><
7655−
7656−Around the Tlon office, we’re always looking for more concise ways to describe what we do. We kicked around ‘personal server’ for a long time. It’s pretty close. ‘Personal cloud computer’ did okay for a while, but it’s a little confusing.
7657−
7658−One way to think about Urbit is as a 100-year computer.
7659−
7660−A 100-year computer has to be durable, reliable and permanent. It has to never lose data or fail in unpredictable ways. It has to be continuous, meaning it should never need to be updated by the user. If I put it in a closet for 10 years and take it out, it should work again without any intervention.
7661−
7662−And, perhaps most importantly, it should be easy and enjoyable to use. Both for a casual user and for a technical person. If it’s not enjoyable to use, and doesn’t actually _get used_, it’s never going to survive for 100 years.
7663−
7664−In theory we could all be using Apple I’s today, but they’re a bit cumbersome. In large part that’s because they don’t update themselves. Those magnetic tapes don’t strike me as particularly durable either.
7665−
7666−Imagine that a computer was something you kept forever. It would comfortably store your entire life: your writing, photos, blood tests, even your genome. Your computer would never show you ads, interrupt you against your wishes, or send your data to someone else without your permission.
7667−
7668−Imagine a computer that was extremely valuable to you, that you’d pay thousands of dollars to recover, but you used _less_ than the one you do today.
7669−]]></content:encoded>
7670− </item>
7671− <item>
7672− <title><![CDATA[~2019.5.10 Update]]></title>
7673− <link>https://urbit.org/updates/2019-5-10-update</link>
7674− <guid>https://urbit.org/updates/2019-5-10-update</guid>
7675− <pubDate>Thu, 09 May 2019 00:00:00 GMT</pubDate>
7676− <content:encoded><
7678−
7679−**Ted** `~rovnys-ricfur` is rewriting `%ames`, Urbit’s encrypted peer-to-peer messaging protocol, in the [“aloe”](https://github.com/urbit/arvo/tree/aloe) branch. **Philip** `~wicdev-wisryt` has been working on a `bind` rune, [monadic pH tests](https://github.com/urbit/arvo/pull/1152), and `%ames` [“aloe”](https://github.com/urbit/arvo/tree/philip/aloe) with **Ted**. **Jared** `~nidsut-tomdun` is reworking `%gall` and has been pushing [Bridge](https://github.com/urbit/bridge/releases) updates with **Mark** `~palfun-foslup`. **Joe** `~master-morzod` has [cc-release](https://github.com/urbit/urbit/tree/cc-release) – the next major version of Urbit – just about ready to go. This bundles a new multi-process architecture, support for running the full bootstrap sequence, new event dispatch and persistence, a new build system, and more. **Elliot** `~littel-ponnys` merged new [event batching](https://github.com/urbit/urbit/pull/1259) (part of cc-release), which [makes Urbit performance less I/O bound](https://github.com/urbit/urbit/pull/1259#issuecomment-487785371). Finally, **Morgan** `~hidrel-fabtel` and **Alex** `~mignyt-mogseb` launched a public mailing list, [urbit-dev](https://groups.google.com/a/urbit.org/forum/#!forum/dev), a [new proposal system](https://github.com/urbit/proposals), and reimplemented [urbit.org](https://github.com/urbit/urbit.org) to enable fast builds and automatic deployment.
7680−
7681−Until next time.
7682−]]></content:encoded>
7683− </item>
7684− <item>
7685− <title><![CDATA[~2019.4.11 Update]]></title>
7686− <link>https://urbit.org/updates/2019-4-11-update</link>
7687− <guid>https://urbit.org/updates/2019-4-11-update</guid>
7688− <pubDate>Wed, 10 Apr 2019 00:00:00 GMT</pubDate>
7689− <content:encoded><
7693−
7694−## Team
7695−
7696−_Philip_ `~wicdev-wisryt` made progress on `%aqua`, simulated Arvo instances running in Arvo, and getting individual continuity breaches working, which will enable resetting of sunk ships. _Elliot_ `~littel-ponnys` and _Joe_ `~master-morzod` have been [readying](https://github.com/urbit/urbit/pull/1232) `cc-release` for release. _Ted_ `~rovnys-ricfur` has been [laying the groundwork](https://github.com/urbit/arvo/pull/1135) for future error handling and making progress on new `%ames`. _Ben_ `~pitmug-roptec` and `pilfer-pandex` continued work on Hoon's type system. Finally, _Jared_ `~nidsut-tomdun` is revamping `%gall`, currently `+mo` and `+ap`.
7697−
7698−## Community
7699−
7700−We conducted an Azimuth AMA and an "IDEA BLITZ" on Landscape. Excerpts from the IDEA BLITZ are collected in [a GitHub issue](https://github.com/urbit/proposals/issues/4), and archives are available at `~dopzod/azimuth-ama` and `~dopzod/idea-blitz`.
7701−
7702−## April Fools
7703−
7704−_Ted_ `~rovnys-ricfur` shared a [convincing argument](https://github.com/urbit/arvo/pull/1129) for uppercasing Hoon and someone launched [Urbit Classic](http://urbit-classic.org/), running 2016-era Arvo. To be clear, we don't recommend sending them Bitcoin.
7705−
7706−Until next time.
7707−]]></content:encoded>
7708− </item>
7709− <item>
7710− <title><![CDATA[~2019.3.27 Update]]></title>
7711− <link>https://urbit.org/updates/2019-3-27-update</link>
7712− <guid>https://urbit.org/updates/2019-3-27-update</guid>
7713− <pubDate>Tue, 26 Mar 2019 00:00:00 GMT</pubDate>
7714− <content:encoded><
7718−
7719−## Team
7720−
7721−_Philip_ `~wicdev-wisryt` [finished](https://github.com/urbit/arvo/pull/1120) Aquarium, which runs a virtual fleet of ships inside a host ship, and pH, an integration testing framework. `~rigdyn-sondur` [pushed](https://github.com/urbit/urbit/pull/1228) ncurses support. _Joe_ `~master-morzod` and _Elliot_ `~littel-ponnys` continued work on new `%eyre` (webserver) while Isaac `~novlud-padtyv` [integrated](https://github.com/urbit/arvo/pull/1119) Landscape. Finally, `~pilfer-pandex` and _Benjamin_ `~pitmug-roptec` made progress on a reimplementation of the compiler.
7722−
7723−Until next time.
7724−]]></content:encoded>
7725− </item>
7726− <item>
7727− <title><![CDATA[~2019.3.11 Update]]></title>
7728− <link>https://urbit.org/updates/2019-3-11-update</link>
7729− <guid>https://urbit.org/updates/2019-3-11-update</guid>
7730− <pubDate>Sun, 10 Mar 2019 00:00:00 GMT</pubDate>
7731− <content:encoded><
7735−
7736−## `@p` Bug
7737−
7738−The `@p` bug [is solved](https://github.com/urbit/arvo/pull/1110), thanks to [@max19](https://github.com/urbit/arvo/issues/1105#issuecomment-472585937) and _Jared_ `~nidsut-tomdun`.
7739−
7740−## Team
7741−
7742−_Ted_ `~rovnys-ricfer`, _Philip_ `~wicdev-wisryt`, and _Joe_ `~master-morzod` developed a proposal for formalizing the semantics around state persistence in a way that enables parallelism, event replay, and a new model for error handling. _Joe_ `~master-morzod` worked on integrating new `%eyre`. _Elliot_ `~littel-ponnys` worked on an elaborate proposal for resolving the `@p` bug involving constraint solvers, which turned out to be unnecessary, but was quite impressive nonetheless!
7743−
7744−_David_ `~rapfyr-diglyt`, _Robert_ `~lodleb-ritrul`, and 23 students completed the first week of Hoon School. `~hadrud-lodsef` implemented automation for handling requests from the community. In the next few weeks we're looking forward to automating Urbit support, the Hoon School queue, and contributor onboarding, toward the end of allowing all of our community support systems to scale.
7745−
7746−_Anthony_ `~poldec-tonteg`, _Jared_ `~nidsut-tomdun`, and _Morgan_ `~hidrel-fabtel` made progress on a plan to upgrade our open-source development processes. We’re moving toward making Tlon’s work more public and making it easier for contributors to get involved. As a first step, we’ve assigned maintainers for each of our repositories, and both repository guidelines and a new proposal system are in the works. _Morgan_ `~hidrel-fabtel` also started working on re-implementing the website to make content updates and external contributions easier.
7747−
7748−Until next time.
7749−]]></content:encoded>
7750− </item>
7751− <item>
7752− <title><![CDATA[~2019.3.04 Update]]></title>
7753− <link>https://urbit.org/updates/2019-3-4-update</link>
7754− <guid>https://urbit.org/updates/2019-3-4-update</guid>
7755− <pubDate>Sun, 03 Mar 2019 00:00:00 GMT</pubDate>
7756− <content:encoded><
7760−
7761−## Network
7762−
7763−We breached successfully. You can read about [what we fixed](https://github.com/urbit/arvo/pull/1101). Issues ocassionally crop up as people join the network, but it looks to be smooth sailing as we make our way toward [cc-release](https://github.com/urbit/urbit/tree/cc-release) and new %ames.
7764−
7765−## `@p` Bug
7766−
7767−The nice folks behind [@urbitlive](https://twitter.com/urbitlive) discovered a bug in `@p` leading to planet name-collisions. Due to a subtly incorrect implementation of the cryptographic algorithm we use to scramble planet names – used to dissociate them from their parent stars – a small percentage of people with different Azimuth points could end up with the same planet name. For example:
7768−
7769−```
7770−> `@p`3.108.299.008
7771−~morlyd-mogmev
7772−> `@p`479.733.505
7773−~morlyd-mogmev
7774−```
7775−
7776−We [announced the bug on Twitter](https://twitter.com/urbit/status/1105850450559918082) today, and [a conversation](https://github.com/urbit/arvo/issues/1105) has been ongoing on GitHub. It appears we've settled on a solution, outlined in [this 3-line suggestion](https://github.com/urbit/arvo/issues/1105#issuecomment-472585937) from @max19, which elegantly corrects the implementation of the algorithm while preserving all existing planet names – a truly miraculous solution that came out of nowhere. Thank you Max!
7777−
7778−Stay tuned for a post with a full report.
7779−
7780−## Team
7781−
7782−_Jared_ `~nidsut-tomdun` spent the week on the `@p` debacle and more than once generated all four billion planet names to check for collisions. _Ted_ `~rovnys-ricfer` spent much of the week thinking about redesigning the PKI only to realize that the existing design is quite good. _Logan_ `~tacryt-socryp` and _Isaac_ `~novlud-padtyv` started working on the next major revision to Landscape. _Ben_ `~pitmug-roptic` quietly [started working on](https://github.com/urbit/urbit/pull/1221) 64-bit Vere. `~pilfer-pandex` [brought the hammer down](https://github.com/urbit/docs/pull/399#issuecomment-472667240) on the pronunciation debate.
7783−
7784−Tlon is at the beginning a new batch of work for 2019, so new proposals are popping up almost daily. _Morgan_ `~hidrel-fabtel` is working on revamping our proposal (“UP”) system so that the outside world can more easily participate in all of the work that’s going on. _Anthony_ `~poldec-tonteg` and _Jared_ `~nidsut-tomdun` are also working on standards for our repository documentation and open-source development process.
7785−
7786−## Community
7787−
7788−Our Austin meetup and San Francisco AMA were a blast. You can watch [the recording of the latter](https://www.youtube.com/watch?v=ndk2b69fA9A) on Youtube. Thank you for coming and for all of your questions!
7789−
7790−Out there on the Internet, people are starting to build their own platforms around Urbit and Azimuth. There are now multiple planet stores and at least one active online community. It's exciting to watch the community start to grow all by itself.
7791−
7792−Until next time.
7793−]]></content:encoded>
7794− </item>
7795− <item>
7796− <title><![CDATA[~2019.2.26 Network Update]]></title>
7797− <link>https://urbit.org/updates/2019-2-26-network-update</link>
7798− <guid>https://urbit.org/updates/2019-2-26-network-update</guid>
7799− <pubDate>Mon, 25 Feb 2019 00:00:00 GMT</pubDate>
7800− <content:encoded><
7802−
7803−## Toward a Permanent Network
7804−
7805−We conduct significant network upgrades to Arvo’s network protocol by “breaching” into discontinuous “eras.” Eventually, the network will reach a final era, after which no more major upgrades will be made. In the meantime, the network should be considered under test.
7806−
7807−We are currently in the third era since [launching Azimuth](/posts/essays/azimuth-is-on-chain) and much work lies ahead. We expect network instability and regular breaching throughout the next few months. If you’re using the network today: hang in there!
7808−
7809−## Recent Progress
7810−
7811−Some recent process improvements should accelerate the path to maturity. Arvo updates are now continuously integrated on `~zod`, Tlon’s galaxy, through which we distribute Arvo updates. Moreover, we’re working on an integration testing framework, tentatively named pH, that allows us to test across virtual networks of ships and dramatically improve debugging.
7812−
7813−## Getting Involved
7814−
7815−In the meantime, there are a few things you can do to get involved.
7816−
7817−### Get an Azimuth point
7818−
7819−We’re working on making the process smoother, but right now you can get an Aizimuth point from a friend. You can also generate your sigil using [sigil-js](https://github.com/urbit/sigil-js), or grab it from the Azimuth points metadata API.
7820−
7821−### Try Arvo
7822−
7823−Arvo isn’t ready for prime time, but you can definitely experiment with it. Follow the [Getting Started](/docs/getting-started) guide to boot a ship and access Landscape, our experimental messaging app.
7824−
7825−### Join Hoon School
7826−
7827−If you’re interested in learning how to write software for Urbit, we’ll be running online classes to teach the language, Hoon, and more in coming months. If you’re interested to join, [shoot us an email](mailto:support@urbit.org) and we’ll add you to the waitlist.
7828−]]></content:encoded>
7829− </item>
7830− <item>
7831− <title><![CDATA[~2019.2.25 Update]]></title>
7832− <link>https://urbit.org/updates/2019-2-25-update</link>
7833− <guid>https://urbit.org/updates/2019-2-25-update</guid>
7834− <pubDate>Sun, 24 Feb 2019 00:00:00 GMT</pubDate>
7835− <content:encoded><
7839−
7840−## Network
7841−
7842−The network remains frothy, but functional. Many connectivity issues have been resolved with a `|bonk` or simply by waiting.
7843−
7844−We published [Operating a Star](https://urbit.org/docs/getting-started/operating-a-star/) and founded a city for star operators. [Contact us](support@urbit.org) for access to the latter.
7845−
7846−Expect a breach next week. We’ll announce the date and instructions on [@zodisok](https://twitter.com/zodisok) once scheduled.
7847−
7848−## Team
7849−
7850−Work continues on _Elliot_'s `~littel-ponys` [lighter-than-eyre](https://github.com/urbit/urbit/tree/lighter-than-eyre) branch. _Ted_ `~rovnys-ricfer` made great strides toward the design for new `%ames`. Most notably, _Ben_ `~pitmug-roptic` got a [Nix](https://nixos.org/nix/) build working and [merged it](https://github.com/urbit/urbit/pull/1196) into the [cc-release](https://github.com/urbit/urbit/tree/cc-release) branch. Finally, support for push notifications is [coming along](https://github.com/urbit/urbit/pull/1203) thanks to _Logan_ `~tacryt-socryp`.
7851−
7852−## Community
7853−
7854−The Hoon School pilot begins Monday. We've received a lot of interest since announcing it last week and we can't wait to get started. [Contact us](mailto:support@urbit.org) if you want to be added to the waitlist for future iterations.
7855−
7856−If you're in Austin on March 8th, _Anthony_ `~poldec-tonteg` and _Alex_ `~mignyt-mogseb` are hosting [a meetup](https://www.meetup.com/urbit-sf/events/259307805/) at [Garage](https://www.garagetx.com/) from 5–7pm.
7857−
7858−In San Francisco on March 26th, _Galen_ `~ravmel-ropdyl` is speaking on [a panel](https://www.eventbrite.com/e/the-future-of-free-speech-online-registration-57429323653) hosted by [Lincoln Network](https://joinlincoln.org/) at [Galvanize](https://www.galvanize.com/campuses/san-francisco).
7859−]]></content:encoded>
7860− </item>
7861− <item>
7862− <title><![CDATA[~2019.2.11 Update]]></title>
7863− <link>https://urbit.org/updates/2019-2-11-update</link>
7864− <guid>https://urbit.org/updates/2019-2-11-update</guid>
7865− <pubDate>Sun, 10 Feb 2019 00:00:00 GMT</pubDate>
7866− <content:encoded><
7870−
7871−## Network
7872−
7873−The network has been frothy since [the transition](https://urbit.org/posts/essays/azimuth-is-on-chain/), with _Isaac_ `~novlud-padtyv`, _Joe_ `~master-morzod`, _Philip_ `~wicdev-wisryt`, _Ben_ `~pitmug-roptic`, and _Ted_ `~rovnys-ricfer` working non-stop to fix first memory and then `%ames` connectivity issues. Their efforts have paid off and we now appear to be sailing calm seas.
7874−
7875−If you haven’t booted into the new era, follow [Getting Started](https://urbit.org/docs/getting-started/) and feel free to `;join ~dopzod/urbit-help` if you need help or want to learn more about the system. See [Messaging](https://urbit.org/docs/learn/arvo/arvo-internals/messaging/) if you don’t know what that means.
7876−
7877−If you’re having connectivity issues, make sure you're running urbit 0.7.3, try updating again, [try this fix](https://twitter.com/zodisok/status/1096982801373491202), or if you're stumped, [let us know](mailto:support@urbit.org).
7878−
7879−To stay up to date on network status, follow [@zodisok](https://twitter.com/zodisok) on Twitter.
7880−
7881−## Team
7882−
7883−_Ted_ `~rovnys-ricfer` and _Joe_ `~master-morzod` got an `%ames` rewrite to compile and are working on documentation and unit tests. _Elliot_ `~littel-ponys` is rewriting `%eyre`, our webserver, which is some of the gnarliest code in Arvo. Outbound web requests are now working, which has allowed us to delete old `%eyre` from the [lighter-than-eyre branch](https://github.com/urbit/arvo/tree/lighter-than-eyre), and work continues porting individual `%gall` applications over to `%light`. We’re looking forward to moving Landscape onto new `%eyre` soon. _Logan_ `~tacryt-socryp` is rewriting the HTTP client in Vere (Arvo’s interpreter) to better support HTTP/2. This will allow us to provide push notifications in the heretofore rumored Landscape iOS app. Finally, _Gavin_ `ridlur-figbud` and _Jimmy_ `fallyn-balfus` are working on a new design system to enable fast UI prototyping. We’re very excited to share more about that in the near future!
7884−
7885−Shout-out to _Philip_ `wicdev-wisryt` for [this heroic weekend PR](https://github.com/urbit/arvo/pull/1072) that fixed persistent connectivity issues on the network after [Thursday’s breach](https://twitter.com/zodisok/status/1096225302210957312).
7886−
7887−## Media
7888−
7889−Palladium, a magazine on governance futurism, talk about Urbit through the second half of [Palladium Podcast Ep. 2](https://palladiummag.com/2019/02/18/palladium-podcast-ep-2/) in a conversation about their recently published article [Facebook’s Political Problems are Inherent to Centralized Social Media](https://palladiummag.com/2019/02/14/facebooks-political-problems-are-inherent-to-centralized-social-media/). Worth a listen.
7890−
7891−## Meetups
7892−
7893−If you're in San Francisco on March 1st, we're hosting [an AMA with Galen Wolfe-Pauly](https://www.meetup.com/urbit-sf/events/259144802/), Tlon's CEO.
7894−]]></content:encoded>
7895− </item>
7896− <item>
7897− <title><![CDATA[~2019.2.5 Update]]></title>
7898− <link>https://urbit.org/updates/2019-2-4-update</link>
7899− <guid>https://urbit.org/updates/2019-2-4-update</guid>
7900− <pubDate>Mon, 04 Feb 2019 00:00:00 GMT</pubDate>
7901− <content:encoded><
7905−
7906−Welcome to the other side. The Urbit PKI, Azimuth, now fully [migrated to the Ethereum blockchain](https://urbit.org/posts/essays/azimuth-is-on-chain/). This migration means that all address-space-holders have cryptographic ownership of their assets. The guide to getting on the network can be found [here](https://urbit.org/docs/getting-started/).
7907−
7908−Azimuth is one of three layers of the Urbit project, alongside _Arvo_ and _Aegean_. Arvo is the Urbit operating system. Aegean is something more abstract; a pattern for building “cities”: Urbit communities whose members run the same custom suite of software on their Arvo servers. Our [Primer](https://urbit.org/primer/) explains these concepts in depth.
7909−
7910−An integration of this size is not without its difficulties, though. ~zod labored mightily for a few days then `bail: meme`d (Arvo for “ran out of memory”). _Joe_ `~master-morzod`, _Ted_ `~rovnys-ricfer`, and _Isaac_ `~novlud-padtyv` discovered the problem: `~zod` had so many neighbors that Vere ran out of memory upon restart. [One fix](https://github.com/urbit/urbit/pull/1167) changed how Vere put header metadata on the event log, allowing it to be traversed both forwards and backwards, and [another fix](https://github.com/urbit/urbit/pull/1180) conserves memory by clearing the cache more often. A [third improvement](https://github.com/urbit/urbit/pull/1171) brings an important memory diagnostic tool, `|mass`, back to Arvo. Our champions breached the network to implement these changes, and problems seemed to be solved. _However_, they ran into new issues with event-playback, and they’ve been debugging that ever since.
7911−
7912−(There’s also a new Twitter account, [@zodisok](https://twitter.com/zodisok), that tweets out updates about `~zod`’s network status and any relevant pull-requests. It also provides a bit more insight into the challenges of building your own tools to maintain a network. Follow it to stay in the loop.)
7913−
7914−_Will_ `~hadrud-lodsef`, _Gavin_ `~ridlur-figbud`, and _Jared_ `~nidsut-tomdun` are making incremental changes to our Azimuth front-end, Bridge: UI fixes, new wallet support, adding conditional star-release capabilities for galaxies, and integrating a wallet-generator feature. The Bridge crew will try to implement these changes on a weekly schedule, and you can keep track of them in the Bridge repo’s new [CHANGELOG](https://github.com/urbit/bridge/blob/master/CHANGELOG) file.
7915−
7916−BONUS: _Mark_ `~palfun-foslup` aka The Dutch Destroyer decided that full bitcoinification was not happening fast enough for his liking and submitted a PR that added bitcoin rpc support to Arvo. Watch the demo [here](https://twitter.com/mdfang/status/1092171862178701313).
7917−
7918−See you next week.
7919−]]></content:encoded>
7920− </item>
7921− <item>
7922− <title><![CDATA[A Founder's Farewell]]></title>
7923− <link>https://urbit.org/blog/a-founders-farewell</link>
7924− <guid>https://urbit.org/blog/a-founders-farewell</guid>
7925− <pubDate>Sun, 13 Jan 2019 00:00:00 GMT</pubDate>
7926− <content:encoded><
7928−
7929−After 17 years, I've left the Urbit project.
7930−
7931−I've resigned as CTO, board member, and voting shareholder of
7932−Tlon (Urbit's corporate sponsor). I've also reassigned my
7933−personal galaxies to urbit.org (Urbit's embryonic foundation,
7934−still in Tlon's custody).
7935−
7936−My family still has a few thousand Urbit stars (in long timelock
7937−contracts), plus a nonvoting minority in Tlon. This isn't
7938−authority, just compensation: I have zero central power over
7939−either Urbit or Tlon. Nor will I contribute code to Urbit, nor
7940−write nor speak publicly about it. I am actually done here.
7941−
7942−From the very start, I knew Urbit could not succeed until it
7943−ceased to be mine and became the world's. Urbit works; its PKI
7944−is on the Ethereum mainnet; it's open source; in every way,
7945−technical, legal, and mathematical, it is the world's.
7946−
7947−(What _is_ Urbit? Please read the [primer](/primer).)
7948−
7949−Let's talk about: why I've left; the state of Tlon; and the state
7950−of Urbit. If there's any time left, we'll read some poetry.
7951−
7952−## Why I left
7953−
7954−No one had the power to fire me. (If anyone wanted to, they kept
7955−it to themselves.) I wanted to quit; I could; I should have; I did.
7956−
7957−I'm a thinker, not a doer; an explorer, not a leader; an author,
7958−not a maintainer. My goal was always to fire myself at the
7959−first possible opportunity. I'm super happy to reach it.
7960−
7961−Any creator is a sort of parent – where control is dependence,
7962−powerlessness is independence, and independence is victory.
7963−There are a lot of ways to light a fire. The last step is just
7964−getting out of the way – which must be done not too late, not
7965−too soon, and just right. No one can beat Satoshi in this act;
7966−anyone should be delighted to follow him.
7967−
7968−I worked full-time on Urbit, alone and self-funded, for eleven
7969−years. From 2002 to 2013, I wrote an end-to-end clean-slate
7970−system-software stack: an axiomatic interpreter that fits on a
7971−T-shirt, a typed functional language that doesn't use abstract
7972−math, and a purely functional operating system. I didn't patent
7973−any of this; I put it all in the public domain. (Not a valid
7974−open-source license; Urbit is now MIT licensed.)
7975−
7976−By 2013 I had a stack that worked well enough to make [a
7977−video](https://vimeo.com/75312418), then raise a 1.5M seed round. Urbit in 2013 was a
7978−working product – in fact, Urbit has had a live global network
7979−since November 2013. But in a new platform, the distance between
7980−_working_ and _compelling_ is nontrivial. Especially for a seed
7981−company with just a few young engineers, building something like
7982−nothing ever built before.
7983−
7984−Urbit in 2013 had roughly the same feature set as Slack in 2013,
7985−but less polished, and decentralized. It was pretty buggy and
7986−slow. But had we put all our resources into debugging and
7987−optimization, it would not have taken five years.
7988−
7989−My instinct was always that Urbit's delivery schedule should be
7990−as long as possible. For me, there are always two Urbits: the
7991−Urbit that exists, and the Urbit that should exist. To invent
7992−the latter I have to inhabit it. When I look at the present,
7993−I try as hard as possible to look at it from the perspective of
7994−the future – that's where my head should be.
7995−
7996−This always makes me think Urbit sucks. And the last thing you
7997−want to do is evangelize anything that sucks. This is a bias,
7998−but that doesn't make it wrong. For instance: the 2013 Urbit had
7999−a shell and a persistent distributed chat – but the shell was
8000−mixed in with the kernel, and the chat with the network protocol.
8001−As seen from the 2019 Urbit, this is very lame indeed.
8002−
8003−The conventional wisdom is to ship your embarrassing "MVP." For
8004−several reasons, Urbit occupies a unique strategic position.
8005−Urbit just isn't relevant until Urbit is, if not perfect,
8006−uniformly excellent. It can't just work. It has to work right.
8007−Urbit has to be amazing – which is hardly a useless discipline.
8008−
8009−I still did not think it would take five years to make Urbit
8010−work right – or to get the resources to make it work right
8011−(which only happened in 2018). But founders always delude
8012−themselves, or no one would do it.
8013−
8014−Urbit is not uniformly excellent quite yet. There are a few
8015−medium-sized cleanups in the near-term pipeline. But this is a
8016−matter of months, not years. I don't see any unknown unknowns.
8017−The adventure isn't over – but the exploration is over.
8018−
8019−A clean-slate system software stack, from fundamental interpreter
8020−to social network, through typed functional language and
8021−deterministic OS, is an enormous architectural journey – so
8022−long and winding that it's easy for anyone to get lost in any
8023−detail. Isn't that any explorer's first job: not getting lost?
8024−
8025−But once the route is marked, there is a second duty: getting out
8026−of the way. It's time for surveyors, not explorers, to map,
8027−measure and smooth every wrinkle on the map. That's how system
8028−software matures. Lines first ripped in one long slash are
8029−polished, straightened and refined across years and decades.
8030−
8031−And Urbit is too deep and interesting for one technical leader.
8032−Every part of it needs its own owner. But others can't build a
8033−real sense of ownership while the founder is still around. I'm
8034−not even the best engineer on the project; I just got here first.
8035−
8036−This codebase is very young and very general; there is a lot of
8037−fun left to be had with it; others deserve to have that fun.
8038−
8039−I have no successor as "BDFL." Technical leadership passes to
8040−Tlon as a company. Urbit is open source and anyone may play, but
8041−anyone who wants to catch up to Tlon still has a lot to learn.
8042−Not that that should stop them!
8043−
8044−I can't make Urbit technically transparent in one speech. But
8045−maybe I can shed a little light on the strategy, organization,
8046−history and future of the company and the project. It's easier
8047−to be frank on the way out.
8048−
8049−## Tlon, boiling oceans since 2013
8050−
8051−First of all: why did we do what we did?
8052−
8053−An ambitious system software project can inhabit one of four
8054−institutional forms: bigco, startup, academia, or community.
8055−
8056−None of these is a fit for a clean-slate system software stack.
8057−The startup is the least worst. I'd do it again.
8058−
8059−A normal startup lifecycle (Tlon actually got into YC, but
8060−declined – this was either cool or lame) looks nothing like a
8061−normal system-software lifecycle. Nor is Urbit normal. But
8062−while Silicon Valley is absurd, it still fits Marianne Moore's
8063−line: "with a perfect contempt for it, one discovers that there
8064−is in it after all a place for the genuine."
8065−
8066−The less said about big companies and big science, the better.
8067−But the choice between startup and community is interesting.
8068−Let's talk a little about why Tlon, this corporation, exists,
8069−then a little more about what it actually is.
8070−
8071−### Tlon, from cathedral to bazaar
8072−
8073−I used to think I could give Urbit directly to the world – that
8074−I could just post the code and an open-source community could
8075−take it from there. That'd probably work now, but it's not yet
8076−the right thing – and not because nobody wants a revolution.
8077−
8078−I've never been an open-source person myself. But the model has
8079−fascinated me since I encountered Nethack in the '80s. Now that
8080−open-source software is a mature field, we can see what kinds
8081−of problems the open-source "bazaar" mode is and isn't good at,
8082−versus the corporate "cathedral" mode.
8083−
8084−One problem open source isn't good at is creative collaboration
8085−on large and novel systems. For example, if we consider the set
8086−of people creating Google's new Fuchsia OS, and the set of people
8087−contributing npm modules, we see that it's almost impossible to
8088−imagine something like Fuchsia as a community effort – but this
8089−is not for lack of talent-hours. Imagine a bazaar creating a
8090−feature film, and you'll get the picture. (And Fuchsia seems
8091−like a fairly traditional OS.)
8092−
8093−Why is creative work so hard for bazaars? We could take this as
8094−an axiom – but it's worth understanding.
8095−
8096−The path from concept to product is an annealing process. Your
8097−code starts as a gas and ends as a metal. It must cool gradually
8098−under precise control. When parts cool too fast, flaws appear.
8099−Where flaws appear, the code must be reheated: ie, rewritten.
8100−
8101−Except for ASCII and a few algorithms, Nock, Hoon and Arvo didn't
8102−really rely on anything from 20th-century CS. We didn't drop any
8103−off-the-shelf parts into the oven; the whole stack is made from
8104−gas. So the code in Urbit has been rewritten at least once; the
8105−best code has been rewritten four or five times; perhaps some has
8106−been rewritten ten, fifteen, even twenty times.
8107−
8108−In 2002, I started out with no idea what I was doing. Urbit was
8109−interstellar vapor. I did have a decent grounding in 20th
8110−century CS, academic and practical. In the '90s I was a grad
8111−student in OS at Berkeley, then spent eight years on system
8112−software projects (a language, an OS and a browser) in industry.
8113−What I wanted, I did not know; what I knew, I did not want.
8114−
8115−In a long annealing process, it's important to triage the order
8116−in which you solve problems. There are three kinds of problems:
8117−problems you can't solve now, problems you don't have to solve
8118−now, and hard problems. Unless you postpone anything that isn't
8119−a hard but solvable problem, your gas will never turn into steel.
8120−There are lots and lots and lots of ways to go nowhere fast.
8121−
8122−Somehow it's 2019. Urbit is hot iron under the hammer. It is
8123−solid, but not yet hard. It has shape, but can yet be shaped.
8124−It is done, but ought to be finished. It is a sword; you don't
8125−want to get stabbed with it; it is not Excalibur, the blade to
8126−end all blades.
8127−
8128−The bazaar is great. But cathedrals still exist for a reason.
8129−The challenge for an ambitious system-software project is not
8130−whether to choose the cathedral or bazaar model, but when and
8131−how to transition from cathedral to bazaar.
8132−
8133−A cathedral – the same classic pyramid org-chart no doubt used
8134−by the builders of the actual pyramids, or the actual cathedrals
8135−– is economically less efficient than a bazaar. Why?
8136−
8137−Even on the world's most fun project, working for some dumb boss
8138−is no fun. The bazaar succeeds because the project extracts free
8139−labor from contributors – not by cheating them, but in exchange
8140−for fun, status, experience, etc. But mainly fun, honestly.
8141−
8142−Whereas a cathedral costs a giant ton of money. But in exchange,
8143−the cathedral gets _cohesion_ – the capacity for intelligent
8144−coordinated action. Bazaars can coordinate, but not easily.
8145−
8146−Because a cathedral can coordinate, a cathedral can _create_ –
8147−acting at a scale above individual action. A bazaar is very
8148−useful, but a bazaar does not create. It can grow; it can heal,
8149−harden, extend, and expand; but creation requires an individual
8150−or a coordinated group.
8151−
8152−But a bazaar can get a lot more done, a lot faster and a lot
8153−cheaper. So the right starting point for a bazaar is an existing
8154−system which is very clear, very final, and very simple. So any
8155−new system should be created by a cathedral and perfected by a
8156−bazaar. Since these institutions share little or no structure,
8157−the transition is by no means straightforward.
8158−
8159−### Tlon, just a little startup
8160−
8161−Tlon is Urbit's little corporate cathedral. It's about 20
8162−people, about 15 of them engineers. Everyone is working on
8163−Urbit, but not everyone is writing Hoon; there is client-side
8164−work, Ethereum work, etc.
8165−
8166−The team is comfortably funded and more than competent. One Tlon
8167−engineer is a 10-year, level 6 Google veteran; another is a YC
8168−alum; these people are great, but not really outliers. And not
8169−to be credentialist – there are plenty of dropouts, too.)
8170−
8171−Today, there's almost no part of the Urbit codebase that I still
8172−know better than anyone else. There are even design areas that
8173−others know better. When we transitioned from Nock 5 to Nock 4,
8174−all I contributed was a suggestion. The same for our Ethereum
8175−address collection, which our customers absolutely loved.
8176−
8177−Who's responsible for growing and maintaining this team? Who's
8178−the stone at at the top of the pyramid? Not me: if you gave me a
8179−goat to feed, the goat would die. The stone that holds the arch
8180−together is Tlon's CEO and my cofounder, Galen Wolfe-Pauly.
8181−
8182−Tlon was founded in 2013; Galen led it through its long seed
8183−stage, with only a few engineers, to 2018, when he finally
8184−secured the resources to do the project justice. (Although way
8185−too much of Tlon's energy in 2018 had to go into Ethereum.)
8186−
8187−Galen's previous project was the social meta-network Ost. He has
8188−an architecture degree from Cooper Union; he is a great designer,
8189−a good front-end engineer, and a pretty good surfer. (He also
8190−runs the @urbit Twitter.)
8191−
8192−Galen sets Tlon's product vision and is responsible for both
8193−visual appearance and human experience. Basically, Galen is the
8194−Steve Jobs of Urbit, with only two differences: Galen's not an
8195−asshole, and Steve wasn't short.
8196−
8197−Galen is joined in the new leadership team by Erik Newton
8198−(operations, legal) and Anthony Arroyo (product, engineering).
8199−Erik used to run a divorce-law firm and still is a relationship
8200−coach. Anthony was a grad student in comparative literature and
8201−managed engineering prototypes at Applied Minds.
8202−
8203−With my departure, Galen is in exclusive control of Tlon and
8204−holds the only board seat. Tlon did take seed funding from VCs.
8205−But outside investors have never held any management role.
8206−
8207−## Urbit, in the rear-view mirror
8208−
8209−Since I'm not going to talk about Urbit again, let me say a few
8210−words that might otherwise go unsaid.
8211−
8212−### Urbit, a level and neutral platform
8213−
8214−Urbit's distribution and sponsorship hierarchy of galaxies,
8215−stars and planets is _not_ designed as a political structure,
8216−or even a social structure. The actual social layer is in
8217−userspace -- one layer up.
8218−
8219−Socially and politically, Urbit is a flat network of planets.
8220−Galaxies and stars are plumbing. No one cares which star is your
8221−sponsor, any more than your Facebook friends care who your ISP
8222−is, or you care what data center Facebook is in.
8223−
8224−The sponsorship hierarchy and the senate of galaxies (which can
8225−amend Urbit's Ethereum constitution) are _technical_ governance
8226−mechanisms. They exist to react to unanticipated technical
8227−issues or conflicts (like denial-of-service attacks). Because
8228−sponsorship has an escape mechanism, it is not a _feudal_ bond
8229−(like your relationship to Facebook).
8230−
8231−Urbit is a decentralized network of social networks. No one can
8232−regulate it. Urbit is made to blossom into an endless garden
8233−of human cultures, each of which must regulate itself, none of
8234−which can bother the others. The soil in which these flowers
8235−grow must be level and neutral.
8236−
8237−### Urbit, anything but a fair distribution
8238−
8239−Who got those galaxies, anyway?
8240−
8241−Urbit has no mining mechanism and needs none. My model was: I
8242−own the whole space, since I made it; on the other hand, it's
8243−worthless until I find a way to give it away.
8244−
8245−In the end, I am probably the only individual with a fair amount
8246−of Urbit address space (no galaxies, a few percent of all stars).
8247−Tlon plus urbit.org also have about the right amount (slightly
8248−less than half). The rest are held by third parties – all of
8249−whom have either much more, or much less, than they deserve.
8250−
8251−But although the distribution of Urbit space was thoroughly
8252−unfair, it was always _honest_ and never _corrupt_. Everyone
8253−who has galaxies or stars did _something_ for Urbit. Some gave a
8254−lot of money, some gave a little; some contributed a lot of code,
8255−some just showed up. We paid a lawyer by bartering a pair. A
8256−bunch went to contest winners who solved a trivial Nock problem
8257−in 2010.
8258−
8259−What's unfair: the standards changed wildly across time. What's
8260−honest: they were always the same across _people_. Granted, you
8261−often had to be in the right place at the right time. This is
8262−another problem with life that we can't fix.
8263−
8264−Every real system of property is unfair. Who deserves to own
8265−Manhattan? Who does own it? If property be not unfair – if it
8266−is not the result of respecting past accidents – it is not
8267−property at all, but something else. I certainly would not do it
8268−this haphazardly again, but the outcome is no tragedy.
8269−
8270−When you live in Manhattan, you simply don't worry about who
8271−owns it or why; and nor does it matter. Are they Jews? Muslims?
8272−Christians? Communists? Italians? You don't care and you don't
8273−have to. You know it's basically random and probably unfair.
8274−Randomness, even blatant unfairness, creates a kind of neutral,
8275−peaceful, even promising urban anonymity.
8276−
8277−Property is always and everywhere a kind of amnesty. It says:
8278−whatever happened in the past, this is now what is. When we all
8279−agree that everyone has what they now have, however they got it,
8280−we have a formula for peace. When we say that everyone should
8281−have what they deserve, we can never expect everyone to agree –
8282−which means we have planted permanent seeds of discord.
8283−
8284−And randomness is a virtue – it disrupts hidden patterns. The
8285−galaxy owners include famous VCs and total nobodies; a Zen monk
8286−and a former Orthodox nun; a blockchain industry leader and a
8287−permaculture farmer. If they do have to all agree on something,
8288−they should have little to agree on but the truth.
8289−
8290−## Urbit, a technical report card (January 2019)
8291−
8292−As a system-software stack, the fundamental thesis of Urbit is
8293−that technical simplicity can flow all the way up to the top of
8294−the stack, where it becomes human usability. If we can build a
8295−purely functional OS, we can build a zero-maintenance server,
8296−which is easy to understand because how it works is simple.
8297−With this problem solved – nothing else matters.
8298−
8299−Unfortunately, I still have to give Urbit an "incomplete" here.
8300−No grade is available, because usability depends on a lot of
8301−fit-and-finish issues that are naturally back-loaded. I would
8302−still much rather run an Urbit ship than a Mastodon instance.
8303−But still, Urbit today can't quite promise zero maintenance.
8304−
8305−So we have to look at smaller indicators. One way to get anyone
8306−to grade their own work is to ask them for three ways they've
8307−succeeded, and three ways they've failed.
8308−
8309−### Urbit, three battles won
8310−
8311−I did once want to be a real computer scientist. Before my
8312−expulsion for sordid & disturbing behavior, I was once a
8313−19-year-old PhD student in CS at Berkeley. I even made an
8314−embarrassing bet with Raph Levien as to which of us would win the
8315−Turing Award – my money is definitely on Raph at this point.
8316−You can even go and read my Usenix '93 paper on ASLR-secured
8317−RPC, which won Best Student Paper and has like 50 citations.
8318−
8319−Well. That whole scene is a bad trip, kids. Avoid it. Also, if
8320−you start out as Rimbaud, you might end up as Lebowski. On the
8321−other hand, to have any excuse for boiling the ocean, you do have
8322−to make some serious CS problems just go away. Here are three.
8323−
8324−#### Validation
8325−
8326−20th-century languages underrate the centrality of communication
8327−to computing. Their type systems expect all data to live in a
8328−single memory forever. They don't consider data serialization
8329−and validation to be core competencies of a programming language.
8330−
8331−So serialization/validation is handled either ad hoc, or by
8332−intermediate data description systems which have inherent
8333−impedance mismatches with the language proper. Not only is work
8334−done over and over – but most network security breaches exploit
8335−seams in custom or complex deserialization and validation code.
8336−
8337−In Urbit there is one kind of data, a noun, which is an atom
8338−(unsigned integer) or a cell (ordered pair of nouns). There is
8339−one serialization model, which maps noun to atom to noun, in a
8340−page of code. And a type defines a set of nouns by defining a
8341−function of an arbitrary noun, whose range is that set – which
8342−means any data type is also its own data validation function.
8343−
8344−#### Idempotence
8345−
8346−20th-century computers have two brains: one fast and temporary,
8347−the other slow and permanent. When one of these two-brained
8348−computers hears a packet, and sends an acknowledgment, that only
8349−means the temporary brain heard it. Acks are not end-to-end
8350−transactions.
8351−
8352−This means you can't write a command protocol where your commands
8353−get executed exactly once. You can only choose "at least once"
8354−or "at most once." This problem is as ridiculous and frustrating
8355−as it sounds.
8356−
8357−You can address it in three ways: (a) make all your commands
8358−formally idempotent, so that repeating them has no additional
8359−effect; (b) insert a layer of stateful middleware — a message
8360−queue; (c) be fine with "almost always once." Guess which
8361−approach is most popular?
8362−
8363−Your Urbit ship has one permanent brain. Its acks are end-to-end
8364−transactions — no packet is acknowledged until all its direct
8365−effects are finalized. Every message channel is its own message
8366−queue. And every message is executed once.
8367−
8368−#### Dependencies
8369−
8370−20th-century languages are all at least vaguely based on a
8371−formalism from the '30s called the "lambda calculus." The
8372−fundamental operation in lambda calculus is variable reduction
8373−from name to value. So lambda languages all have a symbol table
8374−or environment which binds names to values.
8375−
8376−Modern build systems assemble large programs out of small files
8377−by reusing this symbol table for global function names, a process
8378−called "linking." Unfortunately, linking causes a problem known
8379−as "dependency hell," involving baffling, unpredictable upgrade
8380−failures. The fundamental problem is the "diamond dependency" —
8381−when a build requires two different versions of one symbol.
8382−
8383−Urbit does not use the lambda calculus, an environment or symbol
8384−table, or linking. Because it pushes name resolution out of the
8385−fundamental interpreter and up into the language, it can play
8386−many more namespace juggling tricks. And its build system has no
8387−trouble including multiple versions of the same library.
8388−
8389−### Urbit, three battles unwon
8390−
8391−As I mentioned earlier, triage is essential on any long journey.
8392−You have to keep moving forward, even when you have no idea where
8393−you're going – which means attacking the hardest problems you
8394−can solve right now.
8395−
8396−Unfortunately, this is a different standard than the usual rule
8397−for shipping a product: solve the most important problems first.
8398−This principle of triage is a general case of Knuth's apothegm
8399−against premature optimization. Urbit, in fact, was absurdly
8400−slow for a long time, but after a couple of engineer-months of
8401−focused optimization it seems fine now.
8402−
8403−But there are other areas where Urbit today is surprisingly weak.
8404−All look careless, but all are the result of careful triage.
8405−When you find a weakness due to triage, you may think you are
8406−judging Urbit's quality. You are just judging its maturity –
8407−which doesn't make your judgment wrong, of course.
8408−
8409−#### Opacity
8410−
8411−Urbit's notorious opacity is the problem that makes people
8412−complain the most. It's not an unwarranted complaint.
8413−
8414−At least, it's not all an unwarranted complaint. Part of the
8415−complaint is just about novelty. Novelty is of course inherent
8416−in any clean-slate stack. I do regret making 0 true and 1 false.
8417−On every other count, however, I offer all critics of Urbit's
8418−novelty none but the most vulgar gesture.
8419−
8420−But novelty is not the only problem. Urbit's external
8421−documentation has gotten much better in 2018 – in particular,
8422−it's now much easier to learn the language. Its _internal_
8423−documentation, and general code quality, remains at best poor to
8424−average. Worse: the worst code is the oldest, deepest code,
8425−which is also the most fundamental. Not only is it not
8426−commented, it is full of cryptic, meaningless names.
8427−
8428−There is now a new style guide, which should enable all reference
8429−documentation to migrate into the codebase. But this style guide
8430−is so new that none of the codebase complies with it. The guide
8431−demands "space-rated" code that documents every variable and
8432−every line – and almost none of the codebase is space-rated.
8433−
8434−Urbit's internal opacity persists for two reasons, one good and
8435−one bad. The bad reason is just laziness. The good reason is
8436−justified fear of _premature explanation_, which like premature
8437−optimization ruins the annealing process.
8438−
8439−When you don't know exactly what you're doing, preserve as much
8440−ambiguity as possible. For example, a name that means something
8441−is a commitment to one specific explanation; a name that means
8442−nothing is no commitment at all. A cryptic name is productive
8443−procrastination; it lets the hard problem of naming get solved
8444−later, and hence better.
8445−
8446−#### Impermanence
8447−
8448−Your Urbit ship needs to be _permanent_. That means it doesn't
8449−lose data, sink, or get wedged, or rot. It's not complicated.
8450−I wish Urbit today could make this promise, but it can't.
8451−
8452−There are are two problems here: short-term permanence and
8453−long-term permanence. Short-term permanence means your ship
8454−can't fail or lose data except via OS or hardware failure.
8455−Long-term permanence means you can put your ship on a USB stick
8456−in a box for 50 years, or 100, or 500, and when you turn it on
8457−in a modern interpreter it will upgrade itself and work fine.
8458−
8459−There aren't any significant structural obstacles to each of
8460−these milestones. But we can't claim them yet. We haven't
8461−really even worried about them. This is another triage case:
8462−in this case, the issue is _premature reliability_.
8463−
8464−Permanence also includes security. Except for the on-chain PKI,
8465−in which case you're trusting Ethereum, you shouldn't yet trust
8466−Urbit's security at all. Sorry!
8467−
8468−#### Duplication
8469−
8470−Triage can procrastinate in the other direction. It can skip
8471−problems that are too hard to solve. When you procrastinate,
8472−always come back – in this case, when the problem is easier.
8473−Here's one way Urbit has skipped a problem that was too hard.
8474−
8475−Urbit, as you may recall, is a single-level store. It has only
8476−one brain. And yet, we resisted the natural unification of
8477−_documents_ and _applications_ and _secrets_ that a one-brained
8478−computer obviously suggests.
8479−
8480−Instead, Urbit today is built more the Unix way (if not the
8481−Windows way). It has separate subsystems for tracking and
8482−updating these three kinds of data. This was my design. Like
8483−Urbit's opacity or impermanence, this was always obviously lame.
8484−
8485−Why do it the lame way? Because, before understanding the union
8486−of these problems, we had to understand each problem by itself.
8487−We didn't – not even close.
8488−
8489−No one else ever built a purely functional operating system. No
8490−one is going to go straight from zero to the right thing. You
8491−have to solve a hard problem, learn from it, and do it again.
8492−
8493−Now that the team has built and used the specialized subsystems,
8494−it's probably time to go ahead and generalize. The problem now
8495−strikes me as almost straightforward. The constraints are clear
8496−and so are the tools. None of this was true a year ago.
8497−
8498−On the low end, triage keeps you moving forward by stopping you
8499−from wasting time on easy problems. On the high end, triage
8500−keeps you moving forward by keeping you from leaping too far
8501−ahead, and falling down an impossible rathole.
8502−
8503−## Further reading
8504−
8505−What will I do personally? I'll spend more time with my kids.
8506−I'll finish reading my 1911 Britannica – I am only on the B's.
8507−I have no other long-term plans.
8508−
8509−But I won't be back to Urbit. I am leaving not just the project
8510−but the field – no less than Satoshi, or Everett, or Rimbaud.
8511−Will Satoshi weigh in on the next Bitcoin Cash fork? Did Rimbaud
8512−fly back from Ethiopia for his book-release tour? (Did anyone
8513−want him back?) It's not so bad to be a middle-aged Rimbaud.
8514−
8515−Is there more to say? Of course, but not in prose. Read
8516−Bunting's _Chomei at Toyama_ and _Notes on a Fly-Leaf_; Cavafy's
8517−_Il Gran Rifiuto_, Keeley & Sherrard translation; Canto XV of the
8518−Inferno, Pinsky translation. You might learn something.
8519−
8520−## Apologies and acknowledgments
8521−
8522−I apologize to anyone who has too little Urbit space. I refuse
8523−to guilt-trip anyone who has too much.
8524−
8525−I appreciate my friends by not naming them. I disarm my enemies
8526−by inviting them to lunch – but only if they come unarmed.
8527−
8528−I thank everyone who has ever worked on Urbit and everyone who
8529−will work on it in the future; our backers, great and small; my
8530−cofounder, Galen, and his family; my parents, wife and kids.
8531−]]></content:encoded>
8532− </item>
8533− <item>
8534− <title><![CDATA[Azimuth is On-Chain]]></title>
8535− <link>https://urbit.org/blog/azimuth-is-on-chain</link>
8536− <guid>https://urbit.org/blog/azimuth-is-on-chain</guid>
8537− <pubDate>Sun, 13 Jan 2019 00:00:00 GMT</pubDate>
8538− <content:encoded><
8540−
8541−The Urbit address space is now live on the Ethereum blockchain. We’re calling the PKI ‘Azimuth’ and you can find it at [`0x223c067f8cf28ae173ee5cafea60ca44c335fecb`](https://etherscan.io/address/0x223c067f8cf28ae173ee5cafea60ca44c335fecb) or [`azimuth.eth`](https://etherscan.io/address/azimuth.eth). Owners of Azimuth ‘points’ (galaxies, stars or planets) can use [Bridge](https://github.com/urbit/bridge/releases) to manage them and view their balance now.
8542−
8543−Sometime in the next few days, owners of Azimuth points will be able to boot Arvo, the Urbit OS, from their Azimuth point and request access to one of our 'cities': private communities for chat and discussion. These new cities use Landscape, a brand new UI for using Urbit in the browser.
8544−
8545−This means you can boot a deterministic OS from an identity you own, join a totally independent, decentralized and self-governing network and run a clean, simple UI. Pretty exciting. Is it ready for ordinary users? Definitely not.
8546−
8547−Since 2013, you've been able to boot an Urbit and join our test network. And, since 2013, we've always had our sights set on building a personal server that can both last 100 years and be delightful to use. Urbit isn't meant just to be as good as the MEGACORP software we use today. It's meant to be much, much better.
8548−
8549−But Urbit is not a 'product' in the conventional sense. Urbit is a public thing. It's meant to belong to everyone. For the past six years, much of our work was research and design work. Which means lots of weird ideas thrown away, and others rewritten or redesigned many times over. Our work has always been open source, but we tend to be pretty quiet about it.
8550−
8551−With Azimuth on the blockchain, it's time for us to start engaging with the world more directly.
8552−
8553−We aren't calling this a launch. There's no keynote. There's no dancing on stage. I mean, it's 2019. You must be pretty sick of being marketed to. We'll try to stick to the specifics here. What's new, what we've been up to and what works. There's too much to fit into a single post, so we'll keep it pretty light for now. Each of these sections will probably get its own post in the near future.
8554−
8555−> Note: As of `~2019.1.14` we're in the process of rebooting the Arvo network. We expect it to be back online before the end of the week. We'll update this post and [tweet](https://twitter.com/urbit) when the network is online and stable.
8556−
8557−## Rethinking the stack
8558−
8559−We've started to talk about Urbit as a stack of three parts: Azimuth, the address space and identity layer on Ethereum; Arvo, the OS and overlay network; and Aegean, a pattern for building decentralized communities on the Arvo network.
8560−
8561−We tried to capture this separation in [the primer](/primer), a new overview of Urbit. Explaining Urbit has always been challenging. A monolithic project that is OS, network, language, VM and UI barely makes sense. Separating the layers helps, we think.
8562−
8563−Let's step through them to see what's new.
8564−
8565−## Azimuth
8566−
8567−
8568−
8569−As a quick refresher: Urbit addresses, now called Azimuth 'points', are short names like `~diblun-tidduc`. You own your Azimuth point with a private key and can use it as a routable network address on the Arvo network. You can read more about Azimuth in [the primer](/primer#what-azimuth-is). If you're curious who owns all this address space, you can find that [in there too](/primer#azimuth-distribution).
8570−
8571−In late 2017 we decided to migrate the yet-to-be-named Azimuth to a system of Ethereum contracts. After a year of coding, testing, auditing and migrating — they're now fully deployed to the Ethereum mainnet.
8572−
8573−Azimuth is basically two parts, a database of who owns which points, and a set of rules about what points and their owners can do. That set of rules is called Ecliptic, and can be found at [`0x6ac07b7c4601b5ce11de8dfe6335b871c7c4dd4d`](https://etherscan.io/address/0x6ac07b7c4601b5ce11de8dfe6335b871c7c4dd4d) or [`ecliptic.eth`](https://etherscan.io/address/ecliptic.eth). The top-level Azimuth points, the galaxies, can vote on upgrades to the Ecliptic contract, but they can't edit the database of who owns what.
8574−
8575−The ownership database contract is called Azimuth, which you can find at [`0x223c067f8cf28ae173ee5cafea60ca44c335fecb`](https://etherscan.io/address/0x223c067f8cf28ae173ee5cafea60ca44c335fecb) or [`azimuth.eth`](https://etherscan.io/address/azimuth.eth). For those of you who own address space, you can use the `getOwnedPoints` function in the 'Read Contract' tab to check your balance. The function returns the number (not the phonemic string like `~ravmel-ropdyl`) of your points. Each Azimuth point is an ERC-721, non-fungible piece of digital property.
8576−
8577−To manage your points, we built [Bridge](https://github.com/urbit/bridge/releases), a completely custom interface for interacting with our Solidity contracts. Interface quality is really important to us, and we couldn't find anything in the 'crypto' world that met our standards. Bridge is good, but crypto UX is a hard problem. We've already got some ideas for improvements.
8578−
8579−If you're curious, you can find the source for the contracts in the [`urbit/azimuth`](https://github.com/urbit/azimuth) repo. The Bridge source is in the [`urbit/bridge`](https://github.com/urbit/bridge) repo.
8580−
8581−We had the source for our contracts audited by Open Zeppelin, Blockchain at Berkeley and Bloctrax. Did we miss something? We sure hope not — but we'd happily compensate anyone who can find bugs. Please reach out to security@urbit.org if you find something of concern. We'd be happy to hear from you.
8582−
8583−
8584−
8585−Azimuth names have always had a pronunciation system. `~ronryd-nidseg` is 13,695,781, for example. Now, they also have a visual system. We call these strange crests from another planet 'sigils', and you'll notice them used throughout all our new interfaces. You can find the source in the [`urbit/sigil-js`](https://github.com/urbit/sigil-js) repository. Building these was a lot of fun — we'll save the details for a future post.
8586−
8587−So, how do you get an Azimuth point? We've left that question unanswered intentionally. Azimuth points are meant to be like digital land, not currency. They should change hands slowly. In order to get an Azimuth point, you'll need to find someone who already has one and is willing to part with it.
8588−
8589−## Arvo
8590−
8591−
8592−
8593−Arvo boots from Ethereum, is no longer embarrassingly slow, and has a brand new build system. [Our documentation](https://urbit.org/docs/learn/arvo/hoon) has also improved quite a lot. Hoon, Arvo's programming language, has had a lot of work done to its type system and compiler. We built new tooling for generating static sites (you're probably reading this on one right now) that are much, much faster and easier to use.
8594−
8595−It's tough to talk about the progress we've made on Arvo without writing a long technical post. We'll save that for later. In a way, what's remarkable about Arvo is that it has become _less_ remarkable. It's more stable, faster, and the code quality has improved.
8596−
8597−There's plenty of work to do, though. Should you be building on top of Arvo? Probably not yet. The kernel and kernel modules are really where the work still lies. We build things on top of Arvo, and in doing so it's pretty clear that the system can be better. Clay (the filesystem) and Gall (the application model) are due for a rewrite. A complete rewrite of the web server, Eyre is almost finished.
8598−
8599−## Aegean
8600−
8601−
8602−
8603−Aegean is a pattern for building 'cities': groups of people running the same 'agent' on their Arvo servers. Agents aren't just 'apps' or programs. An agent rolls together the tools that a community needs. Today, our companies, communities, cults, cliques all have to duct tape together separate MEGACORP apps and services to compute together.
8604−
8605−Aegean reverses this pattern. A community on Arvo is a city: just a bunch of people running the same agent. Each city is in control of its own codebase: the interface, application code _and_ data storage. This means a community can have complete agency over how to compute together.
8606−
8607−Aegean cities can be completely different without impacting one another at all. Cities share the neutral infrastructure of Arvo and Azimuth — but they may never even know others exist. An archipelago of hypercultures.
8608−
8609−It's important to note: the pattern of these cities is _not_ the pattern of Azimuth. The network hierarchy should impact the society of Urbit as much as the electrical grid impacts the life of the street in Manhattan. It matters when the power goes out — but most of the time groups form and dissipate continuously.
8610−
8611−Before we can let the ocean of cities grow we have to homestead a few of our own.
8612−
8613−Our first agent is called [Landscape](https://github.com/urbit/urbit/tree/master/pkg/interface), an agent for chat and longform discussion. We are using Landscape to run a few experimental cities over the next month or so. If you have an Azimuth point, you'll need to [request access](mailto:support@urbit.org) to join.
8614−
8615−Anyone can create their own city, of course. The source is open. But we're not going to encourage you to just yet. Feel free to explore, but also be patient. We've got a lot planned around this. If Azimuth is done and Arvo is young, Aegean is just being born.
8616−
8617−## Tlon
8618−
8619−
8620−
8621−So who is behind all of this? A team of collaborators and contributors. Many of us work at [Tlon](https://tlon.io) — the company we started in 2013 to advance Urbit platform development. Tlon has attracted an incredible group of smart, talented people who want the world to be able to own and control their computers. I'm proud to work alongside them.
8622−
8623−One important omission on `tlon.io` is Curtis. As of today, he's no longer working on Urbit. [His own words](/posts/essays/a-founders-farewell) are the best way to understand his thinking. It's an achievement for the team, I think, that he can depart with confidence.
8624−
8625−One major reason for that confidence is that Erik and Anthony have now become COO and CPO respectively. Having thoughtful, organized people leading the project is a huge benefit to the whole team. I'm very glad to have them on board.
8626−
8627−## Looking ahead
8628−
8629−I certainly forgot at least a thing or two. We'll dive in to more detail in the coming weeks.
8630−
8631−There's a lot for you to explore. Have fun!
8632−]]></content:encoded>
8633− </item>
8634− <item>
8635− <title><![CDATA[Governance of urbit.org]]></title>
8636− <link>https://urbit.org/blog/governance-of-urbit</link>
8637− <guid>https://urbit.org/blog/governance-of-urbit</guid>
8638− <pubDate>Thu, 10 Jan 2019 00:00:00 GMT</pubDate>
8639− <content:encoded><
8641−
8642−## Summary
8643−
8644−Long before Urbit first appeared as a prototype in 2013, we considered Urbit address space to be property. Granted, Urbit property ownership was only reflected as a text file in a github repository – but it was always designed to be cryptographically owned, and we've always taken that file seriously.
8645−
8646−If you've ever looked at that text file, you've probably noticed that there has been a pool of Urbit assets there marked "urbit.org" since the beginning. Now that we're moving our property registry out of that repository and onto the Ethereum blockchain, we wanted to be as clear as we can be about what the plan is for those urbit.org addresses.
8647−
8648−The TL;DR is that "urbit.org" will likely split into a separate entity from Tlon in the future. For now though, Tlon and urbit.org have the same mandate, so separating them doesn't make sense. For the time being, Tlon will continue to manage and use urbit.org assets directly for platform development. As a first step toward making urbit.org independent we've started to develop a board of advisors who we hope will one day manage those assets independently.
8649−
8650−## Background
8651−
8652−The history of a few lines in a text file doesn't give a whole lot of context. So, first, let's fill in a few more of the details.
8653−
8654−In 2013 Curtis and Tlon each contributed 32 galaxies to a pool newly called "urbit.org." The idea at the time was to set aside address space to fund "platform development" – in the spirit of the IETF or the Mozilla foundation. This was long before anyone had heard of a Swiss blockchain foundation or anything of the sort. Our view was that it was going to take a lot of resources to build a system as robust and far reaching as Urbit intends to be, and 64 galaxies (25% of the total network) seemed sufficient. It was thought at the time that urbit.org might eventually take the form of a separate foundation, but we were simply too small and under-resourced a team to figure out the right legal structure at the time.
8655−
8656−Tlon – as distinct from urbit.org – has always been imagined as a future service provider in the urbit ecosystem. But Urbit is still young, so those services aren't really needed yet.
8657−
8658−Instead, what is needed is platform development. So Tlon has acted, in a way, as urbit.org was supposed to, by taking on the bulk of platform development efforts. This work consists of everything from kernel development to interface design and documentation. Tlon has sold (and granted) both its own galaxies, and some of those originally designated as urbit.org galaxies towards this end. We'll continue to do this for the foreseeable future, since Urbit's development needs (though finite) remain ongoing. We can't predict exactly how long this will continue, although we wish we could!
8659−
8660−## Future plans
8661−
8662−As Urbit becomes more widely used, we expect to make the Tlon/urbit.org separation real.
8663−
8664−We've considered the foundation model, but have come to the conclusion that it doesn't really make sense. For one, it's quite expensive in terms both of administrative overhead, and the associated legal costs. For another, there just isn't anyone we trust enough to take over high level management of such an organization (see Tezos). Finally, our view is that foundations are not entirely effective in their mandates (see [this article](https://nadiaeghbal.com/foundations) from our friend Nadia).
8665−
8666−One step we're pursuing is the creation of a board of advisors to guide our use of the urbit.org assets at Tlon. We're in discussions with several potential board members now. Our goal with this structure is to include more voices outside of Tlon in the process of governing the urbit.org assets, and to make their advice transparent to the public.
8667−
8668−As with all of our projects, we think it's better to walk before we run. For now, Tlon will continue to act as urbit.org and use both pools of resources for ongoing platform development. Next, we'll create a board to advise on the use of those resources. Eventually, Tlon and urbit.org will likely become separate entities. We'll get there – one step at a time.
8669−]]></content:encoded>
8670− </item>
8671− <item>
8672− <title><![CDATA[~2018.12.18 Update]]></title>
8673− <link>https://urbit.org/updates/2018-12-18-update</link>
8674− <guid>https://urbit.org/updates/2018-12-18-update</guid>
8675− <pubDate>Mon, 17 Dec 2018 00:00:00 GMT</pubDate>
8676− <content:encoded><
8680−
8681−With December comes a promise of the land going to sleep to awaken renewed. We
8682−at Tlon carry spirit of the season with us, even amid the perpetual 60-degree
8683−weather of San Francisco.
8684−
8685−The Urbit network has, indeed, been renewed. _Logan_ `~tacryt-socryp`
8686−performed a breach on the network, wiping the slate clean. All urbits must be
8687−booted again with their original tickets, which means that your crashed ships
8688−now have a second chance at life. If your ship is now experiencing connectivity
8689−troubles, don't worry: deleting your old pier should fix everything.
8690−
8691−On the infrastructure side, _Elliot_ the Wonderworker `~littel-ponnys` brought
8692−us a gift-sack of miraculous performance improvements. He started by fixing
8693−memory management, slashing the amount that is required to be pre-allocated for
8694−cells. Next, he found multiple places where the compiler was called
8695−unnecessarily, replacing such calls with less-expensive caching. Also redundant
8696−were many type-checker calls, which were squashed as well. Elliot _also_ updated
8697−the atom parser to remove a big chunk of latency from its operations. And, if
8698−that wasn't enough, he wrote new jets that shaved precious milliseconds from the
8699−web interface. Yes, five separate fixes, all of which add up to Urbit becoming
8700−much, _much_ faster. The once-characteristic CLI input lag is now almost
8701−imperceptible.
8702−
8703−_Morgan_ `~hidrel-fabtel` and _Jimmy_ `~haptyl-wanwes` are hard at work
8704−overhauling the site for the New Year, both in terms of web design and the
8705−presentation of content. The new website will also include Jimmy's primer,
8706−which neatly explains Urbit in layman's terms.
8707−
8708−The docs boys -- _Rob_ `~lodleb-ritrul`, _Josh_ `~taglux-nidsep`, and _David_
8709−`~rapfyr-diglyt` -- are helping out on this front. The documentation is being
8710−completely reorganized so that it's more accessible and less overwhelming. A
8711−great deal of new tutorial content will be included, and it's good enough that
8712−it might put a dent in Urbit's arcane reputation.
8713−
8714−And finally, rejoice! The great Ethereum address-space migration has begun!
8715−
8716−If you own address space, you should have received an email with instructions
8717−about how to register an Ethereum address with us so that we can grant you
8718−cryptographic ownership of your address space. If you haven't received an email
8719−a) check your spam folder and, if that doesn't work, b) send an email to
8720−[registration@urbit.org](mailto:registration@urbit.org).
8721−
8722−See you next week.
8723−]]></content:encoded>
8724− </item>
8725− <item>
8726− <title><![CDATA[~2018.11.20 Update]]></title>
8727− <link>https://urbit.org/updates/2018-11-20-update</link>
8728− <guid>https://urbit.org/updates/2018-11-20-update</guid>
8729− <pubDate>Mon, 19 Nov 2018 00:00:00 GMT</pubDate>
8730− <content:encoded><
8734−
8735−The dreams of the keys crew are finally escaping their heads. After months of
8736−excruciating reworking and fine-turning, _Will_ `~hadrud-lodsef`, _Gavin_
8737−`~ridlur-figbud`, _Morgan_ `~hidrel-fabtel`, and _Jimmy_ `~haptyl-wanwes`
8738−have completed the client-side tools for registering Ethereum addresses to
8739−receive and access their purchased ships. The registration process begins with
8740−the emails that we've begun to send out to ship-owners. The first batch has been
8741−sent, and the next batches will go out in the coming week. If you own address
8742−space, keep an eye out for an email from the urbit.org domain.
8743−
8744−Address registration points towards the real prize: the full ledger of Urbit
8745−ships nesting in the cozy, decentralized embrace of the Ethereum-based PKI. To
8746−this end, _Mark_ `~palfun-foslup` added some Ethereum-facing cryptographic
8747−functions [in the form of jets](https://github.com/urbit/urbit/pull/1028). And
8748−they do what exactly what jets are supposed to do: take things from "unusably
8749−slow" to "actually pretty good." This means that we can start deploying
8750−Constitution transactions.
8751−
8752−Performance isn't always a matter of engineering challenges being surmounted,
8753−though. Occasionally it's a matter of hearing the cracking of joints in
8754−something that's turning the wrong way. _Elliot_ `~littel-ponnys` felt something
8755−so ghastly: a 200-millisecond delay on every Ford build. So the search began.
8756−What was uncovered was two otherwise-benign lines that didn't get along with
8757−_Paul's_ `~fodwyt-ragful` recently merged Vere changes. Elliot handled the
8758−Arvo side, Paul charged the Vere flank, and the build-system bug was vanquished.
8759−
8760−Yes, Urbit is a mission fearsome and sprawling, but we at Tlon live for the
8761−hunt. Tearing up and replacing the entire stack just isn't enough, so we put our
8762−own, meticulous spin on the concept of a cryptocurrency wallet. The _Urbit
8763−Hierarchical Deterministic Wallet_ is a _system_ of related key-pairs that have
8764−distinct powers. That's because you want it to be easy to, say, authenticate
8765−packets without having to risk a chunk of your net worth. It's _deterministic_
8766−because key-pairs of a lower tier can be derived from those of a higher-tier,
8767−making the whole system a nice balance of usability and security. Sound cool?
8768−Check out the details in Tlon's
8769−[Urbit Proposal](https://fora.urbit.org/proposals/posts/~2018.11.8..19.31.59..ba77~/)
8770−on the matter.
8771−
8772−See you next week.
8773−]]></content:encoded>
8774− </item>
8775− <item>
8776− <title><![CDATA[~2018.11.6 Update]]></title>
8777− <link>https://urbit.org/updates/2018-11-6-update</link>
8778− <guid>https://urbit.org/updates/2018-11-6-update</guid>
8779− <pubDate>Mon, 05 Nov 2018 00:00:00 GMT</pubDate>
8780− <content:encoded><
8784−
8785−_Gavin_ `~ridlur-figbud`, _Will_ `~hadrud-lodsef`, and _Jimmy_ `~haptyl-wanwes`
8786−have been working tirelessly on the front-end tooling for bootstrapping our
8787−[PKI on Ethereum](https://urbit.org/blog/2017.9-eth/). The fruits of their labor
8788−are nearly ripe: all that's left is finalizing the copy and the documentation.
8789−
8790−_Philip_ `~wicdev-wisryt`, a powerful Hoonist, is making sure that the Arvo
8791−level of the stack is ready for the Great PKI Migration. Previously, every time
8792−a ship booted, it would need to process every Ethereum block all the way up to
8793−the present. This was _slow_, and we prefer life in the fast lane. So Philip
8794−souped up `%jael`, our keys vane. When a child boots now, its parent sends it a
8795−snapshot of the blockchain, rather than each individual event. And if we ever
8796−need to revert some events because of a chain reorganization, we can just
8797−restore an earlier snapshot instead of starting from scratch.
8798−
8799−Landscape is the charming, user-facing bow on the top of all of this, and it's
8800−just completed the first round of internal user-feedback testing. The entire
8801−company came together to raise interface hell, providing _Isaac_
8802−`~davtyr-nimren` and _Chris_ `~sigtus-hossyn` with a lot of useful data on the
8803−performance and reliability characteristics of the web-facing Arvo
8804−infrastructure, by way of the profiler in the Arvo interpreter.
8805−
8806−Pretty sweet.
8807−
8808−Or, _probably_ sweet. They tell you in college that it's never a compiler error,
8809−but some of the "interesting" results of our profiling may, in fact, be
8810−artifacts of a compiler error. _Ted_ `~rovnys-ricfer` and _Elliot_
8811−`~littel-ponnys` are spelunking the lowest depths of the stack, illuminating any
8812−profiler bugs with their combined brilliance. It's unlikely that our heroes will
8813−find any Balrogs, but you can never be too sure.
8814−
8815−It won't be long now, Martians.
8816−]]></content:encoded>
8817− </item>
8818− <item>
8819− <title><![CDATA[~2018.10.24 Update]]></title>
8820− <link>https://urbit.org/updates/2018-10-24-update</link>
8821− <guid>https://urbit.org/updates/2018-10-24-update</guid>
8822− <pubDate>Tue, 23 Oct 2018 00:00:00 GMT</pubDate>
8823− <content:encoded><
8827−
8828−The heroic efforts of _Mark_ `~palfun-foslup` have ensured that the Ethereum
8829−testnet Constitution is transacting properly, all in the face of the testnet
8830−itself encountering a consensus-failure bug. We can now test various pieces of
8831−our tooling and Urbit functionality against really existing blockchain state.
8832−
8833−On the Landscape side, _Logan_ `~tacryt-socryp` and _Chris_ `~sigtus-hossyn`
8834−finished integration between the mobile app and its desktop counterpart so that
8835−there is a QR-code pairing functionality. These interfaces are now in shape for
8836−internal testing.
8837−
8838−_Ted_ `~rovnys-ricfer` has brought important changes to our build system,
8839−Ford. The latest, fastest version of that system is titled Ford Fiesta, and
8840−it's shaping up to have all the Spartan utility that its name indicates: stack
8841−traces, new Ford-specific runes, and a parser for those runes. Ted also tweaked
8842−Clay and Gall so that they use Ford Fiesta for builds.
8843−
8844−In one of our cavernous basement labs, we've been poking away at a replacement
8845−for our beleagured HTTP server, `%eyre`. This new beast, dubbed `%light`, has
8846−benefited from the talents of _Elliot_ `~littel-ponnys`. A test version of this
8847−new vane can now hold a connection open and send a steady stream of HTTP data to
8848−the client. Big things have small beginnings...
8849−
8850−See you next week.
8851−]]></content:encoded>
8852− </item>
8853− <item>
8854− <title><![CDATA[~2018.10.12 Update]]></title>
8855− <link>https://urbit.org/updates/2018-10-12-update</link>
8856− <guid>https://urbit.org/updates/2018-10-12-update</guid>
8857− <pubDate>Thu, 11 Oct 2018 00:00:00 GMT</pubDate>
8858− <content:encoded><
8860−
8861−It's an exciting time here at Tlon.
8862−
8863−The Keys team is toiling to make the Urbit Wallet air-tight and foolproof. The
8864−Urbit Wallet, a cousin to the more typical cryptocurrency wallet, is an original
8865−system for securing cryptographic assets. It's original enough to demand its own
8866−Manual, a document that _Will_ `~hadrud-lodsef`, _Rob_ `~lodleb-ritrul`, and
8867−_Morgan_ `~hidrel-fabtel` are in the process of perfecting. The Wallet Manual
8868−will be a one-stop shop for information on using the Urbit Wallet system, both
8869−general concepts and technical details.
8870−
8871−Someone claiming to have solved a sufficiently large task with their first
8872−attempt is probably lying. The Keys team are an honest bunch, and they've
8873−decided to simplify our in-house wallet-generation software into something that
8874−produces one Urbit Wallet for each ship. That wallet generator provides secret
8875−keys to users in the form of PDFs, and these PDFs have been redesigned by
8876−_Gavin_ `~riglur-figbud` so that they are more informative and easier to
8877−organize.
8878−
8879−Gavin and _Jimmy_ `~fallyn-balfus` are designing the UI flows for software
8880−that takes the grief out of accessing your ships on the blockchain. This is
8881−distinct from the aforementioned wallet-generation software which helps you
8882−secure your ships on the blockchain, but we will soon to merge the two apps into
8883−a combined application known as Bridge.
8884−
8885−Our foreign correspondents are lending their talents to the Bridge mission.
8886−New Zealand's _Jared_ `~nidsut-tomdun` has been working on the attendant
8887−key-derivation library, and is also creating the library for displaying
8888−Urbit Wallet tickets as human-memorable strings. _Mark_ `~palfun-foslup`, our
8889−beloved Dutchman, worked with Jared to develop a JavaScript interface to the
8890−Urbit constitution.
8891−
8892−The infrastructure team has labored clanking towards the goal of making Vere
8893−less clanky. Two of _Paul's_ `~fodwyt-ragful` changes -- a custom-bytecode
8894−Nock interpreter and a new jet dashboard -- have been integrated, resulting in a
8895−faster and more robust Urbit. Nock itself was updated, too, with the notable
8896−addition being the Nock 12 "edit" operator. Paul, _Ted_ `~rovnys-ricfer`, and
8897−_Joe_ `~master-morzod` joined forces to make this happen, and borrowed our
8898−resident logician _Josh_ `~taglux-nidsep` from the docs team to check it for
8899−correctness.
8900−
8901−All of the above points to the big enchilada: using the Constitution as the
8902−address registry for the Urbit network. Mark has capped off this week's progress
8903−by booting the Urbit testnet (with all the new Landscape features) against an
8904−Ethereum testnet, so now we can do our best to break it. Things are about to get
8905−real.
8906−
8907−See you next week.
8908−]]></content:encoded>
8909− </item>
8910− <item>
8911− <title><![CDATA[~2018.9.11 Update]]></title>
8912− <link>https://urbit.org/updates/2018-9-11-update</link>
8913− <guid>https://urbit.org/updates/2018-9-11-update</guid>
8914− <pubDate>Mon, 10 Sep 2018 00:00:00 GMT</pubDate>
8915− <content:encoded><
8920−
8921−After much gnashing of teeth and abuse of git, we now have a
8922−[release candidate](https://github.com/urbit/arvo/tree/release-candidate)
8923−branch (NB run with the
8924−[correct](https://github.com/urbit/urbit/tree/release-candidate) vere branch).
8925−This branch brings together, for the first time, a few long-running
8926−lines of development. `%ford-turbo`, our new and improved [reactive build
8927−system](https://github.com/urbit/arvo/blob/release-candidate/sys/vane/ford.hoon),
8928−totally replaces `%old-ford` on this branch (take a look at those comments!).
8929−Proud papa _Joe_ `~master-morzod`
8930−[hard work](https://github.com/urbit/arvo/blob/release-candidate/app/acme.hoon)
8931−on HTTPS proxying is baked right in (meaning that ship.urbit.org is graduating
8932−from novelty to utility). `%jael` now actually [holds your
8933−secrets](https://github.com/urbit/arvo/blob/release-candidate/sys/vane/jael.hoon)
8934−and is being used to boot ships. _Curtis'_ `~sorreg-namtyv` swansong as the
8935−auteur behind `hoon` is now included (a crispy new styleguide is also in the
8936−works). Various niceties related to our new web ui are in here (_au revoir_ old
8937−Fora and Webtalk), as well as an actually existing
8938−[test](https://github.com/urbit/arvo/blob/release-candidate/gen/test.hoon)
8939−framework and all kinds of crypto goodies. This release candidate will get the
8940−testnet treatment for a little while, while we confirm that it's good enough for
8941−you, dear Martian.
8942−
8943−Much of the Infrastructure team is living the life of the fireman: making chili
8944−with your friends interspersed with someone yelling at you to put out a fire.
8945−Except, instead of making chili, _Ted_ `~rovnys-ricfer` is redesigning the Ford
8946−Rune language (why should `~sorreg-namtyv` get all the fun?) and _Elliot_
8947−`~littel-ponnys` is bringing `%eyre` into the new Millenium. _Mark_
8948−`~palfun-foslup` and _Joe_ `~master-morzod`, though, continue in their quest to
8949−make Ethereum safe for Martians and _Ben_ continues his grueling (for some value
8950−of gruel) pair programming regime with _Curtis_ `~sorreg-namtyv`.
8951−
8952−_Chris_ `~sigtus-hossyn`, _Isaac_ `~davtyr-nimren`, _Jimmy_ `~fallyn-balfus` and
8953−_Logan_ `~tacryt-socryp` continue refining our new web UI, Landscape. Fonts have
8954−been argued over, tables overturned over line heights. But it will all be worth
8955−it in the end.
8956−
8957−The Keys crew (_Will_ `~hadrud-lodsef`, _Morgan_ `~hidrel-fabtel` and _Gavin_
8958−`~ridlur-figbud`) are forming like Voltron to get our address space ported
8959−over and make sure that we can generate our HD wallets in a secure, usable
8960−way. They are joined by the newest edition to Tlon: _Jared_ `~nidsut-tomdun`.
8961−_Jared_ is down south New Zealand way, bringing Tlon ever closer to our goal of
8962−`%amesing` over the entire globe. Say `|hi`!
8963−
8964−Next year on Mars!
8965−]]></content:encoded>
8966− </item>
8967− <item>
8968− <title><![CDATA[~2018.8.30 Update]]></title>
8969− <link>https://urbit.org/updates/2018-8-30-update</link>
8970− <guid>https://urbit.org/updates/2018-8-30-update</guid>
8971− <pubDate>Wed, 29 Aug 2018 00:00:00 GMT</pubDate>
8972− <content:encoded><
8974−
8975−Here is a smattering of the exciting things going on at Tlon this week.
8976−
8977−Now that we know what the infrastructure for transferring our current
8978−property registry will look like, _Will_ `~hadrud-lodsef`, _Morgan_
8979−`~hidrel-fabtel` are getting the logistics in order. Primary to this is securely
8980−generating new keys and securely transferring existing assets. Since Tlon owns a
8981−_bit_ of address space, we're particularly interested in making sure this
8982−transfer goes down smoothly!
8983−
8984−The Landscape team has been busy integrating changes to Collections (our new
8985−concept for writing, reading and subscribing to static files... like this one!).
8986−Our very own Canadian visionary _Isaac_ `~davtyr-nimren` did a redesign recently
8987−that makes this system more general and takes advantage of the permissions in
8988−our file system, `%clay`.
8989−
8990−Of course, what kind of a square only chats from their desk? Don't most of us
8991−want to chat from our soylent-powered electric scooters as well? Luckily,
8992−wunderkinder _Logan_ `~tacryt-socryp` and _Jimmy_ `~haptyl-wanwes` have been
8993−grinding on Landscape mobile, including new features such as slick navigation
8994−an improved DM flow and, maybe most importantly, a QR-based device pairing flow.
8995−
8996−
8997−
8998−_Mark_, resident solidity jurist, is busy updating `%jael` (our vane for
8999−handling secrets) to accomodate our newest Constitution.
9000−
9001−_Joe_ `~master-morzod` is making good use of his time in the office to make
9002−everyone else feel unproductive. Not only is he the maestro behind the
9003−mergepocalypse that I mentioned last week, he is also finishing up work on
9004−booting a ship using a keypair generated by, you guessed it, the front end key
9005−tools mentioned above.
9006−
9007−Ford Turbo is getting a good work out from its integration with the updates we
9008−made to `%arvo` to accomodate Landscape. Dynamic duo _Ted_ `~rovnys-ricfer` and
9009−_Elliot_ `~littel-ponnys` are fixing these bugs and updating the test suite to
9010−account for these cases.
9011−
9012−Last but not least _David_ `~patpex_ponleg` joins the Docs crew. _David_ has
9013−experience teaching programming, and has even used Hoon in his classes. We're
9014−happy to have him help us teach the world to hoon. Come and say hi to him on
9015−`%talk`, or even better, ask him to help you with your hoon homework ;)
9016−
9017−Next year on Mars!
9018−]]></content:encoded>
9019− </item>
9020− <item>
9021− <title><![CDATA[~2018.8.23 Update]]></title>
9022− <link>https://urbit.org/updates/2018-8-23-update</link>
9023− <guid>https://urbit.org/updates/2018-8-23-update</guid>
9024− <pubDate>Wed, 22 Aug 2018 00:00:00 GMT</pubDate>
9025− <content:encoded><
9027−
9028−At Tlon, oars have been bent for some time towards getting the [Urbit PKI
9029−bootstrapped on Ethereum](https://urbit.org/blog/2017.9-eth/). Well:
9030−The end is in sight! We're not ones to curse an estimate with "dates," so let's
9031−say it's "forthcoming."
9032−
9033−This effort has spurred all kinds of updates to the system, most of which
9034−were long in the coming and all of which will have benefits far beyond the
9035−Ethereum roll out. We're excited to share them with y'all.
9036−
9037−We've finalized our suggested wallet derivation scheme. This was a monumental
9038−effort that included the expertise of a lot of different parts of Tlon,
9039−thanks to _Morgan_ `~hidrel-fabtel`, _Curtis_ `~sorreg-namtyv`, _Will_
9040−`~hadrud-lodsef` and _Mark_ `~palfun-foslup`! Look forward to a full public
9041−announcement of this derivation scheme once the audit has taken place.
9042−
9043−Now that that's all wrapped up, we are finalizing work on client-side tools
9044−for generating and decrypting these wallets in a usable way. _Gavin_
9045−`~ridlur-figbud` and _Will_ `~hadrud-lodsef` have been leading this effort, with
9046−a non-trivial wasm assist from _Chris_ `~sigtus-hossyn` and _Mark_
9047−`~palfun-foslup` (codenamed the Dutch Destroyer). We now have parity between the
9048−front end crypto tools and their Hoon-side cousins.
9049−
9050−A key part of this is also the Wallet application, which will allow you to
9051−manage your assets easily. _Morgan_ `~hidrel-fabtel` has changed the Wallet
9052−application architecture a bit to accommodate our wallet deriviation scheme and
9053−we're working on getting those changes implemented. _Robert_ `~lodleb-ritrul`
9054−is on loan from the Docs team to help us make sure that all of our documentation
9055−and copy around these tools is crystal clear.
9056−
9057−A thread connecting these projects is our concept of the Sigil, some of the
9058−cryptic shapes you may have seen gracing these very updates. An urbit ship is
9059−unique cryptographic property and a Sigil is the visual equivalent of your
9060−pronounceable shipname. Sigils will grace our applications for interacting
9061−with the Urbit Constitution, our new Landscape UI and many other places we've
9062−dreamt up. Work on these Sigils has reached a good point and we're working on
9063−integrating them into these applications.
9064−
9065−Webtalk is not long for this world, into the breach will step: Landscape.
9066−After a lot of prototyping and design iteration, we've settled on a feature
9067−set that will help the Urbit community (that's you!) communicate and
9068−collaborate to reach our next incarnation. Landscape will be on your computer
9069−and in your pocket. _Chris_ `~sigtus-hossyn` and _Jimmy_ `~haptyl-wanwes` have
9070−been hard at work hitting the details of the design implementation, including
9071−nuances like disconnected and reconnected states and other interaction concepts
9072−that we think you'll like. _Logan_ `~tacryt-socryp` has been doing double duty
9073−on Mobile and improving `%hall` support for DMs. Needless to say, Sigils are
9074−present throughout.
9075−
9076−
9077−
9078−What about Arvo, you say? Well, the latest news is a veritable supercollision
9079−of a merge between our various long running lines of work.
9080−[Ford Turbo](https://fora.urbit.org/proposals/posts/~2018.3.15..04.24.35..a47f~/),
9081−whose development you've all been following closely, is now in the process of
9082−being integrated with the rest of the our code, complete with not one but two
9083−caches (thanks _Ted_ `~rovnys-ricfer`). _Elliot_ `~littel-ponnys` is taking on
9084−the task of integrating Ford Turbo with various affordance we've added in
9085−support of Landscape. _Joe_ `~master-morzod`, meanwhile, is integrating updates
9086−to ames and the boot process occasioned by the Ethereum bootstrap. And finally,
9087−_Curtis'_ `~sorreg-namtyv` long-anticipated improvements to Hoon are being
9088−incorporated into all of the above.
9089−
9090−The last of these changes will be of particular interest to new learners of
9091−hoon, since one of their benefits is the ability to pretty print type
9092−information; a useful tool when working in the %dojo.
9093−
9094−_Josh_ `~taglux-nidsep` is closing out a revision of the docs to be released
9095−very soon. We hope that the new docs and friendlier Goon will make the task of
9096−learning Hoon less of a task and more of an adventure.
9097−
9098−Next year on Mars!
9099−]]></content:encoded>
9100− </item>
9101− <item>
9102− <title><![CDATA[~2018.8.8 Update]]></title>
9103− <link>https://urbit.org/updates/2018-8-8-update</link>
9104− <guid>https://urbit.org/updates/2018-8-8-update</guid>
9105− <pubDate>Tue, 07 Aug 2018 00:00:00 GMT</pubDate>
9106− <content:encoded><
9110−
9111−The Interface team spent another week completing the new Urbit frontend. _Gavin_
9112−`~ridlur-figbud` finished up his project for putting an image to your `@p`
9113−("pat-P") (image is teaser). _Galen_ `~ravmel-ropdyl` and _Jimmy_ `~haptyl-wanwes`
9114−did another round of design reviews for a couple of our interfaces. _Chris_
9115−`~sigtus-hossyn` implemented Landscape functionality to reconnect to your Urbit
9116−after a long period of disconnection (we _never_ leave `:talk`, so we of course
9117−wouldn't know about that). _Logan_ `~tacryt-socryp` fixed some more iOS bugs and
9118−implemented mobile in-app caching of Collections, making the app more
9119−feature-complete. _Isaac V_ `~davtyr-nimren` continued the Collections redesign
9120−(code [here](https://github.com/urbit/arvo/tree/collections-redesign)).
9121−
9122−The Infrastructure team put another week in forming a more perfect kernel. _Ted_
9123−`~rovnys-ricfer` continued bug hunting in his Ford Turbo cache implementation.
9124−_Elliot_ `~littel-ponnys` has Ford Turbo integrated with all of Arvo now, but
9125−some last steps are still needed to be able to fully remove old Ford from the
9126−system. You can find Ted and Elliot's code
9127−[here](https://github.com/urbit/arvo/branches/all?utf8=%E2%9C%93&query=ford-turbo),
9128−and their technical updates are posted to Fora
9129−[here](https://fora.urbit.org/proposals/posts/~2018.3.15..04.24.35..a47f~/).
9130−As Ford Turbo has approached completion, we've realized major performance
9131−bottlenecks in our Hoon compiler. So we've called upon _Paul_ `~fodwyt-ragful`
9132−to help make Hoon really fast. Ted's parallelism UP has also some gotten
9133−comments since it was posted last week -- check out the proposal
9134−[here](https://fora.urbit.org/proposals/posts/~2018.7.28..19.57.33..7ed3~/).
9135−
9136−The Keys team got us another week closer to getting on chain. _Joe_
9137−`~master-morzod` now has ships booting from the keys in our testnet contract.
9138−_Travis_ `~rigdyn-sondur` finished implementing our much-needed `secp256k1`
9139−crypto jet (code [here](https://github.com/urbit/secp256k1)). _Mark_
9140−`~palfun-foslup` nearly completed his `argon2-wasm` library for key
9141−generation/derivation. Our man _Chris_ `~sigtus-hossyn` is helping him integrate
9142−it with our other front end libraries (code [here](https://github.com/urbit/argon2-wasm)). _Anthony_ `~poldec-tonteg` and _Morgan_ `~hidrel-fabtel` are busy folding all of this new functionality into
9143−Urbit Wallet to help you manage your ships. _Robert_ `~lodleb-ritrul` is working
9144−on the copy for all of these apps, so that their functionality is crystal clear
9145−to users.
9146−
9147−Lastly: We're throwing a party next Friday, August 17th. Link: [meetup.com: Urbit IRL ~2018.8](https://www.meetup.com/urbit-sf/events/253292678/). Be there!
9148−
9149−See you on Talk, Martians.
9150−
9151−---
9152−
9153−Photo credit: Tlon
9154−]]></content:encoded>
9155− </item>
9156− <item>
9157− <title><![CDATA[~2018.7.30 Update]]></title>
9158− <link>https://urbit.org/updates/2018-7-30-update</link>
9159− <guid>https://urbit.org/updates/2018-7-30-update</guid>
9160− <pubDate>Sun, 29 Jul 2018 00:00:00 GMT</pubDate>
9161− <content:encoded><
9165−
9166−The Keys team worked more this past week on specifying and implementing the plan
9167−to get the Urbit constitution on the Ethereum blockchain. _Anthony_
9168−`~poldec-tonteg` and _Morgan_ `~hidrel-fabtel` have nearly completed updating
9169−the specification for Wallet. _Will_ `~hadrud-lodsef` and _Keaton_
9170−`~tonlur-sarret` have a better idea of how to create a smooth experience for
9171−current address-space holders to generate their Ethereum keys and get them to us
9172−to put in the contract. _Mark_ `~palfun-foslup` and _Travis_ `~rigdyn-sondur`
9173−spent the week implementing more crypto jets (code:
9174−[`urbit/argon2`](https://github.com/urbit/argon2)), and Mark is also working
9175−on an `argon2` WebAssembly library (code:
9176−[`urbit/argon2-wasm`](https://github.com/urbit/argon2-wasm)),
9177−which will help us generate private keys during onboarding. _Robert_
9178−`~lodleb-ritrul` is now working with us to write user documentation for all of
9179−the processes that will be part of our key generation and management
9180−applications. We can't wait for Urbit ownership to be cryptographically real.
9181−
9182−
9183−
9184−The Infrastructure team spent the week making the Urbit computer more beautiful.
9185−_Curtis_ `~sorreg-namtyv` worked more on Hoon improvements and started work on
9186−the Tlon-official Hoon style guide. _Ted_ `~rovnys-ricfer` and _Elliot_
9187−`~littel-ponnys` completed several Ford Turbo design changes and got all their
9188−tests passing again, now working on completing caching implementation and Eyre
9189−integration
9190−(code [here](https://github.com/urbit/arvo/branches/all?utf8=%E2%9C%93&query=ford-turbo),
9191−technical updates [here](https://fora.urbit.org/proposals/posts/~2018.3.15..04.24.35..a47f~/)).
9192−_Joe_ `~master-morzod` got full HTTPS support working on the testnet! Ted also
9193−wrote up a new UP on his thoughts on Urbit parallelism. Check that out [here](https://fora.urbit.org/proposals/posts/~2018.7.28..19.57.33..7ed3~/).
9194−
9195−The Interface team worked more on Landscape, our application to allow better
9196−communication and collaboration. _Galen_ `~ravmel-ropdyl`, _Gavin_
9197−`~ridlur-figbud`, and _Jimmy_ `~haptyl-wanwes` continued their iterative design
9198−revision feedback process, and Landscape is looking good. _Chris_ `~sigtus-hossyn`
9199−and _Logan_ `~tacryt-socryp` continued implementing the latest desktop/mobile
9200−features to get the product ready to ship, as well as extending support for the
9201−latest backend Landscape API's that _Isaac_ `~davtyr-nimren` has been improving.
9202−Urbit is becoming more usable by the day.
9203−
9204−Last but not least, the Documentation team continued doing `~zod`'s work helping
9205−teach Urbit to the world. _Josh_ `~taglux-nidsep` extended his new Hoon docs to cover Hoon cores, an introduction to the Hoon standard library, and a couple of Hoon examples with very detailed walkthrough commentary (drafts [here](https://github.com/joshuareagan/doc-drafts)). And _Robert_ `~lodleb-ritrul` extended the current Hoon-standard-library documentation on random atom generation and atom scrambling, as well as the Hoon cores for computing modular and signed-integer arithmetic (`urbit/docs` pull requests [here](https://github.com/urbit/docs/pulls)). Very soon you'll actually be able to understand how Urbit works.
9206−
9207−Also: we'll be hosting another party this month on Friday, August 17th. Save the date! Link: [meetup.com: Urbit IRL ~2018.8](https://www.meetup.com/urbit-sf/events/253292678/)
9208−
9209−Okay! Have a great week.
9210−
9211−---
9212−
9213−Photo credit: [Studio Olafur Eliasson](http://olafureliasson.net/)
9214−]]></content:encoded>
9215− </item>
9216− <item>
9217− <title><![CDATA[~2018.7.20 Update]]></title>
9218− <link>https://urbit.org/updates/2018-7-20-update</link>
9219− <guid>https://urbit.org/updates/2018-7-20-update</guid>
9220− <pubDate>Thu, 19 Jul 2018 00:00:00 GMT</pubDate>
9221− <content:encoded><
9225−
9226−The Keys team spent another week moving fast to get us on chain. _Anthony_
9227−`~poldec-tonteg` and _Morgan_ `~hidrel-fabtel` worked on a new design for
9228−Wallet, which will manage your Urbit address-space ownership. _Curtis_
9229−`~sorreg-namtyv` and _Mark_ `~palfun-foslup` fortified the Constitution more.
9230−_Will_ `~hadrud-lodsef` and _Keaton_ `~tonlur-sarret` worked to make sure that
9231−existing address-space owners can safely and easily register their ownership
9232−within the new system. More on this soon.
9233−
9234−The Infrastructure team was hard at work this week. _Joe_ `~master-morzod`
9235−merged much of his HTTPS work into the `collections` branch of Arvo and is onto
9236−broader Arvo integration testing (code [here](https://github.com/urbit/arvo/tree/collections)).
9237−_Ted_ `~rovnys-ricfer`
9238−and _Elliot_ `~littel-ponnys` cleaned up new Ford (code
9239−[here](https://github.com/urbit/arvo/branches/all?utf8=%E2%9C%93&query=ford-turbo)),
9240−trimming off several hundred lines
9241−of code and making it easier to reason about while staying within our desired
9242−performance goals. _Curtis_ `~sorreg-namtyv` finished the new implementation of
9243−the `?=` ("wut-tis") rune and designed the type analysis infrastructure for the
9244−new noun printer. _Mark_ `~palfun-foslup` produced an Urbit-specific variant of
9245−the Argon2 password-hashing function (code [here](https://github.com/urbit/argon2)).
9246−_Travis_ `~rigdyn-sondur`, an old friend of Tlon, has also been writing crypto
9247−jets this week, and those will go in the kernel soon.
9248−
9249−The Interface team has had another great week of making Urbit more usable.
9250−_Jimmy_ `~haptyl-wanwes` has been working on a new urbit.org, written in Sail.
9251−_Galen_ `~ravmel-ropdyl` and _Gavin_ `~ridlur-figbud` have been reviewing and
9252−finalizing some Landscape design edits and coordinating with the frontend team.
9253−_Chris_ `~sigtus-hossyn` and _Logan_ `~tacryt-socryp` have been implementing the
9254−updated designs on desktop and mobile and churning through issues. _Isaac_
9255−`~davtyr-nimren` worked on a better backend JSON interface for the Collections
9256−app and made sure that Collections is using all of the permissioning that Clay now offers.
9257−
9258−And the Documentation team continued their quest to teach the world Hoon. _Josh_
9259−`~taglux-nidsep` worked more on his new Hoon tutorials (drafts [here](https://github.com/joshuareagan/doc-drafts)).
9260−_Robert_ `~lodleb-ritrul` successfully documented the Hoon standard library cores
9261−for date/time and hashing (PR's [here](https://github.com/urbit/docs/pulls)).
9262−
9263−Keep on Hooning, Martians. See you in `/urbit-meta`.
9264−
9265−---
9266−
9267−Photo credit: [OMA](http://oma.eu/news/from-ciam-to-cyberspace-architecture-and-the-community)
9268−]]></content:encoded>
9269− </item>
9270− <item>
9271− <title><![CDATA[~2018.7.13 Update]]></title>
9272− <link>https://urbit.org/updates/2018-7-13-update</link>
9273− <guid>https://urbit.org/updates/2018-7-13-update</guid>
9274− <pubDate>Thu, 12 Jul 2018 00:00:00 GMT</pubDate>
9275− <content:encoded><>)
9284−
9285−
9286−
9287−The Infrastructure team -- _Curtis_ `~sorreg-namtyv`, _Anthony_ `~poldec-tonteg`, _Joe_ `~master-morzod`, _Ted_ `~rovnys-ricfer`, _Elliot_ `~littel-ponnys`, _Mark_ `~palfun-foslup` -- worked on improving the core of the Urbit system:
9288−
9289−- Curtis worked on improving Hoon: [`research-tome` Arvo](https://github.com/cgyarvin/arvo/tree/research-tome),
9290− [`research-tome` Vere](https://github.com/cgyarvin/urbit-1/tree/research-tome)
9291−- Joe continued to implement in-Urbit HTTPS integration: [`https-acme-wip`
9292− Arvo](https://github.com/urbit/arvo/tree/https-acme-wip), [`https-proxy-config`
9293− Vere](https://github.com/urbit/urbit/tree/https-proxy-config)
9294−- Ted and Elliot continued the state-machine reimplementation of new Ford: [`ford-turbo-state-machine`
9295− Arvo](https://github.com/urbit/arvo/tree/ford-turbo-state-machine),
9296− [updates](https://fora.urbit.org/proposals/posts/~2018.3.15..04.24.35..a47f~/)
9297−- Mark made crypto additions to the kernel: [`crypto-additions` Arvo](https://github.com/urbit/arvo/tree/crypto-additions)
9298−
9299−The documentation team -- _Josh_ `~taglux-nidsep` and _Robert_ `~lodleb-ritrul` --
9300−improved how we communicate how Urbit works:
9301−
9302−- Josh continued work on the new Hoon tutorials: [`master` doc drafts](https://github.com/joshuareagan/doc-drafts)
9303−- Robert put in more work improving the Hoon standard library doc: [docs pull
9304− requests](https://github.com/urbit/docs/pulls)
9305−
9306−The Interface team -- _Galen_ `~ravmel-ropdyl`, _Anthony_ `~poldec-tonteg`, _Jimmy_ `~haptyl-wanwes`, _Gavin_
9307−`~ridlur-figbud`, _Chris_ `~sigtus-hossyn`, _Isaac V_ `~davtyr-nimren`, _Logan_ `~tacryt-socryp`, and _Keaton_
9308−`~tonlur-sarret` -- worked on Landscape (formerly MVE):
9309−
9310−- Galen, Jimmy, and Gavin have continued work on Landscape's visual design
9311−- Keaton worked on Landscape cloud onboarding on DigitalOcean
9312−- Chris improved the desktop client, still in private alpha
9313−- Logan improved networking in the iOS TestFlight app, still in private alpha
9314−- Isaac V has been rearchitecting the Landscape backend
9315−- Anthony has been getting the latest Landscape code onto the testnet: [`testnet`
9316− Arvo](https://github.com/urbit/arvo/tree/testnet)
9317−
9318−The Constitution/Keys team -- _Mark_ `~palfun-foslup`, _Curtis_ `~sorreg-namtyv`, _Morgan_ `~hidrel-fabtel`, _Will_ `~hadrud-lodsef`, _Anthony_ `~poldec-tonteg`, and _Ben_ `~mirfet-hocbyt` -- worked to make Urbit computing cryptographically real:
9319−
9320−- Curtis, Morgan, and Will have been fortifying the current proposed key ceremony, still in private draft mode
9321−- Ben has been cleaning up Wallet: [`mercury` Wallet](https://github.com/urbit/etherwallet)
9322−- Mark has updated our Constitution to ERC721 compliance, among other updates, and built out more of Jael: [`master`
9323− Constitution](https://github.com/urbit/constitution) [`research-constitution`
9324− Arvo](https://github.com/Fang-/arvo/tree/research-constitution)
9325−
9326−We're alive and growing.
9327−
9328−---
9329−
9330−Photo credit: [Superstudio](https://en.wikipedia.org/wiki/Superstudio)
9331−]]></content:encoded>
9332− </item>
9333− <item>
9334− <title><![CDATA[~2018.7.3 Update]]></title>
9335− <link>https://urbit.org/updates/2018-7-3-update</link>
9336− <guid>https://urbit.org/updates/2018-7-3-update</guid>
9337− <pubDate>Mon, 02 Jul 2018 00:00:00 GMT</pubDate>
9338− <content:encoded><
9340−
9341−Here's a short update from the team at Tlon for the week of `~2018.7.2`
9342−
9343−The interface team -- _Galen_ `~ravmel-ropdyl`, _Jimmy_ `~haptyl-wanwes`, _Logan_
9344−`~tacryt-socryp`, _Gavin_ `~ridlur-figbud`, _Chris_ `~sigtus-hossyn`, _Anthony_
9345−`~poldec-tonteg`, and _Isaac V_ `~davtyr-nimren` -- worked more on MVE. Chris
9346−deployed a new _command palette_ for MVE to our internal testnet which we've been
9347−playing around with and are excited to ship soon. Isaac is re-architecting
9348−Collections a bit. Logan has been buffing up his read/unread code for Hall/Talk.
9349−The design team has been working for a while with our `@p` ship-naming scheme
9350−for a cool new thing. Gavin made this visualization program of the current `@p`
9351−syllables which we've been pretty entranced by:
9352−
9353−
9354−
9355−The constitution team -- _Mark_ `~palfun-foslup`, _Curtis_ `~sorreg-namtyv`,
9356−_Morgan_ `~hidrel-fabtel`, _Will_
9357−`~hadrud-lodsef`, _Anthony_ `~poldec-tonteg`, and _Ben_ `~mirfet-hocbyt` -- worked more on fortifying our summer
9358−key-ceremony gameplan. Mark completed a BIP32 key-derivation library in Arvo. Will has a solid outline for our ETH launch
9359−plan, which we're now getting some feedback on from our crypto nerd friends. Ben, Anthony, and Galen have been scheming a
9360−MyUrbitWallet redesign while we're still awaiting our final contract audits. Overall, everything here is coming together.
9361−The latest [constitution](https://github.com/urbit/constitution), [Urbit wallet](https://github.com/urbit/etherwallet),
9362−and [Arvo](https://github.com/Fang-/arvo/tree/research-constitution) code can all be found on GitHub. We're still a short
9363−while away from launching all of this, but we'll keep you posted.
9364−
9365−
9366−
9367−_Joe_ `~master-morzod` continued his HTTPS work, moving his development to an actual testnet to sort out the bugs
9368−entailed by generating LetsEncrypt certificates and dynamically changing server configs on running ships. In doing so,
9369−he's helped track down some of our gnarlier bugs (like [this one](https://github.com/urbit/arvo/issues/740)) and provided
9370−some more food for thought for the inevitable Gall and Eyre redesigns. He's also chipping away at a UP describing all
9371−this new, exciting functionality. We'll let you know when that comes out. Joe's
9372−[Vere](https://github.com/joemfb/urbit/branches) and [Arvo](https://github.com/joemfb/arvo/branches) work-in-progrsss is
9373−on GitHub.
9374−
9375−_Curtis_ `~sorreg-namtyv` worked mostly on internal Tlon things this week, but you might get a kick out of his current
9376−rendition of renamings for some of Hoon's symbols, pointed out in this recent Fora post: [_Symbol
9377−renaming_](https://fora.urbit.org/general/posts/~2018.7.2..01.08.03..c4af~/).
9378−
9379−_Ted_ `~rovnys-ricfer` and _Elliot_ `~littel-ponnys` continued work this week on new Ford. They've been hitting several
9380−frustrating bugs, and the code they had wasn't as easy to reason about as they were hoping. So to help tackle all this,
9381−they decided to start re-architecting parts of new Ford to track the statuses of builds with per-build state machines.
9382−This will entail a pretty significant reorganization of the `+ford-state` date structure, but they're confident this will
9383−simplify new Ford's semantics and help them get this project fully across the finish line. Ted and Elliot's latest
9384−work-in-progress can be found is [here](https://github.com/urbit/arvo/branches/all?utf8=%E2%9C%93&query=ford-turbo), and
9385−you can read their technical Fora updates [here](https://fora.urbit.org/proposals/posts/~2018.3.15..04.24.35..a47f~/).
9386−
9387−Finally, _Josh_ `~taglux-nidsep` and _Robert_ `~lodleb-ritrul` continue to strengthen our documentation. Josh is well
9388−into Chapter 2 of his new tutorials, and Rob has a couple new standard-library documentation sections which turned out to
9389−not be documented at all until now. Josh's in-progress work is [here](https://github.com/joshuareagan/doc-drafts); Rob's
9390−latest pull requests are [here](https://github.com/urbit/docs/pulls).
9391−
9392−And that's the way it is. Have a great week!
9393−]]></content:encoded>
9394− </item>
9395− <item>
9396− <title><![CDATA[~2018.6.21 Update]]></title>
9397− <link>https://urbit.org/updates/2018-6-21-update</link>
9398− <guid>https://urbit.org/updates/2018-6-21-update</guid>
9399− <pubDate>Wed, 20 Jun 2018 00:00:00 GMT</pubDate>
9400− <content:encoded><
9404−
9405−The interface team -- _Galen_ `~ravmel-ropdyl`, _Jimmy_ `~haptyl-wanwes`,
9406−_Gavin_ `~ridlur-figbud`, _Chris_ `~sigtus-hossyn`, _Anthony_ `~poldec-tonteg`, and _Isaac_ `~davtyr-nimren` -- worked
9407−more on MVE. We're getting incrementally closer to being able to release a public beta. Life has been active on the
9408−testnet as the team coordinates to fix the last known bugs and design issues.
9409−
9410−_Logan_ `~tacryt-socryp` noticed a lacking feature in Hall: read vs. unread messages, a common feature in most messaging
9411−applications. Logan decided to embark on his first real Hoon project and successfully implemented this last week. You can
9412−check out the code [here](https://github.com/loganallenc/arvo/tree/hall-unread), to be merged into MVE soon.
9413−
9414−The constitution team -- _Mark_ `~palfun-foslup`, _Curtis_ `~sorreg-namtyv`, _Morgan_ `~hidrel-fabtel`, _Will_
9415−`~hadrud-lodsef`, _Anthony_ `~poldec-tonteg`, and Texan _Ben_ `~mirfet-hocbyt` -- has been continuing to work to get us
9416−on chain by the end of the summer. Mark has been fortifying some of the contracts and Arvo-side cryptography and Jael
9417−functionality, while Ben and Anthony continue to finalize the control flow of our `MyUrbitWallet` fork. Curtis, Morgan,
9418−and Will are striding forward on designing the key-launch ceremony, more details of which we'll publish soon. The latest
9419−[constitution](https://github.com/urbit/constitution), [Urbit wallet](https://github.com/urbit/etherwallet), and
9420−[Arvo](https://github.com/Fang-/arvo/tree/research-constitution) code with the latest Jael work can all be found on
9421−GitHub.
9422−
9423−_Curtis_ `~sorreg-namtyv` worked more on Hoon, continuing to improve face-wrapping (variable naming) around values. He's
9424−also been working on a couple of new runes, like `^#`, whose designs aren't yet fully complete, but when they are, we'll
9425−document and share with y'all. Curtis' research [Arvo](https://github.com/cgyarvin/arvo/tree/research-tome) and
9426−[Vere](https://github.com/cgyarvin/urbit-1/tree/research-tome) code can be found on GitHub.
9427−
9428−_Joe_ `~master-morzod` worked more on HTTPS this past week and got some of his work merged into the `urbit/arvo`
9429−`collections` branch, which will go live with the MVE release. Included in the PR are new moves in Eyre and Ames to
9430−support his reverse TCP proxy, HTTPS server configuration changes, and child-ship IP address changes. Additionally added
9431−is a dynamic-DNS Gall app, which brings us closer to our envisioned ideal of getting `your-ship.urbit.org` to connect
9432−directly to your ship's IP address, rather than going through Tlon's intermediary proxying ships. Our next step is to
9433−deploy this to our internal testnet before releasing it into the wild. Joe's work can be found
9434−[here](https://github.com/urbit/arvo/pull/752) on GitHub -- very exciting.
9435−
9436−_Ted_ `~rovnys-ricfer` and _Elliot_ `~littel-ponnys` now nearly have a fully-integrated Ford Turbo. They can boot a ship
9437−with a Clay that exclusively uses Ford Turbo and not old, slow Ford. Gall integration is also complete. Now they're
9438−focused on finishing the caching implementation, as well as a new `%walk` schematic to perform a graph-search through the
9439−available marks for data conversion. Ted and Elliot's work is [here](https://github.com/urbit/arvo/tree/ford-turbo) on
9440−GitHub, and their more detailed updates are [here](https://fora.urbit.org/proposals/posts/~2018.3.15..04.24.35..a47f~/)
9441−as comments to their original Fora post.
9442−
9443−And last, but not least, _Josh_ `~taglux-nidsep` and _Robert_ `~lodleb-ritrul` have continued their much-needed
9444−doc-improvement work. Josh's in-progress drafts of his new Hoon tutorials are
9445−[here](https://github.com/joshuareagan/doc-drafts), and Rob's latest pull requests improving the standard library docs
9446−are [here](https://github.com/urbit/docs/pulls). If there's anything you feel should be documented and currently isn't,
9447−feel free to write us a comment below.
9448−
9449−May `~zod` be with you all. Have a great rest of your week.
9450−]]></content:encoded>
9451− </item>
9452− <item>
9453− <title><![CDATA[~2018.6.14 Update]]></title>
9454− <link>https://urbit.org/updates/2018-6-14-update</link>
9455− <guid>https://urbit.org/updates/2018-6-14-update</guid>
9456− <pubDate>Wed, 13 Jun 2018 00:00:00 GMT</pubDate>
9457− <content:encoded><
9461−
9462−_Ted_ `~rovnys-ricfer` and _J_ `~leb / ~ribben-donnyl` had a great time in Boulder, CO last week at LambdaConf 2018. Ted
9463−gave his same Ford talk he gave at the last meetup to a small group there. We should see the video recording of that
9464−published in a few months when the editing process is finished. J's talk on Hoon was a success. He posted to Fora this
9465−week with a link to his slides and talk turned into article form for Martian consumption. Check it out
9466−[here](https://fora.urbit.org/general/posts/~2018.6.10..19.25.23..6f16~/)!
9467−
9468−J also designed some [new T-shirts](https://urbit.threadless.com/). What a fan! We're working on designing some new
9469−official ones ourselves, but until then, feel free to score one of these.
9470−
9471−We breached again last Friday. People were hitting a [nasty Vere issue](https://github.com/urbit/urbit/issues/996)
9472−between versions from a breaking change, but breaching fixed it. We posted a short reminder of post-breach steps to Fora
9473−[here](https://fora.urbit.org/general/posts/~2018.6.9..08.37.48..f79a~/). Let us know if you're hitting any issues
9474−getting back up and running in the new continuity era.
9475−
9476−_Ted_ `~rovnys-ricfer` and _Elliot_ `~littel-ponnys` reunited this week after LambdaConf. Gall and Dojo on the
9477−`ford-turbo` branch now both use new Ford. Next up is Clay, in tandem with one big necessary algorithm change: adding
9478−support for the promotion of one-time builds, useful for things like generators. As usual, their code progress is
9479−[here](https://github.com/urbit/arvo/tree/ford-turbo).
9480−
9481−The interface team -- _Galen_ `~ravmel-ropdyl`, _Anthony_ `~poldec-tonteg`, _Jimmy_ `~haptyl-wanwes`, _Gavin_
9482−`~ridlur-figbud`, _Chris_ `~sigtus-hossyn`, _Isaac_ `~davtyr-nimren`, and _Logan_ `~tacryt-socryp` -- has commenced
9483−internal private alpha MVE testing on web and mobile. Our alpha Urbit iOS app is shipped to Apple's TestFlight, and we've
9484−all been having a blast testing it out on our phones. New web Talk in MVE even supports image display. We can't wait to
9485−ship this all soon -- just need to fix the last of bugs and design issues here and there first.
9486−
9487−
9488−
9489−_Curtis_ `~sorreg-namtyv` worked more on Hoon. He's been working on generalizing name binding by replacing `+toga` in
9490−`hoon.hoon` as part of the new Hoon doc integration. That work in progress is
9491−[here](https://github.com/cgyarvin/arvo/tree/research-tome). He's also been working on designing the "launch ceremony"
9492−for Urbit/Ethereum private keys with _Morgan_ `~hidrel-fabtel` and _Will_ for when we go on chain with our Urbit
9493−constitution on ETH very soon. We'll publish details about all of this once we've squared everything away.
9494−
9495−_Mark_ `~palfun-foslup` worked more on locking down the Urbit constitution by incorporating feedback from our audits and
9496−putting more safeguards around how address space is transferred. Martian soil is too valuable to be lost through a
9497−fat-fingered Ethereum transaction or, worse, malice! We've also been working with some contributors out Texas way to get
9498−our MyEtherWallet fork up to speed with the latest, greatest contract work. You can check out those changes
9499−[here](https://github.com/urbit/etherwallet/pull/29)
9500−
9501−_Joe_ `~master-morzod` is cranking away at setting up a reverse TCP proxy (and all of the associated machinery), so that
9502−we can scrap the Ames-based proxy currently done by ship.urbit.org and move over to real, live HTTPS termination for all
9503−ships. This is a major undertaking and has required `~master` to touch a lot of different parts of the system: Eyre,
9504−Vere, Ames -- you name it. Once his head is above water, he's going to write something up for us and tell us what he's
9505−seen in his wanderings through the system.
9506−
9507−And _Josh_ `~taglux-nidsep` and _Robert_ `~lodleb-ritrul` have spent yet another week making the docs more awesome.
9508−Josh's new Hoon tutorials (WIP link: [here](https://github.com/joshuareagan/doc-drafts)) are nearing completion. Rob
9509−opened up a couple more PR's improving the standard-library docs. You can check the latest `urbit/docs` pull requests
9510−[here](https://github.com/urbit/docs/pulls).
9511−
9512−There's also a third set of Hoon exercises which Josh posted to Fora
9513−[here](https://fora.urbit.org/answers/posts/~2018.6.7..20.54.43..2261~/). Give them a shot!
9514−
9515−No Mars Talk this week. Ted and Josh will return next week to talk about treaps, and where we're using them in Arvo.
9516−
9517−That's it for this week!
9518−]]></content:encoded>
9519− </item>
9520− <item>
9521− <title><![CDATA[~2018.6.6 Update]]></title>
9522− <link>https://urbit.org/updates/2018-6-6-update</link>
9523− <guid>https://urbit.org/updates/2018-6-6-update</guid>
9524− <pubDate>Tue, 05 Jun 2018 00:00:00 GMT</pubDate>
9525− <content:encoded><
9529−
9530−We hired somebody! We're happy to welcome to Tlon:
9531−
9532−- _Will_ `~hadrud-lodsef` -- Will studied CS at Stanford and worked for years in VC. Among other things, he likes
9533− ceramics and decentralized systems. He's going to work on a mix of things for us, from operations to Urbit private-key
9534− distribution and management.
9535−
9536−The interface team -- _Galen_ `~ravmel-ropdyl`, _Anthony_ `~poldec-tonteg`, _Isaac V_ `~davtyr-nimren`, _Jimmy_
9537−`~haptyl-wanwes`, _Chris_ `~sigtus-hossyn`, _Logan_ `~tacryt-socryp`, and _Gavin_ `~ridlur-figbud` -- is narrowing in on
9538−an alpha version of MVE, nearing readiness to start testing internally. Anthony and Isaac have been getting our internal
9539−testnet set up, and Logan is ready to submit our alpha iOS app to Apple's TestFlight. We'll keep you posted about public
9540−beta testing, on the way soon.
9541−
9542−_Isaac V_ `~davtyr-nimren` finished an [in-Urbit static-site generator](https://github.com/urbit/arvo/pull/745) this
9543−week. When merged, this will give you the option to easily host your urbit's static files through a production-ready Unix
9544−web server like Nginx in tandem with Arvo's web server, Eyre. This way, you can still host fast collections while we
9545−continue to work on Arvo's performance.
9546−
9547−_Ted_ `~rovnys-ricfer` has been at LambdaConf 2018 this week spreading the good news of `~zod` and
9548−non-lambda-calculus-based functional programming. Our good friend and galactic senator Justin LeBlanc `~leb` gave a talk,
9549−_Hoon and You - A Functional Programming Perspective_. Hopefully we can get slides and a video for you soon.
9550−
9551−_Elliot_ `~littel-ponnys` worked more on new Ford. It's now working as its own separate vane in the kernel, `%turbo`, and
9552−it reloads itself on Arvo `|reset`s and `|reload`s. While old `%ford` still exists, the next steps are to integrate
9553−`%turbo` with the rest of the system. Elliot has been working on a separate Dojo, _Dontjo_, that uses Turbo instead of
9554−old Ford. New Ford work is [here](https://github.com/urbit/arvo/tree/ford-turbo), and Fora updates are
9555−[here](https://fora.urbit.org/proposals/posts/~2018.3.15..04.24.35..a47f~/).
9556−
9557−_Mark_ `~palfun-foslup` has been wrapping up Urbit-on-ETH constitution work this week. We're just about in our final lap,
9558−finalizing our audit reports, fixing the last of known bugs, upgrading the contracts to latest Solidity and OpenZeppelin
9559−versions, and rounding our our test coverage, code comments and documentation, and ERC721 compliance. The latest contract
9560−code can be found [here](https://github.com/urbit/constitution). We'll come out with an official email blast and
9561−urbit.org post with more information when we're all ready to go.
9562−
9563−_Curtis_ `~sorreg-namtyv` has been working more on Hoon. Notably, one new change on the table is switching the model-arm
9564−rune from `+=` to `+$`, keeping it more in line with the `$` family of Hoon syntax relating to models. The feedback from
9565−the community in `/urbit-meta` on this was positive. Additionally, he's been rethinking the `+toga` data structure for
9566−dealing with faces (variable names) on Hoon values. His research branch is
9567−[here](https://github.com/cgyarvin/arvo/tree/research-tome). We'll have more to report next week.
9568−
9569−_Joe_ `~master-morzod` has been continuing work on the HTTPS project. Notably this week, Joe's been working on an
9570−in-Urbit reverse TCP proxy, so that planets behind private networks / NATs can still have their data served to
9571−`ship.urbit.org` via their star over Ames. With this last feature, in addition to Joe's mostly-completed `libh2o`,
9572−LetsEncrypt, and dynamic-DNS Gall-app implementations, the fast and secure direct `ship.urbit.org` feature of MVE should
9573−be primed to get tested into existence, then shipped. Joe's latest work-in-progress is
9574−[here](https://github.com/joemfb/arvo/tree/reverse-proxy-notification).
9575−
9576−_Josh_ `~taglux-nidsep` and _Robert_ `~lodleb-ritrul` blazed through more doc this week. Josh's [new Hoon
9577−tutorials](https://github.com/joshuareagan/doc-drafts) are starting to come together. Rob has been improving the
9578−standard-library docs and has open [several pull requests](https://github.com/urbit/docs/pulls), to be reviewed and
9579−merged this week. The docs are getting better.
9580−
9581−If you haven't already, give Josh's Hoon exercises a shot! (aka Hoon Bootcamp) You can find exercise set #1 on Fora
9582−[here](https://fora.urbit.org/answers/posts/~2018.5.24/) and set #2
9583−[here](https://fora.urbit.org/answers/posts/~2018.6.1/).
9584−
9585−With Ted out this week and Josh focused on doc work, they're going to push back Mars Talk to next week. So, look out for
9586−next week's update for the time and topic of Season 2, Episode 7.
9587−
9588−One last reminder: [_there is no Urbit ICO_](https://urbit.org/updates/2018.5.29-no-ico). Anything else that you've heard
9589−is wrong. Don't get scammed!
9590−
9591−We hope you've been enjoying these weekly updates, now [actually weekly](https://urbit.org/blog/weekly-updates/).
9592−`/urbit-meta` has been really active lately. Don't be shy to pop in and meet everybody.
9593−
9594−See you around!
9595−]]></content:encoded>
9596− </item>
9597− <item>
9598− <title><![CDATA[~2018.5.30 Update]]></title>
9599− <link>https://urbit.org/updates/2018-5-30-update</link>
9600− <guid>https://urbit.org/updates/2018-5-30-update</guid>
9601− <pubDate>Tue, 29 May 2018 00:00:00 GMT</pubDate>
9602− <content:encoded><
9606−
9607−We had a great meetup last Friday. Thanks to Ted for talking about Ford, Grayson and Morgan for DJing, and everyone for
9608−showing up! We'll keep you updated about the next one.
9609−
9610−We performed a [continuity breach](https://urbit.org/docs/using/admin/#-continuity-breaches) last week. This means that,
9611−if you haven't already, you need to recreate your urbit. The good news is: the network is faster, people are hanging out
9612−in in `/urbit-meta`, and a couple of infrastructure changes were made to make `urbit.org` authentication and proxying a
9613−bit more snappy. See [this post](https://fora.urbit.org/general/posts/~2018.5.26..03.57.28..7b26~/) for help getting set
9614−back up.
9615−
9616−_Curtis_ `~sorreg-namtyv` has been working more on data printing in Hoon. Still work-in-progress, the end result will
9617−have new, simpler ways to express Hoon types, data you want to print, helpful conversion arms accessible via the standard
9618−library, and a couple new runes. If you like deep language code and compiler internals, you can check out Curtis's
9619−research branch [here](https://github.com/cgyarvin/arvo/tree/research-tome).
9620−
9621−The interface team -- _Galen_ `~ravmel-ropdyl`, _Anthony_ `~poldec-tonteg`, _Logan_ `~tacryt-socryp`, _Chris_
9622−`~sigtus-hossyn`, _Jimmy_ `~haptyl-wanwes`, and _Gavin_ `~ridlur-figbud` -- has been working more on MVE. We'll have more
9623−to show in the next couple weeks.
9624−
9625−_Isaac V_ `~davtyr-nimren` worked on Arvo and Collections last week. He implemented a query parameter in Eyre to support
9626−setting the longpoll timeout duration manually, which solves an issue in the way of us doing background refreshes in our
9627−iOS app we're developing. He also got Clay permissions logic into Collections so that the tool will support read-only,
9628−write-only, and private/invite-only collections in addition to public ones. Lastly, Isaac's been working on a static-site
9629−generator in Urbit to support more performance-ready web serving over Nginx in tandem with Eyre. The first step was
9630−modifying Kiln to support batch-writing multiple files to Clay at once. Isaac's work-in-progress can be found
9631−[here](https://github.com/ixv/arvo/branches) -- check it out if you're looking to start hacking near the border between
9632−Arvo's interface and infrastructure.
9633−
9634−_Ted_ `~rovnys-ricfer` and _Elliot_ `~littel-ponnys` finished _all_ of the new Ford Turbo schematics (Ford build types)
9635−and a bunch more cranes (Ford runes). Their next step is to integrate new Ford with the current master kernel by loading
9636−it in as a separate vane, then incrementally connecting the wires needed for it to start working together with real Arvo.
9637−You can find Ted and Elliot's work [here](https://github.com/urbit/arvo/tree/ford-turbo). If you're into functional
9638−programming, build systems, or just want to read the best Hoon code we have on display currently, check it out, and the
9639−updates they've been posting to their Urbit Proposal
9640−[here](https://fora.urbit.org/proposals/posts/~2018.3.15..04.24.35..a47f~).
9641−
9642−_Mark_ `~palfun-foslup` worked on Jael, Urbit's new secret-storage vane, which we're also expanding to include the logic
9643−for querying the state of the [Urbit consitution](https://github.com/urbit/constitution) which will go live on the
9644−Ethereum blockchain in the coming months. Mark has been implementing the necessary Arvo `+gift`s and `+task`s of Jael's
9645−to properly interface with the Urbit constitution via the Ethereum API, then update the local urbit's state of the land
9646−registry and other contract data so that it can use it for networking and in other services. You can find Mark's
9647−work-in-progress [here](https://github.com/Fang-/arvo/tree/research-constitution). Check it out if you're excited by
9648−blockchains, or also just want to see what good, documented Hoon code looks like.
9649−
9650−_Joe_ `~master-morzod` worked more on the HTTPS project. This week was mostly about refactoring the existing code by
9651−adding comments, renaming some things, and improving the style. Safe to say that when this project is done, we think it
9652−will be understandable. The ASN1 and PKCS libraries are mostly complete; progress will continue to finish up the last of
9653−the libraries and necessary styling, then integrate this into current Arvo/Vere. Joe's work-in-progress is
9654−[here](https://github.com/joemfb/arvo/tree/acme-wip).
9655−
9656−_Josh_ `~taglux-nidsep` and _Robert_ `~lodleb-ritrul` made a bunch more progress on the docs. Josh has been adding more
9657−to his [new WIP Hoon tutorials](https://github.com/joshuareagan/doc-drafts), and both Josh and Rob have gifted us with
9658−several [pull requests](https://github.com/urbit/docs/pulls) documenting the simple but elusive `=,` rune and refactoring
9659−much of the existing standard library doc. The docs are a great place to start learning and contributing. [Check them
9660−out](https://github.com/urbit/docs) on GitHub, and [submit an issue](https://github.com/urbit/docs/issues), tagging Josh
9661−and Rob, if you're confused by anything, or think something is documented wrong.
9662−
9663−Josh and Ted also did a [Mars Talk](https://www.youtube.com/watch?v=IgQo5aSezK4) this week -- Season 2, Episode 6 -- to
9664−help people get started with Hoon. They went through some simple onboarding steps and basic math functions to introduce
9665−some of the fundamental concepts in Hoon. If you're new to Hoon and not sure where to start, check out that episode, and
9666−feel free to leave comments below here for feedback.
9667−
9668−Overall, work continues to wipe the slate of computing clean. More news next week.
9669−]]></content:encoded>
9670− </item>
9671− <item>
9672− <title><![CDATA[There is no Urbit ICO]]></title>
9673− <link>https://urbit.org/updates/2018-5-29-update</link>
9674− <guid>https://urbit.org/updates/2018-5-29-update</guid>
9675− <pubDate>Mon, 28 May 2018 00:00:00 GMT</pubDate>
9676− <content:encoded><.
9682−Accept no substitutes!
9683−]]></content:encoded>
9684− </item>
9685− <item>
9686− <title><![CDATA[~2018.5.23 Update]]></title>
9687− <link>https://urbit.org/updates/2018-5-23-update</link>
9688− <guid>https://urbit.org/updates/2018-5-23-update</guid>
9689− <pubDate>Tue, 22 May 2018 00:00:00 GMT</pubDate>
9690− <content:encoded><
9694−
9695−We're hosting a meetup [this Friday](https://www.meetup.com/urbit-sf/events/250889557/) at the SF office. Ted will give a
9696−quick update on new Ford, and then it'll be time to relax, listen to music (our friend Grayson will be playing records),
9697−and talk IRL. Feel free to bring your laptop, and we'll install Urbit for you and give you a tour of Arvo.
9698−
9699−This week, the interface team -- _Galen_ `~ravmel-ropdyl`, _Gavin_ `~ridlur-figbud`, _Jimmy_ `~haptyl-wanwes`, _Chris_
9700−`~sigtus-hossyn`, _Isaac V_ `~davtyr-nimren`, _Logan_ `~tacryt-socryp`, and _Anthony_ `~poldec-tonteg` -- has continued
9701−building the new Arvo frontend. Here's a teaser of something the desktop guys have been working on:
9702−
9703−
9704−
9705−_Joe_ `~master-morzod` fixed an important performance issue in Vere where galaxy IP resolution has been happening
9706−synchronously. This now works asynchronously, which should help take some load off of our stars. He also got support for
9707−`/.well-known/*` LetsEncrypt paths working in Eyre and refactored a lot of parsing and cryptography code in Arvo as part
9708−of his HTTPS-implementation work on his [personal WIP Arvo fork](https://github.com/joemfb/arvo/tree/acme-wip), to be
9709−brought onto master soon.
9710−
9711−_Keaton_ `~tonlur-sarret` got a demo AMI (Amazon Machine Image) working on Amazon Web Services with the Urbit binary
9712−pre-installed, avoiding the need for the user to manually build from source. He plans on documenting this more and
9713−working on a clean-slate onboarding system with _Morgan_ `~hidrel-fabtel` for our summer MVE release. But for now,
9714−consider this a proof-of-concept for one way to get an Urbit running in the cloud more easily. You can follow the short
9715−bulleted steps [here](https://gist.github.com/keatondunsford/8c19bc232650ec1adbb9b6c38954cd90) to get up and running .
9716−
9717−_Ted_ `~rovnys-ricfer` and _Elliot_ `~littel-ponnys` are getting their new beautiful build system closer to the finish
9718−line. New Ford supports nearly all of the functionality laid out in the original [Urbit
9719−Proposal](https://fora.urbit.org/proposals/posts/~2018.3.15..04.24.35..a47f~/) and passes all current tests. This past
9720−week, Ted and Elliot have implemented more schematics and a bunch of the `+cranes`, or Ford runes. If you're into build
9721−systems, check out their more detailed updates they've been posting as comments to the UP.
9722−
9723−_Mark_ `~palfun-foslup` has been working on getting the Urbit/ETH integration logic into Jael, Arvo's new secret-storage
9724−vane, to go live in the summer MVE release. Part of this is implementing direct support for querying the Ethereum
9725−blockchain for the state of the the Urbit constitution smart contract. In this model, Urbit ships can choose to either
9726−get this state directly from their parent stars or galaxies, or they can query the blockchain themselves. An important
9727−step towards making Urbit address-space ownership real, Mark's work-in-progress can be found
9728−[here](https://github.com/Fang-/arvo/tree/research-constitution).
9729−
9730−_Josh_ `~taglux-nidsep` and _Robert_ `~lodleb-ritrul` have been continuing to do ~zod's work to improve the state of the
9731−Urbit documentation. Josh has been writing a [new Hoon tutorial series](https://github.com/joshuareagan/doc-drafts) to
9732−supersede the current Urbytes, while Robert has been blazing a trail through the current standard library docs, making
9733−sure they're up-to-date and [improving them](https://github.com/urbit/docs/tree/rmariani-patch-6) as he goes. There's
9734−been a lot of activity on GitHub recently. Don't be shy: [submit your first docs pull
9735−request](https://github.com/urbit/docs), a classic rite of passage for the neophyte Hoon programmer.
9736−
9737−Lastly, Josh, Ted, and Keaton will be live on Mars Talk tomorrow night, Wednesday at 8:30PM PST. We'll post the Hangouts
9738−link in Talk. Tune in!
9739−
9740−Overall, summer is getting closer, and we're excited about the work that's getting done. More this week.
9741−
9742−See you on Friday!
9743−]]></content:encoded>
9744− </item>
9745− <item>
9746− <title><![CDATA[~2018.5.16 Update]]></title>
9747− <link>https://urbit.org/updates/2018-5-16-update</link>
9748− <guid>https://urbit.org/updates/2018-5-16-update</guid>
9749− <pubDate>Tue, 15 May 2018 00:00:00 GMT</pubDate>
9750− <content:encoded><, _Anthony_ `~poldec-tonteg`, _Joshua_ `~taglux-nidsep`, _Ted_ `~rovnys-ricfer`, and _Keaton_ `~tonlur-sarret` talked about Sail, a DSL for representing XML/HTML data in Hoon. We built a simple web page with Sail and highlighted what features Sail gives you, like Hoon's type system, the Ford build system, and full access to Hoon programming inline. Check it out!
9756−
9757−Tlon hired someone this week! We're excited to have with us:
9758−
9759−- _Isaac V_ `~davtyr-nimren`
9760−
9761−Isaac has solid Hoon and frontend chops, having already implemented server-side rendering of Tree pages for us a short while back. He'll be taking on some of the Collections/Streams work to help us get ready for our summer release.
9762−
9763−_Galen_ `~ravmel-ropdyl`, _Anthony_ `~poldec-tonteg`, _Chris_ `~sigtus-hossyn`, _Gavin_ `~ridlur-figbud`, and _Jimmy_ `~haptyl-wanwes` have been working more on the new interface projects. Here's another leak:
9764−
9765−
9766−
9767−_Logan_ `~tacryt-socryp` almost has a complete demo of the new Urbit iOS app working. This includes TouchID login authentication, an encrypted local database, full support for the Talk/Hall API for Streams, and automatic background fetching, among other features.
9768−
9769−_Curtis_ `~sorreg-namtyv` has been working more on several important major language feature improvements to Hoon: namely, pretty-printing of typed data, and simplifying the type system. Work can be found on his [research branches](https://github.com/cgyarvin/arvo), but we plan on publishing a more formal post of the changes and major documentation updates when they roll out in the coming months. More soon!
9770−
9771−_Ted_ `~rovnys-ricfer` and _Elliot_ `~littel-ponnys` have made a bunch of progress on Ford Turbo. In addition to having a proof-of-concept solution for the main performance bottleneck of current Ford, they've now finished writing over half of the schematics (build types), implemented proper cache reclamation support, and they've gotten basic Clay integration functioning properly. You can find their work [here](https://github.com/urbit/arvo/tree/ford-turbo). They're posting more detailed updates as comments to their original [Urbit Proposal](https://fora.urbit.org/proposals/posts/~2018.3.15..04.24.35..a47f~/).
9772−
9773−_Mark_ `~palfun-foslup` has been wrapping up Urbit/ETH integration, and is now working on getting Jael, the new Arvo secret-storage vane, to compile. This would be a great addition to the summer release.
9774−
9775−_Joshua_ `~taglux-nidsep`, _Robert_ `~lodleb-ritrul`, and _Keaton_ `~tonlur-sarret` have been getting lots of
9776−documentation work done. They've seen several PR's go through to improve the Hoon standard library docs, simplify the
9777−Hoon demo, update our examples to the latest syntax, improve the Urbit installation process, and more. Josh's
9778−work-in-progress is happening [here](https://github.com/joshuareagan/doc-drafts/). The main docs are [on
9779−GitHub](https://github.com/urbit/docs): if there's a piece of doc that's confusing to you, don't hesitate to file an
9780−issue. Or better, submit a pull request.
9781−
9782−_Joe_ `~master-morzod` is making strides on full HTTPS support for individual ships. He's implemented LetsEncrypt
9783−support, ASN.1, and has Dynamic DNS functioning on our testnet. When all this work is done, `your-ship.urbit.org` should
9784−connect automatically to the IP of the Unix machine your urbit is running on, rather than connecting to one of Tlon's
9785−ships, which currently proxies Urbit network data through one of our stars, is slow, and is basically a straight-up
9786−man-in-the-middle. Combined with private Collections and Streams, Urbit will be a lot more secure and usable within the
9787−year.
9788−
9789−Overall, we're making progress. More next week!
9790−]]></content:encoded>
9791− </item>
9792− <item>
9793− <title><![CDATA[~2018.4.14 Update]]></title>
9794− <link>https://urbit.org/updates/2018-4-14-update</link>
9795− <guid>https://urbit.org/updates/2018-4-14-update</guid>
9796− <pubDate>Fri, 13 Apr 2018 00:00:00 GMT</pubDate>
9797− <content:encoded><. He's going to help us make
9805− Urbit easier.
9806−- _Logan_ `~tacryt-socryp` - Logan is going to build us a mobile app, work on which has already begun! Very exciting,
9807− indeed.
9808−
9809−_Ted_ `~rovnys-ricfer` and _Elliot_ `~littel-ponnys` have been working more on [new
9810−Ford](https://fora.urbit.org/proposals/posts/~2018.3.15..04.24.35..a47f~/). They turbocharged the `+execute` algorithm to
9811−use a worklist data structure. This will not only be simpler to reason about, but in the future, it will allow future
9812−support for parallelization of builds at the Vere level in MapReduce fashion. Their work is on
9813−[GitHub](https://github.com/urbit/arvo/tree/ford-turbo).
9814−
9815−_Curtis_ `~sorreg-namtyv` has been working hard to make Hoon's type system less confusing, as well as working on the
9816−problem of data inspection in Hoon. Now that his "structure-to-type" code is mostly done (going from an abstract type
9817−definition to its real compiled internal representation), he'll soon be done with his "type-to-structure" reverse
9818−converter for getting abstract structure data out of any sets of values. More soon, but all of this will supersede the
9819−current mold system and help make Hoon easier to understand, we think.
9820−
9821−_Galen_ `~ravmel-ropdyl`, _Anton_ `~pittyp-datfyn`, _Jimmy_ `~haptyl-wanwes`, _Gavin_ `~ridlur-figbud`, _Chris_
9822−`~sigtus-hossyn`, and _Logan_ `~tacryt-socryp` have been putting in more hard work on the new Urbit frontend. It's all
9823−coming together really nicely, and things seem to be on schedule for a big mid-to-late summer release.
9824−
9825−We haven't posted an obscure graphic in a while. Here's one for the update to tide you over:
9826−
9827−
9828−
9829−What it's for is totally top secret.
9830−
9831−_Keaton_ `~tonlur-sarret` deployed sections to Fora, which will help categorize discussion content better and lead to better curation of StackOverflow-like questions and Urbit Proposals (UPs). He also merged some important pull requests into the system and deployed them to the network.
9832−
9833−_Mikolaj_ `~ponmep-litsem`'s contributor work on moving Vere from Make to the [Meson](https://github.com/mesonbuild/meson) build system was merged this week. This solves several issues with bundling of dependencies, as well as making binary builds generally faster. Great work!
9834−
9835−_Joe_ `~master-morzod` got his [HTTP pull request](https://github.com/urbit/urbit/pull/942) finally merged, which rewrites Vere's HTTP client and server to use the `h2o` library. This is great, as it will allow for full TLS termination in Urbit, which sets us up for full HTTPS connections to direct IP addresses of Urbit ships at `your-ship.urbit.org`, to be fully implemented soon.
9836−
9837−_Robert_ `~lodleb-ritrul` has made a number of helpful PR's to the [Urbit docs](https://github.com/urbit/docs).
9838−
9839−_Mark_ `~palfun-foslup` worked more on the Urbit constitution and put out some important fires caused by code-update syncs over the network and type mismatches. Computers are hard!
9840−
9841−_Joshua_ `~taglux-nidsep`, Ted, Keaton, and Joe went on [Mars Talk](https://www.youtube.com/watch?v=EZKNLcdRbE0) to discuss the Facebook data scandal, the greater battle for privacy and personal computing, and Urbit's role in all of this. We think it turned out great.
9842−
9843−All in all, life has been good over here. Now it's time for a good weekend. See you all on the network!
9844−]]></content:encoded>
9845− </item>
9846− <item>
9847− <title><![CDATA[~2018.4.7 Update]]></title>
9848− <link>https://urbit.org/updates/2018-4-7-update</link>
9849− <guid>https://urbit.org/updates/2018-4-7-update</guid>
9850− <pubDate>Fri, 06 Apr 2018 00:00:00 GMT</pubDate>
9851− <content:encoded>< at our San Francisco office this Sunday. Come, bring your laptop, and we'll get you started building things in Urbit's language -- Hoon.
9855−
9856−Tlon has brought on two new interns! We're excited to have with us:
9857−
9858−- _Gavin_ `~ridlur-figbud` - Gavin's going to help us with some promising frontend design projects.
9859−- _Robert_ `~lodleb-ritrul` - Robert's going to work with us on revamping our documentation, examples, and blog, writing
9860− high-quality original content. He has submitted several pull requests to the docs already this week, which have been
9861− merged.
9862−
9863−_Galen_ `~ravmel-ropdyl`, _Anton_ `~pittyp-datfyn`, _Chris_ `~sigtus-hossyn`, and _Jimmy_ `~haptyl-wanwes` have been
9864−continuing to advance the state of the new Urbit frontend.
9865−
9866−_Mark_ `~palfun-foslup` has been working hard with _Curtis_ `~sorreg-namtyv` to bring the Urbit constitution into its
9867−final, launchable state. He believes it's ready for its final security audit, which keeps us on track to launch it this
9868−summer. You can find the latest contract code [here](https://github.com/urbit/constitution).
9869−
9870−_Ted_ `~rovnys-ricfer` and _Elliot_ `~littel-ponnys` have assembled a basic prototype of the main engine of the new Ford
9871−redesign. They've been improving the design as they go, posting updates as comments to the [original Fora
9872−post](https://fora.urbit.org/posts/~2018.3.15..04.24.35..a47f~/). Their code can be found
9873−[here](https://github.com/urbit/arvo/tree/ford-turbo).
9874−
9875−Lastly, big shoutout to _Mikolaj_ `~ponmep-litsem` for his work on [Plato](http://plato.urbitetorbi.org:8080/plato.html),
9876−which now allows remote Hoon code execution without logging in. This is a big step towards improving our developer
9877−onboarding, as it will allow newcomers to experience interactive Urbit programming in the browser quickly without having
9878−to wait to boot their own ship. See Mikolaj's original thread on GitHub [here](https://github.com/urbit/docs/issues/239).
9879−
9880−We look forward to teaching some of you this Sunday the beginnings of the art of Martian functional programming. To all
9881−else, we'll see you on the network. Have a great weekend, everybody!
9882−]]></content:encoded>
9883− </item>
9884− <item>
9885− <title><![CDATA[~2018.3.24 Update]]></title>
9886− <link>https://urbit.org/updates/2018-3-24-update</link>
9887− <guid>https://urbit.org/updates/2018-3-24-update</guid>
9888− <pubDate>Fri, 23 Mar 2018 00:00:00 GMT</pubDate>
9889− <content:encoded>< at the Tlon office. It's a party.
9901−Morgan is DJing. Galen's showing Beat Takeshi movies on the back wall. Bring your laptop, and we can write Fizzbuzz in
9902−Hoon together. Or just relax, have some drinks, and talk to the weird array of people who also want to replace the
9903−internet.
9904−
9905−_Curtis_ `~sorreg-namtyv` is in the Netherlands this week visiting _Mark_ `~palfun-foslup`. They're self-auditing the
9906−last parts of the [Urbit Constitution](https://github.com/urbit/constitution). While sitting in Gatwick Airport, Curtis
9907−also wrote up some ideas he's been thinking about. Check out these essay drafts, posted to Fora:
9908−
9909−- [The Urbit public record draft](https://fora.urbit.org/posts/~2018.3.23..03.42.41..ab6d~)
9910−- [Spirit and practice of digital homecoming draft](https://fora.urbit.org/posts/~2018.3.22..19.46.35..3499~)
9911−
9912−_Galen_ `~ravmel-ropdyl`, _Anton_ `~pittyp-datfyn`, _Chris_ `~sigtus-hossyn`, _Jimmy_ `~haptyl-wanwes`, and _Anthony_
9913−`~poldec-tonteg` have been working more on the new Urbit frontend.
9914−
9915−_Ted_ `~rovnys-ricfer`, _Elliot_ `~littel-ponnys`, and _Keaton_ `~tonlur-sarret` authored and published an Urbit Proposal
9916−(UP) on New Ford:
9917−
9918−- [UP 4 - Ford Turboencabulator](https://fora.urbit.org/posts/~2018.3.15..04.24.35..a47f~)
9919−
9920−It's a monster post, but if you're a systems geek and want to read into the redesign of this important kernel module,
9921−check it out.
9922−
9923−Ted's and Elliot's daily Ford progress can be tracked here:
9924−
9925−- [`urbit/arvo 'ford-turbo'`](https://github.com/urbit/arvo/tree/ford-turbo)
9926−
9927−_Joshua_ `~taglux-nidsep`, Ted, and Keaton debuted _Mars Talk, Season 2_ on Wednesday night. To reboot the show, we gave
9928−a high-level overview of the Urbit stack for new developers:
9929−
9930−- [Mars Talk Season 2, Ep. 1: High-Level Overview of the Urbit Stack](https://www.youtube.com/watch?v=UaRZVxthVeY)
9931−
9932−Subscribe to [Josh's channel](https://www.youtube.com/channel/UC3c0F4NhOD1LT5A1ShXEWiQ), and tune in weekly for all your
9933−latest and greatest educational content and Urbit news.
9934−
9935−See some of you at the meetup tonight, and the rest of you Hoons on the network.
9936−]]></content:encoded>
9937− </item>
9938− <item>
9939− <title><![CDATA[~2018.3.5 Update]]></title>
9940− <link>https://urbit.org/updates/2018-3-5-update</link>
9941− <guid>https://urbit.org/updates/2018-3-5-update</guid>
9942− <pubDate>Sun, 04 Mar 2018 00:00:00 GMT</pubDate>
9943− <content:encoded>< that implements the _Keccak_
9953−family of cryptographic hashing functions in Hoon, including `SHA-3`, `shake`, and `rawshake`. We'll need `keccak` to
9954−integrate Urbit with Ethereum.
9955−
9956−Also, [moons](https://urbit.org/docs/using/admin/#-moons) are back! You can run the `+moon` generator from your galaxy,
9957−star or planet to create a ticket for a new moon. If you run your ship in the cloud and SSH in to use Talk, try booting a
9958−moon on your laptop and using that for Talk instead. Messages you send from your moon will appear to have been sent from
9959−your usual (parent) identity.
9960−
9961−_Iceman_ `~littel-ponnys` wrote some deep thoughts on Clay, Urbit's filesystem, in this [meaty Fora
9962−post](https://fora.urbit.org/posts/~2018.2.25..02.28.04..bd6d~/).
9963−
9964−P.S. We're hiring! If you're interested, email `galen@tlon.io`.
9965−]]></content:encoded>
9966− </item>
9967− <item>
9968− <title><![CDATA[~2018.2.24 Update]]></title>
9969− <link>https://urbit.org/updates/2018-2-24-update</link>
9970− <guid>https://urbit.org/updates/2018-2-24-update</guid>
9971− <pubDate>Fri, 23 Feb 2018 00:00:00 GMT</pubDate>
9972− <content:encoded><. Now that we've fixed most of the bugs in new Talk, we think the network is going to be pretty smooth for a while. If you haven't already, follow our [setup](https://urbit.org/docs/using/setup) doc again to reboot your planet in this new continuity era. If you'd like a planet, [email me](mailto:keaton@tlon.io)!
9976−
9977−We're hosting a [Meetup now](https://www.meetup.com/urbit-sf/events/247797527/) at the Tlon office. _Josh_ `~taglux-nidsep` is in town, and we all need a drink after the breach. Bring your laptop, stop by for a beer, and let us install Urbit for you. Or just relax and talk to people.
9978−
9979−_Mark_ `~palfun-foslup` had a number of PRs merged this week for various bug fixes to Talk and Hall.
9980−
9981−_Joe_ `~master-morzod` fixed several issues with Urbit's terminal.
9982−
9983−_Anton_ `~pittyp-datfyn` made a one-line fix in Ford that fixed a major bug in cache performance. As a result, the website and Fora feel snappier.
9984−
9985−_Ted_ `~rovnys-ricfer` and _Keaton_ `~tonlur-sarret` continued working on the new Ford design.
9986−
9987−_Galen_ `~ravmel-ropdyl`, _Jimmy_ `~haptyl-wanwes`, and _Chris_ `~sigtus-hossyn` worked more on the new frontend.
9988−
9989−_Curtis_ `~sorreg-namtyv` is finishing up work on Hoon type defaulting, and has started working on a new design for the Hoon pretty printer.
9990−
9991−Josh, Ted and Keaton took a hiatus from Mars Talk this week to discuss future plans. We'll be back next week, better than ever.
9992−
9993−Have a great weekend!
9994−]]></content:encoded>
9995− </item>
9996− <item>
9997− <title><![CDATA[~2018.2.17 Update]]></title>
9998− <link>https://urbit.org/updates/2018-2-17-update</link>
9999− <guid>https://urbit.org/updates/2018-2-17-update</guid>
10000− <pubDate>Fri, 16 Feb 2018 00:00:00 GMT</pubDate>
10001− <content:encoded>< to Urbit's top recent contributors. The winners this term were:
10005−
10006−- _Gold_, _64 stars_: Joe Bryan `~master-morzod`
10007−- _Silver_, _32 stars_: Joshua Reagan `~taglux-nidsep`
10008−- _Silver_, _32 stars_: Mikolaj `~ponmep-litsem`
10009−- _Bronze_, _16 stars_: Assaf Berg `~rophex-hashes`
10010−- _Bronze_, _16 stars_: Matt Levan `~mastyr-bottec`
10011−- _Bronze_, _16 stars_: Anthony Arroyo `~poldec-tonteg`
10012−
10013−Thank you all again for helping bring Urbit to life!
10014−
10015−_Galen_ `~ravmel-ropdyl`, _Jimmy_ `~haptyl-wanwes`, and _Chris_ `~sigtus-hossyn` have been progressing further on the new Urbit frontend.
10016−
10017−_Anton_ `~pittyp-datfyn` has been working hard on making Urbit-flavored markdown, and subsequently, Fora, a lot less slow than it currently is.
10018−
10019−_Mark_ `~palfun-foslup` submitted an [`urbit/arvo` pull request](https://github.com/urbit/arvo/pull/610) that implements permissions for Urbit's Clay filesystem, which Ted merged this week. Among other things, this will play a pivotal role in the new _Collections_ app actively being worked on, so that an Urbit user can store private notes, create invite-only fora and blogs, and collect a private archive of typed documents, all while maintaining referential transparency in the global immutable namespace.
10020−
10021−_Ted_ `~rovnys-ricfer` and _Keaton_ `~tonlur-sarret` have been working on a design for the data structures and control flow for the next version of Ford, Urbit's build system. We'll post to Fora once we've revised it some more.
10022−
10023−_Joshua_ `~taglux-nidsep` rejoined [Mars Talk this week](https://www.youtube.com/watch?v=--hvpMqIeSA) as host with Ted and Keaton for Episode 21. We decided to take a break from deep technical talk to chat about the proposed _Nock 4K_ spec (a cosmic event in the Urbit universe), Josh's dissertation, Vere parallelism, and Urbit as a personal command center to call out to Earth blockchains.
10024−
10025−Have a great weekend, everyone!
10026−]]></content:encoded>
10027− </item>
10028− <item>
10029− <title><![CDATA[~2018.2.9 Update]]></title>
10030− <link>https://urbit.org/updates/2018-2-9-update</link>
10031− <guid>https://urbit.org/updates/2018-2-9-update</guid>
10032− <pubDate>Thu, 08 Feb 2018 00:00:00 GMT</pubDate>
10033− <content:encoded>< a set of labels for our repositories to use, `~rovnys` and I set
10042−out to show all the issues some love.
10043−Today we finally made it through the last of them! You can now look for issues that are
10044−[easy](https://github.com/urbit/arvo/issues?q=is%3Aissue+is%3Aopen+label%3A%22difficulty+low%22) or [good for
10045−contributors](https://github.com/urbit/arvo/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+contributor+issue%22) to
10046−tackle. There's plenty of labels now for all your filtering needs. Internally, we'll try to get eyes on issues labeled
10047−[RFC](https://github.com/urbit/arvo/issues?q=is%3Aissue+is%3Aopen+label%3A%22request+for+comments%22) and [help
10048−wanted](https://github.com/urbit/arvo/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22) every so often.
10049−While contributors can't add labels themselves, we'll make sure your issues get tagged correctly. Enjoy!
10050−
10051−_Curtis_ `~sorreg-namtyv` has been helping Ted and _Anton_ `~pittyp-datfyn` with Ford. He's also continued his work on
10052−improving default values for types in Hoon.
10053−
10054−_Keaton_ `~tonlur-sarret` has been working on a super-secret project that he cannot discuss. Loose lips sink ships ...
10055−
10056−_Mark_ `~palfun-foslup` has submitted a PR for Clay permissions. We just completed a second round of review, and Mark is
10057−now doing more testing.
10058−
10059−_Iceman_ `~littel-ponnys`, _Joe_ `~master-morzod`, and Ted [had some
10060−fun](https://fora.urbit.org/posts/~2018.2.9..21.50.49..709f~/) discussing various forms of persistence in Clay and Gall
10061−in `urbit-meta`.
10062−
10063−Keaton and Ted demoed some Urbit web app examples in [Mars Talk Episode 20](https://www.youtube.com/watch?v=emWy1Afe4qY).
10064−]]></content:encoded>
10065− </item>
10066− <item>
10067− <title><![CDATA[~2018.2.5 Update]]></title>
10068− <link>https://urbit.org/updates/2018-2-5-update</link>
10069− <guid>https://urbit.org/updates/2018-2-5-update</guid>
10070− <pubDate>Sun, 04 Feb 2018 00:00:00 GMT</pubDate>
10071− <content:encoded><.
10079−
10080−_Isaac V_ `~davtyr-nimren` completed the initial version of the static `ren/tree` replacement. The _Collections_ and _Streams_ apps are now being built on top of this foundation. See the [`mve` branch](https://github.com/urbit/arvo/tree/mve) of Arvo to track development.
10081−
10082−_Paul_ `~fodwyt-ragful` [fixed a performance issue](https://github.com/urbit/urbit/pull/920) in unifying large nouns.
10083−
10084−_Iceman_ `~littel-ponnys`'s testing framework has been merged into master. To use the framework to write unit tests, see the [user guide](https://github.com/urbit/arvo/blob/master/web/testing.umd). This pull request also includes a Hoon port of [Haskell's Prelude](https://hackage.haskell.org/package/base-4.10.1.0/docs/Prelude.html), which is [now available](https://github.com/urbit/arvo/blob/master/lib/new-hoon.hoon) as an alternate version of the Hoon standard library, including [unit tests](https://github.com/urbit/arvo/tree/master/tests/new-hoon). Discussion of this subject can be found on [Fora](https://fora.urbit.org/posts/~2017.10.17..04.09.16..7eb8~/).
10085−
10086−On [Mars Talk Episode 19](https://www.youtube.com/watch?v=q3Fjnv0RcR0) (our 20th episode!) this week, Keaton and Ted explained Ford, Urbit's functional reactive build system.
10087−]]></content:encoded>
10088− </item>
10089− <item>
10090− <title><![CDATA[~2018.1.13 Update]]></title>
10091− <link>https://urbit.org/updates/2018-1-13-update</link>
10092− <guid>https://urbit.org/updates/2018-1-13-update</guid>
10093− <pubDate>Fri, 12 Jan 2018 00:00:00 GMT</pubDate>
10094− <content:encoded><.
10104−
10105−**Mark** has a [PR to fix a talk / Gall bug](https://github.com/urbit/arvo/pull/538) and is now working on updating Clay's API to support multiple files per request, which will support the Ford caching improvements.
10106−
10107−**Iceman** `~littel-ponnys` has submitted a [PR implementing a unit testing framework](https://github.com/urbit/arvo/pull/539) for Hoon, which had been in the works for a long time.
10108−
10109−**Mikolaj** `~ponmep-litsem` has been making lots of good contributions recently, including reporting several GitHub issues and work on an Elm web frontend for Urbit, which he's using to implement [Plato](https://github.com/mikolajpp/plato), an in-browser Hoon editor.
10110−
10111−Finally, in [Mars Talk this week](https://youtu.be/oX7TFJ5qzr4) Ted wrote a Gall app using a timer from Behn with help from Keaton and **Josh** `~taglux-nidsep`.
10112−]]></content:encoded>
10113− </item>
10114− <item>
10115− <title><![CDATA[~2018.1.6 Update]]></title>
10116− <link>https://urbit.org/updates/2018-1-6-update</link>
10117− <guid>https://urbit.org/updates/2018-1-6-update</guid>
10118− <pubDate>Fri, 05 Jan 2018 00:00:00 GMT</pubDate>
10119− <content:encoded>< involving what appeared to
10128−be one-way communication in Gall. More updates on that forthcoming.
10129−
10130−_Galen_ `~ravmel-ropdyl` has been working on the Urbit primer that will become the new urbit.org landing page. That's in
10131−review now.
10132−
10133−_Curtis_ `~sorreg-namtyv` has been helping out with the primer and has begun work on an HTTP cache in Vere to help with
10134−web performance. That should synergize nicely with upcoming Ford fixes.
10135−
10136−_Ted_ `~rovnys-ricfer` has been modernizing his and Anton's work on Ford caching to work with new Hoon and Arvo.
10137−
10138−_Keaton_ `~tonlur-sarret` has been helping Ted with Ford. With Mark's help, he also moved Fora onto a standalone ship to
10139−improve the loading times of the rest of urbit.org. All the old links still work, but Fora's true home is now at
10140−[https://fora.urbit.org](https://fora.urbit.org).
10141−
10142−_Isaac_ `~davtyr-nimren` has made some [more
10143−progress](https://github.com/ixv/arvo/commit/bc52d9fc494399c2063cfa7817046d180b6f78d5) on the new static webpage serving
10144−(`ren/tree`).
10145−
10146−Early 2018 should see a lot of usability improvements. We're looking forward to being able to ship them soon.
10147−]]></content:encoded>
10148− </item>
10149− <item>
10150− <title><![CDATA[~2017.12.22 Update]]></title>
10151− <link>https://urbit.org/updates/2017-12-22-update</link>
10152− <guid>https://urbit.org/updates/2017-12-22-update</guid>
10153− <pubDate>Thu, 21 Dec 2017 00:00:00 GMT</pubDate>
10154− <content:encoded><, which had been down since the breach, and as far as we know all the major, show-stopping `:talk` bugs have now been fixed. All currently known `:talk` bugs can be found on our [github issues page](https://github.com/urbit/arvo/issues). Mark, with some help from Ted, has also been working on reproducing and diagnosing [an old Clay bug](https://github.com/urbit/arvo/issues/501) that popped up again recently involving failed filesystem syncing across ships. We now know how to fix the bug, so that's up next for Mark.
10158−
10159−_Ted_ `~rovnys-ricfer` submitted a [PR](https://github.com/urbit/urbit/pull/910) that fixes a long-standing performance bug in Urbit's event-processing model, where effects wouldn't be performed until the whole queue of input events had been processed. The PR is currently in review. He's also resumed work on the Ford caching fixes that he and Anton had been working on before the breach. It's a difficult project, but once it lands, the dreaded 504 errors when loading urbit.org should finally cease.
10160−
10161−_Anton_ `~pittyp-datfyn` has been working on the `:collections` app, which will replace and generalize `:fora`. This work is nearing completion. This work will likely land with the frontend overhaul that Galen is leading.
10162−
10163−_Isaac_ `~davtyr-nimren` has contined to make progress on the new version of `ren/tree`, Urbit's web publishing frontend. The new system has now matured enough that Keaton has been able to translate several of our docs pages to it.
10164−
10165−_Keaton_ `~tonlur-sarret` has been chugging along on converting Urbit's documentation to the new `ren/tree`. He also booted up a new web ship to run urbit.org, since the old one had gotten verklempt.
10166−
10167−_Galen_ `~ravmel-ropdyl` has continued work on the revamped Urbit frontend, including a base.css and a redesigned look and feel and more diagrams, explanations, and blog posts. _Jimmy_ and _Chris_ are working with him on this project. He's also been working with Anton on the `:collections` app.
10168−
10169−_Anthony_ `~poldec-tonteg` has fixed several more bugs with [Urbit's fork of myetherwallet](https://github.com/urbit/etherwallet).
10170−
10171−_Curtis_ `~sorreg-namtyv` has continued working on Hoon performance. Performance of his branch is currently estimated at 30% faster than master.
10172−
10173−_Joshua Reagan_ `~taglux-nidsep` and Ted had Mark and Keaton on [Mars Talk episode 13](https://youtu.be/CfdoGY0u044) and they live-coded a Gall app.
10174−
10175−We also threw what was generally considered to be a pretty good party last night. It was a nice way to end the year. Happy holidays from Mars!
10176−]]></content:encoded>
10177− </item>
10178− <item>
10179− <title><![CDATA[~2017.12.16 Update]]></title>
10180− <link>https://urbit.org/updates/2017-12-16-update</link>
10181− <guid>https://urbit.org/updates/2017-12-16-update</guid>
10182− <pubDate>Fri, 15 Dec 2017 00:00:00 GMT</pubDate>
10183− <content:encoded><.
10194−- _Ted_ has started working on designing a system to run automated stress tests of a fleet of Urbits, sort of like a DIY botnet. This should help us hit more bugs _before_ pushing code to the live network, many of which only appeared at "web scale."
10195−- _Anthony_ `~poldec-tonteg` now has a working alpha of an [Urbit fork of myetherwallet](https://github.com/urbit/etherwallet) (design by _Galen_), with usage instructions. We haven't gone live on Ethereum yet, but you can still check this out to see a glimpse of the future.
10196−- _Galen_ `~ravmel-ropdyl` and _Jimmy_ have been working on an Urbit primer to help explain whatever it is we do here.
10197−
10198−There have also been two Mars Talk episodes since our last update:
10199−[What is Urbit? Panel Discussion](https://www.youtube.com/watch?v=hqACJVSJc5s&t=3703s)
10200−[Learning about Clay, Urbit's Filesystem](https://www.youtube.com/watch?v=aJqNmUMYHHg)
10201−
10202−We're holding a [meetup](https://www.meetup.com/urbit-sf/events/245925902/) at our office next week. No presentations this time, just a party.
10203−]]></content:encoded>
10204− </item>
10205− <item>
10206− <title><![CDATA[~2017.12.2 Update]]></title>
10207− <link>https://urbit.org/updates/2017-12-2-update</link>
10208− <guid>https://urbit.org/updates/2017-12-2-update</guid>
10209− <pubDate>Fri, 01 Dec 2017 00:00:00 GMT</pubDate>
10210− <content:encoded><, which we use for spawning testnets.
10218−The repo now works with the new `urbit` command-line arguments that are part of the breach, and it's now at the point
10219−where we can launch ships from galaxies all the way down to comets. We've been using it to test various aspects of
10220−Urbit's multi-ship functionality, such as `:talk` and filesystem syncing. Turns out there is a bug with filesystem
10221−syncing in master, so we're going to have to fix that before breaching.
10222−
10223−_Anton_ `~pittyp-datfyn` has knocked out a bunch of items in our breach checklist. Some highlights:
10224−
10225−- Fixed single-sign-on
10226−- Cleaned up a bunch of old unused code
10227−- Reorganized `:hood` libraries
10228−- Lots of testing
10229−
10230−_Keaton_ `~tonlur-sarret` has been working with Anton on the breach checklist. He also updated the docs and examples to
10231−reflect the changes made in hoon `%143` (which will be deployed with the breach) and helped Ted debug some urbit/fleet
10232−problems.
10233−
10234−_Curtis_ `~sorreg-namtyv` has made a number of improvements to hoon's defaulting system (bunting). Part of the work
10235−included fixing an inconsistency in how hoon determined which subtype of a fork type would be chosen as default. After
10236−fixing that, he implemented a cache for those defaults, which improved compilation speed by 10-20%. This code has been
10237−merged into Arvo's master branch. He's still working on a parallel defaulting system, which might go even faster.
10238−
10239−_Galen_ `~ravmel-ropdyl` and Jimmy have been working on the new urbit.org homepage, which will be Tlon's next priority
10240−after the breach. This will feature a complete redesign using a new base.css to provide a standardized look and feel for
10241−the Urbit web experience.
10242−
10243−_Mark_ `~palfun-foslup` / `~palnup-salwyx-mortyl-silfyl--digrel-pitbud-dorsym-livpyl` has been working with
10244−~poldec-tonteg to troubleshoot some issues with Urbit's Ethereum constitution. He's still waiting for the rest of Tlon to
10245−test his [monumental PR](https://github.com/urbit/arvo/pull/452) for new talk, which he submitted a couple weeks ago. Now
10246−that we have the fleet repo working, we can use it to test this work more thoroughly. This week he also made some changes
10247−to Hall, which he has expressed in haiku form:
10248−
10249−> the hall has opened,
10250−> circles form to admire,
10251−> people's collections.
10252−
10253−He also says:
10254−
10255−> Or if you want something slightly more serious:
10256−> Hall has received some more fixes and quality of life improvements since I opened the PR. It's > never been more ready
10257−> for the breach! I'm already working on something interesting that uses > it: an interface for managing your own notes,
10258−> blogs and foras. Complete with filesystem, storage, and hall notifications!
10259−
10260−_Joe_ `~master-morzod` has written an implementation of SSL termination in vere. This will allow your Urbit to serve true
10261−end-to-end-encrypted HTTPS, as opposed to Tlon's servers operating as man-in-the-middle, which is not a viable long-term
10262−solution. This has been an important piece of missing functionality, so we're excited to see it start to come together.
10263−Latest code can be found [here](https://github.com/joemfb/urbit/tree/346de776c5fabe3e02fecb7cab3d1652e4cc46e3).
10264−
10265−_Isaac_ `~davtyr-nimren` has been building the next generation of Urbit's web publishing system, currently located in the
10266−ren/tree directory of Arvo. This new system, instead of serializing data down to the client to be fetched after the
10267−initial page load, will perform the HTML rendering on the server. This is now possible because of the integration of our
10268−Udon markup language with the Hoon compiler. This allows us to include Udon files in other Udon files using Ford runes.
10269−The new system is much simpler and should improve page load time. Once we've written our planned Vere HTTP cache, this
10270−new paradigm should also improve the coherence of that cache. This system is mostly complete now, and Isaac is now
10271−working on smaller bugfixes.
10272−
10273−There was also a [new episode of Mars Talk](https://youtu.be/1xcjnBu6qFo) with Ted and Joe discussing Hoon's type system.
10274−
10275−Those are the highlights from this week. Back to breaching!
10276−]]></content:encoded>
10277− </item>
10278− <item>
10279− <title><![CDATA[~2017.11.14 Update]]></title>
10280− <link>https://urbit.org/updates/2017-11-14-update</link>
10281− <guid>https://urbit.org/updates/2017-11-14-update</guid>
10282− <pubDate>Mon, 13 Nov 2017 00:00:00 GMT</pubDate>
10283− <content:encoded><![CDATA[
10284−As usual, we're guilty of wanting to write code more than prose. Last time we
10285−announced our plans for Ethereum integration. This month we'll stick to basic
10286−project status:
10287−
10288−## Fall release goals and status
10289−
10290−_Curtis, Ted, Paul_
10291−
10292−Sometime in the next few weeks, we'll ship the Hoon 143 / Vere 0.5 release.
10293−This release will of course be a continuity breach. The mighty engine is still
10294−running in the lab while we screw on the last bells and make sure the boiler
10295−isn't leaking oil, steam or memory. Currently, Curtis is fighting memory leaks
10296−while Ted and Paul make sure the memoization cache can actually get reclaimed.
10297−
10298−We want this fall 2017 Urbit testnet release to be reasonably rugged across the
10299−board. It is not a production network and its keys remain test keys. However,
10300−it should not crash, sink, etc.
10301−
10302−This is new. For previous releases, it wasn't a realistic goal to keep ships
10303−from sinking, or salvage every pier. It's just incredibly disruptive and
10304−unpleasant in a pseudonymous network to sink people's identities. In this era,
10305−if your ship sinks, please (a) post an incident report to the Urbit fora; (b)
10306−know that we will strain every fiber to help you wrest it from Poseidon's grim
10307−grip.
10308−
10309−Furthermore, although there will be no direct formal continuity between this
10310−release and the next one, we will provide tools to directly convert any data
10311−in your urbit. So, in case you actually do put meaningful datas in your urbit,
10312−you won't have to convert your datas completely by hand. Again, we will do
10313−everything to help.
10314−
10315−## Hoon 143
10316−
10317−_Curtis, Iceman, Ted, Anton, Mark_
10318−
10319−Curtis has spent most of 2017 quasi-surreptitiously in "auteur mode," trying to
10320−complete his initial authorship of Hoon. After this release he promises to work
10321−only on Arvo and above.
10322−
10323−Hoon 143 is not perfect, but it will do for a while. Nothing in Hoon 143 is so
10324−bad it's embarrassing. No one has any need to wait for it to stabilize. Any
10325−errors in the above must be fixed by Hoon 142.
10326−
10327−Hoon 143 establishes a set of standards and conventions which define modern,
10328−high-quality code. Most of the Urbit codebase isn't quite to this standard.
10329−Changing this includes removing the use of deprecated language features, then
10330−removing support for the deprecated features (to create Hoon 142). Someone
10331−should definitely do this work.
10332−
10333−Here are some of the things Curtis has done to Hoon, without asking anyone's
10334−permission. (Did Godard ask permission?) On some of these things he had fellow
10335−conspirators -- Iceman was an equal contributor on the decorators, the team of
10336−Ted, Anton and Mark on Udon.
10337−
10338−Big changes in Hoon 143:
10339−
10340−- Hoon 151's "electroplating," which replaced Hoon 164's "vulcanization,"
10341− has been replaced by 143's "repainting." This means wet gate namespacing
10342− works, so you can write `(weld ~[1 2] ~[3 4])` and get `~[1 2 3 4]` instead of
10343− `error: %mull-bonk-b`.
10344−- There's now only one wide syntax `{a/term b/term}` becomes `[a=term b=term]`.
10345− This is like Hoon 164 syntax, but without the ubiquitous, and horrible, prefix
10346− comma. The price is modes.
10347−- Decorators: formal syntax for adding documentation to types, available at
10348− runtime for reflexive help and diagnosis.
10349−- In addition to the Sail dynamic XML syntax (which everyone forgets about, and
10350− which is basically JSX in Hoon), Hoon now has an embedded, Markdown-flavored
10351− rich text language: Udon. Few dynamic document platforms have this kind of
10352− range -- one file, with everything from code to tree-structured data to styled text.
10353−- Keywords, which everyone despised, have been fully eradicated.
10354−
10355−Curtis is done with Hoon and will never again change or improve it.
10356−He may offer occasional opinions. Ted and Iceman are the new maintainers of
10357−Hoon (including all of hoon.hoon and zuse.hoon, excluding Arvo models).
10358−Anything all they agree on is probably good.
10359−
10360−## What's not in this release
10361−
10362−_Curtis_
10363−
10364−2017 was also the year we learned the lesson that, while Urbit is awesome and
10365−makes many system-software problems trivial, it is not so awesome that a team
10366−this small can advance two branches at once. This fall 2017 release is a
10367−classic, Microsoft-style stick save, cutting off about half of the research
10368−("master" or "cc-release") branch and merging it back with splints and bandaids.
10369−
10370−What got cut (this work is mostly coded, but not fully tested / integrated):
10371−
10372−- The all-new event system in Vere, the all-new Arvo kernel with correct whitepaper-style lifecycle function
10373−- The all-new (not just repaired) Ames (network) vane
10374−- Ted and Anton's the mostly-rewritten Ford (build) vane
10375−- Mark's rewritten Talk app (now Hall)
10376−- The all-new Jael authentication vane
10377−- The new generalized console library
10378−
10379−There is plenty of other stuff that needs to go into our next release. Some of
10380−it is described below.
10381−
10382−## SPA rendering and build system
10383−
10384−_Ted and Anton_
10385−
10386−Ever notice how urbit.org gives 504 errors far too much? Hell, it probably
10387−504-ed when you tried to load this page. This is clearly a problem.
10388−
10389−Perhaps we could hack our way around it — but, as usual, we prefer to get to the
10390−root of the problem. When you request a webpage from an Urbit we use our build
10391−system, Ford, to produce it. Then our single-page app, Tree, renders and builds
10392−the page in the browser.
10393−
10394−There are two problems with the current system:
10395−
10396−The Ford cache is cleared every time something in Clay changes.
10397−
10398−On the client side, pages are built through multiple requests.
10399−
10400−To fix (2) we want to move to a system where each page is a single static build.
10401−This means doing 'server side rendering' with Ford — rather than having the
10402−client make multiple requests for every page component.
10403−
10404−The basic parts of this are done. We implemented a subset of markdown in Hoon
10405−and added some new runes to Ford. This means you can write files that include
10406−other files without any JSX or client side craziness.
10407−
10408−(1) is a bit more complicated, and has taken up quite a bit of Anton and Ted's
10409−time. We've implemented a new cache algorithm, which is designed to promote
10410−unchanged content across revisions. The algorithm seems correct, but doesn't
10411−properly promote unchanged content in all cases.
10412−
10413−With these two things actually completed we'll be able to get much snappier page
10414−loads. The next step is properly terminating SSL at an individual ship — but
10415−more on that next month.
10416−
10417−The details of this project are outlined in UP1 - Ford Caching Redux:
10418−[fora/posts/~2017.10.19..04.47.50..c107~/](https://urbit.org/fora/posts/~2017.10.19..04.47.50..c107~/).
10419−More on UPs below.
10420−
10421−## New primer
10422−
10423−_Isaac, Galen and Jimmy_
10424−
10425−One thing we still don't do a particularly good job of is communicating about
10426−what Urbit is. Even to savvy tech and crypto folks.
10427−
10428−We're working on a new, illustrated, single-page explanation to go up on
10429−urbit.org. The text is coming together and we're starting to work on design.
10430−
10431−## Nock tutorials
10432−
10433−_Josh and Galen_
10434−
10435−Josh is a PhD student who has a lot more teaching experience than we do. To
10436−boot, he's convinced that Nock is incredibly simple and can be taught to just
10437−about anyone. So, he put together a few video tutorials.
10438−
10439−We're touching up the look and feel — but they should go up in the next week or
10440−so.
10441−
10442−## ETH contracts
10443−
10444−_Mark and Curtis_
10445−
10446−Working from Curtis' designs, Mark has helped us implement the Urbit
10447−constitution as a set of ETH contracts. They're off to the auditors, but the
10448−code lives here: [github.com/urbit/constitution](https://github.com/urbit/constitution)
10449−for public scrutiny.
10450−
10451−## MyEtherWallet
10452−
10453−_Anthony and Galen_
10454−
10455−We want to make interacting with the Urbit ETH contracts as easy as possible.
10456−Especially for people who aren't necessarily particularly familiar with
10457−interacting with dApps.
10458−
10459−So, we designed an Urbit-specific frontend for MyEtherWallet. And Anthony, who
10460−actually knows Angular, has been helping us implement it. He has been working
10461−privately, but progress will be visible here:
10462−[github.com/urbit/etherwallet](https://github.com/urbit/etherwallet) soon.
10463−
10464−## UPs
10465−
10466−_Keaton, Ted and Galen_
10467−
10468−About a month ago we were discussing how we'd really like to be more transparent
10469−about the projects we undertake. And, we'd really like to have a way of
10470−cataloging projects we discuss but can't take on.
10471−
10472−Enter the UP or 'Urbit Proposal'. UP0 gives an outline for what a UP should
10473−contain:
10474−[fora/posts/~2017.10.19..03.45.26..dbec~/](https://urbit.org/fora/posts/~2017.10.19..03.45.26..dbec~/).
10475−
10476−## Jaque, an independent interpreter in Java
10477−
10478−_Paul_
10479−
10480−Paul is delighted to announce Jaque, an independent implementation of Urbit
10481−using Graal/Truffle on the JVM.
10482−
10483−Jaque is not just another Nock function -- it boots an actual Urbit pill to a
10484−working dojo prompt. Jaque has no compiler jets and has exposed several jet
10485−mismatches in Vere. It works and is reportedly quite snappy. Paul is still
10486−tuning the interpreter, changing it from a tree interpreter to a small bytecode,
10487−because Graal does not like big stacks and tree interpreters make big stacks.
10488−He'll say more about it when he considers it done, which is not yet.
10489−]]></content:encoded>
10490− </item>
10491− <item>
10492− <title><![CDATA[~2017.10.17 Update]]></title>
10493− <link>https://urbit.org/updates/2017-10-7-update</link>
10494− <guid>https://urbit.org/updates/2017-10-7-update</guid>
10495− <pubDate>Mon, 16 Oct 2017 00:00:00 GMT</pubDate>
10496− <content:encoded>< hosted by `~taglux-nidsep` with guest `~master-morzod` on Arvo, the Urbit operating system. [Discussion on Fora](https://urbit.org/fora/posts/~2017.10.5..03.57.51..f4c0~/)
10500−- [The Absolute State of the Urbit Docs](https://github.com/urbit/docs/issues/137#issuecomment-333444336), a conversation on GitHub between `~taglux-nidsep`, `~sorreg-namtyv`, `~rovnys-ricfer` and `~master-bottec`. [Discussion on Fora](https://urbit.org/fora/posts/~2017.10.3..03.04.45..b532~/)
10501−- [`~rovnys-ricfer` on Hoon casting](https://github.com/urbit/docs/pull/201#issuecomment-333546648). [Discussion on Fora](https://urbit.org/fora/posts/~2017.10.3..01.53.05..07b3~/)
10502−- [Nock macro expansion: A clear explanation that anyone can understand](https://urbit.org/fora/posts/~2017.10.6..23.50.35..fb74~/) by `~rovnys-ricfer`
10503−]]></content:encoded>
10504− </item>
10505− <item>
10506− <title><![CDATA[~2017.9.29 Update]]></title>
10507− <link>https://urbit.org/updates/2017-9-29-update</link>
10508− <guid>https://urbit.org/updates/2017-9-29-update</guid>
10509− <pubDate>Thu, 28 Sep 2017 00:00:00 GMT</pubDate>
10510− <content:encoded>< blog post. [Discussion on Fora](https://urbit.org/fora/posts/~2017.9.25..20.34.38..8e27~/)
10514−- [A question by James Bowery from urbit-dev](https://urbit.org/fora/posts/~2017.9.26..23.26.32..1066~/)
10515−- [Mars Talks, Ep. 1](https://www.youtube.com/watch?v=lX0xx70TcJE) hosted by `~taglux-nidsep` with guest `~poldec-tonteg` on Urbit web development. [Discussion on Fora](https://urbit.org/fora/posts/~2017.9.28..04.10.26..a4bb~)
10516−- [urbit-sync](https://github.com/ngzax/urbit-sync) by `~migsyr_tarnux`. [Discussion on Fora](https://urbit.org/fora/posts/~2017.9.29..11.58.54..4dd1~)
10517−]]></content:encoded>
10518− </item>
10519− <item>
10520− <title><![CDATA[Urbit and the Blockchain Wars]]></title>
10521− <link>https://urbit.org/blog/urbit-and-the-blockchain</link>
10522− <guid>https://urbit.org/blog/urbit-and-the-blockchain</guid>
10523− <pubDate>Sun, 24 Sep 2017 00:00:00 GMT</pubDate>
10524− <content:encoded><
10526−
10527−One core principle of the Urbit network is that _Urbit doesn't take sides_.
10528−This is true in all kinds of conflicts -- and especially blockchain wars.
10529−
10530−We're [moving the Urbit PKI onto Ethereum](https://urbit.org/blog/2017.9.20-bootstrapping-urbit-from-ethereum/)
10531−not because we like Ethereum, but because it's the most practical thing for
10532−Urbit right now. This is not a moral or aesthetic choice.
10533−
10534−Some have objected to this decision. Some of these objections are excellent.
10535−The rest are understandable.
10536−
10537−Let's review our decision, responding to objections along the way. Not everyone
10538−has to agree on everything. No one should stay confused. And we welcome
10539−further comment.
10540−
10541−## Urbit is not endorsing or supporting Ethereum
10542−
10543−There are many technical criticisms of Ethereum. We agree with many of these
10544−criticisms -- even most. But still more important: Bitcoin is the strongest
10545−chain. If Bitcoin could directly enforce Urbit's PKI rules, we'd use Bitcoin,
10546−for this reason alone. (That said, Ethereum may be less exposed to Chinese
10547−politics.)
10548−
10549−We chose ETH because it is the strongest _computational_ chain. It is certainly
10550−stronger than the way we're storing the Urbit land registry now: GitHub, plus
10551−internal records.
10552−
10553−Urbit is not endorsing Ethereum. Urbit is not creating any appreciable monetary
10554−demand for Ethereum. Urbit is not even locked in to Ethereum: with a fully
10555−self-governing constitution, the Urbit galaxies can decide to migrate to another
10556−consensus engine, or no consensus engine, or even our own consensus engine, any
10557−time we like.
10558−
10559−And even if the whole Ethereum network unexpectedly implodes, and stops
10560−generating meaningful new blocks, we (or more generally: the set of active
10561−Urbit galaxies) cannot abandon the social power to manually hard-fork the
10562−network. Ultimately, the Ethereum contract is just a hardcoded address in a
10563−piece of Urbit source code.
10564−
10565−Let's address each of these points at a little more length.
10566−
10567−## On moving to a blockchain
10568−
10569−The first point to remember: our choice wasn't between Ethereum and nothing. It
10570−wasn't between a blockchain and nothing. It was a choice between 21st-century
10571−tools and 20th-century tools.
10572−
10573−The current Urbit land registry is divided into parts stored in various places:
10574−GitHub commits, database records held by Tlon Corporation, and insecure keys on
10575−a test network. This might have been fine, for us, in 2015. In 2017, it's
10576−borderline unacceptable.
10577−
10578−## On choosing a chain
10579−
10580−Our first decision point: whether the public chain enforces the rules of Urbit,
10581−or just logs raw data that anyone can interpret.
10582−
10583−The simplest procedure, with the strongest blockchain, would be just to encode
10584−each Urbit event as raw (OP_RETURN) data on the Bitcoin blockchain. Or we could
10585−use another simple layer on top of Bitcoin; classic "colored coins," for
10586−instance.
10587−
10588−The resemblance between Urbit land-registry titles and colored coins is one we
10589−noticed a long time ago, of course. For a long time it wasn't that relevant,
10590−because colored coins remained largely theoretical.
10591−
10592−The larger problem is just that a non-computational blockchain can't enforce the
10593−specific rules of the Urbit land registry (like the right of a star to create
10594−specific planets).
10595−
10596−You can put arbitrary data into a blockchain and enforce it off-chain. This
10597−strikes us as unsatisfactory, though. For instance, you have to define the
10598−semantics of erroneous or malformed operations. If this is not done perfectly,
10599−it's a short road to major weirdness. Also, your interpretation tools are a
10600−special-purpose one-off not shared with anyone.
10601−
10602−There are other second-order "virtualchains" (Blockstack is one example), which
10603−build computation layers on top of arbitrary chains. These tools are interesting
10604−and cool. They are also quite young. As is Urbit, so we need all the maturity
10605−we can get.
10606−
10607−Also, our use case, as a land registry, is quite simple -- we don't have any
10608−desire to pay (in complexity) for power we don't use. A two-layer solution
10609−just seems to leave more room for bad weirdness.
10610−
10611−## As normal Urbit state?
10612−
10613−The original design was for Urbit to host its own primary copy of the PKI state,
10614−not mirror some external master.
10615−
10616−As more people start believing in Urbit, this makes us extremely nervous. Being
10617−the single source of truth implies a strong commitment to security and
10618−continuity. Urbit needs to get there, but it isn't there yet.
10619−
10620−Trust in the security, continuity, and general maturity of Urbit needs to
10621−develop gradually. An Urbit that isn't ready to store crypto-assets can still
10622−be a great product. But it can't be a great product if its supposedly valuable
10623−keys are in fact insecure, yet needed to operate on the network.
10624−
10625−In short: we can't follow this original plan. It has the same chicken-egg
10626−problem we discussed [last time](https://urbit.org/blog/2017.9.20-bootstrapping-urbit-from-ethereum/).
10627−
10628−## An Urbit consensus engine?
10629−
10630−Urbit is itself a deterministic computer. Building a consensus computer within
10631−Urbit, which is actually a general-purpose OS, is an attractive long-term
10632−possibility.
10633−
10634−But Urbit lacks the principal feature of Ethereum: deterministic performance.
10635−In both Ethereum and Urbit, the semantics of a computation are precisely
10636−defined. In Ethereum, the computation's cost is also precisely defined.
10637−
10638−This would be quite hard to do in Urbit. We traded deterministic performance
10639−off for semantic simplicity. Designing a consensus computer without a
10640−performance definition is a research problem.
10641−
10642−We have solved a number of research problems here at Urbit. Could we build an
10643−Urbit blockchain? This problem doesn't seem utterly intractable. For instance,
10644−we could leverage the semi-trusted hierarchy in some direction resembling proof
10645−of stake.
10646−
10647−One thing is certain, though: research problems don't solve themselves
10648−overnight. If you have any ideas on this one, give us a holler.
10649−
10650−In any case, if Urbit got its own consensus engine, it's obvious that we'd
10651−simply copy the state of the Urbit PKI on Ethereum, and shut it down. Or we
10652−could migrate to another computational blockchain which works better than
10653−Ethereum.
10654−
10655−## An existing computational blockchain
10656−
10657−So we need an existing, mature, computational blockchain. There are only two
10658−major candidates: ETH and ETC (Ethereum Classic).
10659−
10660−It's no secret that we prefer the governance model of ETC. It's also no secret
10661−that the whole Ethereum system, especially Solidity, isn't exactly put together
10662−in the way we would do it.
10663−
10664−But an optimal governance model is just one virtue among many others we need to
10665−consider. ETH's network capitalization is 25x that of ETC. Its hashrate is 15x.
10666−Its tooling support -- in software, hardware, vaulting, exchanging, etc -- is
10667−considerably stronger.
10668−
10669−ETC's governance model is Bitcoin's: code is law. For the network, this is
10670−better. But we are considering threats to Urbit, not threats to the rest of
10671−Ethereum.
10672−
10673−ETH has embraced discretionary human governance. It's quite plausible that this
10674−will lead to total political collapse. But the human political structure of ETH
10675−seems reasonably strong at the moment. It's relatively difficult to imagine
10676−successful, near-term "proof of Vitalik" attacks via Ethereum on Urbit. Political
10677−conflict tends to develop over longer periods of time, giving us room to migrate.
10678−
10679−Ultimately we decided that the minority power of ETC outweighs the governance
10680−issues with ETH. This is of course how imperfect standards win. Betamax had
10681−better resolution than VHS.
10682−
10683−## One reminder
10684−
10685−For Bitcoin maximalists in particular (some of our best friends are Bitcoin
10686−maximalists), it's important to note that (besides the gas price of
10687−transactions) putting Urbit on Ethereum _does not create any net monetary demand
10688−for Ethereum_.
10689−
10690−Yes, you will get an Urbit ship through an Ethereum transaction. However, no
10691−value stays in ether. If you want to buy a ship with bitcoin, you are just
10692−going through a conversion layer. These conversion layers work pretty well
10693−these days. If you have a religious objection to handling altcoins, have a
10694−friend help.
10695−
10696−Bitcoin maximalists understand that all monetary energy should concentrate in a
10697−single currency. But land isn't money. And the technical details of the
10698−implementation of the Urbit registry -- whether `OP_RETURN`, Ethereum, or GitHub
10699−-- have no effect on Bitcoin supply and demand.
10700−
10701−## Another reminder
10702−
10703−Ethereum is not using Urbit. Urbit is using Ethereum. We know every cool
10704−alternative band that gets signed to a major label says this, but we mean it.
10705−
10706−Urbit, as a land registry, is almost a textbook example of very weak, boring use
10707−of a computational blockchain. We're not expecting a lot out of Ethereum.
10708−Ethereum does not feel like a system whose technical envelope should be pushed.
10709−We have no intention of pushing it.
10710−
10711−Moreover, the ability to vote formally in an Ethereum constitution will allow us
10712−to migrate in a cohesive way to _any other formalization of the Urbit PKI_.
10713−This could be another Ethereum contract. Or another blockchain.
10714−
10715−This "clean escape" implies that Ethereum is still operating normally, or at
10716−least normally enough to conduct a galaxy vote. What could happen to Ethereum?
10717−The blockchain could stop generating new blocks; it could fork; it could be
10718−filtered by some kind of collective attacker; it could even start accepting invalid transactions. What seems implausible is destruction of all copies of the whole chain.
10719−
10720−When Ethereum ceases to be functional or trustworthy for any reason, a "dirty
10721−escape" becomes necessary. The galaxy operators need to identify the last point
10722−in the Ethereum chain at which the Urbit constitution remains valid, copy that
10723−data to the new primary record, and resume from there.
10724−
10725−But unlike other blockchains that have wrestled with human-centric governance,
10726−Urbit still has a formal procedure for making this decision. With the Ethereum
10727−chain compromised, we no longer have an automated system that implements the
10728−rules. The rules remain, though. Humans have spent thousands of years
10729−following non-automated rules.
10730−
10731−Basically, we're just using ETH as a self-validating ownership record. So long
10732−as the chain isn't destroyed and owners retain their secrets, Urbit retains the
10733−power to migrate to any record that works better.
10734−
10735−## And one literally constructive criticism
10736−
10737−One excellent criticism (credited to `@sorpaas`) is that just having the Urbit
10738−galaxies mirror the state of Urbit's Ethereum constitution is insufficient.
10739−This design gives Urbit nodes a choice: either mirror the whole Ethereum
10740−blockchain (which is ginormous and certainly not shrinking), or don't validate
10741−the Urbit PKI at all.
10742−
10743−In Urbit, if your parent galaxy is sending you fraudulent reports about the
10744−blockchain (any blockchain), you have a very serious problem which goes way
10745−past blockchains. It's time to switch galaxies.
10746−
10747−The trust relationship between an urbit and its parent is like the trust
10748−relationship between you and a gas station. For all you know, what's coming
10749−out of the hose could be Welch's grape juice. But why have you never, ever worried about cheap surplus vegetable products destroying your engine?
10750−
10751−ExxonMobil has no business motivation to ruin its customers' engines. If it
10752−did, it would just destroy its business, and gain… what? If you don't have an
10753−attack motivation, you don't have a threat model. If you don't have a threat
10754−model, you don't have a threat. This is why we don't tend to worry about
10755−"parent attacks" in Urbit.
10756−
10757−But that said: there's no reason not to make Urbit's cryptographic structure as
10758−strong as possible. If you don't want to trust your gas station -- you
10759−shouldn't have to. We don't need to eliminate reliance on trust. We do prefer
10760−to _minimize_ it.
10761−
10762−Therefore, the Urbit Ethereum mirror needs to track all the Ethereum
10763−transactions that touch the Urbit constitution, and propagate these raw
10764−transactions into Urbit. Urbit nodes can check the transactions and their
10765−signatures themselves, without relying on Ethereum. Then, anyone in Urbit can
10766−validate the Urbit PKI without an Ethereum node.
10767−
10768−(We don't anticipate running a node _in_ Urbit, eg an EVM in Hoon -- for now,
10769−galaxies will just RPC to a local Unix node.)
10770−
10771−## And in closing
10772−
10773−We appreciate everyone's feedback and hope no one remains confused.
10774−
10775−We're happy to address any remaining concerns -- and happier still if someone
10776−finds a mistake on our end. If you have a good counterargument, now is better
10777−than later!
10778−
10779−Fora thread for discussion is here:
10780−[urbit.org/fora/posts/~2017.9.25..20.34.38..8e27~](https://urbit.org/fora/posts/~2017.9.25..20.34.38..8e27~).
10781−]]></content:encoded>
10782− </item>
10783− <item>
10784− <title><![CDATA[~2017.9.23 Update]]></title>
10785− <link>https://urbit.org/updates/2017-9-23-update</link>
10786− <guid>https://urbit.org/updates/2017-9-23-update</guid>
10787− <pubDate>Fri, 22 Sep 2017 00:00:00 GMT</pubDate>
10788− <content:encoded>< blog post. [Discussion on
10792− Fora](https://urbit.org/fora/posts/~2017.9.20..22.56.04..47ce~)
10793−- A [Hoon cheat sheet](https://storage.googleapis.com/media.urbit.org/docs/hoon-cheat-sheet-08-26-17.pdf) by
10794− `~rovnys-ricfer`. [Discussion on Fora](https://urbit.org/fora/posts/~2017.9.18..22.31.06..24d5~)
10795−- [On Searching Filesystems](https://urbit.org/fora/posts/~2017.9.16..06.19.33..72a4~) by `~littel-ponnys`
10796−- [Mars Talks, Ep. 0](https://www.youtube.com/watch?v=LFalNG4eTqU) hosted by `~taglux-nidsep` with guest `~rovnys-ricfer`
10797− of Tlon on the fundamentals of Urbit. [Discussion on Fora](https://urbit.org/fora/posts/~2017.9.21..04.31.08..9ae7~)
10798−- [Exploring Urbit](https://www.youtube.com/watch?v=OOQ2Do6jAi4) by Jordan Leigh of Decypher Media with guest
10799− `~tonlur-sarret` of Tlon. [Discussion on Fora](https://urbit.org/fora/posts/~2017.9.22..23.09.25..c613~)
10800−- [To Understand Blockchains, You Should Understand Cryptographic Hashes
10801− First](https://fitseb-ropnux.urbit.org/blog/Cryptography2/) by `~fitseb-ropnux`. [Discussion on
10802− Fora](https://urbit.org/fora/posts/~2017.9.19..18.39.11..ebaa~/)
10803−]]></content:encoded>
10804− </item>
10805− <item>
10806− <title><![CDATA[Bootstrapping Urbit from Ethereum]]></title>
10807− <link>https://urbit.org/blog/bootstrapping-urbit-from-ethereum</link>
10808− <guid>https://urbit.org/blog/bootstrapping-urbit-from-ethereum</guid>
10809− <pubDate>Tue, 19 Sep 2017 00:00:00 GMT</pubDate>
10810− <content:encoded>< to MVP. Urbit under
10903−construction is fun to play around in. But we certainly won't ask real users or
10904−real developers to set foot in Urbit until their experience is truly simple,
10905−lovable and complete. The original iPhone set the bar for this, and we'll get
10906−as close as we can.
10907−
10908−### The case for Ethereum
10909−
10910−It's obvious that Urbit has a practical problem in deploying a self-hosted PKI.
10911−When does the testnet become a realnet? You wouldn't put real, valuable keys in
10912−your urbit, until you know the system is mature and secure.
10913−
10914−But how does anyone know that Urbit is mature until more daring users have used
10915−it with real, valuable keys? But who wants to be the first person to hop into
10916−the box?
10917−
10918−There is no clear way to bootstrap past the testnet phase. Except, well, reboot
10919−Urbit onto an existing blockchain, with a tested and reasonably-secure
10920−key-handling infrastructure, that can also validate the Urbit PKI rules. Then
10921−each user can decide on their own whether sensitive data is safe in their own
10922−urbit.
10923−
10924−## An Urbit refresher
10925−
10926−Maybe some people are here because they know what Ethereum is, but not so much
10927−Urbit.
10928−
10929−For those of you not familiar, let's try to refresh your memories.
10930−
10931−### What Urbit is
10932−
10933−One simple way to think about Urbit is as a "personal blockchain." Like a
10934−blockchain, Urbit is a deterministic virtual computer. Its semantics are defined
10935−by a frozen lifecycle function, which maps its event history to its current
10936−state. But, unlike a blockchain, an Urbit instance is a private computer for one
10937−user, not a public record for everyone.
10938−
10939−Urbit's lifecycle function is a nano-interpreter called Nock. A typed functional
10940−language, Hoon, compiles itself to Nock. An event-driven OS, Arvo, is written in
10941−Hoon. Everything above Nock can upgrade itself over Urbit's own overlay packet
10942−network, Ames. Ames is live and stable with test keys.
10943−
10944−Our Urbit interpreter runs on any Unix machine. The Urbit server is a
10945−single-level store -- both database and application engine. Every Urbit event is
10946−a transaction. Urbit is semantically frozen and cannot call out to Unix.
10947−
10948−Your Urbit instance is your personal server. Your urbit should eventually
10949−contain and manage your whole digital life. You may compute at home or in the
10950−cloud, based on your security/privacy tradeoff, but Urbit's formal semantics
10951−makes ships trivial to migrate. You'll never be locked in to one computing
10952−provider.
10953−
10954−### The Urbit address space
10955−
10956−An Urbit address is called a "ship." A ship is a network address, a
10957−cryptographic identity, a pronounceable name, and a permanent memory. A ship's
10958−name is just its numeric address, written in a syllabic base-256.
10959−
10960−Smaller addresses mean shorter, more memorable ships. Ships are classified in a
10961−hierarchy: 8-bit "galaxies" (like `~dyl`), 16-bit "stars," (`~ropdyl`), and
10962−32-bit "planets" (`~ravmel-ropdyl`). Galaxies and stars are network
10963−infrastructure. Regular users have planets. The tight 32-bit address space makes
10964−names short enough to remember, and costly enough to deter Sybil attacks.
10965−
10966−Planets are created by their prefix star; stars are created by their prefix
10967−galaxy; galaxies were created by the founders. Parents assist their children,
10968−providing essential services like peer-to-peer packet routing, but don't own or
10969−control them. The prefix is just an initial default -- a ship can switch to any
10970−parent that's willing to adopt it.
10971−
10972−## Summary of the integration model
10973−
10974−In the new integrated model, every planet, galaxy or star is owned by an
10975−Ethereum address. The secret that controls this address is the ship's "master
10976−key."
10977−
10978−The master key is not needed to operate the ship and should not be stored on it,
10979−at least not until Urbit is more mature. Master keys should be kept as "cold" as
10980−possible. They are only used to perform lifecycle operations on your ship, by
10981−signing Ethereum transactions which are sent to the Urbit constitution.
10982−
10983−We'll fork an open-source Ethereum browser and add a custom UI for Urbit
10984−transactions. New users will acquire their urbits entirely on the blockchain.
10985−
10986−The most basic Urbit transaction is starting a ship you own. To start your ship,
10987−you use Urbit to generate an Urbit keypair, and use Ethereum to register the
10988−Urbit public key (a 512-bit pair of Curve25519 for encryption and Ed25519 for
10989−signature) on the Ethereum blockchain.
10990−
10991−For users who want to hold generic stars without starting or even selecting
10992−specific ships, we'll create a divisible "spark" (USP) ERC20 token. A spark is
10993−the right to create one star. Sparks are a convenience tool: they leverage the
10994−mature ERC20 infrastructure for holding and trading token utility rights.
10995−
10996−Instead of launching stars directly, galaxies can cede their unlaunched stars to
10997−the Urbit constitution. The issuing galaxy receives one spark in exchange for
10998−this star. Any Ethereum address can redeem one spark in exchange for the right
10999−to start one star from the constitution's pool.
11000−
11001−Once all the galaxies are created, Urbit is fully decentralized. We retain no
11002−ownership powers over the Urbit constitution.
11003−
11004−The Urbit galaxies will mirror the state of the constitution, distribute its
11005−state and events within Urbit, and post any transactions created within Urbit.
11006−Generally an Urbit ship trusts its parent -- if not, it should find a new one
11007−fast. But a deeply paranoid ship can still listen to Ethereum directly.
11008−
11009−## Contract designs
11010−
11011−The Urbit constitution is four contracts: certificate storage, spark storage,
11012−election storage, and logic controller.
11013−
11014−Following Ethereum best practice, we'll use separate storage and logic
11015−contracts. The logic contract is stateless, and can upgrade itself without
11016−replacing the storage contracts.
11017−
11018−We'll walk through how we have designed these contracts in detail here. You can
11019−also view our in-progress source at the
11020−[`urbit/azimuth` GitHub repo](https://github.com/urbit/azimuth).
11021−
11022−### Certificate storage contract
11023−
11024−For every galaxy, star or planet, the certificate contract holds a current
11025−state: `%latent`, `%locked`, `%liquid` or `%living`.
11026−
11027−The default/empty state is `%latent` (nothing has happened to this ship). The
11028−contract stores no data for a latent ship.
11029−
11030−A `%locked` ship has an owner and an activation date. It cannot be activated
11031−until the given date. Until activated, the locked ship can't be transferred,
11032−vote, liquidate or launch children.
11033−
11034−A `%liquid` ship is held by the Urbit constitution to be redeemed for a spark.
11035−It has no other state.
11036−
11037−A `%living` ship is active. Its state: an Ethereum address which owns it; an
11038−Urbit public key; a revision number, which increments on any lifecycle
11039−operation; and (for planets and stars) both current and requested (for escaping)
11040−parent ships.
11041−
11042−The certificate contract throws an event on every state change.
11043−
11044−### Spark storage contract
11045−
11046−The spark contract is a divisible ERC20 token (you can't hold half a star, but
11047−you can hold half a spark). Only the logic contract can create and destroy
11048−tokens.
11049−
11050−### Governance storage contract
11051−
11052−The governance contract records galaxies' votes on governance proposals.
11053−
11054−There are two kinds of proposals: concrete and abstract. A concrete proposal is
11055−the address of a new logic contract for the constitution. An abstract proposal
11056−is the hash of a document.
11057−
11058−Voting is one-bit -- the default vote is "no" -- and irreversible. A 256-bit
11059−bitfield records the set of galaxies that have voted for each proposal.
11060−
11061−Only active galaxies may vote. A counter records the number of active galaxies.
11062−A proposal passes if more than 50% of active galaxies support it. If the
11063−proposal is concrete, the old logic contract is terminated and the new one
11064−receives storage control. Abstract proposals have no further effects on the
11065−blockchain.
11066−
11067−### Logic contract
11068−
11069−The logic contract is stateless and supports the following ops:
11070−
11071−#### Create a galaxy
11072−
11073−What: move a galaxy from `%latent` to `%locked` state.
11074−
11075−Who: the founders only.
11076−
11077−Comments: this is the only founder-privileged operation.
11078−
11079−#### Liquidate a star
11080−
11081−What: move a specific star from `%latent` to `%liquid` state, granting one spark
11082−to the galaxy owner.
11083−
11084−Who: owner of the active galaxy which is the star's prefix.
11085−
11086−#### Claim a star
11087−
11088−What: move a specific star from `%liquid` to `%locked` state, with the
11089−activation date set to the present, and the owner as claimer; remove one spark
11090−from the owner.
11091−
11092−Who: any Ethereum address which owns a spark.
11093−
11094−#### Launch a star or planet
11095−
11096−What: move a specific star or planet from `%latent` to `%locked` state, with the
11097−activation date set to the present, and set the Ethereum address which owns the
11098−ship.
11099−
11100−Who: owner of the parent of the launched ship.
11101−
11102−#### Start a ship
11103−
11104−What: move a specific ship from `%locked` to `%living` state, setting its Urbit
11105−public key.
11106−
11107−Who: owner of the locked ship.
11108−
11109−#### Transfer a ship
11110−
11111−What: change the owner of a `%living` ship, also resetting the Urbit public key.
11112−
11113−Who: current owner of the ship.
11114−
11115−#### Rekey a ship
11116−
11117−What: in a living ship, change the Urbit public key, without changing the
11118−Ethereum address that owns the ship.
11119−
11120−Who: owner of the ship.
11121−
11122−#### Request adoption
11123−
11124−What: in a living ship, set the requested-parent field.
11125−
11126−Who: owner of the ship.
11127−
11128−#### Accept adoption
11129−
11130−What: in a living ship, set the current parent to the requested parent, and
11131−clear the requested parent.
11132−
11133−Who: owner of the requested parent.
11134−
11135−#### Create a proposal
11136−
11137−What: create a proposal, which is either the hash of a document (abstract) or
11138−the address of a new logic contract (concrete).
11139−
11140−Who: owner of any living galaxy.
11141−
11142−#### Endorse a proposal
11143−
11144−What: register support for a proposal. If the proposal is concrete and this
11145−vote takes it over 50%, upgrade the contract.
11146−
11147−Who: any galaxy who has not yet voted on this proposal.
11148−
11149−### Planet sales and spark auctions
11150−
11151−We'll also write contracts that help galaxies and stars distribute their stars
11152−and planets.
11153−
11154−#### An auction contract for spark sales
11155−
11156−The ERC20 spark token creates a liquid market in stars, or rather star
11157−precursors. But a galaxy liquidating sparks may not want to just sell a large
11158−block into this market, which may have weak depth, especially when the token is
11159−initially launched.
11160−
11161−So we'll validate and deploy the Nick Johnson design for an
11162−[off-chain second-price auction](https://www.reddit.com/r/ethereum/comments/6igsdq/a_proofofconcept_of_a_better_crowdsale_contract/)
11163−
11164−To run an auction, the seller liquidates a block of stars, then transfers the
11165−spark tokens to a seller-owned copy of the auction contract. The Urbit
11166−constitution is not involved with the auction.
11167−
11168−#### A distribution contract for planet sales
11169−
11170−There is no generic token for planets. To start a planet, you need a star to
11171−launch it with your Ethereum address as the owner.
11172−
11173−To distribute planets on the blockchain, a star instantiates a private copy of
11174−the planet sale contract. Since the star is the contract's owner, the contract
11175−can send launch operations to the Urbit constitution.
11176−
11177−The star owner configures the planet sale contract with two parameters: the
11178−price in ether of a planet, and the number of planets available.
11179−
11180−## Okay, so
11181−
11182−That was quite a lot of information! There's also a blog post about the constitution
11183−[here](https://urbit.org/blog/interim-constitution/), and GitHub issues on the
11184−[urbit/azimuth repo](https://github.com/urbit/azimuth) are more
11185−than welcome.
11186−
11187−There's a lot more to come on this front as our contracts get closer to getting
11188−live, and we begin migrating toward an on-chain Urbit PKI.
11189−]]></content:encoded>
11190− </item>
11191− <item>
11192− <title><![CDATA[~2017.8.11 Update]]></title>
11193− <link>https://urbit.org/updates/2017-8-11-update</link>
11194− <guid>https://urbit.org/updates/2017-8-11-update</guid>
11195− <pubDate>Thu, 10 Aug 2017 00:00:00 GMT</pubDate>
11196− <content:encoded><
11225−
11226−Currently, all of Urbit's CSS and styling is based on Bootstrap. It's not a
11227−very good fit. We do a lot of work to override the default styles.
11228−
11229−While we were improving some of our example apps a little while back it became
11230−obvious that we need our own base CSS and style guide. So, we went ahead and
11231−started down that path. After years of working with other CSS frameworks, it's
11232−a relief to be producing one that's purpose-built for Urbit itself.
11233−
11234−Urbit is a tool, so its branding needs to be completely calm and quiet. It
11235−can't get in the way. In a way, a CSS framework is the brand itself. Urbit
11236−isn't a logo or a tagline — it's a look and feel. This way, it's a look and
11237−feel that you can also send pull requests to.
11238−
11239−There's a working prototype of this style guide today, and we'll publish a repo
11240−sometime in the next week or two. Hopefully some substantive design discussions
11241−can be had in connection with the code itself.
11242−
11243−### Write, talk, socialize
11244−
11245−
11246−
11247−We already use Urbit to chat and write, but the edges are pretty rough. Better,
11248−faster publishing and a look and feel refresh will allow us to update and clean
11249−up our existing tools for chatting and writing. Hopefully to the point that
11250−they clear the 'Facebook 2004' bar. But, of course, in a pretty different way.
11251−
11252−## Examples
11253−
11254−
11255−
11256−Also, our examples repo is now hosted on Urbit itself. You can just `|sync` a
11257−desk and open a URL on your own Urbit to view the examples.
11258−
11259−Try it yourself! The instructions are in
11260−[this fora post](https://urbit.org/fora/posts/~2017.8.3..20.53.26..c361~/).
11261−If you've got ideas for examples to contribute, that'd be great.
11262−The source is on [GitHub](https://github.com/urbit/examples).
11263−`~poldec-tonteg` just contributed his Tumblr connector, which he is also using
11264−to syndicate his Tumblr through Urbit.
11265−[Check it out](http://poldec-tonteg.urbit.org/portal.html).
11266−
11267−## Remaint
11268−
11269−The last test network managed to stay up for about a year. That's pretty good!
11270−During that time we discovered a few bugs that would cause urbits to end up in
11271−one-way-connectivity. A short explanation is that remote crashes would often
11272−not get properly passed back to the requesting ship.
11273−
11274−So we fixed that. We could probably hack this change in via an OTA update, but
11275−it's much easier to breach this change in, and it'll be great to have it out on
11276−the network. So, we'll be doing a breach once the code has been properly
11277−tested.
11278−
11279−## Urbit + ETH
11280−
11281−Finally, we've been working on a design for how Urbit can bootstrap itself off
11282−of the Ethereum blockchain. We have a loose specification of how this could
11283−happen, and will present those at the meetup
11284−[tonight](https://www.meetup.com/urbit-sf/events/242295411/). Come, critique
11285−and ask questions. We'll publish what we come up with in the coming weeks.
11286−
11287−## Keep in touch
11288−
11289−As usual, discussion is on fora:
11290−[fora/posts/~2017.8.11..21.45.52..4296~](https://urbit.org/fora/posts/~2017.8.11..21.45.52..4296~).
11291−
11292−Also, we managed to get the `@urbit` Twitter handle:
11293−[https://twitter.com/urbit/status/895698846918909952](https://twitter.com/urbit/status/895698846918909952).
11294−Finally!
11295−]]></content:encoded>
11296− </item>
11297− <item>
11298− <title><![CDATA[~2017.5.11 Roadmap]]></title>
11299− <link>https://urbit.org/updates/2017-5-11-roadmap</link>
11300− <guid>https://urbit.org/updates/2017-5-11-roadmap</guid>
11301− <pubDate>Wed, 10 May 2017 00:00:00 GMT</pubDate>
11302− <content:encoded><.
11325−
11326−Our rocket unicycle is a lot more awesome than a Chevy. But it demands more
11327−custom engineering. We have to invent every little widget as we need it.
11328−Usually that involves rebuilding it two or three times (see the (see the [long-term
11329−strategy](/essays/toward-a-frozen-operating-system/)). This process converges
11330−from the bottom of the stack up, and accelerates as our progress advances.
11331−
11332−Nock, which is now frozen, and which is a page of pseudocode, took from 2002 to
11333−2008 to invent. Hoon took from 2008 to 2012, and is stable but not frozen. All
11334−the real technical problems in 2016 Urbit are either in the top layers (Arvo,
11335−its vanes and apps), or outside Urbit proper (Vere, the Unix event processor).
11336−
11337−Except for one major component (the security vault `%jael`), there isn't any
11338−single big thing wrong with 2016 Arvo or Vere. In retrospect, they can even be
11339−seen as inspired stabs in the right direction. But hammering square pegs into
11340−round holes isn't the Urbit way.
11341−
11342−If we made our AVP into an MVP by straight-out _debugging_, we'd be limping
11343−across the finish line. An MVP must be minimal in affordances. In its
11344−aesthetics, it must be sublime. It has the rest of its life to grow features,
11345−but beauty only fades.
11346−
11347−## A parallel process
11348−
11349−Architecture is entropy in reverse. Urbit has to become _more_ elegant, as it
11350−becomes more functional. This delicate process must be carefully controlled.
11351−
11352−To keep Urbit on the path to absolute zero, we have to work in three directions at
11353−the same time:
11354−
11355−- Stabilizing the Urbit infrastructure
11356−- Developing the Urbit user experience
11357−- Documenting the Urbit system
11358−
11359−Pushing in all three directions at once keeps the whole project in balance. We
11360−could drop any two of these goals and head at top speed for the other. This
11361−would produce a nice simulation of doneness in a single dimension.
11362−
11363−But if we just hardened our infrastructure from the bottom up, we wouldn't be
11364−responding to the needs of the user experience. If we just built a user
11365−experience on top of our prototype infrastructure, it wouldn't be stable enough
11366−to be usable. If we documented the prototype, it would become much harder to
11367−revise. And so on.
11368−
11369−And the balance between these directions shifts with the seasons. After
11370−spending the fall and winter writing infrastructure, and the spring testing it,
11371−it'll be time to spend summer and fall working toward the user and the
11372−developer.
11373−
11374−## Since the last crowdsale
11375−
11376−Maybe this is too vague. What we actually did since the last crowdsale:
11377−
11378−We replaced about half the Unix interpreter (the whole `vere` directory, event
11379−handing and storage), and about a third of Arvo: the lifecycle function, boot
11380−sequence and kernel `%arvo`, the network `%ames`, the PKI (adding a new security
11381−module `%jael`), the console `:drum`, and the `:talk` app. If Arvo was a car, we
11382−replaced the powertrain.
11383−
11384−At the Hoon level, we added formal docstrings and reorganized (or rather,
11385−organized) the kernel and standard library. At the Nock level, we of course did
11386−nothing. And on the client side, we redesigned the Web API, and prototyped a
11387−completely new Urbit user experience. And all the new code is high-quality,
11388−fully documented, and generally ready for anyone to copy and/or abuse.
11389−
11390−This `cc-release` (continuity candidate) isn't quite done — the Arvo code is
11391−written but not fully tested, and one module (the application sandbox `%gall`)
11392−is still waiting for its rewrite. But the new Arvo has that "not quite perfect,
11393−but basically right" feeling of architectural doneness which Hoon has had for a
11394−while.
11395−
11396−Note that we remain a super-tiny team. We've had some serious outside
11397−contributions, but clean loose ends that outsiders can pull on remain
11398−frustratingly scarce. Hoon is too stable and Arvo is too unstable.
11399−Architectural work scales poorly in personnel, and you can't really renovate a
11400−house while people are trying to live in it.
11401−
11402−## Moving forward
11403−
11404−After `cc-release` this summer, we'll move from bottom-up, infrastructure-driven
11405−engineering, to top-down, user-driven engineering. Naturally this is
11406−`dd-release` (deck-directed).
11407−
11408−Our planning target is a stable, useful Urbit we can ship in 2017. Since we're
11409−working top-down, we can abandon the deep architectural essays and work, like
11410−normal human beings, from an illegible list of features scribbled on a
11411−poorly-erased whiteboard.
11412−
11413−## A whiteboard list
11414−
11415−Our feature list for `dd-release`, in no particular order:
11416−
11417−- The top-level `:deck` UI, an interaction multiplexer like GNU screen, but for
11418− terminals or web consoles. (The front end of `:deck` is a working prototype
11419− now.)
11420−
11421−- The "helpful console," which offers contextual help and lets you construct any
11422− dojo command with a wizard-style UI. The three-way combination of a command
11423− parser, contextual completion and help, and webform input, may be our most
11424− interesting little challenge. We think we know to do it.
11425−
11426−- Useful, well-designed web API integrations which contributors can easily clone
11427− to extend Urbit's reach. Stars can proxy APIs for their planets, metering
11428− free service.
11429−
11430−- Integrations for email and SMS are live, so that any ship can at least message
11431− its owner. A storage integration to S3, etc, lets us save external blobs. A
11432− DNS integration lets us forward ship.urbit.org to ships with public IPs.
11433−
11434−- Real keys are ready to be born. An instantiation protocol for the real Urbit
11435− keys exists and has received some public review. The current options:
11436− physical delivery of tamper-resistant artifacts, or registering ownership on
11437− Ethereum or another blockchain. (We'll release a separate essay on this
11438− question soon.)
11439−
11440−- All key updates at the planet level or above are propagated hierarchically
11441− across the network. An offline key can block all transfers. Planet owners
11442− can invite their friends to a self-hosted conversation with webmoons (guest
11443− accounts).
11444−
11445−- The `%eyre` HTTP server is cleaned up and its API simplified. Web
11446− programmers see a clear, CQRS-based query and subscription interface in JSON.
11447− A cookie makes your browser into a virtual moon, with a unique causal identity
11448− for each page instance.
11449−
11450−- No user operation can damage the ship, which can be reset to factory condition
11451− with just the private key.
11452−
11453−- Personal urbits on a home computer don't lose data, except in case of
11454− system/OS failure. Mutual exclusion on interrupt handlers is perfect.
11455− Timeouts, crashes, and user interrupts are handled perfectly. Snapshot
11456− handling is asynchronous and uses two A/B images.
11457−
11458−- Urbits are configured to rotate logs by default, so they don't grow
11459− infinitely. All caches have continuous expiration, and out-of-memory can't
11460− sink a ship. The Web server is secure and has adequate performance without
11461− an external cache or any auxiliary servers.
11462−
11463−- Urbit can connect its event loop to Kafka or a similar event replication
11464− service. Replicated urbits on a hosted service don't lose data, except
11465− through acts of God or government.
11466−
11467−- One star on a normal virtual host can comfortably manage at least 256 active
11468− planets. Dormant planets consume minimal local or remote resources.
11469−
11470−- The whole Urbit stack is managed with telescoping Kelvin numbers. Upgrades
11471− succeed perfectly or crash the transaction. The stack is permanently
11472− upgradeable, even for backward-incompatible changes in Hoon.
11473−
11474−- Hand maintenance is only needed to upgrade the Unix interpreter, vere. The
11475− owner gets a notification when an obsolete `vere` blocks an Urbit update.
11476−
11477−- The new security masks are respected across all vanes. The revision-control
11478− system `%clay` has permission masks. Untrusted code can be installed as a
11479− gateway to a foreign service with same-origin network permissions.
11480−
11481−- Backward-incompatible changes in the Hoon language or Hoon libraries are
11482− unlikely. But the Arvo upgrade mechanism can make arbitrary Hoon changes,
11483− compatible or not.
11484−
11485−- All major Arvo subsystems are architecturally stable. Namespaces, cards, URL
11486− routes, the boot sequence, and the upgrade model, are well-specified. Further
11487− change in these specs will involve a slow-track community process. But the
11488− definitions are stable enough to be taught.
11489−
11490−- Architectural overviews of all major Arvo components are attached to the
11491− source code. Tutorial documentation for both Hoon and Arvo is good enough to
11492− lead a naive programmer up through building a web API gateway (server side
11493− Hoon) and a web agent (client side JS).
11494−
11495−- Urbit stores and manages all Urbit-related development metadata: todos, bugs,
11496− releases, PRs, discussion, etc. It routes this metadata through `:talk` and
11497− logs it to `%clay`.
11498−
11499−- A precise system coding convention is in place and enforced, if only by
11500− measurement. All code in Urbit is graded A, B, or C. Grade A Hoon ("Prime")
11501− is well-structured and well-explained. Grade B ("Select") is well-structured,
11502− but not well-explained. Grade C ("Choice") is still great code, but its
11503− style or technique may not meet our latest standards.
11504−
11505−- All code in Urbit except `++ut` (the compiler itself) is grade B. (We can
11506− relax standards on the compiler because it tests itself so thoroughly.) All
11507− code on the Arvo powertrain (`%arvo`, `%ames`, `%jael`, `%gall`, `:dojo`,
11508− `:helm`) is grade A.
11509−
11510−If you know the current maintenance Urbit, you know that most of these features
11511−are mostly in sight. None of them is exactly _quite_ complete. None of them is
11512−anywhere near a stretch. We have significant parts of all of them.
11513−
11514−Also, since this is the release after the release we're doing now, we're
11515−probably missing as many checkboxes as we've caught. And triage is a thing
11516−that happens. It's really better understood as the _kind_ of work we're going
11517−to do.
11518−
11519−We'd really like to get all these things done in 2017. But a lot depends on
11520−what kinds of resources we have access to. And of course, as we document the
11521−system, it gets easier for all the people who believe in Urbit to help us build
11522−it.
11523−
11524−As usual, comments are on fora. Check out
11525−[this thread](https://urbit.org/fora/posts/~2017.5.12..20.33.04..3db0~/).
11526−]]></content:encoded>
11527− </item>
11528− <item>
11529− <title><![CDATA[Toward a Frozen Operating System]]></title>
11530− <link>https://urbit.org/blog/toward-a-frozen-operating-system</link>
11531− <guid>https://urbit.org/blog/toward-a-frozen-operating-system</guid>
11532− <pubDate>Tue, 09 May 2017 00:00:00 GMT</pubDate>
11533− <content:encoded>< about the
11541−"hundred-year language," but the language is only one part of any complete
11542−platform. And in infrastructure terms, a hundred years isn't that long.
11543−
11544−Why not think of structures that have lasted _thousands_ of years? An aqueduct,
11545−a pyramid, a Parthenon? Why set our sights lower? Why isn't it time to aim for
11546−perfect and timeless code? If not now, when?
11547−
11548−## Scope of the problem
11549−
11550−More prosaically, a frozen OS just means your OS never changes. A frozen OS
11551−never gets any updates. Not because it can't update itself, just because it
11552−doesn't need to.
11553−
11554−Is this even a meaningful concept? A frozen OS? First we'll have to decide
11555−what "OS" even means. Certainly, if "OS" means "the code that your hardware
11556−boots into," hardware always changes and so will the OS.
11557−
11558−A broader, more useful definition: the "OS" is _an opaque model of a persistent
11559−general-purpose computer_. This definition allows for arbitrary levels of
11560−virtualization. Linux on a droplet is an OS. A browser is an OS, because it's
11561−persistent (sorta) and opaque. But `node.js` is not an OS, because it's not
11562−opaque: it exports Linux system calls.
11563−
11564−Within this opaque model, we have to decide what's "system" and "user" software.
11565−It clearly makes no sense to freeze userspace. Let's use the
11566−[trusted codebase](https://en.wikipedia.org/wiki/Trusted_computing_base): code
11567−is system software, if compromising it would compromise the whole system.
11568−
11569−## Infinite maturity
11570−
11571−It's important to remember that just because a system is designed to achieve
11572−frozenness, doesn't mean it's useless until it's frozen. It doesn't even mean
11573−it's immature. It just means that in the very long term, the system's maturity
11574−goals are infinite.
11575−
11576−Systems designed to diverge infinitely (with normal X.X.X semantic versioning),
11577−even those designed to converge infinitely (as with
11578−[Knuth versioning](http://www.tex.ac.uk/FAQ-TeXfuture.html)), also achieve
11579−maturity, often great maturity, without being quite frozen.
11580−
11581−For example, C is a very mature language. C has long since mastered backward
11582−compatibility. We can be sure that any C program which compiles on today's
11583−correct C compilers will compile on any future correct C compiler.
11584−
11585−But, since C is not frozen, we can't be sure that today's C compilers will
11586−compile any future C program. So C has not yet achieved perfect _forward_
11587−compatibility. By definition, a frozen system is compatible both forward and
11588−backward. So C is mature, but it could still get more mature.
11589−
11590−The point of a frozen OS is to shoot for _infinite_ maturity. Obviously a
11591−frozen platform is compatible forever in both directions.
11592−
11593−Infinite maturity does exist in the real world. But only in a few simple file
11594−formats and protocols — IP, JSON, XML. And not all this maturity is the result
11595−of perfection. Some is just the accident of a missing update mechanism.
11596−
11597−But IP, JSON, XML... this is how stable, how taken for granted, system software
11598−should be. And can be. Certainly, any JSON parser today will parse any JSON
11599−document made in the future.
11600−
11601−The dream of absolute zero is an OS whose core components are so simple, so
11602−boring, and so mechanically straightforward that we can imagine them becoming
11603−finished and never changing. We need to freeze not just a format or a protocol,
11604−but a language, a kernel, a standard library. To succeed, we need to flush out
11605−each quirk, complexity, and creeping feature, until the system is so boring and
11606−obvious that no one even wants to change it.
11607−
11608−## Kelvin versioning
11609−
11610−"Kelvin versioning" is one way to track a project designed to be frozen.
11611−
11612−In Kelvin versioning, a version is an integer in degrees Kelvin. Absolute zero
11613−is frozen — no further updates are possible. If your Kelvin versions don't
11614−track your actual progress, you run out of integers. This danger is a concrete
11615−incentive for the project to track its own progress accurately.
11616−
11617−(Kelvin versioning isn't useful only at lifecycle scale. It can be used for any
11618−development process with an irreversible end — as build numbers for a release,
11619−for example.)
11620−
11621−## The palm-tree dependency model
11622−
11623−A whole OS can't have a single Kelvin number. It has to consist of multiple
11624−components which depend on each other. What's the right dependency model for
11625−the parts of a frozen OS?
11626−
11627−One way to think about dependencies across a whole OS is the "palm-tree model."
11628−Fundamentally, there are two kinds of components in a system: "exclusive"
11629−components (where we have to choose one version of the code), and "inclusive"
11630−ones (where different users can see different versions).
11631−
11632−The exclusive components are the trunk of the palm tree: a stack of layers, each
11633−of which has one active copy. For instance, you are only running one kernel at
11634−a time. Different apps cannot use different versions of the kernel.
11635−
11636−The inclusive components are the fronds, branching out in any direction they
11637−want. Not only can two apps use different versions of the same library, in
11638−many situations _one_ app needs to be able to use two different versions of the
11639−same library.
11640−
11641−## The palm trunk: telescoping Kelvins
11642−
11643−Any subsystem that serves as any kind of platform is exclusive, since anything
11644−that runs on top of the platform has to choose one version of the platform to
11645−run on. Since layers are good, this creates a natural stack which can get quite
11646−tall — and include components which are technically in userspace.
11647−
11648−The right way for this trunk to approach absolute zero is to "telescope" its
11649−Kelvin versions. The rules of telescoping are simple:
11650−
11651−1. If tool B sits on platform A, either both A and B must be at absolute zero,
11652− or B must be warmer than A.
11653−
11654−2. Whenever the temperature of A (the platform) declines, the temperature of B
11655− (the tool) must also decline.
11656−
11657−3. B must state the version of A it was developed against. A, when loading B,
11658− must state its own current version, and the warmest version of itself with which
11659− it's backward-compatible.
11660−
11661−Of course, if B itself is a platform on which some higher-level tool C depends,
11662−it must follow the same constraints recursively.
11663−
11664−The important effect of obeying rule 2: in a tall trunk, it's sufficient to
11665−state your dependency on the platform directly below you. Suppose C sits on B,
11666−which sits on A and exports features of A. C can state only the version of B
11667−it's written against, because when A chills, B must also chill.
11668−
11669−If A could chill without B chilling, we could modify C to use new features of A.
11670−Then our new C would silently fail to work on an A-B stack which had not
11671−received the A update.
11672−
11673−## The palm fronds: total flexibility
11674−
11675−The goal of the trunk is to get to the fronds. In the fronds, no one should
11676−ever worry about dependency conflicts. And nothing is ever frozen, or has to be
11677−frozen.
11678−
11679−The right way to solve dependencies in userspace is: within an organization, use
11680−a monorepo and link relative to its head. Between organizations, use pinned
11681−version numbers that are as immutable as possible. Avoid programming
11682−environments that create exclusion problems in userspace — for instance, that
11683−compel a single process to choose one version of a library when a diamond
11684−dependency exists.
11685−
11686−There is almost never any good reason to automatically update dependencies with
11687−fresh versions of foreign code. In the case of a security update, the
11688−maintainer of an app which depends on a patched library needs to catch the
11689−patch and propagate the update in a new version of the app. An app shouldn't be
11690−security-critical to begin with, and propagating updates is a basic function of
11691−a modern OS. Also, if the app is security-critical, it could have its own bugs,
11692−so it needs a maintainer and an update pathway anyway.
11693−
11694−## Urbit: status and prospects
11695−
11696−Yes, we do believe it's possible to write a freezable OS. In fact, we wrote
11697−one. And it works. It's not yet frozen (except at the bottom layer), but it's
11698−getting there.
11699−
11700−Urbit, a clean-slate functional OS, has been under development since 2002. It
11701−took a decade (as a one-man project) just to build a prototype of a freezable OS.
11702−The result in 2017 (now with a small company) is a telescoping Kelvin stack of
11703−layers from VM to UI.
11704−
11705−At the bottom (the VM Nock), this stack is slightly warmer than liquid helium
11706−(5K). It's easy for Nock to get this cold, because it's defined in a page of
11707−axioms that gzips to 340 bytes. We are in no hurry to declare zero, but any
11708−change at this point would be both very unlikely and very difficult to
11709−implement.
11710−
11711−Urbit's typed functional language, Hoon, which compiles itself to Nock, is
11712−closing in on liquid krypton at 143K. Hoon is defined in about 5,000 lines of
11713−Hoon, or 10,000 if you count the deep standard library. Nock will never need to
11714−change; Hoon is perfectly serviceable but has some well-known rough spots.
11715−
11716−Above Hoon, the stack rapidly gets much warmer. Arvo is an event-driven
11717−microkernel that's 1,000 lines of Hoon. Above this are another 5,000 lines of
11718−system library, then 12,000 lines of Arvo modules: a peer-to-peer network, a
11719−PKI and private ledger, a revision-control system, an HTTP gateway, a functional
11720−build system, and an application sandbox. A trivial working system needs
11721−another 5,000 lines for basic chat and shell apps.
11722−
11723−We haven't had meaningful Kelvin numbers for the Arvo layer, but this release
11724−will change that. About a third of Arvo has been or will be rewritten in the
11725−last year; we'll assign Kelvins once this code (which now compiles) is tested
11726−into existence, largely based on how close the last compiling draft was to the
11727−first working draft. But you'll certainly be able to cook eggs on it.
11728−
11729−(Once again, not being frozen doesn't mean not working. Until all these layers
11730−are finished, we'll be updating them over the air. To be exact, Urbit
11731−distributes its own updates through subscriptions in its own revision-control
11732−system.)
11733−
11734−The actual status of Urbit is that in 2017, we hope to make our last
11735−discontinuous update — meaning that instead of your Urbit node updating itself
11736−silently, you destroy and recreate it. Urbit works today, but it isn't really
11737−alive until today's Urbit data lives forever.
11738−
11739−Even committing to continuity is a significant step toward the frozen OS,
11740−because we're committing to never making another change that the present
11741−platform can't install. Fortunately, the only layer that has to stay frozen for
11742−this is Nock.
11743−
11744−## The style of convergent system software
11745−
11746−We're obviously in no position to declare victory at any layer above Nock, but
11747−aiming at absolute zero creates a system design style we think works very well —
11748−even if we never get to zero.
11749−
11750−Deep, onion-like layering is essential. A thin layer has no room to grow. A
11751−good example of this principle is the difference between Urbit and Lisp
11752−machines. Both Nock and Lisp are very simple axiomatic definitions of
11753−computing. But practical Lisp systems expand by extending the model, whereas
11754−Urbit layers over a frozen axiom system.
11755−
11756−Software that expands by extension is inevitable. But we need to be able to
11757−kick it up to userspace. System software should be concerned with the
11758−fundamental problems of computing, which don't change. The few cases in which
11759−they do change — like crypto algorithms — are special cases, easily
11760−encapsulated. And even these changes can be expected to slow down in the long
11761−term.
11762−
11763−Perhaps the best example of the convergent style in existing, mature system
11764−software is the relational database. The genius of the relational model is that
11765−it's designed to never grow hair. Even SQL, with its COBOL-era syntax, is
11766−essentially invulnerable to any significant non-cosmetic improvement.
11767−
11768−The lesson: when we see a system that seems to want to expand indefinitely, we
11769−can and should look for a layer division within this system, separating an inner
11770−layer that tends to converge from an outer layer that naturally diverges.
11771−Layering is what distinguishes true system software from the giant balls of mud
11772−that all deep codebases want to become.
11773−
11774−Are all balls of mud, or at least all the muddy parts of an OS, susceptible to
11775−this transformation? We think so. But we'll see.
11776−
11777−As usual, comments are on fora. Check out
11778−[this thread](https://urbit.org/fora/posts/~2017.5.12..20.30.11..0050~/).
11779−]]></content:encoded>
11780− </item>
11781− <item>
11782− <title><![CDATA[~2017.4.17 Update]]></title>
11783− <link>https://urbit.org/updates/2017-4-17-update</link>
11784− <guid>https://urbit.org/updates/2017-4-17-update</guid>
11785− <pubDate>Sun, 16 Apr 2017 00:00:00 GMT</pubDate>
11786− <content:encoded>< with
11933−comments and questions. We're here to answer them!
11934−]]></content:encoded>
11935− </item>
11936− <item>
11937− <title><![CDATA[~2017.3.1 Update]]></title>
11938− <link>https://urbit.org/updates/2017-3-1-update</link>
11939− <guid>https://urbit.org/updates/2017-3-1-update</guid>
11940− <pubDate>Tue, 28 Feb 2017 00:00:00 GMT</pubDate>
11941− <content:encoded><.
11945−
11946−The entire boot sequence from Nock through the Arvo kernel has now been rewritten,
11947−and actually makes sense. The old Arvo did work, it's true, under most
11948−conditions. It didn't work because it made sense, but mainly through pure
11949−persistence and luck. This is not viable for the deep core of a stable platform.
11950−It has, however, managed to stay alive on the network for the past 7 months.
11951−
11952−This all-new Arvo kernel (at a very fluffy 1065 lines) joins the all-new `%ames`
11953−and `%jael` vanes (kernel modules), and the `%zuse` library, in the new family of
11954−reference-quality Hoon code. (`%ames` is almost there -- the code is good, but not
11955−documented.)
11956−
11957−Roughly speaking, Urbit including all application, library, and kernel code, is
11958−about 40,000 lines of Hoon, in three grades, categorized by how clean and easy to
11959−read they are.
11960−
11961−C-grade Hoon is found in `%eyre` (Web server) and `%dill` (console); a bit of it
11962−has accumulated in `:talk`; the markdown parser; some of the examples; some of
11963−`hoon.hoon`; etc.
11964−
11965−C-grade Hoon is write-only code. To even look at it, even if you know Hoon, is
11966−reverse engineering. It follows no conventions, not even its own. If it has
11967−comments, they mean nothing, except (possibly) to the author. (One bad property of
11968−Hoon is that, like C, it does nothing to stop you from writing obfuscated code.)
11969−Most C-grade Hoon dates to 2014 or early '15.
11970−
11971−B-grade Hoon can be followed with some effort. It is structurally simple, but not
11972−always conceptually simple. It makes no particular effort to explain itself,
11973−either through documentation or otherwise. `%behn`, `%clay` (B+ for decent
11974−comments), `%ford`, `%gall`, most of `hoon.hoon` and most userspace code is
11975−B-grade. Most B-grade code is from late '15 or early '16.
11976−
11977−The A-grade Hoon is everything produced since our crowdsale: `%ames`, `%zuse`,
11978−`%jael`, and `%parv`. Hoon of this quality, you just spread on a cracker and eat.
11979−It's completely smooth. You can almost see what it's doing even if you don't know
11980−Hoon. The only places where A-grade Hoon is hard to understand are places where
11981−the problem is actually tricky.
11982−
11983−Urbit succeeds exclusively through software quality. All A-grade code should be
11984−permanently maintainable at consistent quality. All B-grade and C-grade code will
11985−deteriorate over time and eventually needs to be replaced.
11986−
11987−But `cc-release` is an "infrastructure MVP" in which the critical parts are
11988−A-grade: the boot sequence and OS, networking, and secrets. Lower-grade code
11989−remains suitable for light-duty kernel and userspace work. The good news is that
11990−the longer we wait to rewrite it, the better the replacement will be.
11991−
11992−These new A-grade subsystems remain untested (except `%jael` and `%zuse`) and have
11993−not been integrated. This will involve further tinkering with other vanes and
11994−userspace code. However, Arvo should be the last major module rewrite before
11995−`cc-release`, so we're on our way.
11996−
11997−_Anton_ (`~pittyp-pittyp`) and _Galen_ (`~ravmel-ropdyl`) are working from the
11998−opposite end. They're designing the new, easy-to-use, command-completing Urbit UI
11999−from the top down, using ES6 and React.
12000−
12001−This new framework isn't even connected to Urbit. Its first use is actually a demo
12002−video. We published a few screenshots from our mockups in the last blog post, and
12003−want to give a more complete impression of where we're headed to the public.
12004−Making this interface real will, of course, require nontrivial console engineering
12005−on the Urbit side. We think it's going to be great.
12006−
12007−Like our new server-side code, the new Urbit client-side framework is designed to
12008−be high-quality code that other human beings can read and extend.
12009−
12010−_Raymond_ (`~maldeb-hapben`) has finished breaking the new `vere` system into
12011−client, manager and worker processes. Curtis earlier rewrote the event loop and
12012−the logging system, with correct use of concurrency and `fsync()` in an actual
12013−two-phase commit.
12014−
12015−There's still a large number of small tasks to perform, but we're essentially
12016−turning `vere` into the C equivalent of A-grade Hoon: clean code that just
12017−obviously works. Also, the new `vere` works like an actual, industrial-grade
12018−server, and should be reasonably adapted to the task of hosting nontrivial numbers
12019−of urbits.
12020−
12021−The absolutely crucial requirement for `cc-release` is ships that don't sink. We
12022−have not observed any problems with the new event log so far, but we still need to
12023−stress-test it with powercycles. Yes, Urbit really is an ACID database!
12024−
12025−_Keaton_ (`~livweb-havweb`), our intern, has written a bunch of examples and
12026−cleaned up a bunch of doc.
12027−
12028−_Elliot_ (`~ponnys-podfer`), an outside contributor, sent an amazing `doccords`
12029−patch that adds documentation strings to Hoon. This sounds like a superficial
12030−change, but it actually involved deep work in the heart of the type system. He's
12031−also added a bunch of this doc himself.
12032−
12033−You can check out the pull requests [here](https://github.com/urbit/arvo/pull/353)
12034−and [here](https://github.com/urbit/arvo/pull/356). The original `fora`
12035−discussion is [here](http://urbit.org/fora/posts/~2017.1.16..06.08.17..ae0f~/).
12036−
12037−As usual, comments are on fora. Check out
12038−[this thread](http://urbit.org/fora/posts/~2017.3.1..22.06.50..bf2a~/).
12039−]]></content:encoded>
12040− </item>
12041− <item>
12042− <title><![CDATA[~2017.1.30 Update]]></title>
12043− <link>https://urbit.org/updates/2017-1-30-update</link>
12044− <guid>https://urbit.org/updates/2017-1-30-update</guid>
12045− <pubDate>Sun, 29 Jan 2017 00:00:00 GMT</pubDate>
12046− <content:encoded><
12081−
12082−- _UX_? As a kid it was just _design_ or maybe _web design_. At some point I
12083− remember people talking about _user interface_ or _UI_. But I truly don't
12084− understand where the _X_ came from. It's like Monster Energy got involved in
12085− the branding.
12086−
12087−- An _experience_ sounds like the kind of thing that's going to be littered
12088− with ads, or is going to manipulate me in some way. Something I passively
12089− consume. Not something I actively control. So I prefer _interface_ to
12090− _experience_, and I think you should too.
12091−
12092−
12093−
12094−- Urbit has to be just as usable as any widely used app in 2017. For a personal
12095− server, the usability bar can't be Unix. A Unix server is an industrial tool.
12096− An industrial tool can't be a consumer product. You can attach a blade to the
12097− end of a drill and use it as a blender, but it's not a Vitamix.
12098−
12099−- What is an app, anyway? It's _shared computing_. Everyone's data is one data
12100− structure, in one program, on one server, owned by one corporation. With _one_
12101− UI for everyone to do _one_ thing.
12102−
12103−- But there isn't one big corporation that writes _all_ the code. Everyone's
12104− lives are spread across a bunch of different apps. Every app solves the
12105− ownership problem separately.
12106−
12107−- So the whole user experience of using Web apps involves tracking all these
12108− silly little accounts, learning each and every user experience, and glaring
12109− helplessly at each little piece of data trapped in a different silo.
12110−
12111−- Even your Google account doesn't feel like one thing. Whatever your Google
12112− Docs are, it's not a bunch of document files on your Google Drive. All the
12113− resources of Google can't make their Borg backend feel like one computer which
12114− belongs to you.
12115−
12116−- The phrase 'general-purpose computing' sounds scary, but it shouldn't be.
12117− 'Computing' doesn't mean writing code. We're computing when we browse
12118− Facebook or talk to Alexa.
12119−
12120−- Your personal server will be solving the same problems today's whole ecosystem
12121− of network apps solves, just all in one place that belongs to you.
12122−
12123−- The closest thing to a general-purpose personal server today is probably the
12124− Chinese service WeChat. If you don't know much about WeChat, you should
12125− really watch [this NYT video](https://www.nytimes.com/video/technology/100000004574648/china-internet-wechat.html).
12126−
12127−- From a distance WeChat is great. Everyone in China loves the one-app,
12128− one-identity, all-my-own-stuff user experience. It's clearly better than
12129− being forced to switch apps constantly.
12130−
12131−- But WeChat is just another giant shared-computing service. It's made out of
12132− the usual 2010s server stack mess. The visual and interaction design looks
12133− pretty dated. WeChat tells us that users want one experience, but not much more than that.
12134−
12135−
12136−
12137−- To paraphrase Walter Sobchak: say what you want about the tenets of shared
12138− computing, but at least it's an ethos. We know how to build very good
12139− special-purpose user experiences. What's the conventional UI for a
12140− general-purpose personal server? It doesn't exist.
12141−
12142−- For most users, your urbit runs in a data center (like a web app). You log
12143− into it with your browser (like a web app). Other than that, where do you
12144− even start? A `bash` prompt isn't what we're looking for.
12145−
12146−- But wait, is the idea of a command line bad UI? Or is the Unix command line
12147− just bad UI? We know ordinary people can use command lines. They use
12148− chatbots. Long ago, they used MS-DOS.
12149−
12150−- Today's computing user experiences, the PC and its mobile cousin, rejected the
12151− command line. This made computing easy enough, at the cost of hiding much of
12152− its creative power.
12153−
12154−- The power of a general-purpose server which can command not only local
12155− applications, but also network services, is at a whole new level. We don't
12156− think any visual metaphor or 2D control panel can do it justice.
12157−
12158−- We need to bring the full power of the machine to the user, without breaking
12159− their trust that the machine is on their side. We can't let the user get lost
12160− or break the system. It has to feel safe and simple to explore its furthest
12161− reaches.
12162−
12163−
12164−
12165−- As Neal Stephenson [tells us](http://cristal.inria.fr/~weis/info/commandline.html),
12166− the command line is the natural UI for any computer. It's especially the
12167− natural UI for a _network_ computer, like a personal server. A command line
12168− scales way better than a GUI to a large selection of actions. And a network
12169− computer can do almost infinitely many things.
12170−
12171−- When we've tried to put a simplified "for dummies" GUI on top of Urbit, it's
12172− just awful. It's like a bad Linux desktop GUI. You feel instantly that
12173− you've got a choice between something limited and lame, and something
12174− mysterious and scary. So we threw those designs out, in search of something
12175− better.
12176−
12177−- The true command line is generally thought of as something mysterious and
12178− scary. Somewhere that you can do things to irreparably damage your computer.
12179− It's powerful, but also dangerous.
12180−
12181−- This tradeoff — between control and safety — is false. The unfriendly command
12182− line is actually just another artifact of 70s computing. The UI of the
12183− command line is designed for a programmer, not an ordinary person.
12184−
12185−- `bash` is a bad UI because there's no easy way to control its power, or learn
12186− all the things it can do, or separate its power to do dangerous things from
12187− its power to do safe ones.
12188−
12189−- At the other end of the spectrum is the chatbot, which is a bad UI because
12190− it's hard to make it much more than a toy. Like so many innovations, chatbots
12191− happened by accident. It's just a way to connect an input string to network
12192− services. But the natural-language metaphor of "chat" is confining. It
12193− doesn't scale well to any problem that isn't trivial.
12194−
12195−- What does a great command line look like? It should have a strict syntax, not
12196− try to guess what you mean. But it can't be a constant test of your ability
12197− to memorize the phonebook.
12198−
12199−
12200−
12201−- Urbit already has the beginnings of a great command line. We parse your input
12202− with an actual grammar and catch errors as you type. You can't even press
12203− return on an invalid command.
12204−
12205−- What's missing is help. A great command line needs to reach out and hug you
12206− in every way it can. It needs to assume you don't know anything at all about
12207− the system. It's there for you to solve your problems, but also to help you explore.
12208−
12209−- There's actually one exotic Unix shell that does it right:
12210− [`fish`](https://en.wikipedia.org/wiki/Friendly_interactive_shell). `fish`
12211− jumps through some pretty amazing hoops, like parsing manpages, to give you
12212− context and completion.
12213−
12214−- It's a lot easier for Urbit because we're designing the system from scratch.
12215− From a technical standpoint, all we have to do is add contextual help to our
12216− existing parser framework. An extended rule can parse a string, or tell the
12217− user what it wants to parse. In simple terms: we have to make the `:dojo`
12218− (our shell) much friendlier.
12219−
12220−- The `:dojo` shell is built around the concept of a _generator_, a program that
12221− builds a noun. The idea is that how you build the noun is orthogonal to what
12222− you do with it. You could print it, send it as a command, etc. There are
12223− several kinds of generators -- simple scripts, prompting dialogs, HTTP
12224− scrapers, etc.
12225−
12226−- A generator is initialized with command-line arguments and options, in the
12227− classic Unix style (except typed). In the classic Unix style, Urbit at
12228− present provides no help at all in constructing a command line. You just have
12229− to know.
12230−
12231−- How should it actually work? Let's say you're trying to put Urbit in control
12232− of your Twitter feed. That means you're creating a Twitter gateway on Urbit,
12233− which you can control with a `|twitter` command.
12234−
12235−- Before you type a character, Urbit offers you `|` (any command with side
12236− effects). (You could also add a `!` prefix, which is like `sudo` -- it lets
12237− you do something dangerous.) Once you type `|`, you can page through a list
12238− of commands. Once you type `|t`, that list is much shorter. Once it can tab
12239− complete to `|twitter`, it prompts you with that.
12240−
12241−- And once you get to `|twitter`, you're in a "meta-generator" that's helping
12242− you build the correct command line. At least in a browser, you'll be stepping
12243− through a form with rich entry. But the command line will show you the text
12244− of the command you're building, so next time you can just type it.
12245−
12246−- Building a command is just a case of data entry. In a command-line world,
12247− data entry is always serial. You answer questions serially, one at a time.
12248− The only navigation is forward and back.
12249−
12250−- A great Urbit console also has to be accessible both from a browser and a Unix
12251− terminal. That means a prompt needs to tell the console if it could be a
12252− radio button, even though a terminal can't have a radio button. We'll improve
12253− the interactivity of our terminal a little, but we're not rewriting Lynx.
12254−
12255−- So, what do you do with this fancy command line? Command everything -- from
12256− your urbit to the world. Installing an app is a command. Publishing a tweet
12257− is a command. Paying someone in bitcoin is a command.
12258−
12259−- Your urbit can show you all the things you can do, and help you do them. If
12260− there's something you'd like it to do, build it!
12261−
12262−- A great command line alone is not all that Urbit needs. But it feels like the
12263− right central paradigm for interacting with your Urbit. We'll get into the
12264− specifics in a future post.
12265−
12266−
12267−
12268−## Infrastructure: stability, maturity, performance, documentation:
12269−
12270−We dragged Curtis, whose hide has turned completely white like a cave fish, from
12271−his coding hole to stammer out this update:
12272−
12273−We're actually doing pretty well on the infar. Despite there being all kinds of
12274−unacceptably broken things about Urbit 2016, the network has actually stayed up
12275−since August, and we haven't had an unintentional continuity breach since June.
12276−
12277−Of course, it helps that we don't ask anyone to _use_ Urbit in earnest. And ships
12278−still do sink. Since an urbit is an identity, sinking your planet is a horrendous
12279−experience. You'll never bond with your second planet the way you did with your
12280−first -- never mind any _data_ you may have lost.
12281−
12282−Our upcoming `cc-release` is the last planned breaching release. With certain
12283−exceptions discussed below, all major parts are now (January 2017) code complete
12284−or better.
12285−
12286−This includes the rewritten network stack (`%ames`), code complete but untested;
12287−the new secret vault and promise tracker (`%jael`), mostly tested; and the new
12288−`u3_pier` event execution framework, with worker processes and real two-phase
12289−commit, smoke-tested. We've also completely restructured `hoon.hoon` and
12290−`zuse.hoon`, which now are at least cosmetically acceptable.
12291−
12292−This is not to say that the `cc-release` Urbit won't in many ways embarrass us as
12293−engineers. It will. But your ships won't randomly sink, your secrets won't
12294−randomly leak, and your datas won't randomly rot. Or if they do, it's an
12295−implementation bug, not a design flaw.
12296−
12297−There are still a few cracks we need to fill in. The main one: some top-level
12298−adjustments to the Arvo event system. The boot sequence now executes correctly,
12299−but the actual boot events need to be totally refactored, as does the rather
12300−critical Unix-Arvo interface. The long-promised security mask and voltage flags
12301−need to be added, and vanes adjusted to use them. Causal tracking of execution
12302−crashes needs to actually work. At the user level, `:talk` needs to be split into
12303−a user agent and a daemon, and the user-level `%kiln`, the "systemd of Urbit,"
12304−needs a rethink to make upgrade logic state-triggered, not edge-triggered.
12305−
12306−The console and the dojo need some work to make our user experience real. One way
12307−to view a high-usability command line is that a command, if you don't have the
12308−esoteric knowledge to fill it in by just typing the syntax, is essentially a
12309−form. This form needs to work both in the browser and the terminal, which isn't
12310−trivial. Browser and terminal both need a simple multiscreen navigation model,
12311−which we don't have yet.
12312−
12313−There's also a bunch of Unix-level work to do, mainly in converting the old
12314−"single-player mode" console-bound Urbit into a real system service. Urbit works
12315−better as a daemon which runs one or more worker processes, and talks to client
12316−consoles over a Unix socket. A real architecture actually makes it practical for
12317−star owners to host the planets they issue, for example.
12318−
12319−Finally, because we never forget the wisdom of the sages, our last act before
12320−asking people to use Urbit will be the long awaited performance crusade. The new
12321−event system now at least releases outgoing events before the input queue is
12322−clear! You never know what optimization will achieve before you make a serious
12323−effort, but I don't see any reason we can't carve out a new empire of speed in the
12324−savage, uncharted east.
12325−
12326−We haven't touched the documentation since the first half of 2016. As always,
12327−maturity has to come before documentation. Premature documentation is almost as
12328−dangerous as premature optimization.
12329−
12330−## Notable contributions
12331−
12332−Some notable contributions of late:
12333−
12334−- `~ponnys-podfer` wrote a MUD
12335−- `~palfun-foslup` created a surprisingly capable talkbot
12336−- `~master-morzod` reworked the console in both the Hoon and C layers, adding color and cleaning up a bunch of stuff.
12337−
12338−Anyone who contributes at this point deserves extreme praise for the ability to
12339−work in an immature, often broken system. We look forward to being ready for
12340−normal programmers who aren't intrepid jungle explorers.
12341−
12342−## Next crowdsale
12343−
12344−We'll do another crowdsale in the spring. We understand that the last sale left a
12345−lot of people unable to participate — and our first priority is making sure those
12346−who are excited about Urbit can own some real estate. We'll announce our plans on
12347−how this might happen soon. If you're interested, make sure you're on our mailing
12348−list.
12349−
12350−## Contribution prizes
12351−
12352−We're still thinking about the right way to award Urbit real estate to outside
12353−contributors. Especially after the crowdsale, it really has to feel 100% fair.
12354−But it can't be in any way, whether legally or emotionally, a form of compensation.
12355−We can't afford to kill the fun.
12356−
12357−It doesn't feel right to do this at all when the documentation is completely
12358−inadequate, because it's not fair to people who don't have the time to reverse
12359−engineer. But we're thinking hard about this issue.
12360−
12361−## Future updates
12362−
12363−We know you love these opinionated, literary state-of-the-urbit updates. We love
12364−writing them. But we obsess over them too long and they take too long to write.
12365−Urbit's ultimate success depends almost entirely on the code.
12366−
12367−Going forward we're going to switch to commit-message style updates on a monthly
12368−basis, with longer updates arriving sporadically. Maker DAO does a great job of
12369−these shorter updates
12370−([here](https://blog.makerdao.com/2016/12/14/maker-update-925/) is an example).
12371−
12372−If you're ever curious to check in or hear what's going on, don't hesitate to get
12373−in touch. You can always chat with us on
12374−[urbit.org/stream](https://urbit.org/stream), or by booting your own Urbit.
12375−[Twitter](https://twitter.com/urbit) or email
12376−([urbit@urbit.org](mailto:urbit@urbit.org)) are also perfectly fine.
12377−
12378−There's also [our forum](https://urbit.org/fora/) that anyone can post to. We've
12379−created [this thread](http://urbit.org/fora/posts/~2017.2.1..22.36.47..9f54~/) to
12380−discuss this post.
12381−]]></content:encoded>
12382− </item>
12383− <item>
12384− <title><![CDATA[~2016.10.6 Update]]></title>
12385− <link>https://urbit.org/updates/2016-10-6-update</link>
12386− <guid>https://urbit.org/updates/2016-10-6-update</guid>
12387− <pubDate>Wed, 05 Oct 2016 00:00:00 GMT</pubDate>
12388− <content:encoded><,
12395−Chad Rigetti defines "hard tech" as "solving problems you don't
12396−even know are solvable." Rigetti is building a quantum
12397−computer, which is definitely "hard tech." More power to him!
12398−
12399−But software can be "hard," too. Is Urbit "hard tech"?
12400−
12401−The correct answer at this point is: no, but it _used_ to be hard
12402−tech. Now it's actually real, if not exactly easy. The Urbit
12403−network hasn't crashed once this summer, though we did one
12404−intentional breach (right before delivering the stars). I'm
12405−still kind of amazed by this.
12406−
12407−But we still need to get to the point where (a) the whole network
12408−can't crash ever, (b) you can put your data in an urbit and be
12409−pretty sure it'll live forever, (c) Urbit works well as a social
12410−network, and therefore (d) we can distribute planets to ordinary
12411−human beings and not have them be like, "gah, what is this?"
12412−
12413−If we had the resources of Microsoft or Google, or even of
12414−Mozilla, we could solve these problems with a brute-force
12415−human-wave attack. We could just debug the system into
12416−existence. It must be nice.
12417−
12418−But not. In some ways it's essential to Urbit's mission that
12419−there isn't a giant army behind it. It means that the only way
12420−Urbit can succeed, or even survive, is to be excellent. That's
12421−the right attitude for a stack designed for the 2020s. Not that
12422−we can wait until the 2020s to get (a) through (d). Just that we
12423−don't want our children and grandchildren to curse the day this
12424−stack was born. Unix, the Internet and the Web gained the world
12425−and lost their souls -- we don't have that option.
12426−
12427−Given this attitude, the thing that terrified me most of all
12428−about this summer's crowdsale is that the most important parts of
12429−Arvo -- the network and the PKI -- simply didn't exist in any
12430−viable sense. Yes, the present `%ames` network does net work.
12431−There is even in theory a sort of PKI, although no one has ever
12432−even tried to revoke a key. It might be secure -- who knows?
12433−
12434−More concretely, the existing `%ames` vane (kernel module) contains
12435−both the protocol and the PKI, mixed together in a single giant
12436−state machine of the sort I've learned never to build again.
12437−There is no perfect code anywhere in the present production Arvo,
12438−but the only body of _dead-end_ code -- which needs replacement,
12439−not documentation and maintenance -- is `%ames`.
12440−
12441−Unfortunately, networking and key management is the most
12442−important part of Urbit. In a sense it _is_ Urbit. So having it
12443−not exist, except as a design in our heads, was not a good thing.
12444−
12445−While documenting, evangelizing and in general growing Urbit is
12446−vastly important, what's even more important is finishing it --
12447−without compromising its elegance. Elegance is the only thing
12448−Urbit has. It's not like there aren't other operating systems.
12449−
12450−So the first thing I did after the crowdsale was to disappear
12451−into a hole and take care of this technical debt. This was not
12452−"hard tech" in the sense that I knew it was solvable. I didn't
12453−know it was solvable _well_, though. And it has to be solved
12454−_well_, because otherwise who cares.
12455−
12456−## Check out our new, improved cc-release
12457−
12458−I'm delighted to report that the new, rewritten `%ames` network,
12459−and the all-new `%jael` PKI, are now at code complete. (Code
12460−complete means "compiling but not tested," which is actually
12461−saying a lot in a typed functional language.) They've been
12462−checked in to a new `cc-release` branch on
12463−[`github.com/urbit/arvo`](https://github.com/urbit/arvo).
12464−
12465−I think these two vanes are definitely the best code in Urbit.
12466−There's still a bit of fundamental work in Arvo (implementing the
12467−boot sequence and event security mechanisms described in the
12468−whitepaper), but this is not "hard tech" -- the designs are
12469−clear and surprises seem unlikely.
12470−
12471−## `%xmas`: the new network
12472−
12473−New `%ames` (currently `arvo/xmas.hoon`, since old `%ames` is still in
12474−the build) has had all the key management stripped out; it's just
12475−a network vane. It's also no longer a single giant state
12476−machine, but a system of five simple 200-line state machines.
12477−
12478−It was wonderful to discover that Hoon lets you write purely
12479−functional programs with what are essentially global variables.
12480−Specifically, nested cores generalize across global variables,
12481−local variables, and objects, in a way I find technically quite
12482−lovely if I do say so myself. On the other hand, Hoon ain't
12483−magic, and it's not like we've solved any of the
12484−software-engineering problems inherent in a 2000-line state
12485−machine based on global variables. So, nice to kill that.
12486−
12487−Don't look at new `%ames` just yet. It was done in July and
12488−August. It needs a few touchups to fit the `%jael` interface.
12489−And it needs to be brought up to `%jael`'s quality standards.
12490−
12491−## `%jael`: reference code, PKI, and personal ledger
12492−
12493−`%jael` (`/arvo/jael.hoon`), the PKI, is what I'm really excited
12494−about. It's what you should take a look at if you know any Hoon
12495−or even if you don't. There's several really important things
12496−about `%jael`.
12497−
12498−The first is that it's actually reference-quality code. Or so I
12499−believe. It's literally intended to serve as a reference style
12500−for what all production-quality Hoon should look like. If you're
12501−reading the code and you see anything that isn't absolutely
12502−perfect, whether it's cosmetic or structural or anything in
12503−between, file a PR. `%jael` is fully commented -- if you think
12504−it needs more comments, or fewer, file a PR...
12505−
12506−Needless to say, a reference style will be an enormous help in
12507−managing community contributions. It's not that, for now at
12508−least, we won't accept patches not written in line with the
12509−reference `%jael` style. But we'll always accept patches to bring
12510−'those patches' up to reference. For the moment, the code will just
12511−define the style by analogy, but it'll eventually spawn an actual
12512−document.
12513−
12514−If you're feeling ambitious and want to change the reference
12515−style itself, your change is best submitted as a patch to `%jael`
12516−itself. And _really_ ambitious people can create their own
12517−alternative Hoon styles -- hopefully defined at the same same
12518−level of precision.
12519−
12520−Second, `%jael` actually implements the Urbit PKI as designed,
12521−right down to unusual but politically critical features like
12522−escaping a bad parent. Since the code is readable and heavily
12523−commented, it can and will serve as the best possible reference
12524−for the PKI's semantics.
12525−
12526−Both `%ames` and `%jael` are designed for the new and correct
12527−single-homed urbit model, where one pier is one ship. In the new
12528−world, to boot your planet, you use your ticket to generate a
12529−symmetric key that authenticates you to your parent. When you
12530−share your public key with your parent, over that initial secure
12531−channel, it notices that it hasn't signed it yet and shares its
12532−signature back to you.
12533−
12534−Third, `%jael` isn't just a PKI -- it's a generalized system for
12535−formal promises. The whole point of a PKI is that entities can
12536−make secure statements to each other. Of course, every `:talk`
12537−message is a signed statement, but the really important messages
12538−are _promises_ -- such as, for instance, "Tlon owes you 3 stars."
12539−
12540−(Right now, the stars we sold in the crowdsale are recorded in the
12541−state of a higher-level application (`:womb`). (We have an
12542−encrypted offline backup, of course.) This is fine at a certain
12543−level, but it's a bit rickety and not really up to Urbit's
12544−standards of architectural elegance. Promises and secrets are
12545−fundamental state and need to be handled at a fundamental level.)
12546−
12547−In a secure distributed social network, people need to be able to
12548−make formal promises to each other. Essentially, every ship is
12549−an _accounting entity_. It records its liabilities, which are
12550−the promises it's made to others, and its assets, which are the
12551−promises others have made to it. When I update the promises I've
12552−made to you, I send you an updated statement.
12553−
12554−All kinds of promises fit this mold. For instance, while you
12555−don't usually think of a symmetric key as a promise from one
12556−entity to another, it is. It's a promise from ship A to ship B,
12557−that B can identify itself to A by this secret.
12558−
12559−So `%jael` will, among other glorious things, essentially allow
12560−every galaxy to serve as an exchange for star invitations, and
12561−any star to serve as an exchange for planet invitations. Mere
12562−payments are just the start of what you can do with this. And of
12563−course, one of our big near-term goals is to make first Urbit
12564−invitations, then (once the crypto is truly final) actual ships,
12565−tradeable on "regular" cryptocurrency exchanges.
12566−
12567−One of my views about Bitcoin is that its decentralized,
12568−trust-free ledger isn't really the most important thing about it.
12569−Humans build trust quite easily. For instance, Bitcoin doesn't
12570−even enable trust-free payments -- a payment is always an
12571−exchange for other good or service. Do I provide the good or
12572−service before, or after, the Bitcoin payment? Either way,
12573−trust is unavoidable.
12574−
12575−The important thing about Bitcoin is just that it enables users
12576−to manage their obligations to each other digitally, without
12577−interacting with a 20th-century asset management system made of
12578−paper and magnetic tape. Giving every user their own asset
12579−management ledger is another small revolution in that direction.
12580−And if I'm defining and issuing my own digital assets, why do I
12581−need to put them on a global blockchain? You're still trusting
12582−me to actually live up to my promises.
12583−
12584−Last but not least, `%jael` solves one of Urbit's most important
12585−and hardest problems: how do I back up my urbit? I know I said
12586−this was impossible, but I lied.
12587−
12588−Urbit uses persistent sessions, which means a pair of ships uses
12589−the same session sequence numbers for life. Since every packet
12590−is a transaction, when you send an acknowledgment, you mean it.
12591−The upside is that we get exactly-once messaging, which if you've
12592−ever done distributed programming is a very, very good thing.
12593−The downside is that if you lose your state, there's no way to
12594−recover it, since you don't know what sequence number to send
12595−next. (See under: [Two Generals'
12596−Problem](https://en.wikipedia.org/wiki/Two_Generals%27_Problem)).
12597−
12598−In the new world, the Unix layer will subscribe to a stream of
12599−`%jael` changes which contain all certificate and rights actions.
12600−We'll save this separately from the rest of the pier state, and
12601−it's small and trivial to back up.
12602−
12603−When restoring, if you have all your private keys but have lost
12604−all other state (obviously if you don't have the latest private
12605−key, you're hosed), you sign a new version of your will which
12606−contains a "brain damage" bit. When this will is propagated to
12607−your neighbors, they learn that you're brain-damaged and reset
12608−their sequence numbers -- and forget you know anything they told
12609−you, treating you as a new stranger.
12610−
12611−At the application level, all your subscriptions get closed.
12612−Apps already have to deal with this. Forward messages shouldn't
12613−involve any state coupling; that's what subscriptions are for.
12614−In case there is some coupling anyway, you'll get an event that
12615−"ship X lost his mind, forget anything you know about him."
12616−
12617−Essentially, we're cheating the fact that you can't have
12618−transient sessions and [exactly-once delivery](http://bravenewgeek.com/you-cannot-have-exactly-once-delivery/)
12619−by letting the abstraction leak in this special case, and putting
12620−the responsibility for fixing it on the brain-damaged ship. It
12621−may even leak up to the user. But dude, you're the one that let
12622−your brain fall out of your skull.
12623−
12624−Another thing I like about this solution (and about `%jael` in
12625−general) is that it solves the problem of how you use someone
12626−else's secrets, if you manage to steal them. There's no point in
12627−security through technical difficulty -- if you have the latest
12628−private key for a ship, you're the captain now. You shouldn't
12629−have to hack something up to make this work.
12630−
12631−## Keep in touch / office hours
12632−
12633−`:talk` is always a great place to come and ask questions.
12634−Someone from Tlon will be available in `:talk` from 12PM - 3PM
12635−PDT each weekday. And [our forum](https://fora.urbit.org) is a
12636−great place to post questions. We've created [this
12637−thread](https://urbit.org/fora/posts/~2016.10.7..17.28.21..b058~/) to
12638−discuss this post.
12639−
12640−For anything else you can always get in touch with us via
12641−[`urbit@urbit.org`](mailto:urbit@urbit.org).
12642−]]></content:encoded>
12643− </item>
12644− <item>
12645− <title><![CDATA[~2016.8.30 Update]]></title>
12646− <link>https://urbit.org/updates/2016-8-30-update</link>
12647− <guid>https://urbit.org/updates/2016-8-30-update</guid>
12648− <pubDate>Mon, 29 Aug 2016 00:00:00 GMT</pubDate>
12649− <content:encoded><! Especially [this
12899−thread](https://urbit.org/fora/posts/~2016.8.30..18.05.18..8ba3~/) to
12900−discuss this very post. Don't be afraid, the water's fine! Actually there
12901−are a few glitches, but it's hosted on Urbit (and also backed up).
12902−For the less daring, [r/urbit](https://www.reddit.com/r/urbit) is a
12903−reliable old standby.
12904−
12905−For anything else you can always get in touch with us via
12906−[`urbit@urbit.org`](mailto:urbit@urbit.org).
12907−]]></content:encoded>
12908− </item>
12909− <item>
12910− <title><![CDATA[~2016.7.20 Update]]></title>
12911− <link>https://urbit.org/updates/2016-7-20-update</link>
12912− <guid>https://urbit.org/updates/2016-7-20-update</guid>
12913− <pubDate>Tue, 19 Jul 2016 00:00:00 GMT</pubDate>
12914− <content:encoded><.
12931−
12932−## General status
12933−
12934−The work required to pull off the sale definitely drained the energy
12935−of our two strongest engineers, Philip (`~wictuc-folrex`) and Anton
12936−(`~fyr`).
12937−
12938−Rather than remain on the path to total burnout we decided to push
12939−back the issuing of stars. Our goal is to activate invites on August
12940−12th, 2016. Apologies for the delay, and the short notice.
12941−
12942−## Great renaming, rekeying, and new ames
12943−
12944−If you bought a star, you might notice that while our invitation
12945−server (the womb) is up, it's not currently configured to let you
12946−create a star.
12947−
12948−Our first major release, which comes with a continuity breach
12949−(complete network reboot where all ships are recreated), needs to (a)
12950−fix the ship naming algorithm "`@p`", giving everyone (including us)
12951−new names; and (b) replace the somewhat risible cryptosuite A (RSA and
12952−other horrors) with the competent cryptosuite B (Curve25519, Ed25519,
12953−AES).
12954−
12955−Not only will this let star buyers collect their stars (they don't
12956−need to, but it might be fun), but all planet owners will now claim
12957−their new planets via the womb. If you have an old ticket, the womb
12958−will convert it into a new invitation.
12959−
12960−We had planned to run the great renaming today, but about a week or so
12961−ago we found ourselves reconsidering. This isn't because the new
12962−crypto and `@p` code isn't ready -- it is (largely because it's the work
12963−of Ray, `~raplys-lornex`). But...
12964−
12965−1: Anton needed a break and the womb is his code. For a piece of
12966−critical infrastructure, it's also a little under-documented and
12967−under-tested. Hoon as a typed language makes you lucky. Urbit is
12968−still a testnet, but we're a little tired of relying on luck.
12969−
12970−2: Slipping the great renaming lets me (Curtis, `~tasfyn-partyv`)
12971−resuscitate and integrate my rewrite of the `%ames` network module,
12972−which was mostly completed and then put aside six months ago (so that
12973−I could do things that didn't involve writing code). New `%ames` is
12974−sorely needed, because right now there's a network bug that actually
12975−sinks (permanently disables) ships, and we basically can't debug
12976−anything in the area because we'd be debugging old code.
12977−
12978−People have also expressed some concern about the fact that `%ames` is
12979−sending mysterious UDP messages which aren't documented in any way
12980−(the whitepaper has some protocol description, but it's still not
12981−quite comprehensive. Actually, `%ames` is a pretty clean system overall
12982−and shouldn't be hard to turn into the kind of literate, stable Hoon
12983−code the future should be made of. But again, documenting obsolete
12984−code kind of sucks.
12985−
12986−Finally, we have an idea (half Anton's, half mine) about how to
12987−actually end the unfortunate tradition of continuity breaches, by
12988−providing a "rough start" model which lets you create a working ship
12989−with just the private key. Needless to say, it would be very exciting
12990−to actually stop rebooting the universe, permanently.
12991−
12992−So it's a pretty good fit to push the renaming and the new network
12993−protocol out into a single Great Inception, which currently seems like
12994−it should happen in early August. I certainly can't wait to pick my
12995−new, permanent Urbit name! But as always, we ship no code before its
12996−time. We will keep you up to date on our progress.
12997−
12998−## Other near-term goals
12999−
13000−The short-term focus remains self-hosting and onboarding. Ray is
13001−currently working on building a simple message board on top of `tree`,
13002−so that Urbit can be its own phpBB as well as its own IRC. Persistent
13003−IRC (ie, `:talk`) is extremely useful, but we need long-form
13004−discussion. Reddit is pretty good, but not _quite_ right -- and an
13005−ounce of self-hosting is worth a pound of SaaS.
13006−
13007−Basically, we don't intend to work on user-level features that we
13008−don't use ourselves for quite some time, if not ever. Self-hosting is
13009−the path to maturity, always and everywhere.
13010−
13011−## Medium-term goals
13012−
13013−Our medium-term focus is expanding the attack surface of Urbit as an
13014−open-source project in every possible way. We want to completely
13015−dispel the aura of mystery.
13016−
13017−There are two general paths toward this: teaching and documentation.
13018−On the teaching front, I think you'll like the new, super-easy Urbit
13019−learning series I started [here](https://urbit.org/docs/byte). More
13020−Urbytes are forthcoming.
13021−
13022−On the documentation front, Urbit has a large volume of basically
13023−undocumented and undescribed code at the Hoon and Arvo levels. This
13024−is incredibly shitty from the perspective of an open-source project,
13025−especially because neither I nor anyone has the kind of obsessive
13026−attachment to random details that you'd expect in an under-documented
13027−system.
13028−
13029−We need the community to own the technical decisions in Hoon and Arvo.
13030−Urbit can't be a real open-source project until we truly open this
13031−attack surface.
13032−
13033−The right way to solve this, I think, is to "document into existence" --
13034−producing design documents from the existing codebase, reviewing these
13035−designs collectively, then converging the actual code with them. The
13036−key areas to attack are Arvo itself and the vanes. The first area I
13037−want to do this with is the new `%ames`.
13038−
13039−There is an excuse for not having done this already: premature
13040−documentation is a serious evil. When you're figuring out how a
13041−system should work at all, documenting it is counterproductive. But
13042−Urbit is past this point. It needs to settle down and become a
13043−grownup.
13044−
13045−## Contributors
13046−
13047−Many thanks to those who have been providing the fantastic stream of
13048−PRs we have been getting. We've had great help on all parts of the
13049−stack, from the front-end to the C interpreter to Arvo vanes.
13050−
13051−We'd love to help you get involved. Come join us on `:talk`!
13052−
13053−## Keep in touch / office hours
13054−
13055−`:talk` is always a great place to come and ask questions. Going
13056−forward someone from Tlon will be available in `:talk` from 12PM - 3PM
13057−PDT each weekday.
13058−
13059−[r/urbit](https://www.reddit.com/r/urbit) is also a good place for any
13060−kind of discussion.
13061−
13062−For anything else you can always get in touch with us via
13063−[`urbit@urbit.org`](mailto:urbit@urbit.org).
13064−]]></content:encoded>
13065− </item>
13066− <item>
13067− <title><![CDATA[Toward a New %clay]]></title>
13068− <link>https://urbit.org/blog/toward-a-new-clay</link>
13069− <guid>https://urbit.org/blog/toward-a-new-clay</guid>
13070− <pubDate>Wed, 13 Jul 2016 00:00:00 GMT</pubDate>
13071− <content:encoded><![CDATA[
13072−TLDR: (a) Urbit's revision-control system, `%clay`, is itself due
13073−for a (medium-sized) revision! (b) this time, you yourself can
13074−really help! (c) please don't give away the buried spoiler!
13075−
13076−This explanation does not (or at least should not) require you to
13077−know anything about Urbit.
13078−
13079−### But %clay is already pretty cool
13080−
13081−Of course, nothing in Urbit is allowed to be _lame_. `%clay` is
13082−actually quite cool. It does need some work. But first, let's
13083−talk about what it is and why it's cool.
13084−
13085−`%clay` is the Arvo vane (Urbit kernel module) for revision
13086−control. It's an authenticated, human-memorable global immutable
13087−namespace which is also a typed revision-control system. It's
13088−also very good at subscription and synchronization. Urbit
13089−currently uses `%clay` to distribute live hotpatches; we
13090−transparently upgrade the whole network with one checkin.
13091−
13092−### Compared to other revision-control systems
13093−
13094−`%clay` is clearly a vanilla DVCS in the modern `git` style. Of
13095−deployed DVCS these days, `%clay` is probably closest in spirit
13096−to `bzr` or maybe `fossil`.
13097−
13098−Obviously, as a part of a larger whole, you would expect any
13099−Urbit RCS to be brutally spartan. `%clay` is. It's even more
13100−spartan than `bzr`.
13101−
13102−(In fact, it's really too spartan to fully use at the moment. We
13103−ourselves still use `%clay` mainly as a distribution system, and
13104−do all internal development on GitHub. This is because the
13105−present `%clay` lacks a few little conveniences, like commit
13106−messages. See upgrades, below.)
13107−
13108−There are lots of normal DVCS things in `%clay`. But there are
13109−also cool and unusual ones. Let's take a brief tour of the
13110−high-level system, then describe what we think should change
13111−about it.
13112−
13113−### Anatomy of a DVCS
13114−
13115−A DVCS is a historical state graph. A point in this graph is a
13116−snapshot of some tree-structured system, like a filesystem.
13117−
13118−These snapshots, including recursive internal nodes, are stored in
13119−a content-addressable store. Pointers in this store are used to
13120−construct a revision graph, whose edges are edit and/or merge
13121−actions. Some sort of namespace attaches meaningful names to
13122−current revisions in this graph.
13123−
13124−There are six big questions in the design of a DVCS:
13125−
13126−- how are snapshots named?
13127−- what is the data structure within a snapshot?
13128−- how does it map to the Unix filesystem?
13129−- how is the system queried?
13130−- how is the revision graph defined?
13131−- how does the content-addressable store work?
13132−
13133−## Anatomy of %clay
13134−
13135−A good way to summarize `%clay` (at present) is that its answers
13136−to the first four questions are interesting, and its answers to
13137−the last two are boring. We'll talk about all six, though.
13138−
13139−### Global namespace: [ship desk case]
13140−
13141−The permanent global name of a `%clay` snapshot is a `++beak`. A beak
13142−is a triple: `[ship desk case]`.
13143−
13144−The `++ship` is an Urbit ship. A ship is a network address, a
13145−human-memorable name and a cryptographic identity. The address
13146−width is variable; shorter addresses are more desirable. Most
13147−users have 32-bit addresses, which we map to four-syllable
13148−synthetic names like `~sorreg-namtyv`.
13149−
13150−The `++desk` is a 4-letter word meaning "branch."
13151−
13152−The `++case` is a version, one of three kinds: a version sequence
13153−number, a named label, or a date.
13154−
13155−In the Urbit path syntax, the beak is the first three segments of
13156−the path: `/ship/desk/case/my/cat/picture`.
13157−
13158−In most cases, a path parser has a default ship, desk and case,
13159−each of which can be replaced by `=`. So `/=home=/my/cat/picture`
13160−is the data at `/my/cat/picture` on your own ship, in the `%home`
13161−desk, right now. Immutability doesn't have to be inconvenient.
13162−
13163−`%clay` has no concept of a mutable name or a magic `HEAD`. Use
13164−the current date. If you're referring to remote data and you're
13165−worried about clock skew, subtract a second or three, or be
13166−prepared to block. (Or keep your clock unskewed, which shouldn't
13167−be _that_ hard.) It's not like mutable-name schemes work any
13168−better than this anyway.
13169−
13170−(Immutability is central to `%clay`. `git` merely adopted the
13171−reflog. `%clay` was born in it, molded by it...)
13172−
13173−`%clay` is objective; each Urbit node hosts only one ship, but
13174−treats domestic and foreign data (almost) the same way. If you
13175−ask your `%clay` repository for someone else's data, it will
13176−block the request until it gets the data, which it then caches.
13177−At present, we always fulfill requests from the origin ship,
13178−though in future we could certainly use it as a tracker.
13179−
13180−If `%clay` discards cached data, it keeps a hash, so that your
13181−urbit can't violate the local illusion of immutability. We
13182−can't, of course, prevent anyone else's ship from sending
13183−conflicting claims in different directions. But we can prevent
13184−programs on our own ship from hearing about them, meaning that we
13185−retain local referential transparency.
13186−
13187−### Local structure: dome, arch, leaf and mark
13188−
13189−A `%clay` snapshot is called a `++dome`. A dome is the `%clay`
13190−equivalent of a tree-structured filesystem.
13191−
13192−Each node in this tree is one uniform structure, an `++arch`,
13193−which is both file and directory. A `++leaf` or data value in
13194−this arch is a typed document.
13195−
13196−A logical document type is called a `++mark`. A mark is a
13197−symbolic pointer to a Hoon source file, in the same dome, for an
13198−engine that can validate, compare, and/or convert
13199−documents of that mark.
13200−
13201−Let's go over arches and marks a little more closely...
13202−
13203−#### An arch is a uniform filesystem node
13204−
13205−Most filesystems and RCS have modal nodes. For instance, a git
13206−data node can be a blob or a tree. `%clay` (and the Urbit
13207−namespace in general) has one kind of node, an `arch`:
13208−
13209−```
13210− ++ arch (pair (unit leaf) (map knot arch))
13211− ++ leaf (pair mark noun)
13212−```
13213−
13214−An arch has an optional typed-data leaf, and optional named
13215−children. In Unix terms, it's a file, a directory, or both. It
13216−can't be neither: an empty arch, with no data and no children, is
13217−auto-pruned. As in `git` (but not in Unix), the hierarchy is a
13218−pure function of its leaves. Paths exist only because of the
13219−data they point to.
13220−
13221−The `++knot` names in an arch path are also a little special.
13222−They're typed, in a sense; any knot can be parsed invertibly into
13223−a typed atom. The atom is an arbitrary unsigned integer. Its
13224−type (an `++aura` if you know Hoon) defines the semantics and
13225−presentation of the atom: for instance, a symbol, a decimal,
13226−a date, etc.
13227−
13228−Ultimately a filesystem is a database, and a path is a primary
13229−key. It's very useful to be able to store simple data in this
13230−key, in a standard and unambiguous way.
13231−
13232−Why uniform nodes? One, they map nicely to information trees
13233−where a subtree may need some custom collective presentation,
13234−not an automatically generated Apache style directory listing.
13235−Two, non-uniform nodes introduce a whole pointless category of
13236−node type conflicts -- for which life is far too short.
13237−
13238−#### A mark is an executable document type
13239−
13240−A mark is "like an executable MIME type." It's best defined as a
13241−symbolic mapping from a filesystem to a schema engine.
13242−
13243−If you have a MIME type `text/html`, you need to watch the
13244−Internets to track what the W3C thinks HTML is. If you have an
13245−Urbit mark `%html`, you can functionally construct (using our
13246−insanely powerful functional build vane `%ford`) a core which
13247−can validate or normalize HTML, apply patch and diff logic, and
13248−translate to and from other marks. `%ford` can even reason about
13249−translation paths and construct multistep conversions.
13250−
13251−(Urbit does not actually have this super-smart `%html` mark right
13252−now. But it probably should, huh. And this page was composed in
13253−Markdown and translated to HTML by `%ford`.)
13254−
13255−Where does the source code of a mark live? Within the same dome
13256−as the data it describes. `%html` files are described by the
13257−Hoon source at `/===/mar/html`, which perhaps gets mapped into
13258−your Unix filesystem at `$ship/home/mar/html.hoon`.
13259−
13260−This Hoon file is not self-contained. It has dependencies. The
13261−`%html` mark may depend on various structures and libraries
13262−elsewhere in Urbit. But the source code for all them is within
13263−this dome.
13264−
13265−One constraint this puts on domes is that _all domes are
13266−descendants of the base system dome_. Domes are versions of one
13267−reality, not fragments of that reality. You can't create a new
13268−empty dome -- you'd have no mark source, and be unable to install
13269−any validated files.
13270−
13271−Enforcing the rule that all domes are congruent (if only in that
13272−they all contain the base system files) costs us nothing in the
13273−implementation, does not inconvenience the user, and ensures that
13274−weird collisions between non-parallel things don't happen.
13275−
13276−### Unix mapping and mounting
13277−
13278−Every DVCS is its own filesystem in a sense. But every DVCS
13279−works by mapping and mounting itself, in some sense, to Unix.
13280−
13281−#### Mapping arches to Unix
13282−
13283−How do we map arches into Unix? The arch structure maps 1:1 to
13284−the Unix directory tree. When the arch has a leaf, we derive a
13285−dot extension from the file's mark.
13286−
13287−So, supposing we have a leaf `foo` which is an HTML document
13288−(mark `%html`), with two children `bar` and `moo`, also HTML
13289−documents, in Unix we'll see:
13290−
13291−```
13292−foo.html
13293−foo/bar.html
13294−foo/moo.html
13295−```
13296−
13297−This maps invertibly back into `%clay`, and it looks perfectly
13298−unremarkable from the Unix side. File completion sometimes gets
13299−a little annoying.
13300−
13301−It would be if nice every possible Unix tree, even every
13302−plausible Unix tree, mapped cleanly and completely to a `%clay`
13303−dome. There are always horrid exceptions, even in common use --
13304−like extensionless Makefiles. The trivial solution is that if
13305−`%clay` finds a file mysterious, it won't track it.
13306−
13307−One often unquestioned assumption in new system software is that
13308−compatibility with old content is important. It's nice, but not
13309−that important. Most content in a new system is new content.
13310−The important compatibility direction is export, not import. So
13311−the new system should subset, not superset, the ancient formats.
13312−
13313−### Mounting desks to Unix
13314−
13315−If a `%clay` desk is _mounted_, it has a two-way live sync to
13316−the Unix directory of the same name within the pier.
13317−
13318−When files in a mount directory change, `%clay` notices it
13319−through `libuv` filesystem watching (ultimately `inotify()` or
13320−`FSEvents`), computes diffs, and automatically commits them to
13321−the desk. And if `%clay` creates a new version for its own
13322−urbity reasons, it will revise the Unix files.
13323−
13324−Keeping all mounted files in the same Unix subdirectory makes it
13325−easy to move the whole pier in a tarfile. Edits applied while
13326−the `urbit` process isn't running will be detected and applied
13327−the next time it starts.
13328−
13329−In conventional DVCS terms, `%clay` has a 1:1 static mapping from
13330−branches to working directories. Why?
13331−
13332−Why not? Do we need that "what branches are checked out in what
13333−directories" piece of state? Why force the user to worry about
13334−which branches are mounted to which directories? Why not just
13335−mount them under their own names? Is there some crippling global
13336−shortage of disk space for source files? Our planet is running
13337−out of inodes? Wut?
13338−
13339−### Queries, subscriptions and synchronization
13340−
13341−There are two ways to get data out of `%clay`: dereference the Urbit
13342−namespace, or send a request/subscription. Sync is in userspace.
13343−
13344−#### Dereferencing the namespace
13345−
13346−`%clay` is just part of the full Urbit namespace. The full namespace
13347−has a two-character prefix which expresses what vane to query
13348−(always `%c` for `%clay`). The suffix is a mode flag; `%x` for
13349−data, `%y` for a list of children, `%z` for the whole arch
13350−subtree, `%w` for the version number. (Each vane has its own
13351−modes.)
13352−
13353−For example, the full path to my cat picture is
13354−
13355−```
13356−/cx/~sorreg-namtyv/home/[now]/my/cat/picture
13357−```
13358−
13359−(where `now` is the current date).
13360−
13361−If the data model is `++image` (hypothetical -- we don't really
13362−do image processing in Urbit right now), the normal way to load
13363−this data in a Hoon program is
13364−
13365−```
13366−.^(image /cx/~sorreg-namtyv/home/[now]/my/cat/picture)
13367−```
13368−
13369−This produces a statically typed value (which works by
13370−dynamically checking `image` against the actual type of the
13371−value, but this comparison caches well).
13372−
13373−Internally, an Urbit namespace request produces a `++cage`, which
13374−has a mark, a `++span` (language-level type), and an actual noun.
13375−The product is doubly optional, `(unit (unit cage))`; this is `~`
13376−if we don't know the value of this name at present but might
13377−learn it in future, `[~ ~]` if we know we'll never know it, or
13378−`[~ ~ value]` if we know it now.
13379−
13380−In high-level shell programming (`:dojo`), we can make apparently
13381−"blocking" requests to `%clay`. What actually happens: when `%clay`
13382−produces `~`, we stop trying to compute this expression and wait
13383−on one or more blocking requests. When we are unblocked, we
13384−recompute again from scratch; the intermediate computation is not
13385−saved at all.
13386−
13387−Urbit doesn't like to block. It likes to save coherent data
13388−structures, not incomplete computation contexts. When Urbit
13389−pretends to block for you, this is a courtesy service. You
13390−can return the courtesy of not expecting miracles from it.
13391−When in doubt, send an actual request.
13392−
13393−### Requests and subscriptions
13394−
13395−A true request (local or remote) has access to the same
13396−namespace, but can (a) read across case (revision) ranges,
13397−and (b) filter by subtree.
13398−
13399−If the revision range in a request stretches into the future, the
13400−request becomes a subscription. Urbit messaging always regards a
13401−single response as a special case of a subscription.
13402−
13403−Generally, the response stream created by a request starts with
13404−all the data the server has available right now; updates will
13405−follow when they become available; the subscription will be
13406−closed when the request range is complete.
13407−
13408−#### Userspace synchronization
13409−
13410−Synchronization per se is done in userspace. In `%clay`, sync just
13411−means an application (typically the `%kiln` module in the system
13412−app `:hood`) subscribes to a remote desk, and saves its change
13413−stream locally. So sync is really an emergent feature of `%clay`.
13414−
13415−### Revision graph
13416−
13417−`%clay`'s revision graph is completely uninteresting at present.
13418−Some changes are proposed below, however.
13419−
13420−As in any DVCS, a dome is the child of one parent dome (an edit)
13421−or more parents (a merge). Often the parent of any revision is
13422−the previous version in the sequence, but it can be anything.
13423−
13424−### Storage model
13425−
13426−`%clay`'s storage model is completely uninteresting. It's also a
13427−little funky and I want to change it, so I'll be super vague.
13428−
13429−A `++lobe`, a 128-bit atom, is the Merkle hash of a `blob`, which
13430−is essentially a leaf. All blobs are stored in a hash table
13431−(`(map lobe blob)`), and reference each other through lobes.
13432−
13433−At present we don't GC this space at all, because we don't
13434−actually delete any roots.
13435−
13436−A `blob` may be `%direct`, meaning it's defined as the data
13437−itself, or `%delta`, defined as a change against another blob.
13438−This is motivated by the desire not to store a full snapshot
13439−on every file change. But it may be misguided (see changes #0
13440−and #1 below).
13441−
13442−We cache the full arch tree (`++ankh`) of the latest state in
13443−each desk. For current queries, this mitigates a lot of the
13444−opportunities for slowness that this data model creates. But the
13445−disparity between the speed of the current version and the
13446−speed previous version is an undesirable glitch in the API.
13447−
13448−## Our motivation for change
13449−
13450−We actually have _three_ motivations for change...
13451−
13452−### We need to develop on %clay
13453−
13454−At present, we're still using `git` as a development platform.
13455−`%clay` is certainly used, but just for its strength --
13456−deployment. This is starving Urbit of essential experience and
13457−basically keeping it lame. So, change is necessary.
13458−
13459−### Change must come from the community
13460−
13461−"Why?" you ask? "Why must change come from the community?" Well,
13462−one, duh. Change always comes from the community.
13463−
13464−But two, a great force for change has departed. Philip Monk,
13465−late maintainer of `%clay` (`~wictuc-folrex` in the old era,
13466−`~wicdev-wisryt` in the new), is tired of types and typing. He
13467−spent September roaming with the bison in Montana, and is now
13468−literally on his way to Patagonia. On the one hand, Phil still
13469−exists and is not at all unwilling to answer questions, even dumb
13470−questions. On the other hand, _Patagonia_.
13471−
13472−So %clay needs a new owner, or owners. At this point, we think
13473−the community might be indoctrinated enough to take a stab.
13474−
13475−Alas, `%clay` already has a pretty checkered ownership history.
13476−Long ago I built a `%clay` that was really the only serious
13477−design failure in Arvo. Then Jared Hance, a brilliant summer
13478−intern, took my broken `%clay` and reformed it into a minimal `git`
13479−in about a week. Then Philip modified Jared's `%clay` to be a
13480−_typed_ revision-control system, which is a pretty cool thing.
13481−
13482−But... in none of these transitions did `%clay` actually get
13483−_rewritten_ per se. While it's a reasonably good vane, it
13484−does contain one or two historical decisions.
13485−
13486−We know a lot more about Arvo than we used to, and I think we can
13487−revisit many of these decisions. The point of this post is to
13488−start a `%clay` design discussion that will evolve into actual
13489−collective action.
13490−
13491−### Pioneers may find it worth their time
13492−
13493−We're planning a rewards program for contributions to `%clay`.
13494−It'll simply involve setting a time period and a pool of real
13495−estate, and allocating the pool by judged contribution.
13496−
13497−This is an experimental program. We'll say more about it later.
13498−It may not even happen. It may happen very differently. When in
13499−doubt, don't talk about Fight Club.
13500−
13501−## Some openings for change
13502−
13503−Change, of course, must come from the community. No one can
13504−dictate change from the top down. We _know_ this. But...
13505−
13506−This list of suggested changes for the next `%clay` is not in any
13507−sort of order: priority, structure, difficulty, etc. Let's talk
13508−about the changes first; make actual plans second. The numbers
13509−here are just for convenience.
13510−
13511−_All changes in this program will happen on the next-generation
13512−(`cc-release`) branch._
13513−
13514−### Change #0: state reform
13515−
13516−As mentioned above, the storage model in `%clay`, as the code is
13517−at present, feels a little funky to me. There's nothing terribly
13518−awful about it, but it doesn't feel quite right and its scaling
13519−properties are very questionable.
13520−
13521−Briefly, `%clay` today actually derives the hierarchy from its
13522−leaves -- rather than _logically_ so deriving it. Only leaves
13523−are in the object store. This is just weird, and you can feel
13524−`%clay` trying to be something other than what it is. (I blame
13525−Jared, though it's actually my fault.)
13526−
13527−To store a dome snapshot (`++yaki`), the present code keeps a
13528−`(map path blob)` at the root of the dome. This is enough to
13529−reconstruct the `++arch` structures the namespace exports.
13530−However, all kinds of basic arch operations, like basically `ls`,
13531−become `O(n)` in the number of leaves in the dome. This is
13532−obviously not quite right.
13533−
13534−I believe the storage structure should be (removing everything
13535−that isn't needed to serve the namespace):
13536−
13537−```
13538− ++ clay (pair safe (map term desk))
13539− ++ desk (pair numb (map numb root))
13540− ++ dome (pair date root)
13541− ++ leaf (pair mark noun)
13542− ++ lobe @uvH :: 128-bit base32
13543− ++ numb @ud :: decimal version number
13544− ++ root (pair (unit leaf) (map knot lobe))
13545− ++ safe (map lobe root)
13546−```
13547−
13548−Here a `++root` is the universal node, with children addressed by
13549−hash, but logically representing the abstract `++arch`.
13550−
13551−Users of hierarchical filesystems basically expect performance
13552−qualities that match the filesystem structure. A huge directory
13553−in one place shouldn't affect search speeds somewhere else. And
13554−of course, `ls` can't be O(n) in the size of the filesystem.
13555−
13556−### Change #1: store edges, cache snapshots
13557−
13558−The current `%clay` is snapshot-oriented, like `git`. The actual
13559−changes are discarded. I think this is a bad choice.
13560−
13561−`%clay` is not a research project, and has no idea of going as
13562−far as `darcs` in the "set-of-patches" direction. However, at
13563−present we actually throw away the patch (`++nori`).
13564−
13565−I think the right DVCS design for `%clay` is a snapshot-oriented
13566−system which also keeps the patches. The revision graph has the
13567−same general shape as in the old `git` style. But rather than
13568−just deriving the diffs from the snapshots, we can also derive
13569−the snapshots from the diffs. When in doubt, we save space by
13570−dropping the snapshot, not the diff.
13571−
13572−For an RCS which is also a general-purpose typed filesystem, it's
13573−clear that considering edges (deltas, diffs, changes, etc) as the
13574−primary state is optimal. You can use diff functions to derive
13575−deltas from snapshots, but in many data models this will always
13576−risk losing information from the original action. When in
13577−doubt, save what the user did.
13578−
13579−This is even more true for operations on the tree structure, not
13580−on individual leaves. Consider the heuristic energy that `git` has
13581−to go through to figure out when `mv` has been used -- even when
13582−`git mv` has been used! (According to the `git` faq, this is
13583−because the lowest common denominator remains Linus' style of
13584−working with emailed patches.)
13585−
13586−Edges probably don't even need to be deduplicated. They also can
13587−contain metadata such as commit messages (which `%clay` has no
13588−place for at present).
13589−
13590−Once edges are recognized as unreclaimed primary state, snapshots
13591−can always be derived from the edges. So we can reclaim memory
13592−being used for snapshots.
13593−
13594−It's also straightforward to have a kind of edge which is a list
13595−of edges, letting us collapse feature branches trivially.
13596−
13597−Finally, I think references in edges should wherever possible
13598−indirect through the namespace, rather than directly to the
13599−content address. The user has strictly more information if you
13600−say you merged `/~sorreg-namtyv/base/987/`, than if all you have
13601−is the hash that this reference refers to.
13602−
13603−### Change #2: unconfuse merge and rebase
13604−
13605−The dispute between merge and rebase has all the bad smells of
13606−a historical wart. But here I'm just not sure what's right.
13607−
13608−The user has one _intent_ whether merging or rebasing, which is
13609−to combine changes on one desk into another. The _algorithm_
13610−used to construct this change, whether operational transformation
13611−(rebasing) or a 3-way diff (merging) has one goal: use all
13612−available information to model the authors' editing intent as
13613−realistically as possible. If we save edges, we should use
13614−edges.
13615−
13616−Whether to define the resulting change graph with the typical
13617−structure of a merge, or the typical structure of a rebase,
13618−strikes me as quite arbitrary, and well into the land of "pick
13619−one and force everyone to stick with it." But this call demands
13620−a real expert on RCS workflow, which I'm not.
13621−
13622−Since `%clay` is a humble part of a larger system and needs to
13623−keep its weight down, "do it both ways because people have
13624−different preferences" is not usually the right answer.
13625−
13626−### Change #3: comment jihad
13627−
13628−`%clay` needs to be brought up to the documentation standards of
13629−`%jael`. This means (a) the formatting matches; (b) the comments
13630−are at the same level of quality and ubiquity.
13631−
13632−The basic commenting standards are: (a) every core (class) needs
13633−a block comment explanation; (b) every gate (function) needs a
13634−line comment; (c) every face (variable) needs a line comment.
13635−
13636−This is obviously not just a clerical task. To write these
13637−comments, you need to actually understand the code. This is a
13638−nontrivial but extremely rewarding task, even if the code you're
13639−commenting will get replaced.
13640−
13641−Also, the _symbols_ in `%clay` must be brought up to `%jael`
13642−quality. There is still far too much four-letterism here.
13643−
13644−NB: `%clay` is about 3000 lines of pretty clean Hoon, which is
13645−certainly not at all undocumented. We're not exactly looking at
13646−a Matterhorn of reverse engineering here.
13647−
13648−### Change #4: knot to coin internal paths
13649−
13650−One feature of Urbit paths, briefly mentioned above, is that a
13651−path segment or `++knot` (which is just a `@tas` text string, an
13652−ASCII symbol as an atom) must be within the range of the
13653−invertible noun printer, `++co`.
13654−
13655−`++co` maps a described data value, a `++coin`, to an ASCII
13656−string which is a valid URL segment and Unix filename. Its
13657−friend `++so` inverts the function, perfectly.
13658−
13659−Almost every knot is the simplest kind of `coin`, a `dime.` A
13660−dime is a single atom with a rendering type (`aura` if you know
13661−Hoon). Auras include `@tas` for symbolic text, `@ud` for
13662−unsigned decimal, `@p` for Urbit ship, etc. `++co` can also
13663−print arbitrary cells, though less prettily.
13664−
13665−This feature is cool because it lets us stuff data into names in
13666−a precise and predictable way. Usually the names in a namespace
13667−are human-meaningful and human-originated, and are therefore
13668−symbolic, but there are exceptions. For example, blogposts may
13669−want to be named by date.
13670−
13671−However, it is slightly retarded for the fundamental state of our
13672−arches to store the _rendered_ string (`++knot`), not the source
13673−data (`++coin`). It leads to all kinds of inefficiencies where
13674−we're doing way more parsing than we want to. (Parsing also
13675−should be jet-propelled, but is not.) It also makes it way too
13676−easy to sneak in bad data and make it `%clay`'s problem.
13677−
13678−So, logically, we'd be shifting from
13679−
13680−```
13681− ++ arch (pair (unit (pair mark noun)) (map knot arch))
13682−```
13683−
13684−```
13685− ++ arch (pair (unit (pair mark noun)) (map coin arch))
13686−```
13687−
13688−Also, a vanilla `++map` might not be quite the right data
13689−structure at this point -- we probably want a custom sorted tree,
13690−which separates auras and imposes a custom order on each. This
13691−would let us serve simple range queries quite efficiently, so
13692−long as they match the standard aura order (eg, alphabetical
13693−order for symbols).
13694−
13695−### Change #5: dome semantics by reference
13696−
13697−While the principle that a dome contains its own mark source is
13698−elegant, it's a pain in the ass to implement properly. `%clay`
13699−certainly does not do it justice at present.
13700−
13701−The complexity is in checking every change to see whether it
13702−includes a change to the mark source (which is very unlikely),
13703−or a dependency of the mark source (slightly less unlikely).
13704−And if so, do we have to update all the leaves in the dome?
13705−This is also very unlikely. And yet, it happens.
13706−
13707−Instead, we could simply designate, by beak (ship, desk, and
13708−case) a dome which contains the canonical mark source. This
13709−would rarely change -- you could upgrade a desk to a new mark
13710−dome, but it would be a manual operation and probably a rare one.
13711−
13712−The common case would just be that everyone uses the current
13713−version of the `%base` desk when a desk is created, and never
13714−changes it. In practice, this means not every two-byte edit
13715−needs to get involved in detecting and/or applying schema
13716−evolution, a welcome simplification.
13717−
13718−### Change #6: mark containers
13719−
13720−Marks in present `%clay` are atomic and symbolic (like `%html`).
13721−Since they're also used for network protocols, and the proper
13722−design is one mark per message structure, the mark namespace gets
13723−overloaded fast.
13724−
13725−So we added an app hierarchy within the mark namespace, using hep
13726−`-` as a divider. The `:talk` app expects messages with the mark
13727−`talk-message`, whose sources is in `/===/mar/talk/message`.
13728−
13729−This helps, but it doesn't solve another two problems: trivial
13730−nouns and containers.
13731−
13732−It's retarded to have to add a source file to send a `@ud` or a
13733−`*`. An aura (see above under `coin`) should be a trivial mark.
13734−
13735−Also, we need to be able to construct standard containers of
13736−marks: lists, maps, sets, and tuples (or, as a database person
13737−would say, "rows").
13738−
13739−### Change #7: meta-marks
13740−
13741−Another kind of complex mark that needs to exist: conflict,
13742−difference, and invalid marks.
13743−
13744−Conflict data and difference data are two types of noun that are
13745−generated in normal RCS operation. If we have the concept of an
13746−`%html` noun, we also need the concept of an invertible change
13747−from one `%html` file to another; a merge conflict between two
13748−`%html` files; and even a conflict between two marks.
13749−
13750−There are two kinds of changes to a dome: manual and automatic.
13751−Manual changes are initiated by the user and should crash, unless
13752−manually overridden. Automatic changes should not crash, ever,
13753−and should not lose data. If they create problems, which they
13754−shouldn't, these problems will need to be cleaned up manually.
13755−
13756−This is a complex space to navigate, but it requires a conflicted
13757−merge to be able to resolve to a valid dome containing conflict
13758−leaves, not crash. The present `%clay` goes halfway there and
13759−resolves to a scratch desk, but we can go farther: the whole `git`
13760−dumpster-fire of "merge state" deserves destruction. One change
13761−is a merge that produces conflicts, the next is an edit that
13762−resolves them.
13763−
13764−Similarly, all sorts of errors can produce invalid leaves. One
13765−particularly rare case which is nonetheless important is schema
13766−evolution: what happens to files in a mark, when the mark source
13767−code changes. They all need to be re-normalized. And this
13768−operation can fail, producing an invalid value. (We don't do any
13769−of this now, BTW, although `%ford` has the dependency mechanism to
13770−make it possible.) Again, in some cases this should crash the
13771−update to the mark source; in other cases, there is no local way
13772−to handle the crash.
13773−
13774−So there must be a way to preserve invalid nouns that can be
13775−repaired by repair tools that expect invalid content, while not
13776−actually marking them as valid so that innocent code is deluded
13777−into using the bad content.
13778−
13779−The bottom line: a mark needs to be split into two models:
13780−`++mark`, the original symbolic mark with its source engine, and
13781−something like `++logo`, the meta-mark or mark container. The
13782−mark is the building block; the logo is the building.
13783−
13784−### Change #8: filesystem hierarchy standard
13785−
13786−While all filesystems remain forks of one ur-filesystem, the
13787−standard tends to enforce itself. But not define itself.
13788−
13789−I've always hated the current `/mar` for marks, for instance. I
13790−prefer `/mac`. But others hate this. And so on. Also, by
13791−necessity, our nascent "FHS" is heavily biased toward system
13792−data, away from user data. This is retarded.
13793−
13794−Please focus all bikeshedding energy on this problem! Better to
13795−bikeshed about what color to paint the bikeshed, then what shape
13796−the bike gears should be.
13797−
13798−### Change #9: security and access control
13799−
13800−Oh, yeah, that! They always say not to design security in at the
13801−last minute. Unfortunately, this is exactly what we did. There
13802−is no security at all in present `%clay`. (There is also no push
13803−operation in `%clay`, so it's not as mad as you think -- anyone
13804−can read anything, no one can write anything, which is fine in a
13805−young network where there are no secrets.)
13806−
13807−Fortunately, we don't have anything super fancy planned in this
13808−area, just basic access-control lists. These obviously need to
13809−be designed along with the filesystem-hierarchy standard (see
13810−elsewhere).
13811−
13812−Is it even possible to do ACLs properly in `%clay`? At this
13813−point, yes. There is an event-oriented security model in Arvo,
13814−though it isn't really hooked up to anything at the moment.
13815−There is also a privilege badge system in `%jael`. The
13816−combination of these two features is quite sufficient for a
13817−decent ACL model.
13818−
13819−The idea of event-based security is that every event passed to
13820−`%clay` has a security `++mask`. The mask tells us:
13821−
13822−- the set of ships that has _contaminated_ this event
13823−- the set of ships that has _endorsed_ this event
13824−- the set of ships that this event may be _released_ to.
13825−
13826−To simplify this system a little and maybe explain it, the
13827−security question in any event is: (a) who has _caused_ this
13828−event? (b) who may receive its _effects_? (These sets never
13829−include your urbit itself, of course, only neighbors.)
13830−
13831−For example, if we're doing something because ship X sent us a
13832−packet, and we're going to leak the results of this something
13833−back in a response to ship X, once `%clay` knows what our ship
13834−thinks of its neighbor X, we should have a good picture of what
13835−effects this event should be allowed to cause. If `%jael` knows
13836−that X is our friend, `%clay` can know that X can see our cat
13837−picture.
13838−
13839−Causality is separated out into contamination (data from ship X
13840−got into the event) and endorsement (ship X signed the whole
13841−event). (This may be overdesign.) All these sets can be defined
13842−as the empty set (eg, releasing to the empty set means no output)
13843−or the universal set (input from the universal set could be from
13844−anyone, ie, is unauthenticated).
13845−
13846−### Change #10: stop using mark-extended paths
13847−
13848−When you read a leaf from a `%clay` dome, `%clay` is happy to
13849−perform any necessary mark conversions (the actual work is done
13850−by the `%ford` build vane). You can also just ask for the leaf
13851−in whatever mark `%clay` has it.
13852−
13853−It's confusing to think of this mark extension as part of the
13854−path. You shouldn't say `+cat /===/app/talk/hoon`. You should say
13855−`+cat /===/app/talk`, or maybe `+cat %hoon /===/app/talk`.
13856−
13857−A mark-extended namespace may be added to `%ford`, to compensate.
13858−But type-converting reads are the rare case, not the common case.
13859−
13860−### Change #11: real queries and indexes
13861−
13862−A filesystem should postpone being a database until it can no
13863−longer do so. So, please don't think about this problem yet.
13864−I'm joking, of course!
13865−
13866−### Change #12: meta-query
13867−
13868−Make it possible to query the list of desks in a ship :-)
13869−
13870−### Change #13: completely redesign Unix mounting
13871−
13872−This is actually a series of changes, described below. But
13873−broadly...
13874−
13875−One of Urbit's experiments is live two-way synchronization
13876−between the Unix filesystem and the revision-control store.
13877−Dropbox style, as it were. I think this experiment is basically
13878−a failure. It may be right for cat pictures, but I don't think
13879−it's right for Urbit.
13880−
13881−The fundamental problem is that there are all sorts of weird,
13882−flaky ways applications use a mutable filesystem. It's not at
13883−all unusual for an editor to change a file by deleting the old
13884−file, then writing the new one in its place.
13885−
13886−You really don't want this to produce a delete change. A simple
13887−cooldown timer for the sync helps a lot with this, but causes
13888−other weirdnesses. In theory, a sync can even cause another
13889−change to the same version of the same desk. And so on.
13890−
13891−The thing we fear is just too funky to work (there is some
13892−strange "reflux bug" still affecting it) is any sort of _two-way_
13893−synchronization between Unix and Urbit.
13894−
13895−And what I think puts this feature into the deadpool, or at least
13896−cold storage, is that there's no useful workflow that actually
13897−uses it -- at least, when editing Urbit code.
13898−
13899−It's actually really nice to have files on a disk that nothing
13900−will automatically modify. If you're using `git` and `%clay` in
13901−parallel, it's nice to mount your `git` working directory. The
13902−original Urbit workflow was to work out of a mounted directory,
13903−but the two-way updates were just too weird and scary, so now we
13904−tend to edit elsewhere and copy in -- which is lame.
13905−
13906−### Change #14: figure out what to do with FUSE
13907−
13908−We actually have two forms of filesystem access to `%clay`: read-only
13909−FUSE (in a somewhat experimental state), and filesystem watching
13910−(using `inotify()` and `FSEvents` under a `libuv` wrapper).
13911−
13912−The FUSE interface is a good one, though it needs more work.
13913−Moreover, it exports the whole Urbit namespace to Unix, not just
13914−`%clay`. For reading Urbit data, FUSE is basically ideal.
13915−
13916−The obvious impulse is to make a read-write FUSE. But I don't
13917−think FUSE should be used for recording changes to an RCS, even
13918−though the FUSE API sends you changes as events.
13919−
13920−There are three reasons for this. One, the actual filesystem
13921−writes that Unix apps make are typically of low quality and
13922−confusing. Some crack-brained editor will find it completely
13923−normal and unremarkable to modify a byte in a file, by deleting
13924−the file and rewriting it from scratch. You can use a cooldown
13925−timer to wait for this nonsense to converge, but leaving data in
13926−heuristic limbo seems like a very bad idea in FUSE-land.
13927−
13928−The second is that people derive a lot of comfort from seeing
13929−actual files on an actual disk. The idea that your datas are
13930−stuck in Urbit is slightly terrifying as a user experience.
13931−We claim to be reliable. It's actually hard to imagine datas that
13932−couldn't be recovered from either snapshot or log. But how can
13933−you possibly believe us on this?
13934−
13935−So I think it's correct to lean all the weight of reading data
13936−from Urbit on FUSE, and use filesystem watching for writing.
13937−Heuristic timeouts are fine in filesystem watching, because at
13938−least the data got written when the disk says it got written.
13939−And at least it's on the disk.
13940−
13941−Also, FUSE is a daemon by definition, which forces us to think a
13942−little harder about how to run the Urbit process as a daemon.
13943−But this is a separate discussion.
13944−
13945−### Change #15: one-way, nonced working desk
13946−
13947−A one-way mount is a much less crazy thing. It works the same
13948−way our two-way mount works today, but with only one writer: the
13949−user, via Unix.
13950−
13951−Since a mount is one-way, it needs to have an absolute write lock
13952−on the desk it's writing to. We cannot have a `%home` desk which
13953−we are also editing with filesystem watching.
13954−
13955−Instead, we have a temporary and anonymous state that's connected
13956−itself with your `%home` desk. Desk names have to be valid
13957−symbols, but we can use `hep`, `-`. A reasonable choice is to
13958−pick a random 32-bit name for each mount instance -- so the desk
13959−name is not `%home`, but `%home-bosdut-sigder`. (Randomizing
13960−instead of always using a fixed suffix, say, `%home-work`,
13961−just makes all kinds of screwups less likely.)
13962−
13963−You create a mount simply by mkdiring the desk name in your pier.
13964−Just the base name, Urbit will come up with the `%bosdut-sigder`
13965−part and put it in a `.desk` file at the desk root. To forget
13966−the mount, just delete this file. This avoids the ugly confusion
13967−between unmounting a mount, and deleting all the data in it.
13968−
13969−(Urbit will keep a set of the mount desks it's used and
13970−forgotten, not reuse them, and block all requests into them. By
13971−blocking, we can delete without losing referential transparency.
13972−Yes, Virginia, Urbit can forget!)
13973−
13974−Note that the auto-reload behavior of applications is extremely
13975−useful when testing. When testing, you can either switch the
13976−active application desk from `%home` to `%home-bosdut-sigder`,
13977−or activate autosync from the latter to the former.
13978−
13979−### Change #16: commands as metafiles
13980−
13981−A new idea I'd like to play with is that, since the basic model
13982−of the mount process is to read Unix files and suck their
13983−contents into Urbit, you should be able to control a mounted
13984−`%clay` desk through Unix filesystem operations alone.
13985−
13986−No Urbit command-line access, not even any `urb/` HTTP control
13987−channels, should be required for the user to generate `%clay` data
13988−through filesystem mount, or to set up the mount.
13989−
13990−An RCS experience that works entirely through Unix tools, in
13991−which the only connection between content creation tools and
13992−revision-control tools is shared access to the filesystem itself,
13993−is essential if your RCS has something so repulsive as a daemon.
13994−Otherwise, you're basically, like, reinventing Perforce.
13995−
13996−More concretely, the Urbit experience today requires `:hood`
13997−pokes (Urbit shell commands, basically) for all nontrivial RCS
13998−operations, from mounting to merging. Again, there are lots of
13999−situations in which you can write into a mounted filesystem (the
14000−protocol for Unix communication could be easily adapted to
14001−communicate with a browser-based editor, for instance), but you
14002−don't want the user to have to bother with an Urbit shell.
14003−
14004−Even commands like mounting and merging are easily communicated,
14005−through filesystem writes that any Unix tool (including many
14006−macro editors).
14007−
14008−This is very easy for a filesystem watcher. One such protocol:
14009−if you want to send the daemon a command relative to some
14010−directory, write a `.ur-command` metafile in that directory. The
14011−daemon accepts the command by deleting it.
14012−
14013−The user experience is that you configure your mounts by simply
14014−making the directories and configuring dotfiles in them. Unlike
14015−in the present system, Urbit will never modify your datas
14016−silently in the background.
14017−
14018−Here's what this looks like:
14019−
14020−Suppose you want to edit some data in the `%home` desk. Your
14021−data is in `/=home=/mar/talk`. You also want a read-only view
14022−of `/=home=/arvo`.
14023−
14024−From Unix, you do something like this:
14025−
14026−```
14027− $ cd $pier
14028− $ mkdir -p home/mar/talk
14029− $ touch home/mar/talk/.edit
14030− $ mkdir home/arvo
14031− $ touch home/arvo/.read
14032−```
14033−
14034−Want to commit your changes? That means merging the working
14035−desk, `%home-bosdut-sigder`, into the `%home`. Put a commit message
14036−into `home/.commit` and it'll happen. If there's an error, it
14037−will appear as `.error`.
14038−
14039−The mount has a .version file which simply contains the change
14040−number (of the working desk) which any edits are relative to. If
14041−the urbit daemon is running and watching, edits will be absorbed
14042−quickly (probably after a heuristic timeout), and the version
14043−incremented. But we always are confident that the edits are
14044−against the latest version, or at least we can use this as a
14045−sanity check. All kinds of insane things can happen to get a
14046−filesystem out of consistency.
14047−
14048−This design obviously needs a little fleshing out, but I'm quite
14049−confident it's a convenient and reliable way to drive `%clay`
14050−from Unix.
14051−
14052−## In conclusion
14053−
14054−There's obviously a lot of fun here! There are two things you
14055−can do right now.
14056−
14057−One, talk about `%clay` on [this forum
14058−thread](http://urbit.org/~~/fora/posts/~2016.10.25..17.37.47..6937~/) or
14059−on [:talk](http://urbit.org/stream). Both hosted on Urbit
14060−itself!
14061−
14062−Two, poke around the
14063−[code](https://github.com/urbit/arvo/blob/cc-release/arvo/clay.hoon).
14064−Make sure you're on the development branch (`cc-release`).
14065−
14066−Phasing in this work will be a fun and interesting challenge.
14067−(My suspicion is that the right first task is the Unix mount.)
14068−Let's talk...
14069−]]></content:encoded>
14070− </item>
14071− <item>
14072− <title><![CDATA[Why Urbit Probably Doesn't Need a Blockchain]]></title>
14073− <link>https://urbit.org/blog/why-urbit-probably-does-not-need-a-blockchain</link>
14074− <guid>https://urbit.org/blog/why-urbit-probably-does-not-need-a-blockchain</guid>
14075− <pubDate>Wed, 13 Jul 2016 00:00:00 GMT</pubDate>
14076− <content:encoded><
14078−
14079−TLDR: Urbit (probably) doesn't need a blockchain, because the Urbit
14080−address-space PKI is a special case of a consensus ledger (itself a
14081−special case of Byzantine agreement).
14082−
14083−Special cases are often easier to solve than general problems. The
14084−"New Jersey" or "worse-is-better" school of systems design emphasizes
14085−solving any problem with the weakest possible tools.
14086−
14087−## The worse-is-better school
14088−
14089−Culturally, Urbit is best described as a functional stack built in the
14090−"New Jersey" school of system software design, as described in Richard
14091−Gabriel's famous
14092−["worse is better"](https://en.wikipedia.org/wiki/Worse_is_better) essay.
14093−
14094−There are two kinds of mindsets when approaching hard technical
14095−problems. The "MIT" mindset, more typical among mathematicians and
14096−scientists, wants to attack the problem as its simplest and broadest
14097−case, producing the most general and powerful solution available. In
14098−short: better-is-better.
14099−
14100−The "New Jersey" worse-is-better mentality, more typical among
14101−programmers and engineers, wants to do everything possible to _not_
14102−attack the problem. Can I produce a serviceable approximation to a
14103−true solution? Do I actually have to solve the general problem, or
14104−can I reduce it to an easier special case? Can I change the product
14105−so it doesn't have this problem?
14106−
14107−Ideally, anyone building anything has both these mindsets in their
14108−toolbox. But it's worth noting that (a) Jersey designs (meaning the
14109−Bell Labs school that produced Unix, C, and Go) tend to beat MIT
14110−designs in the marketplace, and (b) there are very few pure-functional
14111−systems built with the true Jersey spirit.
14112−
14113−## Why Urbit (probably) doesn't need a blockchain
14114−
14115−Nakamoto consensus is an example of better-is-better. The blockchain
14116−design is actually more powerful than it needs to be. It's not just a
14117−trustless decentralized ledger; it's a trustless decentralized
14118−database and (as Ethereum has realized; but this idea is clearly
14119−present in Bitcoin's scripting language) a general-purpose, zero-trust
14120−decentralized computer.
14121−
14122−Again, Urbit is not a general-purpose decentralized database or
14123−consensus computer. It's a special case of the former, which is a
14124−special case of the latter. Urbit is nothing but a digital title
14125−chain for network addresses. Our belief is that the special case is
14126−much easier than the general case, which is why Urbit (probably)
14127−doesn't need a blockchain.
14128−
14129−The rest of this essay describes what makes this special case special,
14130−and how we can use that to not need full Nakamoto consensus, or any
14131−kind of general-purpose Byzantine agreement.
14132−
14133−## The double-sell problem
14134−
14135−Urbit has the same basic "double-spend" issue as Bitcoin. As Satoshi
14136−puts it: "The problem of course is the payee can't verify that one of
14137−the owners did not double-spend the coin." But Urbit is not a
14138−currency, so we say "double-selling."
14139−
14140−"Double-selling" means signing over an Urbit address (_ship_) to two
14141−different parties at the same time, presumably with the intent to sell
14142−it to both and skip town with the loot.
14143−
14144−Again, the logical problem is the same. Bitcoin attacks it as a broad
14145−theoretical breakthrough: better-is-better. Urbit attacks it as a
14146−narrow special case: worse-is-better.
14147−
14148−Intuitively, Urbit's answer is that a real-estate transaction is
14149−substantively a very different thing from a credit-card payment. No
14150−real-estate agent ever has ever leaned over the desk, quickly grabbed
14151−_both_ the check and the keys, and run laughing out the door.
14152−
14153−To understand more rigorously how Urbit is a special case, let's take
14154−a quick look at the Urbit address space and PKI.
14155−
14156−## The Urbit address space and PKI
14157−
14158−(NB: this description differs in minor ways from the running code.
14159−Where they differ, the description is right. Urbit is not at present
14160−secure: use for entertainment purpose only.)
14161−
14162−An Urbit ship is an unsigned integer that serves four purposes: a
14163−cryptographic identity, a packet routing address, a stateful virtual
14164−computer, and a unique, human-memorable name.
14165−
14166−Each ship is owned by a private key. To transfer a ship to a new
14167−keypair, sign the new public key with the old private key. This
14168−revokes the old key and activates the new key. Propagating this
14169−update globally makes the revocation global. This is essentially the
14170−digital title system a smart 12-year-old would design.
14171−
14172−### Ships and wills
14173−
14174−Ships are 128-bit numbers classified into tiers by bitwidth. An 8-bit
14175−ship (a number less than 256) is a _galaxy_. A 16-bit ship is a
14176−_star_. A 32-bit ship is a _planet_. A 64-bit ship is a _moon_. A
14177−128-bit ship is a _comet_.
14178−
14179−The chain of signatures for each ship is called a _will_. Unlike most
14180−certificate systems, there is no metadata in an Urbit will. Nothing is
14181−signed but the public-key fingerprint. The length of the will is the
14182−keypair version that owns the ship. This version is called its
14183−_life_. Each new signed fingerprint in the will is a _deed_.
14184−
14185−Who gets to create a ship? Comets are fingerprints of a random
14186−keypair. Moons, planets and stars are created by their _prefix_, the
14187−ship whose bits are the bottom half of their formal width. For
14188−instance, the star `0xbeef` is the prefix of the planet `0xdeadbeef`.
14189−Galaxies have their fingerprints hardcoded in the official kernel.
14190−
14191−Ship numbers are not generally written in hex. They're written in
14192−Hoon's `@p` syntax, a phonemic base-256. `@p` also permutes within
14193−tiers, to superficially conceal prefix structure; for instance,
14194−`0xdead.beef` is `~firbyr-napbes`, while `0xcafe.beef` is
14195−`~nissep-sopnub`.
14196−
14197−### Parent hierarchy
14198−
14199−The prefix of a moon, planet, or star also becomes its _parent_. The
14200−parent of a ship is its natural locus of federated services. The most
14201−basic such service is to mediate P2P routing, as a so-called
14202−"supernode." But the set of potential federated services is
14203−unbounded.
14204−
14205−For moons, each new key update is signed by the parent. Planets and
14206−stars sign their own updates, making them independent. To prevent
14207−denial-of-service attacks by parents against children, stars and
14208−planets can _exit_, choosing a new parent. An exit deed is a key
14209−update also signed by the new parent.
14210−
14211−The full public cryptographic record of a ship is its _dossier_. The
14212−dossier is the set of ship-will pairs, including all parents and
14213−prefixes recursively, needed to validate the ship's current key. A
14214−ship can process a dossier from an untrusted source.
14215−
14216−The full set of ship-will pairs a ship knows is its _cabinet_. So the
14217−crucial question for PKI propagation is whether a submitted dossier is
14218−accepted into a ship's cabinet.
14219−
14220−### Propagation race
14221−
14222−The rule is simple: any deeds in the dossier which are new (not
14223−already in the cabinet) must not use keys superseded in the cabinet.
14224−Otherwise revocation doesn't work. But revocation affects only
14225−dossiers received in the future; nothing already in the cabinet can be
14226−revoked.
14227−
14228−Intuitively, this algorithm creates a propagation race. Life `2` of
14229−`~firbyr-napbes` revokes life `1` of `~firbyr-napbes`, so propagating
14230−life `2` to the whole network ensures that anyone who steals the
14231−private key for life `1` can't use it in any way -- whether to launch
14232−children, or to sign a new, bogus life `2`.
14233−
14234−## Solving the special case
14235−
14236−So how can we solve the double-sell problem, for the special case of
14237−the system designed above?
14238−
14239−### Double-spend relaying in Bitcoin
14240−
14241−The first thing we need to notice about our special case is that _even
14242−Bitcoin_, not considered as a general consensus problem but just as a
14243−decentralized payment rail, isn't that far from _not_ needing a
14244−blockchain.
14245−
14246−As the Karame ["Two Bitcoins at the Price of
14247−One"](http://eprint.iacr.org/2012/248.pdf) paper points out:
14248−
14249−> An efficient countermeasure to combat double-spending on fast
14250−> Bitcoin payments would be for Bitcoin peers to propagate alerts
14251−> whenever they receive two or more transactions that share common
14252−> inputs and different outputs.
14253−
14254−"Fast Bitcoin payments" means zero-confirmation, ie, Bitcoin without
14255−the blockchain. These double-spend alerts have never been integrated
14256−into Bitcoin Core, despite frequent proposals. Given that Bitcoin
14257−_does_ have a blockchain, it seems quite sensible for purists to shun
14258−hacks that make zero-conf transactions somewhat more secure. Also,
14259−double-spend alerts in Bitcoin are a DoS vulnerability; Bitcoin has
14260−fees to control the cost of propagating transactions, but who pays for
14261−an alert?
14262−
14263−In principle, however, we could imagine a version of Bitcoin without a
14264−blockchain, in which the mempool was the ledger, and there was an
14265−alerting and/or conflict model to detect and resolve double spends.
14266−An accepted transaction is simply one that propagates to one or more
14267−randomly chosen observer nodes.
14268−
14269−This design, for the problem that Bitcoin is solving, intuitively
14270−feels weak and a little hacky. The Karame paper is not actually
14271−advocating for removing the blockchain from Bitcoin. At the same
14272−time, low-value zero-confirmation payments are commonly used.
14273−
14274−One way to think about security is to flip the tables and think of the
14275−defender as the attacker, and vice versa. Just imagine you have some
14276−moral right to double spend. The rest of the world is unfairly trying
14277−to stop you. Can you defend yourself?
14278−
14279−In the context of a gossip network that shares all the things, a
14280−procedure that involves telling one person one thing, and another
14281−person another conflicting thing, and not getting "hacked" by the
14282−unfair world which believes there should be only one truth, is
14283−inherently quite fragile. And where the attack is fragile, the
14284−defense is robust.
14285−
14286−Most of the security in any digital title system comes from the PKI
14287−itself. The double-spend problem, the general issue of Byzantine
14288−failures in information propagation, is already a corner case. So
14289−perhaps we can solve it as a corner case.
14290−
14291−Again: _even Bitcoin_ isn't that far from being able to build a
14292−practical decentralized ledger without a blockchain. The same gossip
14293−model that broadcasts nonconflicting transactions is not at all
14294−incapable of reacting to conflicting transactions. We're not really
14295−recommending that Bitcoin ditch the blockchain, but this gives us hope
14296−with our fundamentally easier problem.
14297−
14298−## Various specific specialnesses
14299−
14300−What are the differences between the Urbit double-sell problem and the
14301−Bitcoin double-spend problem? Is our special case really, truly,
14302−special?
14303−
14304−In worse-is-better mode, we want every special-case advantage we can
14305−get. Every difference we find is one we can use as a leverage point.
14306−
14307−### Minimal transaction interdependency
14308−
14309−The first major technical difference between the Urbit title history
14310−and the Bitcoin blockchain is that Bitcoin and its relatives are
14311−designed to secure a complete, interdependent, collective transaction
14312−history. Except for the parent-child relationship, Urbit wills are
14313−independent of each other.
14314−
14315−Bitcoin's use of UTXOs rather than balances reduces interdependency
14316−somewhat. But the validity of each transaction is still dependent on
14317−all the transactions that created its inputs. (Ethereum drops the
14318−UTXO model, whose value in reducing dependencies may not match its
14319−cost in complexity.)
14320−
14321−Urbit is not a payment system or a shared ledger. Bitcoins are
14322−divisible, but Urbit ships aren't. An Urbit will containing its
14323−parent chain is self-validating and has no dependencies. There is no
14324−collective history. There is no Merkle tree. There is no chain, with
14325−or without blocks.
14326−
14327−This simplification doesn't eliminate the double-sell problem in
14328−theory, but makes it much more tractable in practice. The set of past
14329−transactions (key transfers) that a new transaction could conflict
14330−with is much smaller.
14331−
14332−### Trust hierarchy and governance structure
14333−
14334−The second major technical difference is that Bitcoin is a flat,
14335−trustless, fully decentralized system. Urbit has a hierarchical,
14336−polycentric governance system which is a trust hierarchy.
14337−
14338−Now and for quite some time, urbits default to automatically accepting
14339−OS updates from their parent, making this trust effectively absolute.
14340−This is not a novelty -- all "evergreen" browsers now work this way.
14341−You trust your browser quite a bit, which means you trust your browser
14342−vendor.
14343−
14344−And since few Bitcoin node operators code their own daemons, the same
14345−dependency on a source distribution exists in Bitcoin. It's informal
14346−and off-chain, though, which is not really a good thing. (Urbit is
14347−like if Bitcoin Core hotpatched itself automatically by publishing
14348−source-code diffs on the blockchain.)
14349−
14350−To be on the safe side, we should think of Urbit as a centralized
14351−system until the OS update that turns off automatic updates is
14352−shipped. This of course requires a certain measure of perfection,
14353−which cannot in any way be predicted.
14354−
14355−After Arvo proper becomes "deciduous" (apps will of course always be
14356−remotely hotpatched), child-to-parent trust should diminish to the
14357−power of the parent to deny service to the child. This will always be
14358−present without some major redesign.
14359−
14360−But it's opposed by the equal and opposite power of the child to
14361−switch to a different parent, creating a competitive market in
14362−governance. This should deliver service at the highest quality and
14363−lowest price, fortifying trust with incentives. The power of a
14364−restaurant owner to deny you service does not give the food industry
14365−the power to starve you to death.
14366−
14367−And if no parent wants your business, with 2^16 stars who could accept
14368−it, you probably shouldn't be on the network at all. Urbit, like a
14369−real society, is designed to be a network of incentives that holds
14370−everyone in productive tension. We want everyone to be free, and no
14371−one to be unaccountable.
14372−
14373−For example: a parent which extends its will also needs to send
14374−updated signatures to its children and former children. Either will
14375−otherwise be unable to propagate their dossiers to ships whose
14376−cabinets have the updated parent will, _even if some other parent
14377−adopts them_.
14378−
14379−But Urbit is a collectively governed and updatable system. A star or
14380−galaxy which denies service to its own children will (a) get a bad
14381−reputation, (b) drive its children to other parents, and (c) force the
14382−network to hardcode a ship-specific exception into the propagation
14383−algorithm, overriding stale-key revocation.
14384−
14385−In theory, a parent can extort its children by denying service. In
14386−practice, since Urbit is self-governing, not ungoverned, and its
14387−government can right this wrong with a source-code patch, the
14388−extortion won't work. So it won't happen. So the act of government
14389−won't be necessary, and won't happen either.
14390−
14391−Of course a perfectly decentralized system would be freer. But worse,
14392−as usual, is better. And since we are paying for this worseness,
14393−imperfect decentralization, we'd like to get all the mileage out of it
14394−that we can.
14395−
14396−Again, Urbit, not being a trustless system, does not have to solve the
14397−trustless consensus problem -- although we still very much want to
14398−minimize and bound the delegation of trust. This is an obvious
14399−relaxation of Bitcoin's hard theoretical problem.
14400−
14401−### Routing: security through topology
14402−
14403−Please don't laugh. Security through routing topology isn't a joke --
14404−unless firewalls are a joke. Cisco sells too many firewalls for them
14405−to be a joke.
14406−
14407−In Bitcoin we may have all sorts of reasons to ask what ship holds
14408−what coins. In Urbit, when we ask what key controls an ship, we are
14409−either sending or receiving a message. Is our outgoing message safely
14410−sealed to the current owner? Is our incoming message properly signed
14411−by the current owner?
14412−
14413−When the parent also forwards all packets until a P2P link is
14414−established (Urbit forwarding resolves to STUN if either party has
14415−full cone NAT, TURN if not), we can design in all kinds of
14416−interactions between routing and certificate management.
14417−
14418−In particular, a parent which is a single source of truth in some
14419−sense is a very attractive design element. Again, we're paying for
14420−our imperfect decentralization. We might as well use it.
14421−
14422−For example: I want to send a packet to ship X. Two parties, A and B,
14423−are competing for ownership of X. A is the rightful owner. I am
14424−secure against B if either of these conditions are true: my packet can
14425−only be decoded by A, or my packet is not sent to B. Both would be
14426−ideal, of course. Either will do.
14427−
14428−### Latency and friction tolerance
14429−
14430−Confirmed Bitcoin payments aren't especially low-latency by payment
14431−standards. They're reasonably low-friction by payment standards. But
14432−fees are certainly a thing.
14433−
14434−Urbit is digital real estate, not digital money. When we look at the
14435−standards of latency and friction in actual real estate -- where a
14436−transaction that takes a week is super-fast, a 5% payment overhead is
14437−normal, and a third-party intermediary is standard -- we see a much,
14438−much weaker set of requirements.
14439−
14440−Obviously a week and a 5% overhead are incredibly sucky levels of
14441−latency and friction. The point is that even if this is the only
14442−level of performance Urbit can achieve, that's not necessarily the end
14443−of the world for Urbit.
14444−
14445−For instance: if we wait a week for a double-sell alert, and we don't
14446−see one, either the gossip network is totally hosed (to a point we'd
14447−surely find out about), or there wasn't a double-sell. This stuff is
14448−just not that hard.
14449−
14450−(One little-made point about Bitcoin, by the way, is that Bitcoin
14451−enables trust-free _payments_, but not trust-free _exchanges_. The
14452−seller still needs to deliver the goods either before or after the
14453−payment; in either case, there is trust. Only Ethereum can solve this
14454−problem -- and only for digital exchanges.)
14455−
14456−## We can afford to be patient
14457−
14458−With a better-is-better, general-purpose solution, one size fits all
14459−until the end of time. With a worse-is-better, special-case solution,
14460−the details of that case are critical.
14461−
14462−But we actually don't know these details. One rule of the
14463−worse-is-better school: never solve a problem before you have to. You
14464−don't know all the details, and you need those details. (Of course,
14465−with the better-is-better approach, the details don't matter at all.)
14466−
14467−Is there such a thing as a transitive adjective? Grammarians are
14468−unclear. But technically, the adjective "secure" is always an error.
14469−Nothing is "secure." "Secure against X" is the correct usage, where X
14470−is some threat model.
14471−
14472−Urbit is an insecure test network with no sensitive data on it. This
14473−will remain true for a while. No Urbit ship has ever been transferred
14474−cryptographically. This will also remain the status quo for quite a
14475−while.
14476−
14477−We _don't know the threat model_. We _can't solve the problem_. It's
14478−as simple as that. The best Urbit can do, at the present time, is map
14479−out the ballpark of solutions.
14480−
14481−And we have time to proceed patiently. One way to think about the
14482−timing of cryptographic decentralization is to look at the DNS. It's
14483−clear that now, a decentralized DNS with cryptographic domain-name
14484−titles would be extremely desirable. It was never designed to happen.
14485−It will probably never happen.
14486−
14487−But if we look at when cryptographic DNS with allodial title _should_
14488−have happened, it's probably sometime in the mid-90s. Ie, after over a
14489−decade of production use of the Domain Name System. In short: there's
14490−no need to hurry here.
14491−
14492−## A map of the solution space
14493−
14494−But we still need a map of the worse-is-better ballpark. Let's look
14495−at some options, from least secure to most.
14496−
14497−The essential question we can't answer, without a better sense of the
14498−threat model, is how aggressively we need to propagate wills. We
14499−especially are not sure about the threat model of malicious stars
14500−(16-bit ships) and/or galaxies (8-bit ships).
14501−
14502−We need to know what kinds of double-sell attacks are plausible. Since
14503−we don't know this yet, we need not one propagation design, but a
14504−range of designs -- stretching all the way up to a full blockchain.
14505−
14506−### Acceptance model
14507−
14508−What doesn't change is the will _acceptance_ model. A ship will
14509−always accept a new will if (a) the new will extends the old will, (b)
14510−the parent signature on the initial public key is at least as recent
14511−as the ship's current version of that parent.
14512−
14513−The parent clause implies that when a parent extends its will, it
14514−needs to send updated initial signatures to all the children it's
14515−launched. Otherwise, their own future updates will not be accepted by
14516−ships that have seen the parent's update.
14517−
14518−This is not a big deal in the world of parent responsibilities. But
14519−like many such responsibilities, it lets a badly operated parent deny
14520−service to its children.
14521−
14522−A ship accepts all wills, new or updated, and stores them permanently.
14523−If this is abused trivially as a DoS vector, Urbit will mitigate it by
14524−the usual technique of degrading service to non-scarce ship tiers.
14525−Scarcity rules.
14526−
14527−### Level 0: passive propagation only
14528−
14529−The Ames protocol can piggyback a will on any packet. Each ship also
14530−permanently records which other ships hold which version of its own
14531−will. An update is automatically sent when needed.
14532−
14533−With level 0 propagation, all key exchanges in Ames are passive and
14534−invisible to the programmer. When the sender has no will or symmetric
14535−key for the receiver, the packet is signed, bundled with the will, and
14536−sent as cleartext.
14537−
14538−Signed cleartext? If you have no will for a peer, you've never talked
14539−to this ship before. Your first words to a stranger probably won't be
14540−super secret. If this isn't true, the programmer has to send an
14541−innocuous message first and wait for it to be acknowledged. Kicking a
14542−rare corner case up to the programmer is a classic worse-is-better
14543−move.
14544−
14545−With level 0 propagation only (the current implementation, because we
14546−don't even care about key updates yet), an updated does not
14547−effectively revoke the old key. If Alice updates to a new key,
14548−Mallory steals the old key, then Mallory talks to Bob before Alice
14549−does, Mallory can impersonate Alice.
14550−
14551−So not only does level 0 not solve double-sell, it's also quite
14552−insecure. But it's still fine for now (because Urbit isn't really
14553−decentralized yet).
14554−
14555−### Level 1: neighbor-only propagation with parent filtering
14556−
14557−The list of other ships which hold your will, essentially the list of
14558−all ships you've talked to, is your list of _neighbors_. You
14559−essentially have permanent, if perhaps very sporadic, conversations
14560−with all your cryptographic neighbors. Symmetric keys time out fast,
14561−but wills are held forever.
14562−
14563−By proactively pinging all your neighbors when you extend your will,
14564−you prevent anyone who finds the old private key (ideally you update
14565−when your old key is stale, not when it's actually been _stolen_) from
14566−jumping into these conversations.
14567−
14568−What about non-neighbors? We add a second feature: a parent will only
14569−forward a packet if its sender matches the current will. So updating
14570−your parent (who is always your neighbor) transforms it
14571−
14572−There are two cases: where Alice's parent Trent is also Bob's parent,
14573−and where Bob has a separate parent Walter. In the first case, the
14574−expected packet flow is that Alice will send the packet to Trent, who
14575−sends it to Bob. In the second case, Trent sends it to Walter, who
14576−sends it to Bob.
14577−
14578−In either flow, Bob or Walter is sure that the packet came through
14579−Trent. Since Trent is Alice's parent and hence Alice's neighbor, and
14580−hence is updated, Trent will forward no packets from Mallory. So
14581−Mallory has no way to reach Bob.
14582−
14583−Non-neighborly packets not matching this flow can't be accepted.
14584−Suppose Mallory gets Bob's public IP address directly? If Bob gets a
14585−non-forwarded packet marked "Alice," but Alice is not his neighbor,
14586−that's super weird. He must reject the packet.
14587−
14588−Level 1 is nice because it provides a reasonable level of security,
14589−but it's still extremely simple. Not only does it not use a
14590−blockchain, it doesn't even need a gossip flood!
14591−
14592−And level 1 propagation also does a competent worse-is-better job on
14593−the double-sell problem. Trent simply becomes the single source of
14594−truth. The buyer of Alice needs to check that Trent, her parent, has
14595−Alice's latest will from the buyer's perspective. If Alice's seller
14596−propagates a different fork to other ships, this damages Alice's
14597−ability to communicate, but produces no obvious gain for the seller.
14598−
14599−Level 1 puts a lot of security weight on the parent. If Trent
14600−misbehaves, for example by not filtering Mallory's packets, Alice can
14601−be impersonated. And its solution to the double-sell problem is
14602−adequate, but not ideal. Level 1 is the worse-is-better sweet spot
14603−for a young Urbit, but will probably give way to level 2.
14604−
14605−### Level 2: broadcast all wills
14606−
14607−We can't say definitively that level 1 will be inadequate. But
14608−intuitively, it feels slightly weak. We will probably need a gossip
14609−protocol.
14610−
14611−The only ships that can be transferred are galaxies, stars and
14612−planets; if all updates of all wills of all these major ships are
14613−broadcast, we hardly have a scaling problem like Bitcoin's. Even if
14614−changing the lock on your front door counted as a real-estate
14615−transaction, there are a lot fewer real-estate transactions than
14616−credit-card payments.
14617−
14618−Moreover, conflict detection (double-sell alerts) is a natural part of
14619−any gossip protocol. Gossip should be between stars, not directly
14620−between planets; horizontal gossip, vertical distribution.
14621−Star-to-planet distribution may still be limited.
14622−
14623−Especially since stars are somewhat trusted, ganking a gossip protocol
14624−with random update edges is incredibly hard and requires a pretty
14625−preposterous conspiracy. And flooding all planet wills does a lot to
14626−keep stars honest. It would be incredibly stupid for a star to try a
14627−double-sell attack against its own planets, but code is always more
14628−powerful than mere incentives.
14629−
14630−Finally, the exit model isn't fully baked yet, but it will probably
14631−have more aggressive propagation needs. What's clear is that an exit
14632−statement is another type of will entry, involving a signature both
14633−from the previous key and the new parent. You can only escape to
14634−another ship of your parent's class that agrees to adopt you.
14635−
14636−In general, because escaping need to work for routing (without the
14637−cooperation of the former parent), wills containing an exit statement
14638−(a planet moving to a new star, or a star moving to a new galaxy)
14639−exit) probably need to be flooded globally among all 8-bit galaxies
14640−and 16-bit stars. Exits should be rare, so they shouldn't present
14641−much of a scaling problem.
14642−
14643−### Level 3: full blockchain
14644−
14645−Obviously a blockchain can solve Urbit's problem. Probably the right
14646−thing to do would be to use the Bitcoin blockchain, and confirm the
14647−current Urbit key version with a "colored coin" of some kind. (This
14648−should not be confused with the orthogonal idea of representing Urbit
14649−_invitations_ as colored coins.)
14650−
14651−This involves making all Urbit ships into Bitcoin SPV nodes at the
14652−least. Not the worst fate in the world, but also a cost.
14653−Alternatively, Urbit could have its own "altcoin" blockchain, with
14654−actual Urbit-specific mining.
14655−
14656−Again, given that level 2 seems like it should work quite well, it's
14657−hard to see why level 3 propagation would be needed. But we can't
14658−really know at this point. There's a reason Urbit can update itself
14659−over the air. That's why we say: Urbit (probably) doesn't need a
14660−blockchain. If it does, we can retrofit it.
14661−
14662−## Retrospective note
14663−
14664−This essay has presented the Urbit cryptographic title as a low-power,
14665−stripped-down, worse-is-better variation of Nakamoto consensus.
14666−That's clearly the right way to introduce it in 2016.
14667−
14668−Actually, though, this part of Urbit was designed before the Bitcoin
14669−paper was published. There were other academic approaches to
14670−Byzantine consensus, but certainly none validated on a large scale as
14671−Nakamoto consensus has been. It never seemed appropriate to treat
14672−cryptographic titles to network addresses as a case of generalized
14673−Byzantine consensus, and without the existence of Bitcoin there was no
14674−temptation in this direction.
14675−
14676−In a sense the secret of PKIs is that PKIs are easy. What's hard is
14677−adapting an existing identity and authorization structure into a PKI.
14678−If you build the simplest possible PKI, then force the human processes
14679−to fit themselves to the protocol instead of vice versa, you have a
14680−much easier job. Similarly, if you are not adding PKI to an existing
14681−network, but building the network and the PKI as one system, many
14682−simplifications are possible. This is once again the classic
14683−worse-is-better method.
14684−]]></content:encoded>
14685− </item>
14686− <item>
14687− <title><![CDATA[Common Objections to Urbit]]></title>
14688− <link>https://urbit.org/blog/common-objections-to-urbit</link>
14689− <guid>https://urbit.org/blog/common-objections-to-urbit</guid>
14690− <pubDate>Mon, 27 Jun 2016 00:00:00 GMT</pubDate>
14691− <content:encoded><
14693−
14694−We love crowdsourced criticism. We've heard a lot of great
14695−objections to Urbit. Surely there's more out there! We'll
14696−revise this document to include anything new and interesting.
14697−
14698−Here's our list right now:
14699−
14700−- [Urbit is not ready for prime time.](#prime)
14701−- [Nock jets are a total hoax.](#jets)
14702−- [Urbit needs an infinitely extending packet/event log.](#log)
14703−- [Urbit is a total scamcoin. It's 100% premined.](#scam)
14704−- [Urbit isn't even really decentralized! It has a government!](#gov)
14705−- [Sandstorm/IPFS/Ethereum is way ahead of Urbit.](#sand)
14706−- [Urbit doesn't have enough planets for every human being.](#planet)
14707−- [Cloud computing is inherently non-private.](#pwned)
14708−- [Urbit will never be able to call any existing code.](#code)
14709−- [Hoon is too weird. No one will be able to program in it.](#program)
14710−- [Urbit programmers are stuck with Hoon.](#stuck)
14711−- [Ordinary users will never be able to manage an Urbit server.](#user)
14712−- [Urbit has no killer app.](#killer)
14713−- [Urbit is sniffed at by Houyhnhyms.](#horse)
14714−
14715−_"We choose to go to the moon, not because it is easy, but because it is hard."_
14716−— [John F. Kennedy](https://www.youtube.com/watch?v=g25G1M4EXrQ)
14717−
14718−## <a name="prime"></a>Urbit is not ready for prime time.
14719−
14720−_TLDR_: we agree.
14721−
14722−Urbit right now is a fun toy. It is fun to learn Hoon. It is
14723−even fun and quite practical to make actual contributions.
14724−(Hoon's IEEE floating-point was written by someone we've never
14725−met: `~nym`, formerly `~nodpet-rinned`.) In fact, we have never
14726−seen anyone _not_ have fun with Urbit.
14727−
14728−But there is all kinds of stuff wrong with the codebase. Urbit's
14729−documentation is much improved, but remains incredibly weak --
14730−Arvo is almost totally undocumented. Scaling is poor at best.
14731−Urbit's reliability is dubious. Its security is nil.
14732−
14733−Urbit is feature-frozen. The only thing we're working on now,
14734−and for the rest of 2016, is doc, debugging and and self-hosting.
14735−In that order of importance -- teaching Urbit is more important
14736−than fixing it, which is more important than making it useful.
14737−But we're quite confident that these are all solvable problems.
14738−
14739−The most important milestone about Urbit today is that it's ready
14740−for technical decisions to be made collectively. A system like
14741−Urbit can only be invented by a mad auteur. It can't be
14742−maintained or stabilized by a mad auteur. Our primary goal today
14743−is expanding the number of people who understand Urbit, and we
14744−expect these pioneers to participate in technical governance.
14745−
14746−## <a name="jets"></a>Nock jets are a total hoax.
14747−
14748−_TLDR_: all of computing is a hoax. You can't compare a hoax
14749−to nothing. You can only compare it to all the other hoaxes.
14750−
14751−A "jet" is a sort of software device driver in Urbit. Urbit is
14752−precisely defined in terms of an interpreter that fits on a
14753−T-shirt, Nock. But a naive implementation of Nock is nowhere
14754−near practical, because Nock has only one integer operation:
14755−increment. For example, to decrement a number in Nock, you
14756−increment a counter up to the number under it.
14757−
14758−The only way an efficient Nock interpreter can work is to
14759−recognize algorithms like decrement, and implement them
14760−non-naively. By far the easiest way to do this is not to analyze
14761−arbitrary code as it's being executed, but to register and match
14762−well-known implementations in the standard library. No one
14763−should be writing their own decrement.
14764−
14765−But the semantics of the interpreter, _so long as the jet and the
14766−jet harness are defined correctly_, are exactly those of Nock.
14767−We are not extending or changing Nock in any way. We are just
14768−taking a shortcut in certain cases we understand perfectly.
14769−
14770−It's not at all unprecedented to have implementations much more
14771−complex than the corresponding specification. The x86
14772−instruction set is relatively simple; the complexity of its
14773−decoding and execution path in a modern CPU is enormous. This
14774−path may well have "peephole optimizations" that replace matched
14775−algorithms, and if it doesn't the modern compiler does. People,
14776−_bad_ people, use "jets" to cheat on benchmarks all the time.
14777−
14778−Nock is designed as a standard. It's built like a standard.
14779−Typically what causes real problems in standards is ambiguity.
14780−Two implementations are incompatible, but each swears it has the
14781−right interpretation of the natural-language spec. This simply
14782−cannot happen in the Nock world. If two implementations
14783−disagree, at least one of them is incorrect. This puts us firmly
14784−in "with enough eyeballs, all bugs are shallow" territory.
14785−
14786−The fact remains, however, that a Nock interpreter without jets
14787−is completely useless. And there is not even an informal
14788−document that tells you what jets you need for a reasonably
14789−efficient Urbit. (There should be such a document.)
14790−
14791−The correct way to think about jets is not to compare them to a
14792−perfect interpreter created by unicorns. Jets are a combined
14793−replacement for two other techniques in language implementation:
14794−intrinsics and a foreign-function interface.
14795−
14796−Compared to both intrinsics and an FFI, your jets have one key
14797−disadvantage: they need to be specified in pure code. You may
14798−not have this executable specification, which means you need to
14799−write it. Is this really so bad for your development process?
14800−An executable specification? Which can be trivially tested
14801−against the efficient implementation?
14802−
14803−Compared to intrinsics, jets give you true separation between
14804−mechanism and policy; only the interpreter, not the programmer
14805−and not the compiler, needs to know what's accelerated.
14806−
14807−Compared to an FFI, jets preclude I/O, so can be trivially
14808−sandboxed. Except that the programmer needs to mark routines
14809−which may benefit from optimization with a hint, here too we
14810−separate mechanism (efficient implementation) from policy.
14811−
14812−Yes, formal verification of jet equivalence is desirable.
14813−However, in the real world, many specifications, including quite
14814−complex ones, are tested into equivalence by brute force.
14815−
14816−Urbit has some jet abuses. The equivalence between our markdown
14817−parser in Hoon and the CommonMark C library is super dubious. It
14818−should be revisited.
14819−
14820−But the miscomputation resulting from a minor jet discrepancy is
14821−not a security hole or even fatal. It effectively means the
14822−event history, computed correctly, does not match the current
14823−state. The way to resolve this conflict is for the current state
14824−to win, and the event history to be discarded -- not abnormal
14825−anyway. See the next question.
14826−
14827−## <a name="log"></a>Urbit needs an infinitely extending packet/event.
14828−
14829−_TLDR_: no, it doesn't. Urbit can prune the log.
14830−
14831−We can prune the event log because the Urbit transition function
14832−doesn't have any access to the event history -- just the current
14833−state and the current event.
14834−
14835−Urbit defines the semantics of a complete event log. It doesn't
14836−and can't require an implementation to maintain the whole log.
14837−It can maintain a checkpoint and the log since that checkpoint.
14838−
14839−However, any practical urbit maintains a periodically updated
14840−checkpoint. Our present implementation doesn't provide a way to
14841−prune the event log. But that's just a missing feature. We have
14842−one or two of those!
14843−
14844−## <a name="scam"></a>Urbit is a total scamcoin. It's 100% premined.
14845−
14846−_TLDR_: yeah. But at least it's not the DAO.
14847−
14848−Like a cryptocurrency, Urbit is a digital title. But Urbit is
14849−digital land, not digital money. If you assess it as a currency,
14850−it's a lousy currency. If you assess a cat as a dog, it's a
14851−lousy dog.
14852−
14853−In real-world economics, the crucial distinction between land and
14854−money is that land (a) has intrinsic utility and (b) is
14855−non-fungible.
14856−
14857−Because of (b) alone, frictionless transactions in land are
14858−impossible. A blockchain is only needed to ensure zero-cost
14859−high-frequency transactions. So digital land doesn't need a
14860−blockchain. Which means it doesn't need mining.
14861−
14862−Of course, just because a digital title system doesn't need
14863−mining, doesn't mean it can't distribute an initial allocation by
14864−proof-of-work -- or by any other arbitrary method which is
14865−careful not to benefit the system's own developers. Could we
14866−give away the Urbit address space randomly? Sure. But why?
14867−
14868−Probably the purest design is the "proof-of-burn" initial
14869−allocation used by some coins. By any standard, proof-of-burn is
14870−technically beautiful and results in an extraordinary level of
14871−ethical independence. We can't help but admire it.
14872−
14873−But any altcoin or metacoin is just way less work than Urbit. An
14874−altcoin can afford to burn even its creation energy, capturing no
14875−value at all from its seigniorage. Your altcoin doesn't have a
14876−clean-slate system software stack to drive. If your rocket has
14877−to go to the moon, it's going to leave a little bit of smoke in
14878−the air.
14879−
14880−Ethically, what makes "premining" feel wrong is that the creators
14881−of the currency are rewarded disproportionately for their effort.
14882−The scamcoin is a get-rich-quick scheme, vaguely pyramid-shaped.
14883−Nothing about Urbit matches this pattern at all.
14884−
14885−Curtis invented Urbit. So by the [homestead
14886−principle](https://en.wikipedia.org/wiki/Homestead_principle), he
14887−started out owning all of it. But by now, Urbit's 8-bit galaxies
14888−have already been distributed among [57 separate individuals](https://github.com/urbit/arvo/blob/master/sys/vane/ames.hoon#L118-L373).
14889−Curtis owns 20, or about 8%.
14890−
14891−Tlon, the corporation which still runs Urbit development, has 95.
14892−(Without Tlon, there is basically no Arvo.) 50 are reserved for
14893−a hypothetical Urbit Foundation. Tlon employees have another 16.
14894−
14895−The rest of the galaxies belong to donors, investors,
14896−contributors, contest winners, and just random people who were in
14897−the right place at the right time. One is a Silicon Valley
14898−tycoon. Another is an Orthodox nun in a monastery in Greece. A
14899−couple are ex-Tlon employees who might totally hate us. There is
14900−nothing they all have in common, which is sort of the point.
14901−
14902−This property distribution looks a lot like land ownership in the
14903−real world -- complex and asymmetrical. That's no accident. If
14904−you have a problem living in New York because New York's real
14905−estate is not distributed equally among its residents, you may
14906−have a similar problem with Urbit. The reality is that Urbit,
14907−like New York, wasn't born yesterday and comes with a complex
14908−ownership history which we couldn't possibly change, even if we
14909−wanted to.
14910−
14911−Decentralization is hard. The only real goal of a property
14912−system in address space is to create and maintain
14913−decentralization. The whole network has to exhibit centrifugal
14914−force, not centripetal force. Proof-of-work systems certainly
14915−seem to have unexpected centripetal qualities, producing
14916−unanticipated concentrations of centralized hashpower. See the
14917−next objection.
14918−
14919−## <a name="gov"></a>Urbit isn't even really decentralized! It has a government!
14920−
14921−_TLDR_: it's technically impossible for Urbit to be
14922−decentralized at this stage of its life. Urbit is designed to
14923−achieve decentralization, not be born with it.
14924−
14925−A young network can't afford to be decentralized. It has to act
14926−as a unit. Because it has no network effect, it needs every
14927−scrap of efficiency it can get.
14928−
14929−A decentralized general-purpose computing network like Urbit can
14930−_only_ be bootstrapped by a central government. For example, by
14931−default your urbit upgrades its OS automatically (like an
14932−"evergreen" browser) with signed network updates. Whoever signs
14933−these updates is a government by definition.
14934−
14935−When it's impossible to eliminate centralized power, it becomes
14936−necessary to tame, stabilize, and limit it. This should not be
14937−surprising to anyone living under a constitutional government.
14938−
14939−As we found out with the DAO, if a network isn't ready to be
14940−decentralized, its developers shouldn't even try. If Ethereum is
14941−hard-forked to roll back the DAO (which looks like the most
14942−probable result), it acknowledges that it both has a central
14943−government, and needs a central government. Decentralization is
14944−good. Pretend decentralization -- "decentralization theater" --
14945−is harmful, and not a effective path to actual decentralization.
14946−
14947−A key test of a free software project's health is whether it can
14948−fork. So long as the unity of the public-key hierarchy and the
14949−network protocol is maintained, the Arvo kernel and Urbit system
14950−can fork in all kinds of ways without disrupting the network.
14951−Any stress will fragment the "government" that develops the
14952−kernel, and as it fragments it grows more limited and stable.
14953−
14954−Urbit is designed to govern itself collectively by address space
14955−ownership -- effectively, "proof of stake." Any arbitrary power,
14956−will tend to fracture along these property lines. For instance,
14957−our hot updates are sent through the galaxy hierarchy; in a
14958−development fork, active galaxies would pick upstream sources.
14959−Two implementations of a standard are better than one.
14960−
14961−And by fragmenting the galaxy space into 57 separate partitions,
14962−we've created a global property map which is much more likely to
14963−splinter further, than reunite.
14964−
14965−In the long run, every galaxy should have a separate owner, who
14966−is a human being rather than a corporation. Combining galaxy
14967−holdings will damage the reputation of both galaxies. The only
14968−reason to merge ownership is to move toward incipient monopoly.
14969−Whether a galaxy admits this openly or denies it dishonestly, its
14970−reputation will suffer.
14971−
14972−The technical goal of Urbit is to create a network which, _if it
14973−actually takes over the world_, inevitably becomes decentralized.
14974−Even if Urbit takes over the world, no individual or coherent
14975−organization takes over the world. There is nothing even close
14976−to a single point of failure in a mature, successful Urbit.
14977−
14978−This is the goal of all the new "web3" decentralized systems. If
14979−IPFS, Sandstorm or Ethereum takes over the world, nobody takes
14980−over the world. (The same is almost true of the Internet --
14981−though it wouldn't be that surprising if a time traveler from
14982−2116 revealed that ICANN had become a planetary government.)
14983−
14984−Urbit, by starting out as a centralized network, just reduces the
14985−technical problem to match the actual goal. Only long-term
14986−decentralization matters.
14987−
14988−It's very important that Urbit in 2116 be fully decentralized.
14989−For Urbit in 2016, pretending to be decentralized would be a joke
14990−at best, and a hoax at worst. And of course, no one can DAO us
14991−-- since the property system is still just a central registry.
14992−Among other things, we check it into GitHub. GitHub is not a
14993−blockchain -- but still, good luck with that.
14994−
14995−## <a name="sand"></a>Sandstorm/IPFS/Ethereum is way ahead of Urbit.
14996−
14997−In general, web3 (next distributed web) solutions don't compete
14998−with each other. They support each other. Concretely, they are
14999−all part of each others' network effect.
15000−
15001−IPFS, Sandstorm, Ethereum, and Urbit can all take over the world
15002−at the same time. None of them competes with the others. They
15003−enable each other.
15004−
15005−For instance, IPFS and Urbit are both global immutable
15006−namespaces. IPFS is a chord-routed, content-addressed namespace.
15007−Urbit is a direct-routed, identity-addressed namespace. Urbit is
15008−a typed revision-control system; IPFS is a blob store. IPFS
15009−isn't a computer; the work hasn't been done, but Urbit can easily
15010−mount the IPFS namespace and compute functionally against it.
15011−
15012−So the better IPFS does, the less Urbit needs to struggle against
15013−its lack of network effect. The better Urbit does, the easier it
15014−is for IPFS to point to a functional language that can actually
15015−use its referential transparency directly. So their relationship
15016−is symbiotic, not competitive at all.
15017−
15018−The closest thing to a general-purpose competitor that Urbit has
15019−is Sandstorm. Sandstorm, which by the way rocks, is also a
15020−personal server built around a network protocol.
15021−
15022−But Sandstorm and Urbit compete in the way that, on the PC, the
15023−OS and the browser compete. In theory, the OS could solve the
15024−problems that the browser solves; or the browser could be the OS.
15025−In practice, Windows is a great OS to run a browser on.
15026−
15027−Similarly, a world in which Sandstorm takes off is an awesome
15028−world for Urbit, because everyone who has a Sandstorm instance
15029−has a great platform for running Urbit on. Urbit on Sandstorm
15030−will be a sort of "double-hulled" personal server, safer and more
15031−friendly than either system alone.
15032−
15033−Sandstorm and Urbit have very different approaches to network
15034−identification; Sandstorm uses capabilities, Urbit identity.
15035−Broadly speaking, we believe, capabilities are optimal for
15036−expressive power; but identity is optimal for the UI of the
15037−common case. We'd need to see the Powerbox, Sandstorm's UI, more
15038−fully fleshed out to understand its UI approach better.
15039−
15040−## <a name="planet"></a>Urbit doesn't have enough planets for every human
15041−
15042−A 32-bit planet is a tool, not a toy. Like a car, it's a device
15043−for a responsible and independent adult. There aren't 4 billion
15044−cars in the world, nor 4 billion independent adults.
15045−
15046−If you aren't an independent adult, and you don't need or even
15047−shouldn't have unconditional digital freedom (no one's 8-year-old
15048−daughter needs unconditional digital freedom), a moon from
15049−someone else's planet is fine. (Even most of today's independent
15050−adults don't complain enough about being Facebook's moons.)
15051−
15052−And limiting the supply of anything doesn't create a shortage.
15053−It sets a price. Ideally, in the long run, we think a planet
15054−should cost about $10. This could be off by an order of
15055−magnitude either way, and it wouldn't be the end of the world.
15056−
15057−If a planet costs $10, that means you paid $10 to get a planet.
15058−A planet with no reputation has a positive reputation, because
15059−someone paid $10 for it and hasn't yet done anything wrong.
15060−Positive default reputation is the single quality that makes a
15061−social network social.
15062−
15063−There is always a tradeoff between free speech and free beer.
15064−Urbit will always choose free speech.
15065−
15066−## <a name="pwned"></a>Cloud computing is inherently non-private.
15067−
15068−_TLDR_: a general-purpose cloud computer is much, much more
15069−private than a special-purpose cloud computer. In general, a
15070−cloud VM is secure against corporations but not governments.
15071−With a global adversary, compute in your closet -- or even on
15072−your body.
15073−
15074−One reason we want the decentralized Internet is that we're tired
15075−of giant corporations spying on us. Think about it this way:
15076−Amazon is Netflix's main competitor. And yet, Netflix runs its
15077−whole operation on AWS. Why is Netflix sure that Amazon won't
15078−spy on it?
15079−
15080−A general-purpose virtual machine is special from a privacy
15081−standpoint, just because it's commercially realistic to design
15082−terms of service that prevent the host from peeking and poking at
15083−the customer's machine. Crossing this moat is technically
15084−nontrivial and can't possibly happen by any reasonable accident.
15085−No hosting contract could contemplate it.
15086−
15087−Whereas when your cloud computer is a special-purpose machine --
15088−just a database row on some corporation's mainframe -- there is
15089−no way these services can promise not to handle your data.
15090−Handling your data is _what they do_. On a special-purpose
15091−server, the concept of privacy is not even defined.
15092−
15093−Where even a general-purpose server falls down is where the user
15094−has a sovereign adversary, which can secretly violate explicit or
15095−implicit hosting contracts. Users with a sovereign adversary
15096−must rely only on their own physical security.
15097−
15098−However, most users don't have a sovereign adversary. And those
15099−who do maximize their "herd immunity" if they can use the same
15100−protocols as those who don't. Otherwise, the adversary could
15101−simply focus on everyone who uses the secure protocols.
15102−
15103−Also, the portability of a cloud server image is critical. Of
15104−course, since Urbit is formally specified, it's trivially
15105−portable. In fact, one strategy against sovereign adversaries
15106−may be continuous rotation between hosts, like an MX missile.
15107−
15108−## <a name="code"></a>Urbit will never be able to call any existing code.
15109−
15110−_TLDR_: neither will Javascript. And dear Unix, the browser
15111−does not miss interacting with your `$LD_LIBRARY_PATH` at all.
15112−
15113−You can't talk to the OS or use system libraries from Javascript.
15114−Therefore, there is no point in having any kind of gateway,
15115−compatibility bridge, native methods, or other interface between
15116−Javascript and C.
15117−
15118−When in doubt, remember that Urbit is "the browser for the server
15119−side." It plays by the same general rules. Isolation means
15120−isolation.
15121−
15122−## <a name="weird"></a>There's no way Urbit will ever be adopted. It's too weird.
15123−
15124−_TLDR_: Urbit adoption is designed to be driven by ordinary end
15125−users. Urbit isn't ready for ordinary end users yet. We're
15126−working on it -- come help.
15127−
15128−Right now, Urbit is a developer tool. Or rather, a developer toy
15129−-- since the only thing it's useful for is developing Urbit. It
15130−also could be a much better toy. We're working on that too.
15131−
15132−But it's absolutely wrong to think of Urbit being adopted as a
15133−developer tool in the conventional sense. If you think this is
15134−almost impossible, you're right.
15135−
15136−If we look at the way most successful platforms are adopted,
15137−they're not adopted for their own virtues. They're adopted
15138−because they're part of a larger solution. It's very hard to
15139−displace a native component of an existing platform. Urbit is
15140−not trying to do this.
15141−
15142−C is a better language than Pascal, but it didn't beat Pascal
15143−because it's a better language. C beat Pascal because C was the
15144−native language of Unix, and people wanted to program in Unix.
15145−People don't use Javascript because Javascript is a great
15146−language, but because it's the native language of the browser.
15147−Replacing the native language of a platform may be doable -- but
15148−it's incredibly hard.
15149−
15150−Hoon is not competing with C, or even Haskell, as a Unix
15151−programming language. The only reason to program in Hoon is that
15152−it's the native language of Urbit. Urbit is not competing with
15153−node.js or Rails as a Web backend. The only reason to run Urbit
15154−is to run a personal server.
15155−
15156−Nock is cool, but it only gets adopted if Hoon gets adopted.
15157−Hoon is cool, but it only gets adopted if Urbit gets adopted.
15158−Urbit only gets adopted if it's useful as a personal server for
15159−human beings -- most of whom won't be Hoon programmers, or
15160−programmers at all.
15161−
15162−## <a name="program"></a>Hoon is too weird. No one will be able to program in it.
15163−
15164−_TLDR_: Hoon is ridiculously simple. Our documentation and
15165−tooling are just immature.
15166−
15167−It's pretty fair to assume that (a) functional programming is
15168−hard and weird, (b) Hoon is weird even for a functional language,
15169−so (c) Hoon must be hard-squared.
15170−
15171−Actually, Hoon is weird even for a functional language because
15172−it's an attempt to remove the hardest things about functional
15173−programming: category theory, lazy evaluation, and gratuitous
15174−abstraction. To know a language is to know what the compiler is
15175−doing; all the semantics of the Hoon compiler fit in 2000 lines
15176−of code.
15177−
15178−It's too easy for us to wind up living in Isaac Asimov's Trantor,
15179−a world in which everything got invented thousands of years ago
15180−and the idea of new technology is just weird and scary. History
15181−isn't over yet, and nor is technical history.
15182−
15183−New things are harder to learn than old things. We ask smart
15184−high-school students to learn calculus. Think about how much
15185−harder it was for Newton and Leibniz to invent calculus, or for
15186−their first students to pick it up. Hoon is nowhere near as hard
15187−as calculus.
15188−
15189−Most of the difference is just the collective certainty that our
15190−society conveys to a high-school student that calculus is
15191−learnable. When you're learning Urbit, you don't have this
15192−collective knowledge; so you don't have the confidence that the
15193−problem is solvable. Confidence makes a huge difference.
15194−Moreover, any bug or glitch in the developer experience destroys
15195−this confidence and takes a long time to heal.
15196−
15197−Yes, we know: Hoon remains quite hard to learn. Again, we have
15198−no reason to think this problem isn't solvable. Public
15199−enlightenment remains our main priority.
15200−
15201−## <a name="stuck"></a>Urbit programmers are stuck with Hoon.
15202−
15203−_TLDR_: patience, grasshopper.
15204−
15205−There's quite a straightforward way to implement any perfectly
15206−specified language with a reliable interpreter in Hoon. First,
15207−write an interpreter for that language in Hoon. Second, jet that intepreter function with the existing implementation.
15208−
15209−It is not clear that Javascript is _quite_ well-defined enough
15210−for this treatment. But Lua probably is.
15211−
15212−## <a name="user"></a>Ordinary users will never be able to manage an Urbit server.
15213−
15214−_TLDR_: Urbit's technical simplicity has always been designed
15215−to drive human usability. But the polish is the last thing that
15216−goes on. So we can't evaluate this claim right now.
15217−
15218−Right now, Urbit is only for geeks. You already need to be able
15219−to wrangle a Unix machine to run it. What's the point?
15220−
15221−This Urbit isn't the real Urbit. It's an early milestone on the
15222−way to the real Urbit.
15223−
15224−The real Urbit -- for normal human beings -- is a hosted service.
15225−Getting a planet is as easy as signing up for Facebook. Probably
15226−many users will think of it as another web account. They might
15227−not even know it can run more apps than the ones they use.
15228−
15229−A deterministic, persistent cloud computer is something different
15230−from a traditional server. Normally when we think of a server in
15231−the cloud, we think of it like a live animal -- a creature that
15232−needs to be cared for, fed, and herded. A file in the cloud is
15233−more like a rock -- you can forget about it for ten years.
15234−
15235−An urbit is a general-purpose computer, but it doesn't even have
15236−the concept of a reboot. It upgrades itself. If you don't feed
15237−it any packets for ten years, then turn it back on, it will spend
15238−a day or two upgrading itself, then be back to normal. Maybe
15239−it's something in between a rock and an animal -- a cactus?
15240−
15241−Another huge difference versus an Internet server is that we're
15242−confident that Urbit's limited supply of identities will make it
15243−easy to keep abusers off the network. So far, so good -- but of
15244−course, no one abuses a young network.
15245−
15246−The bottom line is that managing your urbit has to be as easy as
15247−managing your iPhone. Normally, it consists of deciding what
15248−apps you want to be running, and how much you trust them.
15249−Resources can't be free, so sometimes you have to play memory
15250−police. Humans have shown that they can handle these tasks.
15251−
15252−Our '70s OSes and networks, which were great designs in their day
15253−and have matured into excellent industrial tools, give us a
15254−totally misleading impression of how hard it should be to manage
15255−a general-purpose computer. Computing isn't scary or dangerous.
15256−Unix and the Internet are scary and dangerous. That's fine for
15257−an industrial tool, but not a personal tool.
15258−
15259−## <a name="killer"></a>Urbit has no killer app.
15260−
15261−_TLDR_: the killer app is personal API aggregation.
15262−
15263−It's a truism that any new platform has to be fundamentally much
15264−better at solving some problem than the mature platform it seeks
15265−to replace.
15266−
15267−We can look at Urbit's killer app from two perspectives: as a
15268−developer, and as a user.
15269−
15270−From the developer's perspective, Urbit's advantage is that it's
15271−a network stack which provides exactly-once delivery of typed,
15272−validated, transactional, encrypted and authenticated messages.
15273−The difference between an Urbit API and a REST API is like the
15274−difference between a paved road and a dirt road. On the other
15275−hand, you do need to learn a new functional language.
15276−
15277−From the user's perspective, there's one task that any personal
15278−server can perform, that can't be performed by any Web service:
15279−unrestricted API aggregation.
15280−
15281−Well before Urbit is ready to _replace_ any conventional web
15282−services, it should be ready to _command_ them in place by API.
15283−(Or if needed, by scraping.) If all you care about is being in
15284−control of your own data, it's fine to leave it in the hands of
15285−these services, as you have the API secrets to get it out.
15286−
15287−Managing a set of security connections to your existing services
15288−is one of the first important tasks of a modern personal server.
15289−This is a stateful task that typically requires both a durable
15290−API key and a temporary OAuth token. APIs change all the time,
15291−so connection maintenance also requires evergreen updates.
15292−
15293−The origin of this API key will vary, but usually the best way to
15294−set it is BYOK: the user registers their own urbit as an "app."
15295−And the neat thing about having your own API keys, for multiple
15296−services, on a single general-purpose computer, is that none of
15297−these services really has any practical way to control what you
15298−do with your own data.
15299−
15300−Terms of service which constrain the use of data (as opposed to
15301−the abuse of the service) simply aren't realistic and will no
15302−longer apply. This enables a variety of novel user experiences
15303−which aren't implementable as traditional web services, and also
15304−aren't available via conventional third-party API aggregators.
15305−
15306−Also, since Urbit is after all quite immature, it doesn't make
15307−much sense to restrict this security state to code within Urbit.
15308−The Urbit interpreter `vere` runs as a Unix daemon that
15309−implements the FUSE user-level filesystem protocol, and maps the
15310−data on your services into the Unix filesystem. For example, one
15311−of our demos lets you `ls` your GitHub issues.
15312−
15313−So it's straightforward to build, for instance, a Python app that
15314−uses Urbit as a gateway to mash up a bunch of web services. As a
15315−Unix programmer, you might even just regard Urbit as a generic
15316−Web API gateway daemon, without worrying about its internals.
15317−
15318−We have other ideas for initial killer apps. But this, we feel,
15319−is the best one. API libraries for `npm` et al abound.
15320−Stateful, self-updating, generic API aggregators with FUSE
15321−integration, also integrated with a reactive web server, are
15322−rarer.
15323−
15324−## <a name="horse"></a> Urbit is sniffed at by Houyhnhyms.
15325−
15326−It's difficult to categorize [this awesome
15327−essay](http://ngnghm.github.io/blog/2016/06/11/chapter-10-houyhnhnms-vs-martians/)
15328−in a single bullet point. So I've saved it for last.
15329−
15330−When reading this essay, it's important not to forget the amazing
15331−absence of genuine, mutually critical discourse in computer
15332−science (as in most sciences today). You never hear what Swift's
15333−designers think of Go, or vice versa. And critical public
15334−discourse decreases, not increases, with increasing academic
15335−legitimacy.
15336−
15337−The basic test of any field purportedly scientific in nature is
15338−whether its researchers are genuinely interested in each others'
15339−work, and willing to share these genuine responses publicly. If
15340−this practice does not exist, the field may still be useful
15341−and/or interesting. But it is not science.
15342−
15343−What's awesome about Fare's essay is that he's _doing it right_.
15344−All the actual details are irrelevant. And mostly wrong. But
15345−that's of very little importance compared to _doing it right_.
15346−
15347−Anyway, we've already addressed the idea that jets are a sham.
15348−Some other points:
15349−
15350−### Event-sourcing and/or caching is a pattern, not a layer
15351−
15352−Fare' is perfectly right that "one size does not fit all" in
15353−persistence. Generally, Urbit uses event-sourced persistence.
15354−
15355−But it has multiple layers of event-sourcing: in the definition
15356−of Urbit itself; in the application sandbox vane (Gall), and in
15357−the application itself. Urbit also has a completely orthogonal
15358−revision control system (Clay).
15359−
15360−And there is not a single cache across the whole system, though
15361−arguably there should be; for instance, the functional build
15362−system (Ford, which Fare' the master of build systems might
15363−appreciate) has its own internal cache.
15364−
15365−It is a common mistake to confuse a design pattern with a layer
15366−or feature, and equally fatal whichever direction you fail.
15367−
15368−### Let's be clear about why DSLs suck
15369−
15370−DSLs suck not because they are difficult to newbies in the base
15371−language. DSLs suck because every time a programmer, even one
15372−_experienced_ in the base language, comes into a new codebase or
15373−project, she has to learn a new custom language.
15374−
15375−You need enormous wins to justify this cost. It's the goal of
15376−the base language designer to preempt these wins, creating a
15377−language which is almost never so tiresome and full of
15378−boilerplate that it requires a DSL or template layer.
15379−
15380−Hoon is almost entirely made of macros -- but they are internal,
15381−fixed, built-in macros (with no gensyms). This fixed set of
15382−macros is essentially enough. Occasionally we want to add one or
15383−two. But we never, ever pine for context-dependent macros.
15384−
15385−### Determinism is not consensus, and is not constraining
15386−
15387−Fare' is totally right that an urbit's data is meant for itself
15388−alone. In fact, an urbit has the right to compute incorrectly if
15389−it wants. We go to considerable lengths to ensure that you can't
15390−gain any particular advantage by incorrect computing.
15391−
15392−The whole point of Nock is that it's so low-level that there is
15393−no conceivable advantage in upgrading it. Divergence is just
15394−pointless. This is not a question of network integrity, just of
15395−practical standardization.
15396−
15397−This consistency stops at Nock. Without anyone violating the
15398−correctness of their lifecycle functions, anyone or everyone in
15399−Urbit could replace Hoon with Javascript. Determinism does not
15400−cramp Urbit's semantic style in any way, shape or form.
15401−]]></content:encoded>
15402− </item>
15403− <item>
15404− <title><![CDATA[The DAO as a Lesson in Decentralized Governance]]></title>
15405− <link>https://urbit.org/blog/the-dao-as-a-lesson-in-decentralized-governance</link>
15406− <guid>https://urbit.org/blog/the-dao-as-a-lesson-in-decentralized-governance</guid>
15407− <pubDate>Thu, 23 Jun 2016 00:00:00 GMT</pubDate>
15408− <content:encoded><.
15419−
15420−_Decentralization theater_ means any system that produces not
15421−decentralization, but the appearance of decentralization.
15422−[Security
15423−theater](https://en.wikipedia.org/wiki/Security_theater) is the enemy of real security; decentralization
15424−theater is the enemy of real decentralization.
15425−
15426−A network without decentralization theater is one that admits:
15427−
15428−- any network is a digital state with a central government.
15429−- any new state is born at war with full emergency powers.
15430−- limiting and/or eliminating governance is a slow, hard task.
15431−
15432−TLDR: true decentralization isn't just a technical problem. It's
15433−also a political problem, and not an easy one. Believing you've
15434−solved it, before actually solving it, is not a way to solve it.
15435−
15436−## Decentralization and legitimacy
15437−
15438−Steve Randy Waldman is not alone in pointing out that [a
15439−blockchain is a
15440−parliament](http://www.interfluidity.com/v2/6581.html). It's
15441−just the technical reality that a majority of miners in a
15442−proof-of-work blockchain, or stakeholders under proof of stake,
15443−have the mathematical power to govern the network absolutely.
15444−
15445−But this power does not give them the legitimate authority to do
15446−whatever they want. Mathematically, the Ethereum miners can
15447−easily roll back the DAO. Do they have the _right_ to roll back
15448−the DAO? As we write, this question is one much debated.
15449−
15450−We have an easy answer: no. The most basic principle of law is
15451−that _pacta sunt servanda_, agreements must be respected. A good
15452−clue is that before the DAO hack, everyone swore great oaths to
15453−"the steadfast iron will of immutable code." Methinks the lady
15454−did protest too much. But these oaths make rolling back the DAO
15455−blatantly illegitimate.
15456−
15457−From a governance perspective, the line of lawlessness isn't the
15458−line between soft and hard forks. It's any fork which makes an
15459−exception for a specific address. Ethereum has already done this
15460−by freezing the DAO contract. At this point, it might as well be
15461−hanged for an ox, and go through with the full rollback.
15462−
15463−## Illegitimacy and belligerency
15464−
15465−Within the ethos of Ethereum (we are obviously not qualified to
15466−comment on "real" law), a rollback is a _lawless act_. This does
15467−not make it a wrongful act. It simply cannot be judged as an act
15468−of law. Rather, it is an act of war.
15469−
15470−And judged as an act of war, a DAO rollback is _exactly right_.
15471−Ethereum is not dealing with a "participant." It is dealing with
15472−a pirate, a thief, _hostis humani generis_.
15473−
15474−As a state at war with an external enemy, the Ethereum network
15475−shouldn't just zero the DAO hacker's booty. It must do all it
15476−can to destroy her. If possible, it must dox and report her.
15477−The right place for this fool is the supermax, not the Riviera.
15478−
15479−But does Ethereum really want to be at war? And if Ethereum is
15480−at war -- and this certainly isn't the only pirate in the sea --
15481−how does it become decentralized? If Ethereum is at war, where
15482−there is no law, how can it achieve its goal of creating a world
15483−where code is law?
15484−
15485−But we really shouldn't panic. It is actually possible to go
15486−from wartime government to peacetime government, from absolute
15487−martial law to absolute rule of law. It is just nontrivial.
15488−It's a political engineering problem that can't be ignored.
15489−If it has to be solved, it should be solved properly.
15490−
15491−What really doesn't work is to declare martial law, execute all
15492−traitors, terrorists and enemies of the state, then declare that
15493−elections will proceed as scheduled next week. If the goal is
15494−the decentralized rule of code as law, a rollback takes an
15495−enormous step backward. Reversing this setback isn't trivial.
15496−
15497−Should Ethereum actually go to war? Or should it just let the
15498−hacker win? Clearly, from a pure blockchain perspective, the
15499−only correct thing to do is let the DAO burn -- as a painful
15500−warning to all future contract authors and participants.
15501−
15502−At present, it seems that Ethereum's leadership has chosen war.
15503−Certainly, neither choice is obviously imprudent. Ethereum is a
15504−winner and probably has a bright future either way. But who
15505−chooses war needs a plan to win that war, and return to peace.
15506−
15507−## Sovereignty is conserved
15508−
15509−For a government to even have the power to consider wartime
15510−measures, a government has to exist in the first place.
15511−
15512−Again, we can't remind ourselves too often that a blockchain just
15513−puts absolute authority in the hands of the miners. We just
15514−think of this power in terms of the law it's supposed to enforce.
15515−But the two are different -- at least in wartime.
15516−
15517−Why is it so hard to eliminate unaccountable power? Who watches
15518−the watchmen? The German legal scholar [Carl
15519−Schmitt](https://en.wikipedia.org/wiki/Carl_Schmitt) defined the
15520−problem well when he wrote: "the sovereign is who decides the
15521−exception."
15522−
15523−In the American regime, the Supreme Court is sovereign by
15524−Schmitt's definition. We have a complex system of laws, which
15525−are not formal code but in some ways aspire to be; above it, we
15526−have a judiciary system that can decide arbitrary exceptions to
15527−those laws. Pure rule of law, Schmitt tells us, is always and
15528−everywhere an illusion. We can and should strive to approach
15529−this limit, but it's an infinity that we can't actually reach.
15530−
15531−Schmitt's exception principle can be rephrased as "sovereignty is
15532−conserved." There is always someone who answers to nobody. We
15533−cannot eliminate government; the best we can do is tame it.
15534−
15535−One way to think of the problem of reducing exceptional force to
15536−zero is to compare it to a simple unstable equilibrium, like a
15537−pencil standing on its point. The pencil on its point needs
15538−almost no force to stay upright. But the farther it deviates
15539−from this orderly, self-sustaining equilibrium, the more energy
15540−must be applied to return it to vertical.
15541−
15542−Vitalik seems to have grasped more or less Schmitt's point:
15543−"_Intent is fundamentally complex_... we believe that we value
15544−things like 'fairness', but it's hard to define what fairness
15545−even means."
15546−
15547−If we could define fairness, we would have a rule to which there
15548−were no exceptions. We would need no judges, or governments, or
15549−even soldiers. We would need no sovereignty. But since we can't
15550−define fairness -- yet need to enforce some clear vision of
15551−fairness -- sovereignty remains conserved.
15552−
15553−## Bitcoin, a blockchain at peace
15554−
15555−Bitcoin has done an excellent job of freezing the war power of
15556−its own "parliament." Ironically, mining power in Bitcoin is
15557−quite centralized -- a small number of Chinese mining-pool
15558−managers, who have every opportunity to collude, could roll back
15559−anything. But they never have and they probably never will.
15560−
15561−Even if a single pool controlled 51% of Bitcoin mining power,
15562−they'd have no incentive to break the rules -- quite the
15563−converse. We equate physical decentralization with limited
15564−governance, perhaps because we think of the physical difficulty
15565−of coordination as the main protection against arbitrary power.
15566−
15567−Bitcoin shows that this isn't true. As far as we can tell,
15568−Bitcoin would keep working fine if there was only one miner.
15569−This uni-miner would have still have no incentive to corrupt the
15570−network -- though another party, such as a real government, might
15571−have an incentive to coerce the miner.
15572−
15573−The important success of Bitcoin is the collective acceptance --
15574−mathematically false, but politically true -- that rollbacks in
15575−Bitcoin are inconceivable. Bitcoin has governance problems, but
15576−they're confined to relatively unimportant questions, like the
15577−blocksize debate. "Decentralization" may not be quite the word,
15578−but somehow Bitcoin has achieved limited government. The pencil
15579−is standing on its point. For now.
15580−
15581−## Ethereum's dilemma
15582−
15583−A rollback creates a scary precedent. It's a sort of military
15584−coup. Just as the miners have the power to rule any blockchain,
15585−the military has the power to rule any country. Do they want it?
15586−The first coup makes the next coup much easier. Same with the
15587−first rollback.
15588−
15589−In retrospect, the great mistake here was that Ethereum didn't
15590−know it needed a government, and did its best to pretend it
15591−didn't have one. After a rollback, Ethereum doesn't just have a
15592−government. It has a military dictatorship.
15593−
15594−Ethereum and Bitcoin are qualitatively different. Bitcoin has a
15595−simple UI metaphor: cash. Everyone knows how cash works. A
15596−smart contract has its own UI metaphor: law. But as we see,
15597−mechanically administered law, law without judges, is a very
15598−different thing from ordinary human law.
15599−
15600−What the DAO shows is that Ethereum just wasn't ready to be
15601−decentralized. It was not ready to allow a $150 million contract
15602−with no supervision or appeals process. The problem was not
15603−Ethereum's code per se -- although Solidity doesn't seem terribly
15604−well designed for preventing these pitfalls -- but the human
15605−understanding of its capabilities and limits.
15606−
15607−A rollback acknowledges this. It acknowledges that Ethereum
15608−wasn't ready for complete self-government, and _someone_ needed
15609−to have stopped the DAO from trading. It's not quite clear what
15610−the principle behind the rollback was.
15611−
15612−Perhaps the best kind of DAO rollback would be a rollback which
15613−understood this error fully, and acknowledged that -- for the
15614−moment -- Ethereum needs a sovereign government, with the power
15615−to restrict and/or steward contracts.
15616−
15617−Contracts are not payments. They are infinitely more complex.
15618−They will keep blowing up. Ethereum is full of buggy contracts,
15619−scammy contracts, ponzis and casinos, etc. A governed Ethereum,
15620−in the present state of the technology, might well choose to vet
15621−all contracts centrally _before_ they started trading.
15622−
15623−Would this be a permanent feature? Certainly not -- it would be
15624−a way for the community to collectively define a good contract.
15625−Once we know what a responsible, well-tested, non-scammy Ethereum
15626−contract looks like, it's much easier to return to the principle
15627−of _caveat emptor_ and let good contracts outcompete bad ones.
15628−
15629−But after the DAO hack, how does anyone trust any contract?
15630−Arguably, Ethereum is ready to be decentralized only when users
15631−are able to make this decision rationally, and get it right.
15632−This work simply hasn't been done.
15633−
15634−Perhaps the worst-case scenario is one in which Ethereum approves
15635−the hard fork, on the "just this once" principle. To save the
15636−country, we need a military coup. But don't panic! "After
15637−executing all traitors and enemies of the people, the generals
15638−will immediately restore democracy and the rule of law."
15639−
15640−The "just this once" fork takes us back to decentralization
15641−theater, where Ethereum pretends not to have a government. But
15642−now, this pretense is even more threadbare. The next hack, which
15643−will certainly happen, will produce yet another coup -- or at
15644−least a food fight over whether to have a coup. This is the path
15645−to a "digital banana republic," where the tattered illusion of
15646−law barely conceals the real law of nature.
15647−
15648−The bottom line is that if a rollback happens once, we can expect
15649−it to happen again. This time, the rollback can be treated as an
15650−act of war, and no process is necessary. Next time, there needs
15651−to be a process -- or the dream of code as law will drift further
15652−away.
15653−
15654−Having a central government isn't inconsistent with the ultimate
15655−objective of eliminating central government. Certainly, before
15656−Ethereum was released, its developers were its government. Every
15657−government is born in a state of chaos and war.
15658−
15659−The mistake is just in thinking something as complex as Ethereum
15660−can jump directly to decentralization in a single step. The
15661−pencil is not standing on its point, or anywhere close. Before
15662−anyone can think about letting go, someone needs to actually lift
15663−it. To reach law, first enforce peace.
15664−
15665−## Constitutional structure
15666−
15667−One of the governance problems of blockchains, related to the
15668−fundamental error of decentralization theater, is the failure to
15669−build deliberative institutions on top of the "parliament of
15670−miners." Voting by proof of work is great, especially if the
15671−majority is well above 51%, and can demonstrate its strength
15672−without an actual hashing race. It's a good way to finalize
15673−decisions. But not a good way to make them.
15674−
15675−But blockchain governance would be considerably improved if the
15676−miners actually had a formal way to delegate their power to a
15677−structured institution that represented them. Both Bitcoin and
15678−Ethereum have foundations and/or core teams, but authority in
15679−these institutions isn't tied in any way to actual mining power.
15680−Informal politics fills this void with personality cults and
15681−eloquent blogposts, all hoping to create collective agreement
15682−among the actual voting miners.
15683−
15684−History shows this is not a great way to run a railroad.
15685−Misalignment between a fundamental power, like the miners, and a
15686−group purporting to represent them, like the foundations, is
15687−inherently dangerous.
15688−
15689−What's the alternative? An actual constitution. Perhaps the
15690−first smart contract that Ethereum needs is not the DAO, not even
15691−well-engineered, high-quality smart contracts like Augur and
15692−Maker, but just its own equivalent of 1789. If Ethereum needs a
15693−government, it must govern itself. It certainly has all the
15694−technical tools it needs!
15695−
15696−Or, of course, it could just let the hackers win. This is the
15697−easiest path. And in the end, it may still be the best. War,
15698−who needs it?
15699−
15700−## A quick Urbit plug
15701−
15702−Technically, Urbit needs governance much more than Ethereum.
15703−Decentralization remains our goal -- but it's a long-term goal.
15704−Decentralization theater has never even been a temptation. It's
15705−just technically impossible.
15706−
15707−For example, until the Urbit OS and language (Arvo and Hoon) are
15708−frozen and perfect -- which, unlike Nock, will take a while --
15709−Urbit is still "evergreen" -- it still needs automatic hotpatches
15710−from the network.
15711−
15712−Whatever institution signs these updates is, by any standard, an
15713−absolute government. It's as if the Ethereum Foundation could
15714−push a hardfork of all clients by signing the new code on the
15715−blockchain. Getting out of this situation is a long-term goal --
15716−where "long term" means years. Decentralization is hard.
15717−
15718−Read our [interim
15719−constitution](http://urbit.org/essays/interim-constitution) and our
15720−[beliefs and principles](http://urbit.org//essays/beliefs-and-principles).
15721−]]></content:encoded>
15722− </item>
15723− <item>
15724− <title><![CDATA[Interim Constitution]]></title>
15725− <link>https://urbit.org/blog/interim-constitution</link>
15726− <guid>https://urbit.org/blog/interim-constitution</guid>
15727− <pubDate>Sun, 15 May 2016 00:00:00 GMT</pubDate>
15728− <content:encoded><
15730−
15731−## Declaration of purpose
15732−
15733−Urbit is a new network created by the Tlon Corporation. Tlon's
15734−broad intention is to surrender governance of Urbit to its users,
15735−as soon as the community is collectively ready to receive it.
15736−
15737−This constitution (which is not a legal contract, just our present
15738−intent, which may be updated arbitrarily) describes our governance
15739−process during this interim period. Its design borrows from validated
15740−historical structures, mainly Roman and Anglo-American.
15741−
15742−The last and most important task of the interim government is to
15743−write the next version of the constitution. This document may or
15744−may not incorporate any or all of the interim structures.
15745−
15746−## Beliefs and principles
15747−
15748−See our document of [beliefs and principles](/blog/beliefs-and-principles).
15749−
15750−## Governance structures
15751−
15752−The interim republic has four branches: an executive consulate, a
15753−galactic senate, a stellar congress and a planetary assembly.
15754−
15755−For the interim, full authority is held by the (Roman style)
15756−consulate. The legislature (senate, congress, assembly) is
15757−advisory. The senate is never consulted and the congress is
15758−almost never consulted.
15759−
15760−In the future, the assembly of planets specializes in technical
15761−governance. The congress of stars specializes in internal, but
15762−nontechnical, governance. The senate of galaxies selects the
15763−consuls and holds them accountable, and specializes in compliance
15764−with external powers. All votes, elections and other public
15765−actions are logged in the Urbit global namespace.
15766−
15767−As in most parliamentary systems, each of these structures sets
15768−and enforces its own internal rules of operation.
15769−
15770−### Consulate
15771−
15772−A consulate is a two-person executive. The consuls must work out
15773−their own organization and division of labor. Disagreements
15774−between consuls are resolved by the senate.
15775−
15776−A consul must be a senator. The senate, voting per galaxy,
15777−replaces the consulate whenever either a vacancy exists, or a
15778−vote of no confidence gains a majority. When electing consuls,
15779−first a plurality selects one consul; then the plurality of those
15780−who voted for anyone but the winner selects the second.
15781−
15782−### Senate
15783−
15784−The _senate_ is the set of all galaxy holders, voting per galaxy.
15785−It does not convene except to replace the consuls. Its
15786−proceedings are in private.
15787−
15788−To avoid growing the network too quickly, galaxies are activated
15789−gradually. Initially, only one galaxy is active, the root `~zod`
15790−(galaxy 0).
15791−
15792−Further activation is at the discretion of the consuls, who
15793−control `urbit.org` and will only bind activated galaxies to
15794−`galaxy.urbit.org`. Routing at the galaxy layer is by DNS, so
15795−unbound galaxies, and any stars or planets they launch, hear no
15796−packets.
15797−
15798−When any galaxy, activated or not, creates its initial
15799−certificate, the consuls add its fingerprint to the galaxy table.
15800−Non-activated galaxies can still be rekeyed.
15801−
15802−### Congress
15803−
15804−The _congress_ is the set of all active independent stars.
15805−voting per star. An _independent star_ is any star _not_ owned
15806−by anyone who is either a senator, or has some connection to one
15807−that would pose a conflict of interest.
15808−
15809−The congress of stars is designed to exercise project and
15810−community governance. Its proceedings are in private. The
15811−consuls convene it at their pleasure, and keep it informed.
15812−
15813−### Assembly
15814−
15815−The _assembly_ is the set of all active primary planets, voting
15816−per planet. A _primary planet_ is the main planet of a unique
15817−human (no sockpuppets).
15818−
15819−The assembly is responsible for technical governance. Its
15820−proceedings are in public.
15821−
15822−### The next constitution
15823−
15824−The congress proposes, and the senate approves, the next version
15825−of this constitution. Future constitutions should be defined in
15826−a smart contract platform, such as Ethereum.
15827−
15828−## Galaxy table
15829−
15830−95 galaxies are held by the [Tlon Corporation](https://tlon.io/). 50,
15831−reserved for urbit.org, the future community foundation. 40, by
15832−Tlon employees and their family members (24 by Curtis, who
15833−started in 2002; 16 by everyone else, who started in 2014). 34,
15834−by outside investors in Tlon. 37, by 33 other individuals, who
15835−donated to the project, contributed code or services, won a
15836−contest, or were just at the right place at the right time.
15837−
15838−Note that while Tlon and its employees still control a majority
15839−of galaxies, the senate is a ceremonial body; the consulate is
15840−effectively equivalent to Tlon.
15841−
15842−## Inception
15843−
15844−This constitution takes effect as soon as the initial public
15845−presale of Urbit address space is complete.
15846−
15847−## Endowment
15848−
15849−The 50 galaxies marked "urbit.org" in the galaxy table are
15850−intended as property of the republic, and will be used only in
15851−the interests of the republic and Urbit as a whole.
15852−
15853−Externally, these galaxies are held by Tlon; internally, they are
15854−managed and voted by Tlon. Once the republic acquires a legal
15855−identity and an independent human organization, Tlon pledges to
15856−donate the `urbit.org` galaxies, the DNS domain, and the GitHub
15857−`urbit` account to it.
15858−
15859−## First consuls
15860−
15861−The first consuls are Galen Wolfe-Pauly and Raymond Pasco.
15862−]]></content:encoded>
15863− </item>
15864− <item>
15865− <title><![CDATA[Magic]]></title>
15866− <link>https://urbit.org/blog/magic</link>
15867− <guid>https://urbit.org/blog/magic</guid>
15868− <pubDate>Sun, 15 May 2016 00:00:00 GMT</pubDate>
15869− <content:encoded><
15871−
15872−It's easy to get too obsessed with Urbit's alien technology. We
15873−didn't build Urbit for its tech. We built it for people to use.
15874−
15875−It's also hard to understand the power of Urbit, because it's
15876−still quite immature. Unless you understand it already, it's
15877−just a weird OS that doesn't work all that well.
15878−
15879−And this OS is supposedly designed as a new kind of product: a
15880−personal server. What is a personal server? If you had one,
15881−you'd know. Since you don't, you don't. So both your problem
15882−and our solution are totally unclear.
15883−
15884−One way to understand Urbit is to forget the technology totally.
15885−Instead, let's build the same product out of magic. Technology
15886−is hard and imperfect and slow. Magic is easy and perfect and
15887−fast. Why not use it? At least for a demo?
15888−
15889−## Magic step one: total integration.
15890−
15891−Make a list of all the cloud apps which have your personal data.
15892−OK, just imagine making a list. OK, use magic.
15893−
15894−By magic, we make some giant company buy all these apps. It
15895−could be any of them, but let's say it's Facebook. Facebook buys
15896−_all the apps_. As of now, _all your cloud computing happens in
15897−your Facebook profile_.
15898−
15899−Your Facebook is now your Dropbox and your Evernote and your
15900−Wordpress and your Gmail. And it's not just Web apps; all your
15901−servers move to Facebook. Your Nest talks to a Facebook server.
15902−Your iPhone talks to Facebook instead of iCloud. Your Fitbit
15903−records your heart rate in a Facebook log. Your Facebook
15904−manages your finances and pays your bills. Got bitcoin?
15905−Facebook is your wallet. Shop online? Check out the Facebook
15906−Store -- it sells everything!
15907−
15908−In short, you can just lock your browser to `facebook.com`. The
15909−Web is dead. Or more precisely, it's an obsolete protocol which
15910−you use to log in to Facebook.
15911−
15912−Does this sound creepy? Sure. It's incredibly creepy. But look
15913−on the bright side: it's also incredibly convenient. (And
15914−incredibly secure, at least with a 2-factor key.)
15915−
15916−For the first time ever, _all your data is in one place_. For
15917−example, the engineers at Facebook, who are awesome, would never
15918−leave Dropbox, Instagram and iCloud as three separate things.
15919−You don't need an "integration" between them. Your profile is
15920−one thing: you. Your entire digital life.
15921−
15922−(In fact, if you're a geek and have Unix boxes, your Facebook is
15923−magically integrated with Unix. You can just open your laptop
15924−and type `ls /photos/2016/May/` -- as if your digital life was a
15925−chip in a box in your backpack, not redundant servers in multiple
15926−secure data centers.)
15927−
15928−Imagine we all lived in hotels, all the time, even in just one
15929−city. Imagine you don't even have one room with a long-term
15930−lease. You sleep in one pod Mondays, another on Tuesdays...
15931−then, someone offers you a home. Your own house. With your own
15932−furniture, your own books in your own bookcases...
15933−
15934−## Magic step two: free your data.
15935−
15936−The good news is, you get your own house. The bad news is, it's
15937−in North Korea.
15938−
15939−Having your whole life owned by Facebook is still creepy. Or so
15940−most people would think. It's not actually clear that it's more
15941−creepy to be owned by one corporation, than nine corporations.
15942−But it _feels_ creepier.
15943−
15944−By magic, Facebook cares. So it decides to free you. Actually,
15945−Facebook's business is owning you. So freedom will destroy its
15946−business. But magically, Facebook doesn't mind.
15947−
15948−Right now, the software behind your Facebook experience is a
15949−million lines of Facebook goo. It solves your problems and shows
15950−your ads and does whatever the heck it wants with your data.
15951−(Not that it's "your" data. It's Facebook's data, about you.)
15952−
15953−Without changing the functionality of your Facebook experience,
15954−Facebook replaces every component of this goo with an "agent."
15955−(You have about as many agents as you used to have apps.) If you
15956−don't care about being free, you won't notice the change. If you
15957−do care, everything changes.
15958−
15959−One, you don't have to run Facebook's agents. You can replace
15960−them with anyone else's software, free or paid. Agents upgrade
15961−themselves automatically, but you are never locked in; you can
15962−always switch agents and/or vendors without damaging your data.
15963−
15964−Don't like your email UI? Change it. Don't like to see ads?
15965−You no longer see any ads -- why would someone use an agent that
15966−showed them ads? Ick. Unless it's something ridiculously
15967−specialized, an agent is either free software or costs $3.99.
15968−
15969−Two, agents _act as you_. Facebook is no longer the Panopticon.
15970−It is not a giant mainframe where all the code can access all the
15971−data. An agent can use as much of your own data as you give it;
15972−it cannot use anyone else's data. At least not without asking.
15973−
15974−When anyone can write an agent, only code can be law. Privacy is
15975−no longer enforced by the informal decisions of Facebook product
15976−managers. It must be enforced by formal security policies.
15977−
15978−This might constrict the services Facebook can offer, but only a
15979−little. Since privacy is a human universal, apps that don't
15980−respect it (for instance, image face tagging) feel weird. A
15981−service like this can't be broken up into personal agents; it
15982−still requires a Big Data mainframe somewhere. But it's okay;
15983−the agents can still talk to it.
15984−
15985−For the most part, Big Data (everyone's) has become little data
15986−(yours). You no longer have a Facebook profile -- a fancy UI
15987−backed by a million lines of Facebook goo on one big mainframe.
15988−Now what you have is a Facebook _server_: a real computer. Or at
15989−least, a virtual computer (which is much more reliable than any
15990−one physical computer).
15991−
15992−Is this computer hard to manage? You have the same basic job as
15993−someone who owns an iPhone: deciding what software to run. If
15994−you skip this job, your iPhone or your Facebook is still pretty
15995−useful. You also need to decide what data to keep. An iPhone
15996−has finite, free storage; the cloud has infinite, non-free
15997−storage. You still want a warning when your server gets fat.
15998−But at least it keeps working.
15999−
16000−## Magic step three: free your server.
16001−
16002−This agent-oriented Facebook can't show you ads. But this is not
16003−actually a huge business problem. Since Facebook owns everyone's
16004−life, it has the mother of all monopoly lockins. It can just
16005−bill you $9.99 a month for running your Facebook server. This is
16006−a great deal, for you and for Facebook.
16007−
16008−But you're still a slave, Neo. A Facebook server still isn't a
16009−personal server. Monopolies suck.
16010−
16011−Magic works, so Facebook feels guilty. It goes all the way
16012−toward freeing you, and ruins its own business.
16013−
16014−Now, your server is just a big file whose format is precisely
16015−defined. You can move it to any hosting service, or even run it
16016−on a home PC. Since hosting is now a commodity, it costs almost
16017−nothing and has zero profit margin. It may even come bundled
16018−with your Internet service.
16019−
16020−Every data center is owned by the local government. If you have
16021−data to hide from the authorities, compute at home. Most people
16022−don't have anything to hide and should run in the cloud, because
16023−the cloud works better. But using the _same platform_ as those
16024−who do have something to hide creates "herd immunity". You don't
16025−have to choose between a secure platform with no network effect,
16026−and a non-secure platform that everyone else uses.
16027−
16028−## Magic step four: free your name.
16029−
16030−Freeing your server also means freeing your identity. It's no
16031−longer true that Facebook decides who you are. Facebook just
16032−wrote the algorithm. Your server contains cryptographic secrets
16033−that control your identity. If your identity was a bitcoin, your
16034−server would be a giant bitcoin wallet.
16035−
16036−The bad news: lose the file, lose the identity. The good news:
16037−your server is genuinely personal now. It's yours in every way.
16038−It's so personal that if you destroy it, it's gone.
16039−
16040−Facebook doesn't even keep its power to create new servers. The
16041−"real name" policy has done great things to control spam, because
16042−spam always depends on disposable accounts. But it implies a
16043−central authority.
16044−
16045−Instead, Facebook borrows an idea from bitcoin and just limits
16046−the number of identities. If you need one, you have to buy one.
16047−They don't cost that much; just enough to deter spammers.
16048−
16049−(Is your real name still linked to your identity? Maybe, maybe
16050−not. There's a role for name validation, but not everyone needs
16051−to have a real name, and not everyone else needs to know it. A
16052−dissident, or anyone who wants to speak out and let the words
16053−speak for themselves, might want a second anonymous identity.
16054−But sock puppets remain evil -- two names for the same person
16055−should not interact in the same place.)
16056−
16057−## Magic step five: call it Urbit.
16058−
16059−And, with magic, we've succeeded in turning Facebook into Urbit.
16060−Technically, Urbit is pretty close to magic, but there is no way
16061−it's going to happen this way. See the [roadmap](/blog/roadmap) for how it
16062−actually happens.
16063−]]></content:encoded>
16064− </item>
16065− <item>
16066− <title><![CDATA[The Urbit Address Space]]></title>
16067− <link>https://urbit.org/blog/the-urbit-address-space</link>
16068− <guid>https://urbit.org/blog/the-urbit-address-space</guid>
16069− <pubDate>Sun, 15 May 2016 00:00:00 GMT</pubDate>
16070− <content:encoded><
16072−
16073−## Basics
16074−
16075−Urbit contains a lot of new technology. As an ordinary user, all you
16076−need to understand is Urbit's identity model. If you're in a hurry,
16077−just read these simplified basics.
16078−
16079−An Urbit identity, or "ship," is a string like `~firbyr-napbes`. It
16080−means nothing, but it's easy to remember and say out loud.
16081−`~firbyr-napbes` is actually just a 32-bit number, like an IP address,
16082−that we turn into a human-memorable string.
16083−
16084−Technically, a ship is a secure digital identity that you own and
16085−control with a cryptographic key, like a Bitcoin wallet. As in
16086−Bitcoin, the supply of ships is mathematically limited. This keeps
16087−the network friendly, by making spam and abuse expensive.
16088−
16089−A ship name is just a number; smaller numbers make shorter names.
16090−Shorter names are easier to remember, so they're more valuable. So
16091−ships are classified by the number of bits in their name. (A ship
16092−name is just a scrambled base-256 representation of the number.)
16093−
16094−A 32-bit ship (like `~firbyr-napbes`) is called a "planet." A 16-bit
16095−ship (like `~pollev)` is a "star." An 8-bit ship (like `~mun`) is a
16096−"galaxy." A planet is an identity for an independent, adult human.
16097−Stars and galaxies are network infrastructure.
16098−
16099−Each planet or star is launched by its "parent," the star or galaxy
16100−whose number is its bottom half. So the planet `~firbyr-napbes`,
16101−`0xdead.beef` or `3.735.928.559`, is the child of `~pollev`, `0xbeef`
16102−or `48.879`, whose parent is `~mun`, `0xef`, `239`. The parent of
16103−`~mun` and all galaxies is `~zod`, `0`.
16104−
16105−If Bitcoin is money, Urbit is land. Much as all real-estate titles in
16106−England trace back to William the Conqueror, all certificates in Urbit
16107−trace back to `~zod`.
16108−
16109−But this universe is worthless unless dispersed. It's already quite
16110−well fragmented. And as it grows distributed, it grows decentralized.
16111−The endpoint is a virtual city of 4 billion (`2^32`) citizens, all
16112−owners of their own independent digital identities. The stars and
16113−galaxies continue as a federated governance and service network.
16114−
16115−This city is a social network, a peer-to-peer packet network, and a
16116−public-key infrastructure (PKI). In the social layer, your ship is
16117−your name. In the packet layer, your ship is your network address.
16118−In the PKI, your ship is your cryptographic identity. Perhaps more
16119−intuitively, a ship is a sort of pronounceable phone number.
16120−
16121−And once Urbit is built, no one owns the city. No one can control it.
16122−It does need governance; but it governs itself as a digital republic.
16123−
16124−## Details
16125−
16126−As an Urbit user, these basics are all you need to know. As a
16127−developer, a few more details might interest you. (An even more
16128−comprehensive treatment is in the [whitepaper](https://media.urbit.org/whitepaper.pdf)).
16129−
16130−### Design goals
16131−
16132−An identity system has three goals: a name wants to be secure,
16133−human-meaningful, and decentralized. A principle called "Zooko's
16134−triangle" says that a practical identity system can achieve any two of
16135−these goals.
16136−
16137−The art of OS design is the art of using strategic tradeoffs to almost
16138−solve unsolvable problems. Urbit's goals are to be secure,
16139−human-_memorable_, and _eventually_ decentralized. We sacrifice
16140−meaning (Urbit is not competing with the DNS), and postpone
16141−decentralization. These tradeoffs buy us a simple system that can
16142−actually be built.
16143−
16144−### Comparison to existing identity layers
16145−
16146−The Internet doesn't have anything like Urbit ships, so you may need
16147−to stretch your brain a little here.
16148−
16149−There are three levels of naming on the Internet: raw, numeric IP
16150−addresses (like `126.78.92.112`), domain names (like
16151−`foobar.com`), and user identities (like `galen@tlon.io` or
16152−`@galenwp`).
16153−
16154−Urbit (or more precisely, its Ames protocol) squeezes all three layers
16155−into one. At the network level, Urbit is a P2P overlay network; your
16156−ship is your network address. It's also the name of your server.
16157−Finally, it's your secure digital pseudonym. And we map your ship
16158−name into the DNS, at `ship.urbit.org`.
16159−
16160−(One way to use Urbit is as an identity for the Internet, which
16161−doesn't have a standard system of secure authentication. Urbit has a
16162−single-signon API which lets any Web server accept Urbit logins, like
16163−a normal social login -- but not captive to any central mainframe.)
16164−
16165−### Cryptographic ownership
16166−
16167−You own an Urbit ship cryptographically, like a Bitcoin wallet. But
16168−Urbit doesn't use a blockchain or mining.
16169−
16170−You transfer a ship by signing a new public key with the old private
16171−key, then broadcasting the signature. Any urbit that receives this
16172−new certificate will no longer trust the old key.
16173−
16174−Urbit is digital land, not digital money. A currency needs to support
16175−high-frequency, zero-friction transfers. Real estate transfers are
16176−low frequency and high friction, so the "double spend" problem (which
16177−mining solves) is much less pressing.
16178−
16179−Don't expect urbits to be tradeable on cryptocurrency exchanges. A
16180−trade adds at least one signature to the ship's certificate, or two if
16181−the parties don't trust each other and an intermediary is needed. A
16182−bulky certificate isn't free, since it slows down new connections.
16183−
16184−This isn't a serious problem if urbits are treated like land. But it
16185−prevents Urbit from being a competent currency. This is a feature,
16186−not a bug. Urbit has no need to compete with Bitcoin or Ethereum,
16187−and every reason not to.
16188−
16189−## Moons and comets
16190−
16191−In the general case, a ship is actually a 128-bit number. A full
16192−table of ship classes:
16193−
16194−```
16195−8 bits galaxy router ~syd
16196−16 bits star router ~delsym
16197−32 bits planet human ~mighex-forfem
16198−64 bits moon device ~dabnev-nisseb-nomlec-sormug
16199−128 bits comet bot ~satnet-rinsyr-silsec-navhut--bacnec-todmeb-harwen-fabtev
16200−```
16201−
16202−Moons are for clients and connected devices: a laptop, a phone, a
16203−digital thermostat. A moon is not independent; its parent planet has
16204−to sign its key updates. (We don't want rogue clients floating
16205−randomly around the universe.)
16206−
16207−A comet's address is the hash of its initial public key. Anyone can
16208−launch a comet. Nothing stops you from using a comet as your
16209−identity, except that the name is a mouthful and everyone will assume
16210−you're a bot.
16211−
16212−### Scarcity, reputation, friendliness and trust
16213−
16214−A crucial difference between Urbit and other networks is that planets
16215−are scarce. Even when the network is fully populated, there are only
16216−4 billion. Early in Urbit's life, most stars and galaxies are not yet
16217−operating, so far fewer are available. No one will ever be able to
16218−get planets trivially and for free.
16219−
16220−Urbit is a _friendly network_: a network on which you can assume that
16221−a stranger is nice until proven nasty. Friendliness is a direct
16222−consequence of scarce, individually owned identities. We're not
16223−changing human nature, just creating the right economic incentives.
16224−
16225−Most forms of network abuse are "Sybil attacks": they rely on an
16226−infinite supply of fresh identities. Scarcity makes reputation work.
16227−Spam is a business; if the cost of a new planet exceeds the amount of
16228−money you can make by spamming from that planet until its reputation
16229−is trashed, there will be no spam.
16230−
16231−Shady stars and galaxies that sell blocks of planets to spammers will
16232−also develop reputations as "bad neighborhoods," damaging the value of
16233−the whole block. Abuse at any level is designed to be
16234−counterproductive and economically self-terminating.
16235−
16236−Urbit has no reputation system at all at the moment, simply because
16237−we're so small that friendliness is automatic. The clear and rigorous
16238−structure of the address space is not a reputation system; it is a
16239−platform on which any number of such systems can and should be built.
16240−But we can't build one until we need one.
16241−
16242−### Initial allocation and rationale
16243−
16244−In cryptocurrency terms, Urbit is "100% premined." Why? Three
16245−reasons.
16246−
16247−One, Urbit doesn't need mining. Two, Urbit is a much more ambitious
16248−software project than Bitcoin or even Ethereum. To fund its own
16249−development, the project needs to capture the potential value of its
16250−own real estate.
16251−
16252−Three, most theories of property agree that anyone whoever creates or
16253−discovers new property starts out by owning it. Because galaxies are
16254−premined, Urbit starts as a centralized system. But it has two strong
16255−motivations to decentralize.
16256−
16257−One, the more decentralized Urbit is, the more Urbit is worth. Two,
16258−the only way for Urbit to fund its own development is to homestead its
16259−own real estate.
16260−
16261−Urbit was created by Curtis Yarvin, who has distributed the 256
16262−galaxies as follows (allocation as of June 1, 2016):
16263−
16264−95, to the [Tlon Corporation](/blog/company). 50, to urbit.org, the future
16265−community foundation. 40, to Tlon employees and their family members
16266−(24 to Curtis, who started in 2002; 16 to everyone else, who started
16267−in 2014). 34, to outside investors in Tlon. 37, to 33 other
16268−individuals, who donated to the project, contributed code or services,
16269−won a contest, or were just in the right place at the right time.
16270−
16271−What's critical is that the whole system is unlikely to collapse back
16272−into a single landlord. This is why we've intentionally scattered
16273−Urbit's ownership across a diverse set of entities.
16274−
16275−Furthermore, we've defined informal conventions designed to motivate a
16276−healthy ownership structure by punishing violators with reputation
16277−cost. Address blocks should only split, never merge; galaxies and
16278−stars should be owned by different parties; galaxies should be owned
16279−by true individuals, not corporations. Urbit does not live up to
16280−these ideals at present, but must always progress toward them.
16281−
16282−### Federated services, adoption and escape
16283−
16284−Urbit is a peer-to-peer network. Urbits that live behind a firewall
16285−or on a home network need "supernodes" to help them route packets.
16286−The supernode is the parent. So a parent's work isn't done once it's
16287−launched all its children.
16288−
16289−There's no way to enforce this responsibility. So a star or planet
16290−can be _adopted_ by a new parent of the same class, letting it escape
16291−from a bad default parent. If your parent stops serving you, and no
16292−other parent is willing to adopt you, you're probably a bad actor.
16293−
16294−Supernode routing is just one example of why you need a parent. A
16295−mature Urbit will naturally develop all kinds of other _federated
16296−services_ -- from technical standardization and update approval, to
16297−certificate update broadcast, to reputation and friend lookup. All
16298−these services are delivered by cooperating stars and galaxies. Bad
16299−actors at this level should be rare.
16300−
16301−Especially when Urbit is young, the level of trust that a child places
16302−in its parent is high. The trust implied by automatic kernel updates
16303−is almost infinite. You can disable updates, but that's nowhere near
16304−practical yet. (Ideally we will be able to freeze the Arvo kernel,
16305−like Nock, and turn off kernel updates; but this will take years at
16306−least.)
16307−
16308−### Code is law: seeing like a pattern language of great cities
16309−
16310−Constitutional innovation is dangerous. Our vision of digital
16311−governance isn't ours, but is synthesized as best we can from the work
16312−of four great 20th-century thinkers: the legal scholar Lawrence
16313−Lessig, the political scientist James C. Scott, the urbanist Jane
16314−Jacobs and the architect Christopher Alexander.
16315−
16316−All decentralized computation systems rely to some extent on Lessig's
16317−principle: "code is law." Where law uses human interpretation to
16318−determine an outcome, code uses mathematics. It is code, not law,
16319−that decides who owns a Bitcoin wallet.
16320−
16321−But all these systems, including Bitcoin, need governance. They need
16322−as little as possible, but not none. In the digital world as in the
16323−real world, _laissez-faire_ is always necessary, never sufficient.
16324−Governance is a human universal.
16325−
16326−That's why we call Urbit a "virtual city." And as a city, it can't be
16327−a corporate gated community. It might start as that, but it has to
16328−grow up into a true city-state: a self-governing digital republic.
16329−This pattern is not just blind clinging to Anglo-American tradition;
16330−like every prudent constitution, it fits the actual virtues and vices
16331−of its target population.
16332−
16333−Urbit's galactic hierarchy resembles the natural patterns we find in
16334−many existing human political systems. As Alexander wrote:
16335−
16336−> Wherever possible, work toward the evolution of independent regions
16337−> in the world, each with its own natural and geographic boundaries;
16338−> each with its own economy; each one autonomous and self-governing;
16339−> each with a seat in a world government, without the intervening power
16340−> of larger states or countries.
16341−
16342−We adapt Alexander's vision to a digital republic as the pattern that
16343−_authority is proportional to property_. This pattern already has a
16344−name in the cryptocurrency community, which calls it _proof of stake_.
16345−Urbit's launch hierarchy is a sort of built-in proof of stake.
16346−
16347−Another governance pattern, a political cliche but no less valuable
16348−for it, is the system of checks and balances. The address space of
16349−Urbit is covered by three independent tiers, galaxies, stars and
16350−planets; which should govern? The obvious design is a three-chambered
16351−legislature balanced against itself.
16352−
16353−For more on Urbit's governance design, see our [beliefs and
16354−principles](/posts/principles/) and our [interim constitution](/posts/constitution/).
16355−]]></content:encoded>
16356− </item>
16357− <item>
16358− <title><![CDATA[~2016.5.16 Urbit Roadmap 2016]]></title>
16359− <link>https://urbit.org/updates/2016-5-16-roadmap</link>
16360− <guid>https://urbit.org/updates/2016-5-16-roadmap</guid>
16361− <pubDate>Sun, 15 May 2016 00:00:00 GMT</pubDate>
16362− <content:encoded><.
16597−]]></content:encoded>
16598− </item>
16599− <item>
16600− <title><![CDATA[An Urbit Overview]]></title>
16601− <link>https://urbit.org/blog/an-urbit-overview</link>
16602− <guid>https://urbit.org/blog/an-urbit-overview</guid>
16603− <pubDate>Tue, 10 May 2016 00:00:00 GMT</pubDate>
16604− <content:encoded><
16606−
16607−## What Urbit is
16608−
16609−Urbit is a virtual city of general-purpose personal servers.
16610−
16611−## Your old personal server
16612−
16613−What's a personal server? In a sense, you already have one. Your
16614−personal server is the combination of all the cloud services you use
16615−now.
16616−
16617−This "server" is a mess. It's broken into 17 different fragments
16618−which are scattered all over the planet. You have no control at all
16619−over any of the pieces. The more we depend on Web services, the more
16620−we realize how unsustainable this situation is.
16621−
16622−Can you remember all the services you have accounts for? How about
16623−the username and password for each? Some of them will let you pull
16624−your data out somehow, some won't. Sometimes you can move your data
16625−between them, sometimes you can't. But they're all good at
16626−showing you ads.
16627−
16628−## Your new personal server
16629−
16630−Your urbit is your own general-purpose server. It holds your
16631−data; runs your apps; wrangles your connected devices; and
16632−defines your secure identity. If you still need your old
16633−services, it drives them with APIs.
16634−
16635−Your urbit presents your whole digital life as a single web
16636−service. And since it's yours, open source and patent-free, it
16637−never shows you ads. Or loses your data. Or updates without
16638−your consent.
16639−
16640−Technically, Urbit is a new kind of OS that has a precise formal
16641−definition. (Urbit is actually a [single mathematical function](https://media.urbit.org/whitepaper.pdf).) One advantage of a math-based OS is that Urbit is perfectly
16642−portable. It can't tell whether it's in a cloud data center or on
16643−your home PC.
16644−
16645−Concerned about mass surveillance? Download your urbit and restart it
16646−on your laptop, or move to a new host in Iceland. Urbit's formal
16647−simplicity makes managing it as easy as managing an iPhone: all you
16648−have to decide is what apps to add.
16649−
16650−Each urbit is a node on a global, encrypted P2P network. Your Urbit
16651−name, a generated pseudonym like `~talsur-todres`, is also your
16652−network address. Like Bitcoin, Urbit address space is a cryptographic
16653−asset with a limited supply.
16654−
16655−By keeping addresses scarce, we make spam and abuse expensive. Urbit
16656−is a "friendly network," like the Internet in 1986, where a stranger
16657−is nice until proven nasty. As it matures, Urbit will grow into a
16658−decentralized, self-governing virtual city both safe and free.
16659−
16660−## The Urbit future
16661−
16662−In an Urbit world, your data is no longer trapped in a jumble of
16663−proprietary servers. Your urbit is a permanent, versioned, typed
16664−archive the size of your digital life. Even before you move your data
16665−from a Web service to a local Urbit app, your urbit can drive your
16666−account with an API or scraper.
16667−
16668−And within Urbit, data is never locked inside apps. Imagine if you
16669−could painlessly switch between Facebook and Google+, Asana and
16670−Trello, Tumblr and WordPress. Not only does your urbit upgrade itself
16671−and its apps automatically, you can "sidegrade" a running app to
16672−another vendor without losing data.
16673−
16674−Your urbit is also your digital identity. Along with your data
16675−lifestream of media, messages and documents, it has the keys and
16676−tokens to manage all your legacy Web services. It holds the keys
16677−for your cryptocurrency wallets, so it can buy and sell for you.
16678−(With one personal server to secure, not 17 different accounts,
16679−you actually have the bandwidth to take security seriously.)
16680−
16681−You still use network services. But instead of interacting with
16682−the service provider's HTML UI, which phones home using
16683−proprietary HTTP APIs, you interact with a third-party app on
16684−your urbit, which talks to multiple service providers using
16685−public, typed Urbit protocols. For example, your urbit runs a
16686−single shopping app, which downloads catalogs and uploads orders.
16687−This app is one store which sells everything in the world, with a
16688−salesman who's 100% on your side and always has the best price.
16689−Every computing experience is different when the UI is working
16690−exclusively for the user.
16691−
16692−Finally, your urbit is the hub for your network of connected
16693−devices. Your smart thermostat, your wristband, your phone and
16694−tablet, all run satellite urbits which talk securely to your main
16695−urbit in the cloud.
16696−
16697−## A chance for digital freedom
16698−
16699−The promise of the personal server isn't just convenience.
16700−General-purpose computing is magic. This magic must be in the
16701−hands of all, not just those who can master Unix. The computer
16702−is a bicycle for the mind. It's an open vehicle for exploration
16703−and discovery. It's not a way to optimize ad delivery.
16704−
16705−Urbit, as virtual city, is a platform that brings together all our
16706−datastreams -- from emails to heartbeats -- in a way that we ourselves
16707−control. Can we work together to match faces in photos, without
16708−submitting to some panopticon in Mountain View? While the first step
16709−in freedom is the right to be left alone, the second is the power to
16710−form new intentional communities, to create and evolve a voluntary
16711−definition of public space. We have no idea at all what people will
16712−do with this power.
16713−
16714−General-purpose computing is digital freedom. And today, a cloud data
16715−center is the technically optimal locus of computation. The cloud is
16716−always on, always available, never loses data. Hosts are sometimes
16717−attacked; but they never intentionally tamper with their virtual
16718−computers. The cloud can never be secure against a global adversary;
16719−but most people don't have a global adversary. A single portable
16720−platform provides "herd immunity" for the few who do need direct
16721−physical control over their main computers.
16722−
16723−Though even laptops are atrophying into mere browsers, mass-market,
16724−general-purpose computing on the client side remains an endangered
16725−species that must be protected. But on the server side, this species
16726−has never even _existed_. There has never been anything like a
16727−mass-market personal server. Why not?
16728−
16729−## Freedom is an engineering problem
16730−
16731−Urbit is not a difficult idea. Urbit is like a flying car: the idea
16732−is not the hard part. Almost everyone we talk to about Urbit turns
16733−out to have had pretty much the same idea themselves. The problem is
16734−building it.
16735−
16736−A server is a computer. It's running some operating system. This OS
16737−is a flavor of Unix. There are no alternatives. It's connected to
16738−some network. This network is the Internet. It has no competitors.
16739−You can have a personal server, if it's a Unix server on the Internet.
16740−
16741−Almost no one thinks being a Unix system administrator is fun. Not
16742−even Unix system administrators think running an Internet server is
16743−fun. So the personal Unix/Internet server is like the personal
16744−bulldozer. This is not a consumer product. Any number of engineers
16745−can't turn a bulldozer into a bicycle.
16746−
16747−How did we build the personal bulldozer? We didn't. We started
16748−from scratch. (The people who built the first PCs didn't start
16749−with a mainframe OS, either.) We created a new platform: Urbit.
16750−
16751−Urbit doesn't compete with Unix and the Internet. It's a new,
16752−opaque layer on top of them. Your browser runs on a native OS,
16753−but it doesn't give Web apps any way to talk to the native OS.
16754−Urbit is like a browser for the server side: code within Urbit is
16755−formally isolated from the platform it runs on top of.
16756−
16757−Your urbit is a Unix process, in a data center or your PC. It sends
16758−UDP packets over the Internet. It can both load and serve web pages
16759−over HTTP. Except for character sets and crypto, nothing in Urbit
16760−reuses or depends on any 20th-century code.
16761−
16762−Urbit is a complete, clean-slate system software stack: a
16763−non-lambda interpreter (Nock), a functional language (Hoon), and
16764−an event-driven OS (Arvo), with its own encrypted protocol
16765−(Ames), typed revision control (Clay), reactive web server (Eyre)
16766−and functional build system (Ford). The full system, including
16767−basic apps, is only 30,000 lines of Hoon.
16768−
16769−The first end-to-end prototype of Urbit took one engineer eleven
16770−years. The current beta took three more years, with about three
16771−engineers on average.
16772−
16773−How does it take 14 years to write 30,000 lines of code? The code
16774−wasn't the hard part. The hard part was rewriting it until it was
16775−right. We think we've solved all the real CS problems, and we're
16776−certainly done changing major interfaces. But it will take more than
16777−our small team to deliver a polished Urbit user experience that can
16778−actually challenge modern web apps.
16779−
16780−## Where we are, what we're doing
16781−
16782−Urbit is in feature freeze. It's a minimum viable product in
16783−early beta. It still needs quite a bit of fit-and-finish work.
16784−We certainly don't recommend it for end users or consider it in
16785−any way secure. But it's fun to play with, if you're a hacker.
16786−
16787−This summer, we're making the switch to an open and transparent
16788−development and specification process. A system as unusual as
16789−Urbit can't be invented in public. But it has to be finished and
16790−maintained in public.
16791−
16792−Additionally, we're creating an open political and economic process,
16793−with a small, fixed-price public presale of Urbit address space. Join
16794−us and help make this future actually happen.
16795−
16796−To keep reading, learn more about [Urbit's address
16797−space](/blog/the-urbit-address-space); share our vision of the Urbit user
16798−experience, from the [top down](/blog/what-is-urbit-for) or the [bottom
16799−up](/blog/magic); check out the [development roadmap](/blog/roadmap);
16800−evaluate Urbit's [beliefs and principles](/blog/beliefs-and-principles) or its
16801−[interim constitution](/blog/interim-constitution).
16802−
16803−(For technical readers, check out our [documentation](https://urbit.org/docs/) or
16804−the [whitepaper](https://media.urbit.org/whitepaper.pdf)).
16805−]]></content:encoded>
16806− </item>
16807− <item>
16808− <title><![CDATA[Beliefs and Principles Guiding the Urbit Project]]></title>
16809− <link>https://urbit.org/blog/beliefs-and-principles</link>
16810− <guid>https://urbit.org/blog/beliefs-and-principles</guid>
16811− <pubDate>Tue, 10 May 2016 00:00:00 GMT</pubDate>
16812− <content:encoded><
16814−
16815−## Beliefs
16816−
16817−We believe that general-purpose computing is an essential tool to
16818−unlock the power of individual creativity.
16819−
16820−We believe that ownership, privacy and control don't need to be
16821−sacrificed in exchange for usability, accessibility and reliability.
16822−
16823−We believe in the power of the informed crowd to develop and maintain
16824−software, through the IETF principles of sincerity and rough consensus.
16825−The ability of the engineering community to govern itself through
16826−republican forms is not an abstract theory; it's a proven fact.
16827−
16828−We believe in both free speech and individual accountability. We
16829−believe that a healthy network is one with diverse and well-defined
16830−communities, and clear, user-controlled, boundaries between public and
16831−private space.
16832−
16833−We believe that no software system can replace human trust and
16834−communication. Dialogue, judgment and governance are essential to
16835−communities of all scales. Code and law can reduce conflict in the
16836−common case; they can never handle all exceptions.
16837−
16838−## Principles
16839−
16840−Here are some principles of Urbit. Where principles conflict,
16841−the first stated takes precedence.
16842−
16843−### Digital independence
16844−
16845−Digital independence is independent control of your own
16846−general-purpose computer which holds your own primary data.
16847−Urbit's ultimate purpose is to make practical digital
16848−independence a useful and widely available product.
16849−
16850−### Code is law
16851−
16852−Wherever possible, the rules of Urbit must be executable as code.
16853−Wherever possible, code must be self-enforcing. If not, it must
16854−be perfectly defined. If not, it must not be stated.
16855−
16856−### Sovereignty is conserved
16857−
16858−Even where code is law, exceptional situations demanding
16859−effective collective action will always arise. There must
16860−always be a collective authority to solve these problems.
16861−
16862−Two known problems in Urbit that require central authority are
16863−approval of software updates and activation of the network. But
16864−there will certainly be others.
16865−
16866−### Purpose of collective authority
16867−
16868−Urbit, as opposed to the Tlon corporation, is a republic. Its
16869−government has one task: promoting, preserving and protecting Urbit.
16870−It may take any legal action which advances this goal. Any other
16871−actions are _ultra vires_, out of scope. Urbit is not a
16872−general-purpose charity.
16873−
16874−### Decentralized control
16875−
16876−Urbit should never fall under any kind of central control. All
16877−transitions in galaxy ownership should divide positions, not
16878−unite them.
16879−
16880−Galaxy and star ownership should also be separated. It is
16881−harmful for a single entity to hold both galaxies and stars.
16882−
16883−### Property is contingent
16884−
16885−Property rights are contingent and accidental, not moral or
16886−meritorious. A property register does not record why an owner
16887−deserves some property. Ownership is neither a reward nor a
16888−right; it is a fact.
16889−
16890−### Governance is by stake
16891−
16892−Ultimately, Urbit must be governed by those who own it. In each
16893−tier, equal stakes must hold equal authority.
16894−
16895−### Content-neutral
16896−
16897−Urbit does not admit a tradeoff between anarchy and tyranny,
16898−order and liberty. Urbit has zero tolerance for abuse, nor does
16899−it facilitate censorship.
16900−
16901−Urbit will do everything possible to help you block content you
16902−don't want to see. It does nothing to help you block content you
16903−don't want others to see.
16904−
16905−### Trolling considered harmful
16906−
16907−If you post content on Urbit which may offend or disturb any
16908−significant group of users, it is your responsibility to mark it
16909−properly for automatic blocking.
16910−
16911−### Sockpuppets considered harmful
16912−
16913−The only legitimate reason for one individual to use multiple
16914−identities is to maintain multiple active pseudonyms. But
16915−multiple identities must never interact in the same context.
16916−
16917−### Not a darknet
16918−
16919−Urbit is not a darknet. It does not break real-world laws. It
16920−is not designed to facilitate the breaking of real-world laws.
16921−For any problem that lawbreakers have, there must always be a
16922−better solution that is not Urbit.
16923−
16924−### Responsibility to route
16925−
16926−As long as they are not facilitating violations of any of these
16927−principles, or laws in their own jurisdictions, stars and
16928−galaxies are responsible for routing their children. They are
16929−also collectively responsible for escape-routing the children of
16930−stars and galaxies which fail in their responsibility.
16931−]]></content:encoded>
16932− </item>
16933− <item>
16934− <title><![CDATA[What is Urbit For?]]></title>
16935− <link>https://urbit.org/blog/what-is-urbit-for</link>
16936− <guid>https://urbit.org/blog/what-is-urbit-for</guid>
16937− <pubDate>Tue, 10 May 2016 00:00:00 GMT</pubDate>
16938− <content:encoded><
16940−
16941−Open platforms don't beat closed systems just because they're open.
16942−They win because you can do more exciting things with them. We
16943−believe we're overdue for new infrastructure not purely on principle:
16944−but because we think you can build better products on top.
16945−
16946−We look forward to a future where your fleet of Urbits run the devices
16947−throughout your house, keep your biometric data in sync with the data
16948−center and hold your secure medical and financial data. Today Urbit
16949−is just a proof of concept — but we see a road from here to there.
16950−
16951−## Today
16952−
16953−These are things that work but are under development today. We expect
16954−them to improve and stabilize in the coming months.
16955−
16956−### Making the web programmable
16957−
16958−The first thing your Urbit can do is act as a transparent layer to
16959−your existing services. We'd like urbit to be usable as a self-hosted
16960−IFTTT for geeks. Your urbit can hold your keys, store data, run
16961−programs and seamlessly connect to your existing services. Plus, with
16962−a global revision controlled filesystem it's easy to share API
16963−connectors and keep them up to date.
16964−
16965−With an Urbit running on your machine you can `ls` your Gmail from
16966−Unix. Write a short script to poll Twitter on a keyword and deliver
16967−the results to your email or into a Slack channel. Send an SMS when
16968−an HTTP request doesn't resolve. These are just a few examples. Your
16969−Urbit is designed to make data trapped in your existing services feel
16970−like an extension of your local programming environment.
16971−
16972−### Self-hosted publishing and communication
16973−
16974−Additionally your Urbit is a flexible platform for publishing data to
16975−the web and communicating with others. Sort of like a self-hosted
16976−Slack, WordPress and Wiki in one. It's more common to use many tools
16977−for sharing our content and communicating. Urbit is designed to bring
16978−those tools together; giving the individual control over their
16979−creative output.
16980−
16981−Simply write markdown in your favorite editor and have an Urbit sync
16982−them to the cloud. Use React components to control your layout and
16983−extend our toolset. Host your own discussion channels and comment
16984−threads. On a computer you own and control, whose source is 100%
16985−open.
16986−
16987−### Cryptographic identity
16988−
16989−Your Urbit is your digital identity, cryptographically secured but not
16990−controlled by any central authority. The Urbit PKI fills a gap that
16991−remains unsolved on the web. We can send encrypted messages, securely
16992−exchange digital currency, but how do I know who anyone is?
16993−
16994−Your Urbit can post public proof to your third party services and its
16995−validity is easily auditable. Using Urbit as an identity scheme for
16996−new services would be a great decentralized alternative to 'Sign in
16997−with [company x]'.
16998−
16999−## Tomorrow
17000−
17001−Urbit's crypto isn't tested, the network still gets rebooted from time
17002−to time. The next milestone comes when Urbit matures to the point
17003−that it's as reliable as its SaaS counterparts.
17004−
17005−### Lifestreams, finally
17006−
17007−The combination of great API tools and great publishing tools means we
17008−can finally build an integrated interface for today's social networks.
17009−The web is full of streams of data. For the user there's not much
17010−utility in bouncing from service to service. Instead, it'd be great
17011−to have general-purpose tools for consuming and publishing data.
17012−Imagine a Medium-quality interface that makes no distinction between
17013−Facebook and Twitter; SMS and Skype.
17014−
17015−### Secret storage, web3
17016−
17017−Bitcoin and Ethereum are both part of a new era of decentralized
17018−infrastructure that's just beginning. For the blockchain to realize
17019−its potential individuals need ought to have a way to host their own
17020−nodes. At the very least, individuals need a reliable place to keep
17021−their secrets. What's more, the blockchain isn't designed for
17022−computation. It's great for contracts and currency, but too slow for
17023−practical computing.
17024−
17025−Urbit is a great complement to the blockchain. Your Urbit can safely
17026−store your keys, providing an always-available keychain on the
17027−network. Even better, your Urbit can hold your blockchain assets and
17028−provide an off-chain computation layer. Urbit's computation doesn't
17029−provide any kind of distributed consensus, but our computation model
17030−is very simple and lends itself well to auditing. This makes it a
17031−very blockchain-friendly platform.
17032−
17033−## Over the horizon
17034−
17035−If there's one thing we know from the history of personal computers
17036−it's that computers are always expanding into more and more of our
17037−lives. The more _personal_ our computers get the more they need to
17038−reflect our thinking and our relationships. We don't know exactly
17039−what this will look like, but we can certainly speculate on the areas
17040−that deserve the most attention.
17041−
17042−### Data permanence and software competition
17043−
17044−Right now applications and data are practically the same thing.
17045−There's no practical way for the user to separate them. Apps come and
17046−go, either by falling out of fashion or actually shutting down. In
17047−both cases our data becomes orphaned. There's no practical way for us
17048−to get it back. The raw data from your LiveJournal is as good as a
17049−floppy disk from the 80s. Computers hold the records of our lives.
17050−Losing the history of the world to bitrot is a preventable problem.
17051−
17052−Since each person owns their own Urbit there's no way to separate the
17053−user from their data. When you run software on your Urbit you
17054−_actually run it_ and your programs manipulate data that _you own_.
17055−The individual has permanent access to their data by design. Ensuring
17056−its durability is a technical problem, not a license agreement
17057−problem.
17058−
17059−When individuals are running their own software it's no longer
17060−possible to lock them in by controlling their data. Instead, software
17061−has to actually compete on utility. If one could trivially replace
17062−the interface for Evernote with one from another developer for $10
17063−wouldn't it be worth it? Even more so with Urbit, since after
17064−installing software you're not dependent on the developer staying
17065−alive. You're running a local copy. This model puts pressure on
17066−applications to interoperate better and become more modular.
17067−
17068−### Reputation
17069−
17070−With a working identity system it's possible to build up contextual
17071−reputation systems that aren't held hostage by their applications.
17072−Just like the marriage of applications and data, reputation is
17073−permanently tethered to and jealously guarded by the services we use.
17074−
17075−For example, today we have karma systems on a per-site basis, like
17076−Reddit. Is there any reason that individuals shouldn't have karma
17077−scores per-topic? An individual's authority on a certain topic could
17078−be verified by other experts while still denied by detractors. It's
17079−easy to extend this to services like Yelp. With a strong identity
17080−system it's possible for pseudonymous reviews to be counted with real
17081−value. We'd no longer need a central authority for deciding on the
17082−reputation of a restaurant, but just a way to pseudonymously aggregate
17083−individual opinions. There's a broad swath of territory ripe for
17084−exploration here.
17085−
17086−### Privacy
17087−
17088−With a reliably secure place to store your data on the network,
17089−wouldn't you want to store even more personal information yourself?
17090−Why is it that we don't store our own medical records, biometric data
17091−or financial data? In a world where we have a safe place to keep them
17092−we wouldn't require anyone else to keep them for us.
17093−
17094−Furthermore, we'd be able to share them pseudonymously. One could
17095−imagine medical research or census-like polling being done without
17096−compromising the privacy of those involved. This also lowers the
17097−barrier to entry for fintech and medical software developers. If I
17098−can run my own personal health and finance software that can reliably
17099−access my own transactions and medical records, what would developers
17100−come up with?
17101−
17102−### IoT
17103−
17104−What needs a network _and_ computation? Devices. Turning a unix box
17105−into a usable platform for hardware isn't something that any
17106−individual manufacturer is incentivized to do. For the internet of
17107−things to actually work we need a platform for devices to interoperate
17108−simply and securely. Urbit is up to the task. Your Urbit isn't just
17109−a single instance, it can sign the keys for a whole network of Urbits
17110−intended to be used for your devices, sensors, appliances, machines,
17111−robots, VR helmet, etc.
17112−
17113−The future of the individual's computing experience may very likely be
17114−among many different devices. Bret Victor's 'Seeing Spaces' is a
17115−great exploration of what this future may look like. For the
17116−industrial enterprise there's a whole other set of parallel problems:
17117−tracking inventory, controlling a vast array of machines, and managing
17118−logistics. In both cases we need a decentralized network and
17119−computing platform. Urbit is up to the task.
17120−]]></content:encoded>
17121− </item>
17122− <item>
17123− <title><![CDATA[After hours: Bootstrapping Urbit from the Ethereum blockchain]]></title>
17124− <link>https://urbit.org/events/2017-08-11-after-hours-bootstrapping-urbit-from-the-ethereum-blockchain</link>
17125− <guid>https://urbit.org/events/2017-08-11-after-hours-bootstrapping-urbit-from-the-ethereum-blockchain</guid>
17126− <pubDate>Invalid Date</pubDate>
17127− <content:encoded><![CDATA[
17128−One thing that's been keeping us busy over the past month is designing the relationship between Urbit and the Ethereum blockchain. We'll present our current design for this (from ~8:30 - 9) for people to comment on and ask questions about.
17129−
17130−Otherwise, as usual, there will be plenty of time to hang out and chat with other Urbit people.
17131−
17132−The backyard is really nice in the evening! Feel free to bring friends"
17133−]]></content:encoded>
17134− </item>
17135− <item>
17136− <title><![CDATA[After hours: Fun with %arvo (the Urbit OS)]]></title>
17137− <link>https://urbit.org/events/2017-09-22-after-hours-fun-with-arvo-the-urbit-os</link>
17138− <guid>https://urbit.org/events/2017-09-22-after-hours-fun-with-arvo-the-urbit-os</guid>
17139− <pubDate>Invalid Date</pubDate>
17140− <content:encoded><![CDATA[
17141−Ted, the newest addition to our team, has been working on making changes to %arvo all over the place. He'll give a short talk about some of his adventures in the Urbit OS and how they're going to make Urbit faster and easier to use.
17142−
17143−That, and discussing why Equifax should have never been holding all that customer data in the first place.
17144−
17145−Oh yeah, and we just got a fresh batch of Nock shirts!"
17146−]]></content:encoded>
17147− </item>
17148− <item>
17149− <title><![CDATA[After hours: Designing robust human systems]]></title>
17150− <link>https://urbit.org/events/2017-10-26-after-hours-designing-robust-human-systems</link>
17151− <guid>https://urbit.org/events/2017-10-26-after-hours-designing-robust-human-systems</guid>
17152− <pubDate>Invalid Date</pubDate>
17153− <content:encoded><![CDATA[
17154−Galen is going to give a short (~20m) talk on designing robust human systems. No code, no math, no time in the terminal. This is a completely non-technical talk about design principles. It was originally given at the IDEO Blueprint event a few weeks ago.
17155−
17156−Above all, these meetups are for meeting other people crazy enough to think the internet can be replaced.
17157−
17158−Feel free to bring friends!
17159−]]></content:encoded>
17160− </item>
17161− <item>
17162− <title><![CDATA[After hours: Visiting contributors]]></title>
17163− <link>https://urbit.org/events/2017-11-16-after-hours-visiting-contributors</link>
17164− <guid>https://urbit.org/events/2017-11-16-after-hours-visiting-contributors</guid>
17165− <pubDate>Invalid Date</pubDate>
17166− <content:encoded><![CDATA[
17167−This week we have ~mastyr-morzod, ~littel-ponnys and ~mastyr-harlud visiting the office. They've all been contributing great stuff from afar, so we figured out how to get them all in the same room to hack on Urbit for the week. On Thursday evening they'll talk about what they've been coming up with.
17168−
17169−We'll also spend plenty of time just hanging around and talking about Parity, BCH, and everything else crypto-related. Feel free to bring friends!"
17170−]]></content:encoded>
17171− </item>
17172− <item>
17173− <title><![CDATA[Urbit IRL ~2018.1]]></title>
17174− <link>https://urbit.org/events/2018-01-26-urbit-irl-20181</link>
17175− <guid>https://urbit.org/events/2018-01-26-urbit-irl-20181</guid>
17176− <pubDate>Invalid Date</pubDate>
17177− <content:encoded><![CDATA[
17178−Turns out that just getting Urbit fans in one room is pretty fun — so come join. No demos or talks this time. Just some time to hang, listen to music and meet up IRL. The room is full of desks and the internet is pretty fast. So impromptu demos and tutorials are the norm. Bring your laptop and we'll install Urbit for you.
17179−
17180−Feel free to bring friends!"
17181−]]></content:encoded>
17182− </item>
17183− <item>
17184− <title><![CDATA[Urbit IRL ~2018.2]]></title>
17185− <link>https://urbit.org/events/2018-02-23-urbit-irl-20182</link>
17186− <guid>https://urbit.org/events/2018-02-23-urbit-irl-20182</guid>
17187− <pubDate>Invalid Date</pubDate>
17188− <content:encoded><![CDATA[
17189−No demos or talks. Just some time to hang, listen to music and meet up IRL. The room is full of desks and the internet is pretty fast. So impromptu demos and tutorials are the norm. Bring your laptop and we'll install Urbit for you. Or just relax and talk to people.
17190−
17191−Feel free to bring friends!"
17192−]]></content:encoded>
17193− </item>
17194− <item>
17195− <title><![CDATA[~2018.3 Hoon School]]></title>
17196− <link>https://urbit.org/events/2018-03-11-20183-hoon-school</link>
17197− <guid>https://urbit.org/events/2018-03-11-20183-hoon-school</guid>
17198− <pubDate>Invalid Date</pubDate>
17199− <content:encoded><![CDATA[
17200−There's no lesson per-se, think of it more like an 'independent projects' class. A few of us will be around to help you get started working on whatever you're interested in. It's completely fine if you're new to the language. We're going to start with only 10 spots so we can help everyone individually.
17201−]]></content:encoded>
17202− </item>
17203− <item>
17204− <title><![CDATA[Urbit IRL ~2018.3]]></title>
17205− <link>https://urbit.org/events/2018-03-23-urbit-irl-20183</link>
17206− <guid>https://urbit.org/events/2018-03-23-urbit-irl-20183</guid>
17207− <pubDate>Invalid Date</pubDate>
17208− <content:encoded><![CDATA[
17209−No demos or talks. Just some time to hang, listen to music and meet up IRL. The room is full of desks and the internet is pretty fast. So impromptu demos and tutorials are the norm. Bring your laptop and we'll install Urbit for you. Or just relax and talk to the weird array of people who also want to replace the internet.
17210−
17211−Feel free to bring friends!
17212−]]></content:encoded>
17213− </item>
17214− <item>
17215− <title><![CDATA[~2018.4 Hoon School]]></title>
17216− <link>https://urbit.org/events/2018-04-08-20184-hoon-school</link>
17217− <guid>https://urbit.org/events/2018-04-08-20184-hoon-school</guid>
17218− <pubDate>Invalid Date</pubDate>
17219− <content:encoded><![CDATA[
17220−There's no lesson per-se, think of it more like an 'independent projects' class. A few of us will be around to help you get started working on whatever you're interested in. It's completely fine if you're new to the language. We're going to start with 20 spots so we can help everyone individually.
17221−]]></content:encoded>
17222− </item>
17223− <item>
17224− <title><![CDATA[Urbit IRL ~2018.5]]></title>
17225− <link>https://urbit.org/events/2018-05-25-urbit-irl-20185</link>
17226− <guid>https://urbit.org/events/2018-05-25-urbit-irl-20185</guid>
17227− <pubDate>Invalid Date</pubDate>
17228− <content:encoded><![CDATA[
17229−Ted will give a quick update on Urbit's new build system, ford. Then it's time to hang, listen to music (our friend Grayson will be playing records) and meet up IRL. The room is full of desks and the internet is pretty fast. Impromptu demos and tutorials are the norm. Bring your laptop and we'll install Urbit for you. Or just relax and talk to the weird array of people who also want to replace the internet.
17230−
17231−Feel free to bring friends!
17232−]]></content:encoded>
17233− </item>
17234− <item>
17235− <title><![CDATA[After hours 'decentralized web summit']]></title>
17236− <link>https://urbit.org/events/2018-08-03-after-hours-decentralized-web-summit</link>
17237− <guid>https://urbit.org/events/2018-08-03-after-hours-decentralized-web-summit</guid>
17238− <pubDate>Invalid Date</pubDate>
17239− </item>
17240− <item>
17241− <title><![CDATA[Urbit IRL ~2018.8]]></title>
17242− <link>https://urbit.org/events/2018-08-17-urbit-irl-20188</link>
17243− <guid>https://urbit.org/events/2018-08-17-urbit-irl-20188</guid>
17244− <pubDate>Invalid Date</pubDate>
17245− <content:encoded><![CDATA[
17246−Turns out that just getting Urbit fans in one room is pretty fun — so come hang out and have a beer.
17247−
17248−No demos or talks this time, but we will be hosting Hoon School again soon. Just some time to hang, listen to music and meet up IRL. The room is full of desks and the internet is pretty fast. So impromptu demos and tutorials are the norm. Bring your laptop and we'll install Urbit for you. Or just relax and talk to the weird array of people who also want to replace the internet.
17249−
17250−Feel free to bring friends!
17251−]]></content:encoded>
17252− </item>
17253− <item>
17254− <title><![CDATA[Urbit IRL ~2018.9]]></title>
17255− <link>https://urbit.org/events/2018-09-21-urbit-irl-20189</link>
17256− <guid>https://urbit.org/events/2018-09-21-urbit-irl-20189</guid>
17257− <pubDate>Invalid Date</pubDate>
17258− <content:encoded><![CDATA[
17259−Gavin will give an update on Urbit design at 8:30. Then it's time to hang, listen to music and meet up IRL. The room has tables and the internet is pretty fast. Impromptu demos and tutorials are the norm. Bring your laptop and we'll install Urbit for you. Or just relax and talk to the weird array of people who also want to replace the internet.
17260−
17261−Feel free to bring friends!
17262−]]></content:encoded>
17263− </item>
17264− <item>
17265− <title><![CDATA[Urbit + Zcash: 'Blockchain Week']]></title>
17266− <link>https://urbit.org/events/2018-10-10-urbit-zcash-blockchain-week</link>
17267− <guid>https://urbit.org/events/2018-10-10-urbit-zcash-blockchain-week</guid>
17268− <pubDate>Invalid Date</pubDate>
17269− <content:encoded><![CDATA[
17270−~Schedule
17271−
17272−7 - 8: Come on time for hot pizza!
17273−
17274−8 - 8:30: Alejandro Machado, researcher, advocate, and member of the Zcash community will speak
17275−
17276−8:30 - 9: Galen Wolfe-Pauly will tell you things about Urbit and our wallet
17277−
17278−9 - 10: Hangout
17279−]]></content:encoded>
17280− </item>
17281− <item>
17282− <title><![CDATA[After hours: It's just a party, man]]></title>
17283− <link>https://urbit.org/events/2018-12-20-after-hours-its-just-a-party-man</link>
17284− <guid>https://urbit.org/events/2018-12-20-after-hours-its-just-a-party-man</guid>
17285− <pubDate>Invalid Date</pubDate>
17286− <content:encoded><![CDATA[
17287−Come have a beer, connect with Urbit developers, fans and friends IRL, and ask questions about the address space going on-chain (if you have them).
17288−
17289−Feel free to bring friends!
17290−]]></content:encoded>
17291− </item>
17292− <item>
17293− <title><![CDATA[After hours: Ask Galen Anything]]></title>
17294− <link>https://urbit.org/events/2019-03-01-after-hours-ask-galen-anything</link>
17295− <guid>https://urbit.org/events/2019-03-01-after-hours-ask-galen-anything</guid>
17296− <pubDate>Invalid Date</pubDate>
17297− <content:encoded><![CDATA[
17298−8:00-9:00pm: AMA
17299−
17300−Afterwards, have a beer, connect with Urbit developers, fans, and friends IRL.
17301−
17302−Feel free to bring friends and share the primer. <a href="https://urbit.org/primer" class="linkified">https://urbit.org/primer</a>
17303−]]></content:encoded>
17304− </item>
17305− <item>
17306− <title><![CDATA[Urbit IRL: Austin, TX]]></title>
17307− <link>https://urbit.org/events/2019-03-08-urbit-irl-austin-tx</link>
17308− <guid>https://urbit.org/events/2019-03-08-urbit-irl-austin-tx</guid>
17309− <pubDate>Invalid Date</pubDate>
17310− <content:encoded><![CDATA[
17311−Thank you to our friends over at Garage for hosting us. We'll be there from 5-7 PM.
17312−]]></content:encoded>
17313− </item>
17314− <item>
17315− <title><![CDATA[Urbit IRL ~2019.4]]></title>
17316− <link>https://urbit.org/events/2019-04-19-urbit-irl-20194</link>
17317− <guid>https://urbit.org/events/2019-04-19-urbit-irl-20194</guid>
17318− <pubDate>Invalid Date</pubDate>
17319− <content:encoded><![CDATA[
17320−By popular demand: we'll try to keep this one QUIET so everybody can talk.
17321−
17322−Come for a quick update on what we're working on. Stay to relax and talk to a weird array of people who also want to replace the internet.
17323−
17324−Feel free to bring friends!
17325−]]></content:encoded>
17326− </item>
17327− <item>
17328− <title><![CDATA[Urbit IRL ~2019.5]]></title>
17329− <link>https://urbit.org/events/2019-05-17-urbit-irl-20195</link>
17330− <guid>https://urbit.org/events/2019-05-17-urbit-irl-20195</guid>
17331− <pubDate>Invalid Date</pubDate>
17332− <content:encoded><![CDATA[
17333−This time we'll give a brief update on what we've been up to around 8pm. Turning the music down worked well, so we'll do that again. And if you want help installing Urbit, bring a laptop.
17334−
17335−Feel free to bring friends!
17336−]]></content:encoded>
17337− </item>
17338− <item>
17339− <title><![CDATA[Urbit IRL ~2019.6]]></title>
17340− <link>https://urbit.org/events/2019-06-21-urbit-irl-20196</link>
17341− <guid>https://urbit.org/events/2019-06-21-urbit-irl-20196</guid>
17342− <pubDate>Invalid Date</pubDate>
17343− <content:encoded><![CDATA[
17344−This time we'll give a brief update on what we've been up to around 8pm. Turning the music down worked well, so we'll do that again. And if you want help installing Urbit, bring a laptop.
17345−
17346−Feel free to bring friends!
17347−]]></content:encoded>
17348− </item>
17349− <item>
17350− <title><![CDATA[Urbit IRL ~2019.7]]></title>
17351− <link>https://urbit.org/events/2019-07-19-urbit-irl-20197</link>
17352− <guid>https://urbit.org/events/2019-07-19-urbit-irl-20197</guid>
17353− <pubDate>Invalid Date</pubDate>
17354− <content:encoded><![CDATA[
17355−Turning the music down has worked well, so we'll continue doing that. And if you want help installing Urbit, bring a laptop.
17356−
17357−Feel free to bring friends!
17358−]]></content:encoded>
17359− </item>
17360− <item>
17361− <title><![CDATA[Urbit Austin ~2019.8]]></title>
17362− <link>https://urbit.org/events/2019-08-29-urbit-austin-20198</link>
17363− <guid>https://urbit.org/events/2019-08-29-urbit-austin-20198</guid>
17364− <pubDate>Invalid Date</pubDate>
17365− <content:encoded><![CDATA[
17366−Come have a drink on us, and bring friends! We'll be there 6–8pm.
17367−]]></content:encoded>
17368− </item>
17369− <item>
17370− <title><![CDATA[Urbit IRL ~2019.10]]></title>
17371− <link>https://urbit.org/events/2019-10-04-urbit-irl-201910</link>
17372− <guid>https://urbit.org/events/2019-10-04-urbit-irl-201910</guid>
17373− <pubDate>Invalid Date</pubDate>
17374− <content:encoded><![CDATA[
17375−We're calling it Urbit IRL. You can use it to see your friends face-to-face, converse about Urbit, even to share a beer. And we're trying it out Friday, October 4.
17376−
17377−We hope to see you there! If you want help installing Urbit, bring a laptop. And bring a friend, especially if they are interested in replacing the internet.
17378−]]></content:encoded>
17379− </item>
17380− <item>
17381− <title><![CDATA[Urbit IRL ~2019.11]]></title>
17382− <link>https://urbit.org/events/2019-11-15-urbit-irl-201911</link>
17383− <guid>https://urbit.org/events/2019-11-15-urbit-irl-201911</guid>
17384− <pubDate>Invalid Date</pubDate>
17385− <content:encoded><![CDATA[
17386−We're calling it Urbit IRL. You can use it to see your friends face-to-face, converse about Urbit, even to share a beer. And we're trying it out Friday, November 15.
17387−
17388−We hope to see you there! If you want help installing Urbit, bring a laptop. And bring a friend, especially if they are interested in replacing the internet.
17389−]]></content:encoded>
17390− </item>
17391− <item>
17392− <title><![CDATA[Urbit IRL ~2019.12]]></title>
17393− <link>https://urbit.org/events/2019-12-13-urbit-irl-201912</link>
17394− <guid>https://urbit.org/events/2019-12-13-urbit-irl-201912</guid>
17395− <pubDate>Invalid Date</pubDate>
17396− <content:encoded><![CDATA[
17397−We're getting together to savor the moment and get hype about what the next decade holds (the whole replacing the internet thing).
17398−
17399−We hope to see you there!
17400−
17401−Things to bring:
17402−
17403−-A friend
17404−
17405−-A laptop, if you want help installing Urbit
17406−
17407−-Good cheer
17408−]]></content:encoded>
17409− </item>
17410− <item>
17411− <title><![CDATA[Urbit IRL ~2020.1]]></title>
17412− <link>https://urbit.org/events/2020-01-24-urbit-irl-20201</link>
17413− <guid>https://urbit.org/events/2020-01-24-urbit-irl-20201</guid>
17414− <pubDate>Invalid Date</pubDate>
17415− <content:encoded><![CDATA[
17416−It's 2020 and Urbit is accelerating. We've got a lot going live this year.
17417−
17418−Replacing the internet is a thing to behold. Come by the offices to hang out, have a drink, and hear the latest.
17419−
17420−Bring a laptop if you want help installing Urbit.
17421−
17422−And as always, bring a friend!
17423−]]></content:encoded>
17424− </item>
17425− <item>
17426− <title><![CDATA[Urbit IRL ~2020.2]]></title>
17427− <link>https://urbit.org/events/2020-02-28-urbit-irl-20202</link>
17428− <guid>https://urbit.org/events/2020-02-28-urbit-irl-20202</guid>
17429− <pubDate>Invalid Date</pubDate>
17430− <content:encoded><![CDATA[
17431−Before we go headlong into that unknown region, we're gonna have a party at basecamp (aka the office). Come hang out and have a drink with your fellow Urbit explorers.
17432−
17433−Bring your laptop if you want to install Urbit.
17434−
17435−And as always, drag a friend!
17436−]]></content:encoded>
17437− </item>
17438− <item>
17439− <title><![CDATA[Urbit OS1 Launch Party]]></title>
17440− <link>https://urbit.org/events/2020-04-03-urbit-os1-launch-party</link>
17441− <guid>https://urbit.org/events/2020-04-03-urbit-os1-launch-party</guid>
17442− <pubDate>Invalid Date</pubDate>
17443− <content:encoded><.
17449−
17450−To receive the event merch, RSVP on this event page by midnight!
17451−
17452−Ready to launch OS1? Check out our install guide:
17453−
17454−[https://urbit.org/using/install/](https://urbit.org/using/install/)
17455−
17456−Want address space for your friends? Apply for an Urbit Community Grant:
17457−
17458−[https://urbit.org/community/community-grants/](https://urbit.org/community/community-grants/)
17459−
17460−Interested in contributing to Urbit? Sign up for Hoon School:
17461−
17462−[https://urbit.org/community/hoonschool/](https://urbit.org/community/hoonschool/)
17463−
17464−Get the latest on Urbit:
17465−
17466−Blog: <a href="https://urbit.org/blog/" class="linkified">https://urbit.org/blog/</a>
17467−
17468−Urbit Twitter: <a href="https://twitter.com/urbit" class="linkified">https://twitter.com/urbit</a>
17469−
17470−Urbit Github: <a href="https://github.com/urbit" class="linkified">https://github.com/urbit</a>
17471−
17472−Still confused about what Urbit is?
17473−
17474−<a href="https://urbit.org/understanding-urbit/" class="linkified">https://urbit.org/understanding-urbit/</a>
17475−]]></content:encoded>
17476− </item>
17477− <item>
17478− <title><![CDATA[Urbit Hosting Launch Event]]></title>
17479− <link>https://urbit.org/events/2020-10-09-urbit-hosting-launch-event</link>
17480− <guid>https://urbit.org/events/2020-10-09-urbit-hosting-launch-event</guid>
17481− <pubDate>Invalid Date</pubDate>
17482− <content:encoded><![CDATA[
17483−We've been busy building, testing and refining — and now it's time to show off what we've been up to.
17484−
17485−We're going to do a live demo of Tlon's Urbit hosting solution, check out some of the new features of Landscape and generally catch up on what both we (at Tlon) and the community have been up to.
17486−
17487−Since the OS 1 launch, back in April, we've been living on Urbit day to day. Urbit has gotten gotten a lot faster, more reliable and nicer to use. Most importantly, we've got an easy way for friends to come join us without running their own node. We're really excited to let people explore what's possible with Urbit and build communities without ever touching the command-line.
17488−
17489−Join the waitlist for hosting here: <a href="https://tlon.io/" class="linkified">https://tlon.io/</a>
17490−
17491−---
17492−
17493−Got a group of friends who want to use Urbit together? We periodically give away blocks of planets and help people get set up. Apply for a community grant:<br/><a href="https://urbit.org/community/community-grants/" class="linkified">https://urbit.org/community/community-grants/</a>
17494−
17495−Interested developing on Urbit? Hoon School is a community-run program to teach you the basics of the language and system. Sign up here:<br/><a href="https://hooniversity.org" class="linkified">https://hooniversity.org</a>
17496−
17497−Mostly, you can find us on Urbit in the Urbit Community group. But you can also follow along here:<br/><a href="https://urbit.org/blog/" class="linkified">https://urbit.org/blog/</a><br/><a href="https://twitter.com/urbit" class="linkified">https://twitter.com/urbit</a><br/><a href="https://github.com/urbit" class="linkified">https://github.com/urbit</a>
17498−
17499−And if you're still confused about what Urbit is, try these:<br/><a href="https://urbit.org/understanding-urbit/" class="linkified">https://urbit.org/understanding-urbit/</a>
17500−]]></content:encoded>
17501− </item>
17502− <item>
17503− <title><![CDATA[Developer Call: Graph Store]]></title>
17504− <link>https://urbit.org/events/2020-11-05-developer-call-graph-store</link>
17505− <guid>https://urbit.org/events/2020-11-05-developer-call-graph-store</guid>
17506− <pubDate>Invalid Date</pubDate>
17507− <content:encoded><![CDATA[
17508−Developer calls are focused on the technologies that underpin Urbit, from the top of the stack to the very bottom. They’re an opportunity for the people developing and contributing to Urbit to share their knowledge and expertise, including things that typically don’t make it into the docs, such as how and why Urbit works the way it does.
17509−
17510−This call will feature a discussion by Tlon engineer Logan Allen about graph-store, the general-purpose store that is gradually replacing the bespoke stores behind Chat, Publish and Links.
17511−
17512−You can join the event by clicking the gotowebinar.com link posted here. Details for joining the conversation were also emailed to all registered attendees, and will be sent again shortly before the event starts. Please check your email inbox for a message from Meetup.com.
17513−]]></content:encoded>
17514− </item>
17515− <item>
17516− <title><![CDATA[Developer Call: BitTorrent tracking on Urbit]]></title>
17517− <link>https://urbit.org/events/2020-11-19-developer-call-bittorrent-tracking-on-urbit</link>
17518− <guid>https://urbit.org/events/2020-11-19-developer-call-bittorrent-tracking-on-urbit</guid>
17519− <pubDate>Invalid Date</pubDate>
17520− <content:encoded><![CDATA[
17521−This call will feature a discussion by Tlon engineer Mark Staarink, also known as ~palfun-foslup, about writing an HTTP BitTorrent tracker and command line app in 1500 lines of code.
17522−
17523−The livestream will be held on YouTube, and a group video call will be made available via Google Meet after the talk for casual discussion and in-person conversation.
17524−]]></content:encoded>
17525− </item>
17526− <item>
17527− <title><![CDATA[Developer Call: Injecting External Services into Urbit]]></title>
17528− <link>https://urbit.org/events/2020-12-10-developer-call-injecting-external-services-into-urbit</link>
17529− <guid>https://urbit.org/events/2020-12-10-developer-call-injecting-external-services-into-urbit</guid>
17530− <pubDate>Invalid Date</pubDate>
17531− <content:encoded><![CDATA[
17532−This call will feature a discussion by well-known developer in the Urbit community, ~timluc-miptev. ~timluc will be discussing the work he's been doing to provide access to a Bitcoin full node, which will enable Urbit ships to make Bitcoin payments to other ships. More generally, he'll be discussing the patterns that he's using to manage an Urbit ship's connection to externally-running infrastructure, and how access to that infrastructure can be provided to other Urbit nodes.
17533−
17534−Developer calls are focused on the technologies that underpin Urbit, from the top of the stack to the very bottom. They’re an opportunity for the people developing and contributing to Urbit to share their knowledge and expertise, including things that typically don’t make it into the docs, such as how and why Urbit works the way it does.
17535−
17536−The livestream will be held on YouTube, and a group video call will be made available via Google Meet after the talk for casual discussion and in-person conversation."
17537−+++
17538−]]></content:encoded>
17539− </item>
17540− <item>
17541− <title><![CDATA[Developer Call: Architectural Idea Maze]]></title>
17542− <link>https://urbit.org/events/2021-02-04-developer-call-architectural-idea-maze</link>
17543− <guid>https://urbit.org/events/2021-02-04-developer-call-architectural-idea-maze</guid>
17544− <pubDate>Invalid Date</pubDate>
17545− <content:encoded><![CDATA[
17546−Tlon Engineer Philip Monk is interviewed by Poprox in an "Architectural Idea Maze" discussion, where Phil will discuss the choices made, and possibly more importantly, the choices _not_ made in the design of a component of Urbit. In this discussion, Phil will be focusing on subscriptions in all their forms throughout Urbit.
17547−
17548−Developer calls are focused on the technologies that underpin Urbit, from the top of the stack to the very bottom. They’re an opportunity for the people developing and contributing to Urbit to share their knowledge and expertise, including things that typically don’t make it into the docs, such as how and why Urbit works the way it does.
17549−
17550−The livestream will be held on YouTube, and a group video call will be made available via Google Meet after the talk for casual discussion and in-person conversation.
17551−]]></content:encoded>
17552− </item>
17553− <item>
17554− <title><![CDATA[Developer Call: Scaling Azimuth]]></title>
17555− <link>https://urbit.org/events/2021-03-04-developer-call-scaling-azimuth</link>
17556− <guid>https://urbit.org/events/2021-03-04-developer-call-scaling-azimuth</guid>
17557− <pubDate>Invalid Date</pubDate>
17558− <content:encoded><![CDATA[
17559−Urbit engineer Philip Monk will be discussing the solution space to scaling Azimuth, the infrastructure for Urbit ID that's built on Ethereum.
17560−
17561−Unless you're living under a rock, you know that Ethereum is thoroughly congested and, as a result the cost of working with it is quite high. Most pertinently for Urbit, this means that the cost of bringing new planets onto the network is unacceptably high.
17562−
17563−Phil has been doing a ton of research for the past few months on different approaches to scaling Azimuth. In this talk, he'll lay out the what's been explored so far, the relevant considerations for Urbit, and the emerging solutions that are being pursued.
17564−
17565−As usual, this talk will feature a presentation, a Q&A period and a follow-up video call that anyone from the audience can join.
17566−
17567−See you there!
17568−]]></content:encoded>
17569− </item>
17570− <item>
17571− <title><![CDATA[Developer Call: Pressure and Protolith]]></title>
17572− <link>https://urbit.org/events/2021-03-18-developer-call-pressure-and-protolith</link>
17573− <guid>https://urbit.org/events/2021-03-18-developer-call-pressure-and-protolith</guid>
17574− <pubDate>Invalid Date</pubDate>
17575− <content:encoded><![CDATA[
17576−Landscape was an experiment. Now it’s Tlon's flagship client for the Urbit project: a product, a full-stack application, spread across a variety of Gall agents and libraries, lighting the way forward against the dwindling unknowns in the reality of Urbit userspace development and distribution.
17577−
17578−Matilde Park, Landscape team lead, talks about the distinctions between the Landscape product and basic Urbit development, and the significance of building Landscape for Tlon — the role of “high-pressure experiments” in forcing our computer toward something rock-hard, diamond-perfect. With a few examples of ongoing deployments, she also outlines the problems being solved right now and the ones still a touch further out.
17579−
17580−As usual, join us after the talk on the call to ask questions and hang out.
17581−]]></content:encoded>
17582− </item>
17583− <item>
17584− <title><![CDATA[Developer Call: JavaScript Apps on Urbit]]></title>
17585− <link>https://urbit.org/events/2021-04-01-developer-call-javascript-apps-on-urbit</link>
17586− <guid>https://urbit.org/events/2021-04-01-developer-call-javascript-apps-on-urbit</guid>
17587− <pubDate>Invalid Date</pubDate>
17588− <content:encoded><![CDATA[
17589−Urbit provides a powerful and extensible platform for all kinds of app development. It can serve as a general-purpose datastore, decentralized network, and identity solution for a variety of front-end applications. The client that ships with Urbit, Landscape, provides one example of the kind of applications that can be built on the platform. However, other developers can use the same tools used to create Landscape to power their own interfaces and clients for Urbit.
17590−
17591−Tyler Brown Cifu Shuster (~radbur-sivmus) has worked with the Landscape team over the past few months to extract these tools into reusable Javascript packages. In this talk, he will explain how to use them to develop a client for Urbit independent of Landscape. He will cover the basic lifecycle of a client and explain how Javascript interface and state frameworks pair with Urbit's data model.
17592−
17593−This talk should enable anyone familiar with modern Javascript development and HTTP grammar to build an application on top of Urbit without writing any back-end code
17594−]]></content:encoded>
17595− </item>
17596− <item>
17597− <title><![CDATA[Developer Call: 3rd Party Software Distribution]]></title>
17598− <link>https://urbit.org/events/2021-04-15-developer-call-software-distribution</link>
17599− <guid>https://urbit.org/events/2021-04-15-developer-call-software-distribution</guid>
17600− <pubDate>Invalid Date</pubDate>
17601− <content:encoded><
17611−- [ucal](https://github.com/taalhavras/ucal)
17612−]]></content:encoded>
17613− </item>
17614− <item>
17615− <title><![CDATA[Bitcoin Launch]]></title>
17616− <link>https://urbit.org/events/2021-04-27-bitcoin-launch</link>
17617− <guid>https://urbit.org/events/2021-04-27-bitcoin-launch</guid>
17618− <pubDate>Invalid Date</pubDate>
17619− <content:encoded><
17627−]]></content:encoded>
17628− </item>
17629− <item>
17630− <title><![CDATA[Developer Call: Real-Time Communication on Urbit]]></title>
17631− <link>https://urbit.org/events/2021-04-29-developer-call-real-time-communications-on-urbit</link>
17632− <guid>https://urbit.org/events/2021-04-29-developer-call-real-time-communications-on-urbit</guid>
17633− <pubDate>Invalid Date</pubDate>
17634− <content:encoded><
17644−- Check out WebRTC progress reports on `~ritpub-sipsyl/webrtc-on-urbit`
17645−]]></content:encoded>
17646− </item>
17647− <item>
17648− <title><![CDATA[Developer Call: P2P Versioned Networking]]></title>
17649− <link>https://urbit.org/events/2021-05-13-developer-call-versioned-networking</link>
17650− <guid>https://urbit.org/events/2021-05-13-developer-call-versioned-networking</guid>
17651− <pubDate>Invalid Date</pubDate>
17652− <content:encoded><![CDATA[
17653−Building solid networking infrastructure has been a major focus of the Urbit project since its inception. There's a lot going on under the hood
17654−that ensures our servers reliably stay connected. Liam Fitzgerald (~hastuc-dibtux) will be explaining how Urbit is able to deploy changes without breaking the network. Anyone designing userspace applications will be interested in the approach he has designed.
17655−
17656−Liam is an Interface Engineer working at Tlon working on the Landscape team. He will be discussing networking userspace applications in depth and going into detail about the new versioning system.
17657−
17658−As usual, there will be an opportunity to jump on the call with us afterward to ask questions and hang out.
17659−]]></content:encoded>
17660− </item>
17661− <item>
17662− <title><![CDATA[Town Hall]]></title>
17663− <link>https://urbit.org/events/2021-05-27-town-hall</link>
17664− <guid>https://urbit.org/events/2021-05-27-town-hall</guid>
17665− <pubDate>Invalid Date</pubDate>
17666− <content:encoded><. You can see the full list of [proposed talks here](https://airtable.com/shreGQ4kCU8RA5GJS/tblTZxCpqedJBwSkE), and if you'd like to voice your support for any of these specifically, [cast a vote using this form](https://airtable.com/shrhNRUAGCqZ38VXA).
17696−]]></content:encoded>
17697− </item>
17698− <item>
17699− <title><![CDATA[Developer Call: The Urbit Runtime and its Future]]></title>
17700− <link>https://urbit.org/events/2021-07-01-developer-call-runtime-future</link>
17701− <guid>https://urbit.org/events/2021-07-01-developer-call-runtime-future</guid>
17702− <pubDate>Invalid Date</pubDate>
17703− <content:encoded><![CDATA[
17704−Please join us for a look behind the curtain at the Urbit Runtime. Host Ted Blackman (~rovnys-ricfer) will be interviewing Joe Bryan (~master-morzod). Topics will include event log truncation, plans for storing more than 2GB, multithreading implementation, and much more.
17705−
17706−Ted Blackman (~rovnys-ricfer) has worked on Urbit since 2017, mostly on the kernel, with forays into the runtime and userspace. Before Urbit, he worked in sensor fusion, robotics, web development, distributed systems, and data engineering. He has a degree in physics from MIT.
17707−
17708−As always, join us for happy hour after the talk.
17709−]]></content:encoded>
17710− </item>
17711− <item>
17712− <title><![CDATA[Developer Call: Urbit Yakshaving]]></title>
17713− <link>https://urbit.org/events/2021-07-15-developer-call-yakshaving</link>
17714− <guid>https://urbit.org/events/2021-07-15-developer-call-yakshaving</guid>
17715− <pubDate>Invalid Date</pubDate>
17716− <content:encoded><![CDATA[
17717−This week Jake Miller (~littel-wolfer) will be giving us a look at his development process, walking through his "urbit-emacs" setup and how he uses org-mode and tmux for hoon development. He'll also be giving us a quick demo of his work-in-progress Roam importer.
17718−
17719−Jake considers himself a recovering Fintech engineer currently working at Tlon. He is interested in building learning systems and tools in Urbit.
17720−
17721−Please join us for Happy Hour after the talk to ensure all your burning yakshaving questions get answered.
17722−]]></content:encoded>
17723− </item>
17724− <item>
17725− <title><![CDATA[Urbit DC Meetup Q3 2021]]></title>
17726− <link>https://urbit.org/events/2021-09-02-21q3-dc-meetup</link>
17727− <guid>https://urbit.org/events/2021-09-02-21q3-dc-meetup</guid>
17728− <pubDate>Invalid Date</pubDate>
17729− <content:encoded><
17735−]]></content:encoded>
17736− </item>
17737− <item>
17738− <title><![CDATA[Developer Call: Azimuth, Scaled]]></title>
17739− <link>https://urbit.org/events/2021-09-16-developer-call-azimuth-scaled</link>
17740− <guid>https://urbit.org/events/2021-09-16-developer-call-azimuth-scaled</guid>
17741− <pubDate>Invalid Date</pubDate>
17742− <content:encoded>< of the naive rollup code ahead of time so you can ask questions.
17746−]]></content:encoded>
17747− </item>
17748− <item>
17749− <title><![CDATA[Urbit Outside]]></title>
17750− <link>https://urbit.org/events/2021-09-24-urbit-outside</link>
17751− <guid>https://urbit.org/events/2021-09-24-urbit-outside</guid>
17752− <pubDate>Invalid Date</pubDate>
17753− <content:encoded><
17755−
17756−For our second post-Covid Urbit IRL, we're heading to the East Bay!
17757−
17758−Please join us at Sibley Preserve for a hangout and (optional) hike.
17759−
17760−We'll meet at the Sibley Staging Area at 3:00PM, and leave for a casual walk to the caldera and labyrinth at 4:00PM.
17761−
17762−Hiking shoes, snacks, water, and picnic blankets/chairs are encouraged! There are restrooms and water at the Staging Area.
17763−
17764−Please join the channel 'Urbit Outside ~[masked]' in ~bitbet-bolbel/urbit-community to get in touch with the gang.
17765−]]></content:encoded>
17766− </item>
17767− <item>
17768− <title><![CDATA[Developer Call: Urbit Visor - Transforming the Web Browser Into an Urbit Client]]></title>
17769− <link>https://urbit.org/events/2021-10-07-developer-call-visor</link>
17770− <guid>https://urbit.org/events/2021-10-07-developer-call-visor</guid>
17771− <pubDate>Invalid Date</pubDate>
17772− <content:encoded><![CDATA[
17773−Please join us for a deep dive into Urbit Visor, a brand new web extension which transforms your browser into a first class Urbit client. Robert Kornacki from dcSpark will be taking viewers step-by-step through the history of how Urbit Visor came to be, starting off with his initial work on the Rust airlock implementation, moving into Login With Urbit, and finally arriving at the final product of Urbit Visor that we have today.
17774−
17775−From there Robert will hit on many topics including:
17776−
17777−- Live demonstration of how Urbit Visor works
17778−- How Urbit Visor improves and increases the security of the Landscape login experience
17779−- An overview of the first Urbit Web App: Urbit Dashboard
17780−- Ship hot-swapping
17781−- Streamlining the developer experience for any JS/TS dev to jump into the ecosystem and start building immediately
17782−- UV Extensions and how they will allow Urbit and the current web to integrate seamlessly
17783−- The long term goals and vision of Urbit Visor
17784−
17785−Robert Kornacki (~mocrux-nomdep) is CSO at dcSpark and has been in the Urbit ecosystem since 2019. Robert has significant experience working in the crypto industry over the past several years, developing tooling and smart contract protocols which hold millions of dollars of assets to this day.
17786−
17787−Hosted by Josh Lehman, the Director of the Urbit Foundation.
17788−]]></content:encoded>
17789− </item>
17790− <item>
17791− <title><![CDATA[Assembly]]></title>
17792− <link>https://urbit.org/events/2021-10-15-assembly</link>
17793− <guid>https://urbit.org/events/2021-10-15-assembly</guid>
17794− <pubDate>Invalid Date</pubDate>
17795− <content:encoded><
17797−
17798−Assembly 2021 marks a pivotal moment in Urbit: software distribution. Yes, Urbit is ready to be built upon. We’ll spend three days together doing just that.
17799−
17800−- Learn about building applications on Urbit (it’s easy).
17801−- Find out how to work and create on a platform that is fully owned by you.
17802−- Meet with the growing ecosystem of communities and businesses built on Urbit.
17803−
17804−If you’re simply into calm computing, well, there will be plenty of that too.
17805−
17806−You’ll choose between two tracks:
17807−
17808−- Assembly: Assemble software or work together on projects in small groups
17809−- Workshop: A two day workshop taught by Neal Davis, Urbit for Developers
17810−]]></content:encoded>
17811− </item>
17812− <item>
17813− <title><![CDATA[Assembly Keynote Live Stream]]></title>
17814− <link>https://urbit.org/events/2021-10-16-assembly-keynote</link>
17815− <guid>https://urbit.org/events/2021-10-16-assembly-keynote</guid>
17816− <pubDate>Invalid Date</pubDate>
17817− <content:encoded><![CDATA[
17818−Join us for the Assembly 2021 introduction, keynote and demos on Saturday, October 16th. You'll hear from Galen Wolfe-Pauly, Josh Lehman, Edouard Urcades, Jake Miller and Ted Blackman for five separate talks spanning roughly two hours.
17819−]]></content:encoded>
17820− </item>
17821− <item>
17822− <title><![CDATA[Assembly Software Distribution Q&A Live Stream]]></title>
17823− <link>https://urbit.org/events/2021-10-16-assembly-sw-dist-qa</link>
17824− <guid>https://urbit.org/events/2021-10-16-assembly-sw-dist-qa</guid>
17825− <pubDate>Invalid Date</pubDate>
17826− <content:encoded><![CDATA[
17827−We wish we could get everyone together at once for Assembly, but travel still isn't as easy as we wish it was. For those that can't make it to Assembly, join Urbit Foundation Director and Tlon CPO Josh Lehman for an online-only AMA about Urbit's new software distribution capabilities.
17828−]]></content:encoded>
17829− </item>
17830− <item>
17831− <title><![CDATA[Developer Call: Running a Hosting Provider]]></title>
17832− <link>https://urbit.org/events/2021-10-28-developer-call-hosting</link>
17833− <guid>https://urbit.org/events/2021-10-28-developer-call-hosting</guid>
17834− <pubDate>Invalid Date</pubDate>
17835− <content:encoded><![CDATA[
17836−As many of you know, Urbit runs best when hosted, seeing that it's a server and all. The problem of course is that hosting an Urbit ship isn't the easiest of things to do for most people. Hosting Urbit ships in production is actually pretty tough though—doing it right requires wrangling the complexity of traditional "Earth" infrastructure in addition to a strong sense of how Urbit works.
17837−
17838−In this call we're joined by Brendan Hay, the lead behind Tlon Hosting, and Lukas Bühler of UrbitHost, in what's sure to be an entertaining and informative conversation. Bren and Lukas have both been the masterminds behind their respective hosting architectures, and were somewhat surprised to learn that they'd independently settled on highly similar architectures.
17839−
17840−This will be an unscripted conversation that's sure to span a gamut of topics including, but not limited to: the unique technical challenges of hosting Urbit ships, the upcoming %khan vane, Kubernetes operators, product roadmaps, custodianship of (or plans to do away with) private keys, and probably a ton more.
17841−
17842−Hosted by Josh Lehman, the Director of the Urbit Foundation.
17843−]]></content:encoded>
17844− </item>
17845− <item>
17846− <title><![CDATA[Meetup: Brisbane Australia]]></title>
17847− <link>https://urbit.org/events/2021-11-26-meetup-brisbane</link>
17848− <guid>https://urbit.org/events/2021-11-26-meetup-brisbane</guid>
17849− <pubDate>Invalid Date</pubDate>
17850− <content:encoded><![CDATA[
17851−What is the Urbit??
17852−
17853−Philosophers, mathematicians and other timewasters have pondered this tough question for aeons. Many went mad, others grew long beards or even buried themselves alive, thinking the riddle unsolvable. So did we... until now.
17854−
17855−Urbit Brisbane are proud to announce that we finally have found an answer: yes, we have figured out what is the Urbit!!
17856−
17857−We'd like to share this important knowledge with you, so join us among the fair hills of St Lucia this Friday night. The Secret Venue will be announced on Friday arvo. RSVP and stay tuned to the event page so you don't end up walking around Guyatt Park accosting joggers for clues.
17858−
17859−Come along and learn about the Urbit with us. You will gain access to an eldritch power far beyond the frail grasp of worldly things. If that isn't enough to tempt you, we also have beers and pizza with your name on them.\*
17860−
17861−\*If your name is Asahi or Godfather Supreme.
17862−]]></content:encoded>
17863− </item>
17864− <item>
17865− <title><![CDATA[Meetup: Austin]]></title>
17866− <link>https://urbit.org/events/2022-01-21-meetup-austin</link>
17867− <guid>https://urbit.org/events/2022-01-21-meetup-austin</guid>
17868− <pubDate>Invalid Date</pubDate>
17869− <content:encoded><![CDATA[
17870−Austin, Texas martians - come hangout and talk Urbit Friday, January 21st at 6:30 pm at Distribution Hall. We will be joined by ~poldec-tonteg, the director of The Combine (the-combine.org), which is the Urbit Foundation's incubator that invests in teams building on Urbit. He will give a presentation around 8pm on The Combine, its purpose and how to get involved as an entrepreneur. It will be followed by a more technical presentation by Edward Amsden (~ritpub-sipsyl), an Urbit kernel developer who is currently rewriting Vere, the Nock run-time environment and Urbit's virtual machine. Team members from many Urbit companies will be in attendance including ~Tirrel, dcSpark, Tlon.io, Urbit Live, Wexpert Systems, Native Planet, and Holium. Hosted by Assembly Capital and the Urbit Foundation.
17871−
17872−If you haven't joined the network yet, bring a computer and we will help you get set up. Other than that we'll have some food, beverages and a fire, but be sure to bring a jacket too. See you there!
17873−]]></content:encoded>
17874− </item>
17875− <item>
17876− <title><![CDATA[Developer Call: Building the Next Developers on Mars]]></title>
17877− <link>https://urbit.org/events/2022-02-17-developer-call-building-developers</link>
17878− <guid>https://urbit.org/events/2022-02-17-developer-call-building-developers</guid>
17879− <pubDate>Invalid Date</pubDate>
17880− <content:encoded><.
17886−]]></content:encoded>
17887− </item>
17888− </channel>
17889−</rss>