@@ -4,7 +4,7 @@
44 <title>Urbit</title>
55 <link>https://urbit.org</link>
66 <description>Urbit is a personal server built from scratch</description>
7− <lastBuildDate>Fri, 15 Oct 2021 01:21:23 GMT</lastBuildDate>
7+ <lastBuildDate>Thu, 18 Nov 2021 19:21:20 GMT</lastBuildDate>
88 <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
99 <generator>https://github.com/jpmonette/feed</generator>
1010 <language>en</language>
@@ -966,209 +966,6 @@ post on the `urbit-dev` mailing list. Lastly, the primary working branch on
966966Github for the Urbit side of naive rollups is
967967[here](https://github.com/urbit/urbit/tree/philip/naive), though it is not the
968968only place code is accumulating.
969−]]></content:encoded>
970− </item>
971− <item>
972− <title><![CDATA[A brief update from urbit.org]]></title>
973− <link>https://urbit.org/updates/2021-05-05-update</link>
974− <guid>https://urbit.org/updates/2021-05-05-update</guid>
975− <pubDate>Tue, 04 May 2021 00:00:00 GMT</pubDate>
976− <content:encoded><![CDATA[
977−Hello!
978−
979−Welcome to the May edition of the urbit.org newsletter. April was a busy month with many updates to share—let’s dig in.
980−
981−0 – Updated Urbit Binaries
982−
983−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
984−
985−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.”
986−
987−1 – Upcoming Events
988−
989−Urbit Town Hall @ May 20th 12pm PDT – Keynote from Justin Murphy
990−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).
991−
992−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.
993−
994−Developer Calls @ May 13th and May 27th
995−As you probably know, we have developer calls every two weeks. Stay tuned for more information on our events page: https://urbit.org/events
996−
997−Austin Urbit Conference @ September/October 2021
998−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!
999−
1000−2 – April Developer Calls
1001−
1002−Developer Call: 3rd Party Software Distribution
1003−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
1004−
1005−Developer Call: Real-Time Communication on Urbit
1006−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!
1007−
1008−3 – Urbit Bitcoin Launch
1009−
1010−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
1011−
1012−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
1013−
1014−4 – Blog
1015−
1016−We have a couple of new posts to announce:
1017−“Lunar Urbit and the Internet of Things”
1018−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/
1019−
1020−“Community Spotlight: The Portico”
1021−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
1022−
1023−5 – Odds and Ends
1024−
1025−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.
1026−
1027−~hodzod-walrus made a page with statistics on various stars: https://bacrys.org/uptime/
1028−
1029−~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.
1030−
1031−Thanks for reading. Talk to you next month!
1032−
1033−Josh (~wolref-podlex) and ~tirwyd-sarmes
1034−
1035−https://twitter.com/urbit
1036−https://github.com/urbit/urbit
1037−]]></content:encoded>
1038− </item>
1039− <item>
1040− <title><![CDATA[Community Spotlight: The Portico]]></title>
1041− <link>https://urbit.org/blog/community-spotlight-the-portico</link>
1042− <guid>https://urbit.org/blog/community-spotlight-the-portico</guid>
1043− <pubDate>Mon, 03 May 2021 00:00:00 GMT</pubDate>
1044− <content:encoded><
1046−
1047−_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._
1048−
1049−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.
1050−
1051−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.
1052−
1053−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.
1054−
1055−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.
1056−
1057−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.
1058−
1059−I encourage you to take a look. Find The Portico at ~topnup-firber/the-portico.
1060−
1061−\-\-\-\-
1062−
1063−**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.**
1064−
1065−It’s tough to say with certainty—I’ve never read _The Benedict Option_.
1066−
1067−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.
1068−
1069−[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.
1070−
1071−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)?
1072−
1073−I don’t claim to know the answers to these questions.
1074−
1075−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.
1076−
1077−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?
1078−
1079−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.
1080−
1081−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?
1082−
1083−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!
1084−
1085−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.
1086−
1087−**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?**
1088−
1089−I feel obligated to answer this question in two ways.
1090−
1091−(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.
1092−
1093−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.
1094−
1095−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.
1096−
1097−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.
1098−
1099−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.
1100−
1101−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.
1102−
1103−For more on this topic, see the blog post in my Urbit group: “St. Gregory the Theologian and the Liar Paradox”.
1104−
1105−(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?
1106−
1107−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.
1108−
1109−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.
1110−
1111−Instead, the proper response is to develop a superior account of rationality. Readers can probably guess where I went looking!
1112−
1113−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.
1114−
1115−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.
1116−
1117−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.
1118−
1119−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)>).
1120−
1121−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.
1122−
1123−Sadly we are conceived in sin and ignorant; hence the need for redemption by Christ.
1124−
1125−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.
1126−
1127−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.
1128−
1129−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.
1130−
1131−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.
1132−
1133−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.
1134−
1135−**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?**
1136−
1137−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.
1138−
1139−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.
1140−
1141−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.
1142−
1143−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.
1144−
1145−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.
1146−
1147−**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?**
1148−
1149−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.
1150−
1151−Social media companies in the US confront similar governance challenges, so we can analyze them in similar terms.
1152−
1153−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.
1154−
1155−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:
1156−
1157−(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.
1158−
1159−(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.
1160−
1161−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.
1162−
1163−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.
1164−
1165−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.
1166−
1167−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.
1168−
1169−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.
1170−
1171−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.
1172969]]></content:encoded>
1173970 </item>
1174971 <item>
@@ -1655,1231 +1452,1716 @@ After honing our commercial tools on these use-cases, we’ll sail into a blue o
16551452]]></content:encoded>
16561453 </item>
16571454 <item>
1658− <title><![CDATA[A brief update from urbit.org and Tlon]]></title>
1659− <link>https://urbit.org/updates/2021-04-01-update</link>
1660− <guid>https://urbit.org/updates/2021-04-01-update</guid>
1661− <pubDate>Wed, 31 Mar 2021 00:00:00 GMT</pubDate>
1455+ <title><![CDATA[After the Machine War]]></title>
1456+ <link>https://urbit.org/blog/after-machine-war</link>
1457+ <guid>https://urbit.org/blog/after-machine-war</guid>
1458+ <pubDate>Sun, 14 Mar 2021 00:00:00 GMT</pubDate>
16621459 <content:encoded><
16661463
1667−1 - Events
1464+<br>
16681465
1669−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:
1466+> 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.
1467+>
1468+> Really the only notable thing about it is that it was written on Urbit. And that, perhaps, has made all the difference.
1469+>
1470+> 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.
1471+>
1472+> 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.
1473+>
1474+> 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.
16701475
1671−4/1: Tyler Shuster (~radbur-sivmus) discussed Javascript apps on Urbit: https://www.meetup.com/urbit-sf/events/277261928/
1476+<br>
16721477
1673−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.
1478+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.
16741479
1675−4/29: Edward Amsden (~ritpub-sipsyl) will be discussing and demoing his WebRTC work, which enables audio/video calls on Urbit.
1480+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?
16761481
1677−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/
1482+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.
16781483
1679−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.
1484+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.
16801485
1681−2 - Content
1486+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.
16821487
1683−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:
1488+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.
16841489
1685−~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
1490+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.
16861491
1687−~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
1492+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.
16881493
1689−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
1494+2050 turned out to be a pretty good year after all.
1495+]]></content:encoded>
1496+ </item>
1497+ <item>
1498+ <title><![CDATA[2020 -> 2021]]></title>
1499+ <link>https://urbit.org/blog/2020-to-2021</link>
1500+ <guid>https://urbit.org/blog/2020-to-2021</guid>
1501+ <pubDate>Wed, 20 Jan 2021 00:00:00 GMT</pubDate>
1502+ <content:encoded><
17071506
1708−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!
1507+<br>
17091508
1710−5 - Hosting
1509+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.
17111510
1712−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/
1511+## 2020
17131512
1714−6 - Team news
1513+In spite of the many challenges presented over the last year, it was a resoundingly good one for Urbit.
17151514
1716−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).
1515+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.
17171516
1718−If you’re interested in working with Tlon or urbit.org, feel free to get in touch.
1517+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.
17191518
1720−7 - Culture recs
1519+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.
17211520
1722−Finally, we’re going to leave you with some recommendations from the team:
1521+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.
17231522
1724−~fabled-faster released an insane new mix that melted my face in a good way: https://soundcloud.com/flowerstructure/fs-s-s-2021
1523+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.
17251524
1726−Our designer ~natnex-ronret curates a playlist website. Check it out: https://www.door.link
1727−~datnut-pollen has been trying to understand how information processing evolves over time in evolutive systems. Here’s what he’s been reading:
1525+## 2021
17281526
1729−(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.
1730−(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.
1731−(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.
1527+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.
17321528
1733−~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).
1529+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:
17341530
1735−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.
1531+- Rework urbit.org to better help developers learn how to contribute to Urbit
1532+- Since Urbit is ready to build on top of, provide practical guides that demonstrate how to do so
1533+- Guide developers to make high-value contributions to Urbit and its ecosystem
1534+- Build community amongst contributors
17361535
1737−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
1536+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.
17381537
1739−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.
1538+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.
17401539
1741−~wolref-podlex and ~roslet-tanner
1540+See you on the network!
17421541]]></content:encoded>
17431542 </item>
17441543 <item>
1745− <title><![CDATA[After the Machine War]]></title>
1746− <link>https://urbit.org/blog/after-machine-war</link>
1747− <guid>https://urbit.org/blog/after-machine-war</guid>
1748− <pubDate>Sun, 14 Mar 2021 00:00:00 GMT</pubDate>
1544+ <title><![CDATA[Ames Security Audit and the Future of the Protocol]]></title>
1545+ <link>https://urbit.org/blog/security-audit</link>
1546+ <guid>https://urbit.org/blog/security-audit</guid>
1547+ <pubDate>Thu, 17 Dec 2020 00:00:00 GMT</pubDate>
17491548 <content:encoded><
1551+
17531552
17541553<br>
17551554
1756−> 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.
1757−>
1758−> Really the only notable thing about it is that it was written on Urbit. And that, perhaps, has made all the difference.
1759−>
1760−> 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.
1761−>
1762−> 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.
1763−>
1764−> 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.
1555+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.
17651556
1766−<br>
1557+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."
17671558
1768−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.
1559+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.
17691560
1770−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?
1561+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:
17711562
1772−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.
1563+- Forward secrecy
1564+- Protection against denial of service attacks
1565+- Enforcement of social boundaries
17731566
1774−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.
1567+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.
17751568
1776−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.
1569+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.
17771570
1778−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.
1571+## Forward Secrecy
17791572
1780−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.
1573+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.
17811574
1782−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.
1575+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.
17831576
1784−2050 turned out to be a pretty good year after all.
1785−]]></content:encoded>
1786− </item>
1787− <item>
1788− <title><![CDATA[Eliza]]></title>
1789− <link>https://urbit.org/blog/eliza</link>
1790− <guid>https://urbit.org/blog/eliza</guid>
1791− <pubDate>Mon, 22 Feb 2021 00:00:00 GMT</pubDate>
1792− <content:encoded><
1579+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.
1580+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.
17961581
1797−<br>
1582+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.
17981583
1799−## The Storm before the Calm
1584+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.
18001585
1801−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.
1586+## Denial of Service
18021587
1803−We call her Eliza. She is a data-collection robot.
1588+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.
18041589
1805−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.
1590+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.
18061591
1807−## What Eliza is and isn’t
1592+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.
18081593
1809−> Replicants are like any other machine - they're either a benefit or a hazard. If they're a benefit, it's not my problem.
1810−>
1811−> <cite>Rick Deckard</cite>
1594+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.
18121595
1813−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.
1596+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.
18141597
1815−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.
1598+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.
18161599
1817−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.
1600+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.
18181601
1819−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.
1602+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.
18201603
1821−## A New Internet Economics
1604+- Sign each packet, and any relay or final recipient could validate the signature
1605+- Wrap each packet in an HMAC, validated by the final receiver
1606+- 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
18221607
1823−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.
1608+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.
18241609
1825−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.
1610+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.
18261611
1827−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.
1612+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.
18281613
1829−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.
1614+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.
18301615
1831−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.
1832−]]></content:encoded>
1833− </item>
1834− <item>
1835− <title><![CDATA[A brief update from urbit.org]]></title>
1836− <link>https://urbit.org/updates/2021-02-19-update</link>
1837− <guid>https://urbit.org/updates/2021-02-19-update</guid>
1838− <pubDate>Thu, 18 Feb 2021 00:00:00 GMT</pubDate>
1839− <content:encoded><![CDATA[
1840−Hello!
1616+### DoS Mitigation Approach 1: Signature
18411617
1842−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:
1618+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.
18431619
1844−1 - Scholarships
1620+#### Advantages of a signature over other approaches
18451621
1846−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.
1622+- 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.
1623+- 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.
18471624
1848−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.
1625+#### Disadvantages of a signature over other approaches
18491626
1850−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.
1627+- Generating and validating a signature is significantly slower than generating and validating an HMAC.
1628+- An ECDSA signature is 64 bytes, which is ~6% of a packet payload. As far as I can tell, it can't be compressed.
1629+- 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.
18511630
1852−If you’re interested in a scholarship, sign up for the waitlist here: https://airtable.com/shr6Xmo55h8dZ0O46
1631+### DoS Mitigation Approach 2: End-to-End HMAC
18531632
1854−2 - Community
1633+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.
18551634
1856−Our community has been pretty busy lately. Here’s a non comprehensive list of what they’ve been up to:
1635+#### Advantages of end-to-end HMAC
18571636
1858−- ~timluc-miptev completed the Bitcoin gall agents. They’re now being integrated into Landscape as a wallet.
1859−- ~sovmep-ripsum finished his work on ucal, an iCalendar-compatible calendaring backend for Urbit.
1860−- ~tabnus-fondeg began work on Urbit LFS (large file storage) for providing file sharing and hosting support.
1861−- ~sipfyn-pidmex is writing a comprehensive suite of documentation for graph-store to enable an easier on-ramp to building new social applications.
1862−- ~minder-folden launched a new hosting provider that you can check out here: https://escapepod.store
1863−- ~naltyc-wornes is contributing a set of official, battle-tested guides for running Urbit on “smol” devices to the urbit.org website.
1864−- ~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
1637+- It's simple in some sense; relays don't need to do anything cryptographic.
1638+- HMACs are much faster to create and validate than signatures.
1639+- 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.
18651640
1866−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.
1641+#### Disadvantages of end-to-end HMAC
18671642
1868−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
1643+- 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.
18691644
1870−3 - Foundation growth
1645+### DoS Mitigation Approach 3: Point-to-Point HMAC
18711646
1872−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.
1647+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.
18731648
1874−~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.
1649+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.
18751650
1876−~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.
1651+#### Advantages of point-to-point HMAC
18771652
1878−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.
1653+- 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.
1654+- 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.
18791655
1880−4 - King Haskell
1656+#### Disadvantages of point-to-point HMAC
18811657
1882−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.
1658+- Not everyone on the network can validate a packet, unlike a signature.
1659+- 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.
1660+- 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.
18831661
1884−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.
1662+#### An Aside About Cryptographic Performance
18851663
1886−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
1664+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.
18871665
1888−./urbit-king run path/to/your/pier
1666+### DoS Protection Strategy and Timeline
18891667
1890−To create a new ship, use the `urbit-king new` command.
1668+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.
18911669
1892−If you run into any problems doing this, or notice any incompatible behavior, please inform the authorities immediately.
1670+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.
18931671
1894−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.
1672+## Enforcement of Social Boundaries
18951673
1896−5 - Getting Started guide
1674+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.
18971675
1898−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.
1676+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.
18991677
1900−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!
1678+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.
19011679
1902−https://urbit.org/using/install/
1680+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.
19031681
1904−--
1682+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.
19051683
1906−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!
1907−Josh / ~wolref-podlex
1684+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.
19081685
1909−https://twitter.com/urbit
1910−https://github.com/urbit/urbit
1686+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.
1687+
1688+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.
1689+
1690+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.
1691+
1692+## Conclusion
1693+
1694+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.
19111695]]></content:encoded>
19121696 </item>
19131697 <item>
1914− <title><![CDATA[2020 -> 2021]]></title>
1915− <link>https://urbit.org/blog/2020-to-2021</link>
1916− <guid>https://urbit.org/blog/2020-to-2021</guid>
1917− <pubDate>Wed, 20 Jan 2021 00:00:00 GMT</pubDate>
1698+ <title><![CDATA[Input and Output in Hoon]]></title>
1699+ <link>https://urbit.org/blog/io-in-hoon</link>
1700+ <guid>https://urbit.org/blog/io-in-hoon</guid>
1701+ <pubDate>Tue, 15 Dec 2020 00:00:00 GMT</pubDate>
19181702 <content:encoded><
1705+
19221706
19231707<br>
19241708
1925−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.
1709+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.
19261710
1927−## 2020
1711+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!
19281712
1929−In spite of the many challenges presented over the last year, it was a resoundingly good one for Urbit.
1930−
1931−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.
1932−
1933−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.
1934−
1935−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.
1936−
1937−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.
1938−
1939−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.
1940−
1941−## 2021
1713+## The three styles of IO
19421714
1943−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.
1715+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.
19441716
1945−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:
1717+### Imperative IO
19461718
1947−- Rework urbit.org to better help developers learn how to contribute to Urbit
1948−- Since Urbit is ready to build on top of, provide practical guides that demonstrate how to do so
1949−- Guide developers to make high-value contributions to Urbit and its ecosystem
1950−- Build community amongst contributors
1719+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.
19511720
1952−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.
1721+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.
19531722
1954−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.
1723+ output = fetchUrl(stripWhitespace(readFile(cliInput())))
19551724
1956−See you on the network!
1957−]]></content:encoded>
1958− </item>
1959− <item>
1960− <title><![CDATA[A brief update from urbit.org]]></title>
1961− <link>https://urbit.org/updates/2021-01-15-update</link>
1962− <guid>https://urbit.org/updates/2021-01-15-update</guid>
1963− <pubDate>Thu, 14 Jan 2021 00:00:00 GMT</pubDate>
1964− <content:encoded>< 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.
19741736
1975−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.
1737+### State machines
19761738
1977−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.
1739+Languages that use explicit state machines for IO (such as Elm) perform IO by accepting events and producing a list of effects.
19781740
1979−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.
1741+ event :: Initialize
1742+ | CLIInput text
1743+ | FileInput text
1744+ | HTTPResponse body
1745+ effect :: CLIInput
1746+ | ReadFile fileName
1747+ | FetchUrl url
1748+ | Print text
1749+ main(event) {
1750+ switch event {
1751+ Initialize -> [CLIInput ~]
1752+ CLIinput fileName -> [ReadFile fileName]
1753+ FileInput url -> [FetchUrl stripWhitespace(url)]
1754+ HTTPResponse body -> [Print body]
1755+ }
1756+ }
19801757
1981−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.
1758+The effects produced are not functions but data.
19821759
1983−2 - 2021
1760+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.
19841761
1985−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).
1762+## A stateful, loopy example
19861763
1987−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:
1764+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.
19881765
1989−- Rework urbit.org to better help developers learn how to contribute to Urbit
1990−- Since Urbit is ready to build on top of, provide practical guides that demonstrate how to do so
1991−- Guide developers to make high-value contributions to Urbit and its ecosystem
1992−- Build community amongst contributors
1766+Imperative:
19931767
1994−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.
1768+ text = "no text entered yet"
1769+ while (true)
1770+ cli = readCli()
1771+ if (cli != Null)
1772+ text = cli
1773+ request = readHttp()
1774+ if (request != Null)
1775+ respond(request,text)
19951776
1996−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.
1777+Monadic:
19971778
1998−3 - Town Hall
1779+ loop("no text entered yet")
19991780
2000−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!).
1781+ where:
20011782
2002−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!
1783+ loop :: text -> IO Null
1784+ loop =
1785+ input <- readInput()
1786+ switch input
1787+ CLIInput newText -> loop(newText)
1788+ HTTPRequest request ->
1789+ _ <- respond(request,text)
1790+ loop(text)
20031791
2004−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.
1792+State machine:
20051793
2006−--
1794+ text = "no text entered yet"
1795+ main(text,event) {
1796+ switch event {
1797+ CLIInput newText -> [newText, Null]
1798+ HTTPRequest request -> [text, HTTPResponse text]
1799+ }
1800+ }
20071801
2008−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.
1802+Again, note the response in the state machine is data, not a function.
20091803
2010−That’s all for now. See you on the network!
2011−Josh / ~wolref-podlex
1804+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.
20121805
2013−https://twitter.com/urbit
2014−https://github.com/urbit/urbit
2015−]]></content:encoded>
2016− </item>
2017− <item>
2018− <title><![CDATA[Ames Security Audit and the Future of the Protocol]]></title>
2019− <link>https://urbit.org/blog/security-audit</link>
2020− <guid>https://urbit.org/blog/security-audit</guid>
2021− <pubDate>Thu, 17 Dec 2020 00:00:00 GMT</pubDate>
2022− <content:encoded><![CDATA[
2023−<br>
1806+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]`.
20241807
2025−
1808+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.
20261809
2027−<br>
1810+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.
20281811
2029−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.
1812+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.
20301813
2031−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."
1814+## In Urbit
20321815
2033−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.
1816+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.
20341817
2035−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:
1818+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.
20361819
2037−- Forward secrecy
2038−- Protection against denial of service attacks
2039−- Enforcement of social boundaries
1820+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.
20401821
2041−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.
1822+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.
20421823
2043−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.
1824+Agents are:
20441825
2045−## Forward Secrecy
1826+- 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.
20461827
2047−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.
1828+- 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.
20481829
2049−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.
1830+- Permanent. Since it's upgradable and robust, there's no reason to stop its running.
20501831
2051−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.
1832+- 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.
20521833
2053−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.
2054−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.
1834+Threads are:
20551835
2056−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.
1836+- 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.
20571837
2058−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.
1838+- 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.
20591839
2060−## Denial of Service
1840+- 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.
20611841
2062−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.
1842+- Easy to write long sequences of IO. Just...write the IO one line at a time.
20631843
2064−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.
1844+Arvo proper and the vanes are permanent pieces of software and, for this reason, state machines are more natural.
20651845
2066−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.
1846+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.
20671847
2068−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.
1848+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.
20691849
2070−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.
1850+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:
20711851
2072−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.
1852+ loop()
20731853
2074−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.
1854+ where:
20751855
2076−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.
1856+ loop =
1857+ request <- receiveRequest()
1858+ agent = lookupAgent(request)
1859+ response <- callAgent(agent, request)
1860+ _ <- sendResponse(request, response)
1861+ loop()
20771862
2078−- Sign each packet, and any relay or final recipient could validate the signature
2079−- Wrap each packet in an HMAC, validated by the final receiver
2080−- 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
1863+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?
20811864
2082−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.
1865+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".
20831866
2084−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.
1867+In a state machine, the naive solution is:
20851868
2086−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.
1869+ state :: (map request agent)
1870+ main(state, event) {
1871+ switch event {
1872+ HTTPRequest request ->
1873+ agent = lookupAgent(request)
1874+ [put(state, request, agent), CallAgent agent request]
1875+ AgentResponse request response ->
1876+ [del(state, request), HTTPRespond request response]
1877+ }
1878+ }
20871879
2088−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.
1880+Upgrading this is trivial, since the state (map of requests to outstanding calls to agents) is explicit. It also trivially handles concurrent requests.
20891881
2090−### DoS Mitigation Approach 1: Signature
1882+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.
20911883
2092−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.
1884+Userspace agents similarly are permanent entities that need to not lose data or get stuck. For this reason they’re structured as state machines.
20931885
2094−#### Advantages of a signature over other approaches
1886+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!
20951887
2096−- 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.
2097−- 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.
1888+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.
20981889
2099−#### Disadvantages of a signature over other approaches
1890+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.
21001891
2101−- Generating and validating a signature is significantly slower than generating and validating an HMAC.
2102−- An ECDSA signature is 64 bytes, which is ~6% of a packet payload. As far as I can tell, it can't be compressed.
2103−- 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.
1892+Monadic:
21041893
2105−### DoS Mitigation Approach 2: End-to-End HMAC
1894+ topStories <- fetch(topStoriesUrl)
1895+ loop(topStories)
21061896
2107−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.
1897+ where:
21081898
2109−#### Advantages of end-to-end HMAC
1899+ loop :: topStories -> IO Null
1900+ if topStories is Null
1901+ return Null
1902+ comments <- retryLoop(5,head(topStories))
1903+ otherComments <- loop(tail(topStories))
1904+ append(comments,otherComments)
21101905
2111−- It's simple in some sense; relays don't need to do anything cryptographic.
2112−- HMACs are much faster to create and validate than signatures.
2113−- 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.
1906+ retryLoop :: [n story] -> IO Comments
1907+ comments <- fetchComments(story)
1908+ if comments is HTTPError:
1909+ if n == 0:
1910+ bail
1911+ else:
1912+ retryLoop(n-1, story)
21141913
2115−#### Disadvantages of end-to-end HMAC
1914+State machine:
21161915
2117−- 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.
1916+ state :: Initial
1917+ | FetchingTop
1918+ | FetchingStory comments stories retries
1919+ | Done comments
21181920
2119−### DoS Mitigation Approach 3: Point-to-Point HMAC
1921+ main(state, event) {
1922+ switch event {
1923+ Initialize ->
1924+ assert state == Initial
1925+ [FetchingTop, Fetch topStoriesUrl]
1926+ HttpResponse response ->
1927+ switch state {
1928+ FetchingTop ->
1929+ [FetchingStory Null stories 5, FetchComments head(stories)]
1930+ FetchingStory comments stories retries ->
1931+ if response is HTTPError:
1932+ if retries == 0:
1933+ [Initial, Null]
1934+ else:
1935+ [FetchingStory comments stories retries-1,
1936+ FetchComments head(stories)]
1937+ else:
1938+ comments = append(response,comments)
1939+ if tail(stories) is Null:
1940+ [Done comments, Null]
1941+ else:
1942+ [FetchingStory append(comments,response) tail(stories) 5,
1943+ FetchComments head(tail(stories))]
1944+ }
1945+ }
1946+ }
21201947
2121−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.
1948+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.
21221949
2123−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.
1950+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.
21241951
2125−#### Advantages of point-to-point HMAC
1952+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.
21261953
2127−- 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.
2128−- 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.
1954+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?
21291955
2130−#### Disadvantages of point-to-point HMAC
1956+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.
21311957
2132−- Not everyone on the network can validate a packet, unlike a signature.
2133−- 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.
2134−- 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.
1958+These aren't completely mutually exclusive, but it's surprising how often they are.
21351959
2136−#### An Aside About Cryptographic Performance
1960+### Jael: a case study
21371961
2138−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.
1962+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).
21391963
2140−### DoS Protection Strategy and Timeline
1964+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.
21411965
2142−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.
1966+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.
21431967
2144−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.
1968+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.
21451969
2146−## Enforcement of Social Boundaries
1970+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.
21471971
2148−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.
1972+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:
21491973
2150−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.
1974+ syncEthereum oldBlockNumber -> IO [newBlockNumber, newTxs]
21511975
2152−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.
1976+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.
21531977
2154−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.
1978+From Jael's perspective, it looks something like:
21551979
2156−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.
1980+ state :: State block txs outstandingThread
1981+ main(state,event) {
1982+ switch event {
1983+ Initialize -> [State 0 Null Null, StartTimer (now + five minutes)]
1984+ TimerFired ->
1985+ effects = If outstandingThread is Null
1986+ then Null
1987+ else [Kill outstandingThread]
1988+ newId = newThreadId()
1989+ [State txs newId,
1990+ append(effects,
1991+ StartThread newId syncEthereum(block),
1992+ StartTimer (now + five minutes))]
1993+ ThreadFinished Failure -> [State block txs Null, Null]
1994+ ThreadFinished Success newBlockNumber newTxs ->
1995+ [State newBlockNumber append(txs,newTxs) Null, Null]
1996+ }
1997+ }
21571998
2158−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.
1999+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.
21592000
2160−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.
2001+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.
21612002
2162−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.
2003+## Recap
21632004
2164−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.
2005+Let's recap what we've covered:
21652006
2166−## Conclusion
2007+- There are three styles of IO: imperative, monadic, and explicit state machines.
2008+- Urbit supports explicit state machines (agents) and monadic IO (threads).
2009+- Explicit state machines are preferred for permanent, robust, concurrent code.
2010+- Monadic IO is preferred for short-lived code with complex IO.
2011+- 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.
21672012
2168−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.
2013+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.
21692014]]></content:encoded>
21702015 </item>
21712016 <item>
2172− <title><![CDATA[Input and Output in Hoon]]></title>
2173− <link>https://urbit.org/blog/io-in-hoon</link>
2174− <guid>https://urbit.org/blog/io-in-hoon</guid>
2175− <pubDate>Tue, 15 Dec 2020 00:00:00 GMT</pubDate>
2017+ <title><![CDATA[Metaphase]]></title>
2018+ <link>https://urbit.org/blog/metaphase</link>
2019+ <guid>https://urbit.org/blog/metaphase</guid>
2020+ <pubDate>Tue, 08 Dec 2020 00:00:00 GMT</pubDate>
21762021 <content:encoded><
2024+
21802025
21812026<br>
21822027
2183−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.
2028+_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:_
21842029
2185−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!
2030+```
2031+|ota ~hanruc-nalfus-nidsut-tomdun %kids
2032+|merge %home ~hanruc-nalfus-nidsut-tomdun %kids, =gem %take-that
2033+|merge %kids ~hanruc-nalfus-nidsut-tomdun %kids, =gem %take-that
2034+```
21862035
2187−## The three styles of IO
2036+_We will surface this option more broadly in a future settings overhaul._
21882037
2189−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.
2038+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.
21902039
2191−### Imperative IO
2040+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.
21922041
2193−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.
2042+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.
21942043
2195−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.
2044+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.
21962045
2197− output = fetchUrl(stripWhitespace(readFile(cliInput())))
2046+## Landscapers and lifecycles
21982047
2199−For readability, intermediate variables would be a good idea, but nothing stops you from nesting IO this way.
2048+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.
22002049
2201−### Monadic IO
2050+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.
22022051
2203−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.
2052+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)).
22042053
2205− fileName <- cliInput()
2206− url <- readFile(fileName)
2207− output <- fetchUrl(stripWhitespace(url))
2054+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.
22082055
2209−[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.
2056+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.
22102057
2211−### State machines
2058+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”).
22122059
2213−Languages that use explicit state machines for IO (such as Elm) perform IO by accepting events and producing a list of effects.
2060+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.
22142061
2215− event :: Initialize
2216− | CLIInput text
2217− | FileInput text
2218− | HTTPResponse body
2219− effect :: CLIInput
2220− | ReadFile fileName
2221− | FetchUrl url
2222− | Print text
2223− main(event) {
2224− switch event {
2225− Initialize -> [CLIInput ~]
2226− CLIinput fileName -> [ReadFile fileName]
2227− FileInput url -> [FetchUrl stripWhitespace(url)]
2228− HTTPResponse body -> [Print body]
2229− }
2230− }
2062+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.
22312063
2232−The effects produced are not functions but data.
2064+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.
22332065
2234−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.
2066+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.
22352067
2236−## A stateful, loopy example
2068+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.
22372069
2238−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.
2070+So now, before we could launch a stable stream, we had some things to do first:
22392071
2240−Imperative:
2072+- **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.
2073+- **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.
2074+- **We wanted to release the notification-store**. After the October 2020 groups release, Landscape simply wouldn’t be complete without it.
2075+- 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.
22412076
2242− text = "no text entered yet"
2243− while (true)
2244− cli = readCli()
2245− if (cli != Null)
2246− text = cli
2247− request = readHttp()
2248− if (request != Null)
2249− respond(request,text)
2077+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**.
22502078
2251−Monadic:
2079+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.
22522080
2253− loop("no text entered yet")
2081+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.
22542082
2255− where:
2083+## Mitosis
22562084
2257− loop :: text -> IO Null
2258− loop =
2259− input <- readInput()
2260− switch input
2261− CLIInput newText -> loop(newText)
2262− HTTPRequest request ->
2263− _ <- respond(request,text)
2264− loop(text)
2085+Describing our progress so candidly can feel strange — after all, it sounds so _early_. But to me, it’s exciting. It’s mitosis.
22652086
2266−State machine:
2087+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.
22672088
2268− text = "no text entered yet"
2269− main(text,event) {
2270− switch event {
2271− CLIInput newText -> [newText, Null]
2272− HTTPRequest request -> [text, HTTPResponse text]
2273− }
2274− }
2089+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.
22752090
2276−Again, note the response in the state machine is data, not a function.
2091+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.
22772092
2278−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.
2093+But this is, after all, how a body forms.
2094+]]></content:encoded>
2095+ </item>
2096+ <item>
2097+ <title><![CDATA[Security and Continuity]]></title>
2098+ <link>https://urbit.org/blog/security-and-continuity</link>
2099+ <guid>https://urbit.org/blog/security-and-continuity</guid>
2100+ <pubDate>Mon, 30 Nov 2020 00:00:00 GMT</pubDate>
2101+ <content:encoded><
22792103
2280−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]`.
2104+## Security and Continuity
22812105
2282−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.
2106+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.
22832107
2284−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.
2108+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.
22852109
2286−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.
2110+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’.
22872111
2288−## In Urbit
2112+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.
22892113
2290−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.
2114+## Ames Audit
22912115
2292−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.
2116+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.
22932117
2294−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.
2118+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.
22952119
2296−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.
2120+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.
22972121
2298−Agents are:
2122+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:
22992123
2300−- 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.
2124+- No one can impersonate another ship on the network
2125+- No one (including relays) can intercept and decrypt messages not meant for them
2126+- Ames messages don’t leak keys that could endanger the sender’s data
23012127
2302−- 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.
2128+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.
23032129
2304−- Permanent. Since it's upgradable and robust, there's no reason to stop its running.
2130+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.
23052131
2306−- 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.
2132+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.
23072133
2308−Threads are:
2134+## Continuity
23092135
2310−- 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.
2136+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.
23112137
2312−- 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.
2138+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.
23132139
2314−- 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.
2140+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.
23152141
2316−- Easy to write long sequences of IO. Just...write the IO one line at a time.
2142+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.
23172143
2318−Arvo proper and the vanes are permanent pieces of software and, for this reason, state machines are more natural.
2144+## Status + conclusion
23192145
2320−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.
2146+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.
23212147
2322−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.
2148+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`.
23232149
2324−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:
2150+It's going to be an exciting couple of weeks!
2151+]]></content:encoded>
2152+ </item>
2153+ <item>
2154+ <title><![CDATA[An Email from the Archive]]></title>
2155+ <link>https://urbit.org/blog/an-email</link>
2156+ <guid>https://urbit.org/blog/an-email</guid>
2157+ <pubDate>Sun, 29 Nov 2020 00:00:00 GMT</pubDate>
2158+ <content:encoded><
23252160
2326− loop()
2161+I found this email in my archives recently and thought it might be fun to share publicly.
23272162
2328− where:
2163+```
2164+From: Galen Wolfe-Pauly <galen@tlon.io>
2165+Date: Thu, Jul 2, 2020 at 9:50 AM
2166+Subject: Continuing
2167+To: XXXXXXXXXXXXX
2168+```
23292169
2330− loop =
2331− request <- receiveRequest()
2332− agent = lookupAgent(request)
2333− response <- callAgent(agent, request)
2334− _ <- sendResponse(request, response)
2335− loop()
2170+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:
23362171
2337−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?
2172+1 -
23382173
2339−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".
2174+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.
23402175
2341−In a state machine, the naive solution is:
2176+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:
23422177
2343− state :: (map request agent)
2344− main(state, event) {
2345− switch event {
2346− HTTPRequest request ->
2347− agent = lookupAgent(request)
2348− [put(state, request, agent), CallAgent agent request]
2349− AgentResponse request response ->
2350− [del(state, request), HTTPRespond request response]
2351− }
2352− }
2178+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.
23532179
2354−Upgrading this is trivial, since the state (map of requests to outstanding calls to agents) is explicit. It also trivially handles concurrent requests.
2180+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.
23552181
2356−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.
2182+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.
23572183
2358−Userspace agents similarly are permanent entities that need to not lose data or get stuck. For this reason they’re structured as state machines.
2184+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.
23592185
2360−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!
2186+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.
23612187
2362−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.
2188+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.
23632189
2364−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.
2190+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.
23652191
2366−Monadic:
2192+2 -
23672193
2368− topStories <- fetch(topStoriesUrl)
2369− loop(topStories)
2194+(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.
23702195
2371− where:
2196+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.
23722197
2373− loop :: topStories -> IO Null
2374− if topStories is Null
2375− return Null
2376− comments <- retryLoop(5,head(topStories))
2377− otherComments <- loop(tail(topStories))
2378− append(comments,otherComments)
2198+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.
23792199
2380− retryLoop :: [n story] -> IO Comments
2381− comments <- fetchComments(story)
2382− if comments is HTTPError:
2383− if n == 0:
2384− bail
2385− else:
2386− retryLoop(n-1, story)
2200+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.
23872201
2388−State machine:
2202+3 -
23892203
2390− state :: Initial
2391− | FetchingTop
2392− | FetchingStory comments stories retries
2393− | Done comments
2204+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.
23942205
2395− main(state, event) {
2396− switch event {
2397− Initialize ->
2398− assert state == Initial
2399− [FetchingTop, Fetch topStoriesUrl]
2400− HttpResponse response ->
2401− switch state {
2402− FetchingTop ->
2403− [FetchingStory Null stories 5, FetchComments head(stories)]
2404− FetchingStory comments stories retries ->
2405− if response is HTTPError:
2406− if retries == 0:
2407− [Initial, Null]
2408− else:
2409− [FetchingStory comments stories retries-1,
2410− FetchComments head(stories)]
2411− else:
2412− comments = append(response,comments)
2413− if tail(stories) is Null:
2414− [Done comments, Null]
2415− else:
2416− [FetchingStory append(comments,response) tail(stories) 5,
2417− FetchComments head(tail(stories))]
2418− }
2419− }
2420− }
2206+(In my view, a real network is always decentralized. Centralized networks are basically just companies.)
24212207
2422−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.
2208+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.
24232209
2424−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.
2210+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.
24252211
2426−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.
2212+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_.
24272213
2428−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?
2214+4 -
24292215
2430−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.
2216+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.
24312217
2432−These aren't completely mutually exclusive, but it's surprising how often they are.
2218+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.
24332219
2434−### Jael: a case study
2220+5 -
24352221
2436−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).
2222+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.
24372223
2438−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.
2224+[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)
24392225
2440−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.
2226+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)
24412227
2442−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.
2228+Hejduk was able to see that architecture isn’t about building buildings per se, but something else. That was always quite obvious to me.
24432229
2444−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.
2230+Talk soon!
2231+G
2232+]]></content:encoded>
2233+ </item>
2234+ <item>
2235+ <title><![CDATA[Models of Society]]></title>
2236+ <link>https://urbit.org/blog/20201119-models-of-society</link>
2237+ <guid>https://urbit.org/blog/20201119-models-of-society</guid>
2238+ <pubDate>Wed, 18 Nov 2020 00:00:00 GMT</pubDate>
2239+ <content:encoded><![CDATA[
2240+_I had used Facebook and Google for my entire adult life. I knew they were toxic but I didn't know why. For a few weeks I tried to create a website that would scrape data from Facebook’s API and push data back, puppetting it from my own server. But as I stared headlong into the ever-shifting darkness of the modern web, I despaired and abandoned my attempt. Less than a year later I heard about Urbit. Technically, it went way over my head—but socially I knew exactly what it was, what it always had to be, why it was a discovery and not an invention, a place and not a product. I've watched the settlers there for four years, only just now using the opportunity of the pandemic to swim to this new landscape and gaze upon this young nation, this digital city, this urbis ec bit. I do not work for Tlon. I just live here._
24452241
2446−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:
2242+<hr>
24472243
2448− syncEthereum oldBlockNumber -> IO [newBlockNumber, newTxs]
2244+All people like to talk. Society is built by talking. In this—the year of our Lord two thousand and twenty—for many (maybe most) talking means typing on computers: handheld, laptop, or desktop. Computers can do all sorts of interesting things, like aid in designing buildings or simulate protein folding—fundamentally, a computer is a machine for doing math really fast. But computers can be networked, which turns them into tools for communication. Because society runs on talking and because computers enable us to do that, the most common thing that computers end up doing is to transmit human thoughts in text. Normal people call this writing, which is a kind of talking. Let’s call it messaging. When we think about building a good computer—and computer network—one that serves society in the best ways needs to do messaging well. Only a small percentage of people will regularly do anything else. (Urbit does serve those needs but I will leave that explanation to more capable minds.)
24492245
2450−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.
2246+## Modes of Messaging
24512247
2452−From Jael's perspective, it looks something like:
2248+<br>
24532249
2454− state :: State block txs outstandingThread
2455− main(state,event) {
2456− switch event {
2457− Initialize -> [State 0 Null Null, StartTimer (now + five minutes)]
2458− TimerFired ->
2459− effects = If outstandingThread is Null
2460− then Null
2461− else [Kill outstandingThread]
2462− newId = newThreadId()
2463− [State txs newId,
2464− append(effects,
2465− StartThread newId syncEthereum(block),
2466− StartTimer (now + five minutes))]
2467− ThreadFinished Failure -> [State block txs Null, Null]
2468− ThreadFinished Success newBlockNumber newTxs ->
2469− [State newBlockNumber append(txs,newTxs) Null, Null]
2470− }
2471− }
2250+
24722251
2473−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.
2252+<br>
24742253
2475−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.
2254+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.
24762255
2477−## Recap
2256+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.
24782257
2479−Let's recap what we've covered:
2258+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.
24802259
2481−- There are three styles of IO: imperative, monadic, and explicit state machines.
2482−- Urbit supports explicit state machines (agents) and monadic IO (threads).
2483−- Explicit state machines are preferred for permanent, robust, concurrent code.
2484−- Monadic IO is preferred for short-lived code with complex IO.
2485−- 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.
2260+In order to digitize messages well, computers need to reconcile two facts about all modes of messaging. They have:
24862261
2487−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.
2262+1. One basic shape, and
2263+2. An infinite variety of forms.
2264+
2265+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.
2266+
2267+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.
2268+
2269+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.
2270+
2271+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.
2272+
2273+## People in Places
2274+
2275+<br>
2276+
2277+
2278+
2279+<br>
2280+
2281+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.
2282+
2283+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.
2284+
2285+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.
2286+
2287+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.
2288+
2289+## Urbis ec Bit
2290+
2291+<br>
2292+
2293+
2294+
2295+<br>
2296+
2297+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.
2298+
2299+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.
2300+
2301+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.
2302+
2303+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.
2304+
2305+_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._
24882306]]></content:encoded>
24892307 </item>
24902308 <item>
2491− <title><![CDATA[Metaphase]]></title>
2492− <link>https://urbit.org/blog/metaphase</link>
2493− <guid>https://urbit.org/blog/metaphase</guid>
2494− <pubDate>Tue, 08 Dec 2020 00:00:00 GMT</pubDate>
2309+ <title><![CDATA[Aesthetic Culture #1]]></title>
2310+ <link>https://urbit.org/blog/aesthetic-culture-1</link>
2311+ <guid>https://urbit.org/blog/aesthetic-culture-1</guid>
2312+ <pubDate>Wed, 11 Nov 2020 00:00:00 GMT</pubDate>
24952313 <content:encoded><
2316+
24992317
25002318<br>
25012319
2502−_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:_
2320+_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_
25032321
2504−```
2505−|ota ~hanruc-nalfus-nidsut-tomdun %kids
2506−|merge %home ~hanruc-nalfus-nidsut-tomdun %kids, =gem %take-that
2507−|merge %kids ~hanruc-nalfus-nidsut-tomdun %kids, =gem %take-that
2508−```
2322+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.
2323+
2324+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.
2325+
2326+## ~datnut-pollen
2327+
2328+~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.
2329+
2330+
2331+
2332+## ~lagrev-nocfep
2333+
2334+~lagrev- [made a thread of Dinosaur Comics](https://twitter.com/sigilante/status/1299101593997127680), using the Urbit Whitepaper as the seed text.
2335+
2336+
2337+
2338+A sweet poem about the potential for Martian felines is theirs as well:
2339+
2340+
2341+
2342+## ~litmus-ritten
2343+
2344+~litmus- produces art full of glowing gases and colourful curves:
2345+
2346+
2347+
2348+~litmus- also drew Urbitan for the release of OS1:
2349+
2350+
2351+
2352+More of their work is available in the notebooks of the Internet Weirdness Research Unit.
2353+
2354+## ~minder-folden
2355+
2356+~minder- stylistically ranges from retrofuturistic memes to flat-out classic 50s retro:
2357+
2358+
2359+
2360+
2361+
2362+More of ~minder-’s work is available in his The New Era notebook.
2363+
2364+## ~naltyc-wornes
2365+
2366+~naltyc-, & by extension ~dasfeb industries, produces content related to the exploration of Urbit on small & unique computers:
2367+
2368+
2369+
2370+
2371+
2372+More of their work is available in the smol computers group.
2373+
2374+## ~nartes-fasrum
2375+
2376+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).
2377+
2378+
2379+
2380+## ~norsyr-torryn
2381+
2382+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.
2383+
2384+
2385+
2386+## ~radbur-sivmus
2387+
2388+~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.
2389+
2390+## ~sitful-hatred
2391+
2392+~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.
2393+
2394+
2395+
2396+## ~tocrex-holpen
2397+
2398+~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.
2399+
2400+
2401+
2402+## Landscape
2403+
2404+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).
2405+
2406+
2407+
2408+
2409+]]></content:encoded>
2410+ </item>
2411+ <item>
2412+ <title><![CDATA[Late 2020 Progress Update: OS 1 -> OS 1.N]]></title>
2413+ <link>https://urbit.org/blog/20200929-state-of-urbit</link>
2414+ <guid>https://urbit.org/blog/20200929-state-of-urbit</guid>
2415+ <pubDate>Mon, 28 Sep 2020 00:00:00 GMT</pubDate>
2416+ <content:encoded><
2420+
2421+<br>
2422+
2423+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.
2424+
2425+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.
2426+
2427+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.
2428+
2429+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.
2430+
2431+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.
2432+
2433+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.
2434+
2435+### Infrastructure
2436+
2437+
2438+
2439+In April, Urbit was slow, fragile, and didn’t always update itself properly. We made enormous progress on all of these.
2440+
2441+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.
2442+
2443+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.
2444+
2445+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.
2446+
2447+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.
2448+
2449+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.
2450+
2451+### Interface
2452+
2453+
2454+
2455+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.
2456+
2457+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.
2458+
2459+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.
2460+
2461+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.
2462+
2463+
2464+
2465+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.
2466+
2467+### Community + network
2468+
2469+
2470+
2471+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.
2472+
2473+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.
2474+
2475+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.
2476+
2477+### What’s next
2478+
2479+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.
2480+
2481+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.
2482+]]></content:encoded>
2483+ </item>
2484+ <item>
2485+ <title><![CDATA[~2019.10 Roadmap]]></title>
2486+ <link>https://urbit.org/blog/2019-10-3-roadmap</link>
2487+ <guid>https://urbit.org/blog/2019-10-3-roadmap</guid>
2488+ <pubDate>Wed, 02 Oct 2019 00:00:00 GMT</pubDate>
2489+ <content:encoded><
2491+
2492+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.
2493+
2494+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.
2495+
2496+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.
2497+
2498+## Identity (Azimuth)
2499+
2500+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.
2501+
2502+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.
2503+
2504+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.
2505+
2506+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.
2507+
2508+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).
2509+
2510+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.
2511+
2512+**Q4 2019**
2513+
2514+- Release Bridge to the public
2515+- Get Bridge working well on mobile
2516+- Add payments support, hopefully including BTC
2517+- Add a network explorer
2518+
2519+**Q1 2020**
2520+
2521+- Integrate Bridge with a native app for Arvo
2522+
2523+## OS (Arvo)
2524+
2525+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.
2526+
2527+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.
2528+
2529+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.
2530+
2531+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.
2532+
2533+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.
2534+
2535+### Landscape (Arvo UI)
2536+
2537+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.
2538+
2539+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.
2540+
2541+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.
2542+
2543+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.
2544+
2545+**Q4 2019**
2546+
2547+- Improved Arvo-level error handling
2548+- Implementation plan for ‘telescoping kelvins’ — or [how we plan to future proof Arvo](https://groups.google.com/a/urbit.org/forum/#!topic/dev/6Mwn6TQFVwc)
2549+- Versioning scheme between Arvo and Vere
2550+- A new Haskell implementation of the daemon
2551+- A native client (instead of just a browser tab)
2552+- A [new user-space architecture](https://docs.google.com/document/d/1hS_UuResG1S4j49_H-aSshoTOROKBnGoJAaRgOipf54/edit)
2553+- Hoon.hoon that’s OTA upgradeable
2554+- Working Jacque prototype, a graal-truffle-based implementation of vere
2555+
2556+**Q1 2020**
2557+
2558+- Integrated client with Bridge and Arvo
2559+- New interface framework, codenamed ‘Widescreen’
2560+
2561+## Docs + Community
2562+
2563+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.
2564+
2565+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.
2566+
2567+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.
2568+
2569+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.
2570+
2571+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.
2572+
2573+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.
2574+
2575+**Q4 2019**
2576+
2577+- Vane level documentation
2578+- An active grant program
2579+
2580+## urbit.org
2581+
2582+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.
2583+
2584+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!
2585+
2586+That covers it for now. If you have questions or want to chat — find us in `~dopzod/urbit-help`. See you online!
2587+]]></content:encoded>
2588+ </item>
2589+ <item>
2590+ <title><![CDATA[~2019.5 Roadmap]]></title>
2591+ <link>https://urbit.org/blog/2019-5-roadmap</link>
2592+ <guid>https://urbit.org/blog/2019-5-roadmap</guid>
2593+ <pubDate>Wed, 15 May 2019 00:00:00 GMT</pubDate>
2594+ <content:encoded><
2596+
2597+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.
2598+
2599+At a very high level we have two goals for 2019: make Azimuth easier to use, and get Arvo to a 1.0.
2600+
2601+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.
2602+
2603+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/).
2604+
2605+For now, let’s just look at what’s on the immediate horizon:
2606+
2607+## Azimuth
2608+
2609+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.’
2610+
2611+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.
2612+
2613+So the question is why haven’t we told the world about it?
2614+
2615+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.
2616+
2617+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.
2618+
2619+Here’s what we’re building first:
2620+
2621+### Q2 2019
2622+
2623+- A simplified onboarding flow for getting an Azimuth point that’s simple to share with friends over email, text or as a URL.
2624+- A redesigned and improved Bridge for managing your points.
2625+- An interface that allows you to easily send money between Azimuth points without running Arvo.
2626+
2627+### Q3 2019
2628+
2629+- Expanded Azimuth-centric example modules, documentation and developer tooling.
2630+
2631+Still under consideration:
2632+
2633+- An OAuth server or JWT flow for logging into any service with an Azimuth point.
2634+- A mobile app for point to point payments using Azimuth.
2635+
2636+### 2020
2637+
2638+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
2639+
2640+## Arvo
2641+
2642+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.
2643+
2644+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.
2645+
2646+There are still rough edges, and Landscape is not nearly general purpose enough, but we have plans:
2647+
2648+### Q2 2019
2649+
2650+- 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.
2651+- 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.
2652+- Significant improvements to testing with a new simulation testing framework and integration testing pipelines.
2653+
2654+### Q3 2019
2655+
2656+- A significant overhaul to Gall, our application model, making it much simpler for users to write apps or ‘agents’ in Arvo.
2657+- 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.
2658+- 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.
2659+- Tooling for hosting and hopefully a beta program for hosted Arvo instances run by Tlon.
2660+
2661+### 2020
2662+
2663+- 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.
2664+- We come to work every day, use Arvo, go home.
2665+
2666+## Community
2667+
2668+We’ve often felt like it was far too early to invite others in to the system.
2669+
2670+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.
2671+
2672+Hoon school was the first effort in this direction. We intend to do a lot more:
2673+
2674+### Q2 2019
2675+
2676+- Scaling Hoon school up to include both a track for experts and for beginners, and allowing many more participants.
2677+- Holding more meetings and events on Landscape, experimenting with Arvo-native discussion.
2678+- A clear program for address space grants for developers + contributors.
2679+- New documentation site with searchable library docs.
2680+
2681+### Q3 2019
2682+
2683+- Hoon School participants understand clearly how to build a Modulo agent, and invite others into it.
2684+- The road toward building an Azimuth module is well understood, paved, and clear.
2685+- We have clear instructions and tutorials for building Azimuth modules and using Azimuth as a login or reputation primitive.
2686+]]></content:encoded>
2687+ </item>
2688+ <item>
2689+ <link>https://urbit.org/blog/2021-11-18-the-promise-and-paradox-of-decentralization</link>
2690+ <guid>https://urbit.org/blog/2021-11-18-the-promise-and-paradox-of-decentralization</guid>
2691+ <pubDate>Invalid Date</pubDate>
2692+ </item>
2693+ <item>
2694+ <title><![CDATA[A brief update from urbit.org]]></title>
2695+ <link>https://urbit.org/updates/2021-05-05-update</link>
2696+ <guid>https://urbit.org/updates/2021-05-05-update</guid>
2697+ <pubDate>Tue, 04 May 2021 00:00:00 GMT</pubDate>
2698+ <content:encoded><![CDATA[
2699+Hello!
2700+
2701+Welcome to the May edition of the urbit.org newsletter. April was a busy month with many updates to share—let’s dig in.
2702+
2703+0 – Updated Urbit Binaries
2704+
2705+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
2706+
2707+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.”
2708+
2709+1 – Upcoming Events
2710+
2711+Urbit Town Hall @ May 20th 12pm PDT – Keynote from Justin Murphy
2712+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).
2713+
2714+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.
2715+
2716+Developer Calls @ May 13th and May 27th
2717+As you probably know, we have developer calls every two weeks. Stay tuned for more information on our events page: https://urbit.org/events
2718+
2719+Austin Urbit Conference @ September/October 2021
2720+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!
2721+
2722+2 – April Developer Calls
2723+
2724+Developer Call: 3rd Party Software Distribution
2725+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
2726+
2727+Developer Call: Real-Time Communication on Urbit
2728+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!
2729+
2730+3 – Urbit Bitcoin Launch
2731+
2732+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
2733+
2734+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
2735+
2736+4 – Blog
2737+
2738+We have a couple of new posts to announce:
2739+“Lunar Urbit and the Internet of Things”
2740+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/
2741+
2742+“Community Spotlight: The Portico”
2743+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
2744+
2745+5 – Odds and Ends
2746+
2747+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.
2748+
2749+~hodzod-walrus made a page with statistics on various stars: https://bacrys.org/uptime/
2750+
2751+~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.
2752+
2753+Thanks for reading. Talk to you next month!
2754+
2755+Josh (~wolref-podlex) and ~tirwyd-sarmes
2756+
2757+https://twitter.com/urbit
2758+https://github.com/urbit/urbit
2759+]]></content:encoded>
2760+ </item>
2761+ <item>
2762+ <title><![CDATA[Community Spotlight: The Portico]]></title>
2763+ <link>https://urbit.org/blog/community-spotlight-the-portico</link>
2764+ <guid>https://urbit.org/blog/community-spotlight-the-portico</guid>
2765+ <pubDate>Mon, 03 May 2021 00:00:00 GMT</pubDate>
2766+ <content:encoded><
25092768
2510−_We will surface this option more broadly in a future settings overhaul._
2769+_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._
25112770
2512−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.
2771+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.
25132772
2514−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.
2773+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.
25152774
2516−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.
2775+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.
25172776
2518−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.
2777+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.
25192778
2520−## Landscapers and lifecycles
2779+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.
25212780
2522−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.
2781+I encourage you to take a look. Find The Portico at ~topnup-firber/the-portico.
25232782
2524−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.
2783+\-\-\-\-
25252784
2526−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)).
2785+**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.**
25272786
2528−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.
2787+It’s tough to say with certainty—I’ve never read _The Benedict Option_.
25292788
2530−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.
2789+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.
25312790
2532−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”).
2791+[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.
25332792
2534−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.
2793+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)?
25352794
2536−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.
2795+I don’t claim to know the answers to these questions.
25372796
2538−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.
2797+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.
25392798
2540−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.
2799+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?
25412800
2542−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.
2801+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.
25432802
2544−So now, before we could launch a stable stream, we had some things to do first:
2803+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?
25452804
2546−- **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.
2547−- **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.
2548−- **We wanted to release the notification-store**. After the October 2020 groups release, Landscape simply wouldn’t be complete without it.
2549−- 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.
2805+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!
25502806
2551−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**.
2807+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.
25522808
2553−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.
2809+**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?**
25542810
2555−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.
2811+I feel obligated to answer this question in two ways.
25562812
2557−## Mitosis
2813+(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.
25582814
2559−Describing our progress so candidly can feel strange — after all, it sounds so _early_. But to me, it’s exciting. It’s mitosis.
2815+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.
25602816
2561−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.
2817+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.
25622818
2563−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.
2819+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.
25642820
2565−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.
2821+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.
25662822
2567−But this is, after all, how a body forms.
2568−]]></content:encoded>
2569− </item>
2570− <item>
2571− <title><![CDATA[Security and Continuity]]></title>
2572− <link>https://urbit.org/blog/security-and-continuity</link>
2573− <guid>https://urbit.org/blog/security-and-continuity</guid>
2574− <pubDate>Mon, 30 Nov 2020 00:00:00 GMT</pubDate>
2575− <content:encoded><
2823+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.
25772824
2578−## Security and Continuity
2825+For more on this topic, see the blog post in my Urbit group: “St. Gregory the Theologian and the Liar Paradox”.
25792826
2580−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.
2827+(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?
25812828
2582−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.
2829+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.
25832830
2584−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’.
2831+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.
25852832
2586−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.
2833+Instead, the proper response is to develop a superior account of rationality. Readers can probably guess where I went looking!
25872834
2588−## Ames Audit
2835+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.
25892836
2590−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.
2837+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.
25912838
2592−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.
2839+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.
25932840
2594−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.
2841+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)>).
25952842
2596−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:
2843+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.
25972844
2598−- No one can impersonate another ship on the network
2599−- No one (including relays) can intercept and decrypt messages not meant for them
2600−- Ames messages don’t leak keys that could endanger the sender’s data
2845+Sadly we are conceived in sin and ignorant; hence the need for redemption by Christ.
26012846
2602−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.
2847+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.
26032848
2604−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.
2849+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.
26052850
2606−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.
2851+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.
26072852
2608−## Continuity
2853+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.
26092854
2610−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.
2855+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.
26112856
2612−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.
2857+**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?**
26132858
2614−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.
2859+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.
26152860
2616−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.
2861+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.
26172862
2618−## Status + conclusion
2863+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.
26192864
2620−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.
2865+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.
26212866
2622−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`.
2867+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.
26232868
2624−It's going to be an exciting couple of weeks!
2625−]]></content:encoded>
2626− </item>
2627− <item>
2628− <title><![CDATA[An Email from the Archive]]></title>
2629− <link>https://urbit.org/blog/an-email</link>
2630− <guid>https://urbit.org/blog/an-email</guid>
2631− <pubDate>Sun, 29 Nov 2020 00:00:00 GMT</pubDate>
2632− <content:encoded><
2869+**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?**
26342870
2635−I found this email in my archives recently and thought it might be fun to share publicly.
2871+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.
26362872
2637−```
2638−From: Galen Wolfe-Pauly <galen@tlon.io>
2639−Date: Thu, Jul 2, 2020 at 9:50 AM
2640−Subject: Continuing
2641−To: XXXXXXXXXXXXX
2642−```
2873+Social media companies in the US confront similar governance challenges, so we can analyze them in similar terms.
26432874
2644−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:
2875+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.
26452876
2646−1 -
2877+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:
26472878
2648−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.
2879+(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.
26492880
2650−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:
2881+(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.
26512882
2652−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.
2883+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.
26532884
2654−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.
2885+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.
26552886
2656−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.
2887+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.
26572888
2658−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.
2889+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.
26592890
2660−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.
2891+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.
26612892
2662−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.
2893+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.
2894+]]></content:encoded>
2895+ </item>
2896+ <item>
2897+ <title><![CDATA[A brief update from urbit.org and Tlon]]></title>
2898+ <link>https://urbit.org/updates/2021-04-01-update</link>
2899+ <guid>https://urbit.org/updates/2021-04-01-update</guid>
2900+ <pubDate>Wed, 31 Mar 2021 00:00:00 GMT</pubDate>
2901+ <content:encoded>< 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)
2938+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/
26992939
2700−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)
2940+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!
27012941
2702−Hejduk was able to see that architecture isn’t about building buildings per se, but something else. That was always quite obvious to me.
2942+4 - Landscape news
27032943
2704−Talk soon!
2705−G
2706−]]></content:encoded>
2707− </item>
2708− <item>
2709− <title><![CDATA[Models of Society]]></title>
2710− <link>https://urbit.org/blog/20201119-models-of-society</link>
2711− <guid>https://urbit.org/blog/20201119-models-of-society</guid>
2712− <pubDate>Wed, 18 Nov 2020 00:00:00 GMT</pubDate>
2713− <content:encoded><
2955+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).
27252956
2726−<br>
2957+If you’re interested in working with Tlon or urbit.org, feel free to get in touch.
27272958
2728−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.
2959+7 - Culture recs
27292960
2730−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.
2961+Finally, we’re going to leave you with some recommendations from the team:
27312962
2732−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.
2963+~fabled-faster released an insane new mix that melted my face in a good way: https://soundcloud.com/flowerstructure/fs-s-s-2021
27332964
2734−In order to digitize messages well, computers need to reconcile two facts about all modes of messaging. They have:
2965+Our designer ~natnex-ronret curates a playlist website. Check it out: https://www.door.link
2966+~datnut-pollen has been trying to understand how information processing evolves over time in evolutive systems. Here’s what he’s been reading:
27352967
2736−1. One basic shape, and
2737−2. An infinite variety of forms.
2968+(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.
2969+(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.
2970+(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.
27382971
2739−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.
2972+~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).
27402973
2741−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.
2974+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.
27422975
2743−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.
2976+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
27442977
2745−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.
2978+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.
2979+
2980+~wolref-podlex and ~roslet-tanner
2981+]]></content:encoded>
2982+ </item>
2983+ <item>
2984+ <title><![CDATA[Eliza]]></title>
2985+ <link>https://urbit.org/blog/eliza</link>
2986+ <guid>https://urbit.org/blog/eliza</guid>
2987+ <pubDate>Mon, 22 Feb 2021 00:00:00 GMT</pubDate>
2988+ <content:encoded><
27482992
27492993<br>
27502994
2751−
2995+## The Storm before the Calm
27522996
2753−<br>
2997+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.
27542998
2755−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.
2999+We call her Eliza. She is a data-collection robot.
27563000
2757−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.
3001+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.
27583002
2759−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.
3003+## What Eliza is and isn’t
27603004
2761−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.
3005+> Replicants are like any other machine - they're either a benefit or a hazard. If they're a benefit, it's not my problem.
3006+>
3007+> <cite>Rick Deckard</cite>
27623008
2763−## Urbis ec Bit
3009+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.
27643010
2765−<br>
3011+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.
27663012
2767−
3013+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.
27683014
2769−<br>
3015+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.
27703016
2771−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.
3017+## A New Internet Economics
27723018
2773−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.
3019+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.
27743020
2775−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.
3021+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.
27763022
2777−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.
3023+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.
27783024
2779−_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._
3025+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.
3026+
3027+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.
27803028]]></content:encoded>
27813029 </item>
27823030 <item>
2783− <title><![CDATA[Aesthetic Culture #1]]></title>
2784− <link>https://urbit.org/blog/aesthetic-culture-1</link>
2785− <guid>https://urbit.org/blog/aesthetic-culture-1</guid>
2786− <pubDate>Wed, 11 Nov 2020 00:00:00 GMT</pubDate>
3031+ <title><![CDATA[A brief update from urbit.org]]></title>
3032+ <link>https://urbit.org/updates/2021-02-19-update</link>
3033+ <guid>https://urbit.org/updates/2021-02-19-update</guid>
3034+ <pubDate>Thu, 18 Feb 2021 00:00:00 GMT</pubDate>
27873035 <content:encoded><
3038+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:
27913039
2792−<br>
3040+1 - Scholarships
27933041
2794−_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_
3042+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.
27953043
2796−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.
3044+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.
27973045
2798−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.
3046+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.
27993047
2800−## ~datnut-pollen
3048+If you’re interested in a scholarship, sign up for the waitlist here: https://airtable.com/shr6Xmo55h8dZ0O46
28013049
2802−~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.
3050+2 - Community
28033051
2804−
3052+Our community has been pretty busy lately. Here’s a non comprehensive list of what they’ve been up to:
28053053
2806−## ~lagrev-nocfep
3054+- ~timluc-miptev completed the Bitcoin gall agents. They’re now being integrated into Landscape as a wallet.
3055+- ~sovmep-ripsum finished his work on ucal, an iCalendar-compatible calendaring backend for Urbit.
3056+- ~tabnus-fondeg began work on Urbit LFS (large file storage) for providing file sharing and hosting support.
3057+- ~sipfyn-pidmex is writing a comprehensive suite of documentation for graph-store to enable an easier on-ramp to building new social applications.
3058+- ~minder-folden launched a new hosting provider that you can check out here: https://escapepod.store
3059+- ~naltyc-wornes is contributing a set of official, battle-tested guides for running Urbit on “smol” devices to the urbit.org website.
3060+- ~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
28073061
2808−~lagrev- [made a thread of Dinosaur Comics](https://twitter.com/sigilante/status/1299101593997127680), using the Urbit Whitepaper as the seed text.
3062+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.
28093063
2810−
3064+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
28113065
2812−A sweet poem about the potential for Martian felines is theirs as well:
3066+3 - Foundation growth
28133067
2814−
3068+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.
28153069
2816−## ~litmus-ritten
3070+~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.
28173071
2818−~litmus- produces art full of glowing gases and colourful curves:
3072+~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.
28193073
2820−
3074+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.
28213075
2822−~litmus- also drew Urbitan for the release of OS1:
3076+4 - King Haskell
28233077
2824−
3078+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.
28253079
2826−More of their work is available in the notebooks of the Internet Weirdness Research Unit.
3080+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.
28273081
2828−## ~minder-folden
3082+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
28293083
2830−~minder- stylistically ranges from retrofuturistic memes to flat-out classic 50s retro:
3084+./urbit-king run path/to/your/pier
28313085
2832−
3086+To create a new ship, use the `urbit-king new` command.
28333087
2834−
3088+If you run into any problems doing this, or notice any incompatible behavior, please inform the authorities immediately.
28353089
2836−More of ~minder-’s work is available in his The New Era notebook.
3090+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.
28373091
2838−## ~naltyc-wornes
3092+5 - Getting Started guide
28393093
2840−~naltyc-, & by extension ~dasfeb industries, produces content related to the exploration of Urbit on small & unique computers:
3094+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.
28413095
2842−
3096+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!
28433097
2844−
3098+https://urbit.org/using/install/
28453099
2846−More of their work is available in the smol computers group.
3100+--
28473101
2848−## ~nartes-fasrum
3102+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!
3103+Josh / ~wolref-podlex
28493104
2850−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).
3105+https://twitter.com/urbit
3106+https://github.com/urbit/urbit
3107+]]></content:encoded>
3108+ </item>
3109+ <item>
3110+ <title><![CDATA[A brief update from urbit.org]]></title>
3111+ <link>https://urbit.org/updates/2021-01-15-update</link>
3112+ <guid>https://urbit.org/updates/2021-01-15-update</guid>
3113+ <pubDate>Thu, 14 Jan 2021 00:00:00 GMT</pubDate>
3114+ <content:encoded><
3117+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!
28533118
2854−## ~norsyr-torryn
3119+1 - 2020
28553120
2856−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.
3121+In spite of the many challenges presented over the last year, it was a resoundingly good one for Urbit.
28573122
2858−
3123+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.
28593124
2860−## ~radbur-sivmus
3125+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.
28613126
2862−~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.
3127+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.
28633128
2864−## ~sitful-hatred
3129+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.
28653130
2866−~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.
3131+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.
28673132
2868−
3133+2 - 2021
28693134
2870−## ~tocrex-holpen
3135+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).
28713136
2872−~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.
3137+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:
28733138
2874−
3139+- Rework urbit.org to better help developers learn how to contribute to Urbit
3140+- Since Urbit is ready to build on top of, provide practical guides that demonstrate how to do so
3141+- Guide developers to make high-value contributions to Urbit and its ecosystem
3142+- Build community amongst contributors
28753143
2876−## Landscape
3144+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.
28773145
2878−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).
3146+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.
28793147
2880−
3148+3 - Town Hall
28813149
2882−
3150+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!).
3151+
3152+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!
3153+
3154+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.
3155+
3156+--
3157+
3158+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.
3159+
3160+That’s all for now. See you on the network!
3161+Josh / ~wolref-podlex
3162+
3163+https://twitter.com/urbit
3164+https://github.com/urbit/urbit
28833165]]></content:encoded>
28843166 </item>
28853167 <item>
@@ -3107,112 +3389,39 @@ We also caught wind of https://urbit.me the other day, a nice little tool for fi
31073389
31083390(And we can’t forget about https://urbit.live, the first ones to get into this arena.)
31093391
3110−I wrote a little bit about how I see the future of Urbit Providers here: https://urbit.org/blog/providers/
3111−
3112−3 - Update + updates
3113−
3114−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/
3115−
3116−We also updated our roadmap in Understanding Urbit: https://urbit.org/understanding-urbit/roadmap/
3117−
3118−4 - The beginning of urbit.org
3119−
3120−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.
3121−
3122−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/
3123−
3124−Just recently, he announced the recipients of our biannual Gifts program: https://urbit.org/blog/gifts-q3-2020/
3125−
3126−5 - Hooniversity
3127−
3128−If you’re interested in learning Hoon, the next session of the community-run Hooniversity is set to start on October 12th.
3129−
3130−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/.
3131−
3132−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
3133−
3134−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/
3135−
3136−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.
3137−
3138−See you on the network,
3139−Galen / ~ravmel-ropdyl
3140−
3141−https://twitter.com/urbit
3142−https://github.com/urbit/urbit
3143−]]></content:encoded>
3144− </item>
3145− <item>
3146− <title><![CDATA[Late 2020 Progress Update: OS 1 -> OS 1.N]]></title>
3147− <link>https://urbit.org/blog/20200929-state-of-urbit</link>
3148− <guid>https://urbit.org/blog/20200929-state-of-urbit</guid>
3149− <pubDate>Mon, 28 Sep 2020 00:00:00 GMT</pubDate>
3150− <content:encoded><
3154−
3155−<br>
3156−
3157−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.
3158−
3159−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.
3160−
3161−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.
3162−
3163−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.
3164−
3165−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.
3166−
3167−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.
3168−
3169−### Infrastructure
3170−
3171−
3172−
3173−In April, Urbit was slow, fragile, and didn’t always update itself properly. We made enormous progress on all of these.
3174−
3175−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.
3176−
3177−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.
3178−
3179−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.
3180−
3181−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.
3182−
3183−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.
3184−
3185−### Interface
3392+I wrote a little bit about how I see the future of Urbit Providers here: https://urbit.org/blog/providers/
31863393
3187−
3394+3 - Update + updates
31883395
3189−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.
3396+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/
31903397
3191−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.
3398+We also updated our roadmap in Understanding Urbit: https://urbit.org/understanding-urbit/roadmap/
31923399
3193−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.
3400+4 - The beginning of urbit.org
31943401
3195−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.
3402+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.
31963403
3197−
3404+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/
31983405
3199−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.
3406+Just recently, he announced the recipients of our biannual Gifts program: https://urbit.org/blog/gifts-q3-2020/
32003407
3201−### Community + network
3408+5 - Hooniversity
32023409
3203−
3410+If you’re interested in learning Hoon, the next session of the community-run Hooniversity is set to start on October 12th.
32043411
3205−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.
3412+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/.
32063413
3207−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.
3414+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
32083415
3209−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.
3416+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/
32103417
3211−### What’s next
3418+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.
32123419
3213−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.
3420+See you on the network,
3421+Galen / ~ravmel-ropdyl
32143422
3215−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.
3423+https://twitter.com/urbit
3424+https://github.com/urbit/urbit
32163425]]></content:encoded>
32173426 </item>
32183427 <item>
@@ -6804,111 +7013,6 @@ We think that a new system like this, even in a simple form, will be a relief fr
68047013<img class="mv5 w-100" src="https://media.urbit.org/site/understanding-urbit/your-last-computer/your-last-computer-ocean%402x.png">
68057014
68067015Your 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.
6807−]]></content:encoded>
6808− </item>
6809− <item>
6810− <title><![CDATA[~2019.10 Roadmap]]></title>
6811− <link>https://urbit.org/blog/2019-10-3-roadmap</link>
6812− <guid>https://urbit.org/blog/2019-10-3-roadmap</guid>
6813− <pubDate>Wed, 02 Oct 2019 00:00:00 GMT</pubDate>
6814− <content:encoded><
6816−
6817−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.
6818−
6819−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.
6820−
6821−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.
6822−
6823−## Identity (Azimuth)
6824−
6825−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.
6826−
6827−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.
6828−
6829−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.
6830−
6831−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.
6832−
6833−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).
6834−
6835−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.
6836−
6837−**Q4 2019**
6838−
6839−- Release Bridge to the public
6840−- Get Bridge working well on mobile
6841−- Add payments support, hopefully including BTC
6842−- Add a network explorer
6843−
6844−**Q1 2020**
6845−
6846−- Integrate Bridge with a native app for Arvo
6847−
6848−## OS (Arvo)
6849−
6850−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.
6851−
6852−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.
6853−
6854−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.
6855−
6856−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.
6857−
6858−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.
6859−
6860−### Landscape (Arvo UI)
6861−
6862−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.
6863−
6864−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.
6865−
6866−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.
6867−
6868−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.
6869−
6870−**Q4 2019**
6871−
6872−- Improved Arvo-level error handling
6873−- Implementation plan for ‘telescoping kelvins’ — or [how we plan to future proof Arvo](https://groups.google.com/a/urbit.org/forum/#!topic/dev/6Mwn6TQFVwc)
6874−- Versioning scheme between Arvo and Vere
6875−- A new Haskell implementation of the daemon
6876−- A native client (instead of just a browser tab)
6877−- A [new user-space architecture](https://docs.google.com/document/d/1hS_UuResG1S4j49_H-aSshoTOROKBnGoJAaRgOipf54/edit)
6878−- Hoon.hoon that’s OTA upgradeable
6879−- Working Jacque prototype, a graal-truffle-based implementation of vere
6880−
6881−**Q1 2020**
6882−
6883−- Integrated client with Bridge and Arvo
6884−- New interface framework, codenamed ‘Widescreen’
6885−
6886−## Docs + Community
6887−
6888−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.
6889−
6890−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.
6891−
6892−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.
6893−
6894−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.
6895−
6896−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.
6897−
6898−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.
6899−
6900−**Q4 2019**
6901−
6902−- Vane level documentation
6903−- An active grant program
6904−
6905−## urbit.org
6906−
6907−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.
6908−
6909−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!
6910−
6911−That covers it for now. If you have questions or want to chat — find us in `~dopzod/urbit-help`. See you online!
69127016]]></content:encoded>
69137017 </item>
69147018 <item>
@@ -7206,105 +7310,6 @@ Until next time.
72067310In 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/).
72077311
72087312Until next time.
7209−]]></content:encoded>
7210− </item>
7211− <item>
7212− <title><![CDATA[~2019.5 Roadmap]]></title>
7213− <link>https://urbit.org/blog/2019-5-roadmap</link>
7214− <guid>https://urbit.org/blog/2019-5-roadmap</guid>
7215− <pubDate>Wed, 15 May 2019 00:00:00 GMT</pubDate>
7216− <content:encoded><
7218−
7219−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.
7220−
7221−At a very high level we have two goals for 2019: make Azimuth easier to use, and get Arvo to a 1.0.
7222−
7223−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.
7224−
7225−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/).
7226−
7227−For now, let’s just look at what’s on the immediate horizon:
7228−
7229−## Azimuth
7230−
7231−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.’
7232−
7233−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.
7234−
7235−So the question is why haven’t we told the world about it?
7236−
7237−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.
7238−
7239−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.
7240−
7241−Here’s what we’re building first:
7242−
7243−### Q2 2019
7244−
7245−- A simplified onboarding flow for getting an Azimuth point that’s simple to share with friends over email, text or as a URL.
7246−- A redesigned and improved Bridge for managing your points.
7247−- An interface that allows you to easily send money between Azimuth points without running Arvo.
7248−
7249−### Q3 2019
7250−
7251−- Expanded Azimuth-centric example modules, documentation and developer tooling.
7252−
7253−Still under consideration:
7254−
7255−- An OAuth server or JWT flow for logging into any service with an Azimuth point.
7256−- A mobile app for point to point payments using Azimuth.
7257−
7258−### 2020
7259−
7260−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
7261−
7262−## Arvo
7263−
7264−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.
7265−
7266−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.
7267−
7268−There are still rough edges, and Landscape is not nearly general purpose enough, but we have plans:
7269−
7270−### Q2 2019
7271−
7272−- 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.
7273−- 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.
7274−- Significant improvements to testing with a new simulation testing framework and integration testing pipelines.
7275−
7276−### Q3 2019
7277−
7278−- A significant overhaul to Gall, our application model, making it much simpler for users to write apps or ‘agents’ in Arvo.
7279−- 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.
7280−- 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.
7281−- Tooling for hosting and hopefully a beta program for hosted Arvo instances run by Tlon.
7282−
7283−### 2020
7284−
7285−- 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.
7286−- We come to work every day, use Arvo, go home.
7287−
7288−## Community
7289−
7290−We’ve often felt like it was far too early to invite others in to the system.
7291−
7292−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.
7293−
7294−Hoon school was the first effort in this direction. We intend to do a lot more:
7295−
7296−### Q2 2019
7297−
7298−- Scaling Hoon school up to include both a track for experts and for beginners, and allowing many more participants.
7299−- Holding more meetings and events on Landscape, experimenting with Arvo-native discussion.
7300−- A clear program for address space grants for developers + contributors.
7301−- New documentation site with searchable library docs.
7302−
7303−### Q3 2019
7304−
7305−- Hoon School participants understand clearly how to build a Modulo agent, and invite others into it.
7306−- The road toward building an Azimuth module is well understood, paved, and clear.
7307−- We have clear instructions and tutorials for building Azimuth modules and using Azimuth as a login or reputation primitive.
73087313]]></content:encoded>
73097314 </item>
73107315 <item>
@@ -17544,6 +17549,24 @@ You’ll choose between two tracks:
1754417549
1754517550- Assembly: Assemble software or work together on projects in small groups
1754617551- Workshop: A two day workshop taught by Neal Davis, Urbit for Developers
17552+]]></content:encoded>
17553+ </item>
17554+ <item>
17555+ <title><![CDATA[Assembly Keynote Live Stream]]></title>
17556+ <link>https://urbit.org/events/2021-10-16-assembly-keynote</link>
17557+ <guid>https://urbit.org/events/2021-10-16-assembly-keynote</guid>
17558+ <pubDate>Invalid Date</pubDate>
17559+ <content:encoded><![CDATA[
17560+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.
17561+]]></content:encoded>
17562+ </item>
17563+ <item>
17564+ <title><![CDATA[Assembly Software Distribution Q&A Live Stream]]></title>
17565+ <link>https://urbit.org/events/2021-10-16-assembly-sw-dist-qa</link>
17566+ <guid>https://urbit.org/events/2021-10-16-assembly-sw-dist-qa</guid>
17567+ <pubDate>Invalid Date</pubDate>
17568+ <content:encoded><![CDATA[
17569+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.
1754717570]]></content:encoded>
1754817571 </item>
1754917572 <item>
@@ -17566,6 +17589,21 @@ From there Robert will hit on many topics including:
1756617589
1756717590Robert 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.
1756817591
17592+Hosted by Josh Lehman, the Director of the Urbit Foundation.
17593+]]></content:encoded>
17594+ </item>
17595+ <item>
17596+ <title><![CDATA[Developer Call: Running a Hosting Provider]]></title>
17597+ <link>https://urbit.org/events/20211028-developer-call-hosting</link>
17598+ <guid>https://urbit.org/events/20211028-developer-call-hosting</guid>
17599+ <pubDate>Invalid Date</pubDate>
17600+ <content:encoded><![CDATA[
17601+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.
17602+
17603+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.
17604+
17605+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.
17606+
1756917607Hosted by Josh Lehman, the Director of the Urbit Foundation.
1757017608]]></content:encoded>
1757117609 </item>