what is this?

[p. j.]

my endless confusion re: urbit and seeking answers got me sent to this mailing list, provided i ask in good faith, which i'm more than willing to.

it is very hard for me to understand what urbit /is/, for the most holistic and broad definition of is-ness i can muster.

i'm a security researcher and software engineer who also reads a lot of philosophy/critical theory, horror comics, pulp sci-fi or whatever; i hack on 9front and inferno in my free time, generally an intense contrarian that constantly aches for the new and the different in computing. i sort of figured i would be your target audience, but i'm... not exactly sure?

for someone like me who has a pretty robust technical background, who read the urbit whitepaper and has combed through a number of parts of the source wondering how functionality x is implemented - this only causes more dissonance about what this project is, what it is trying to accomplish. it feels like there is at least four urbits:

1. the urbit yarvin wrote (and/or intended?)
2. the one that currently exists
3. the one that urbit.org talks about, the one described in radio interviews - the PR urbit
4. the urbit of the future that has aspirations beyond the one that exists now

i think i have a decent-enough understanding of 1 and 2. there are a number of design and implementation decisions that jump out at me as total show-stopping problems, but perhaps this is due to a severe ideological difference, which is fine and understandable.

3 and 4 are what really confuse me. every claim seems, to me, to be either nakedly disingenuous or an outright lie. eg, i spun up a comet to do some feature analysis, and the first thing i clicked on told me to link an s3 bucket. like, ok, fine for anything else, but your copywriting says with little room for ambiguity that you are not doing precisely this.

the other day i was thinking about the processes of planets receiving updates from stars, and went to seek out if there was a notion of consent or negotiation here. finally finding an answer in the whitepaper (i truly had to dig), i see: "Normally, the child automatically syncs and loads source updates from the parent. Subscribing to an update server requires almost complete trust; this problem is not unique to Urbit, however." alright. my iphone basically does this, who cares: except for the stressed concepts of ownership and sovereignty(?) that this seems to negate

the examples are endless - just scrolling through this list to judge the milieu before posting i found the announced goal of getting people's cloud-independent personal servers back into the cloud

so, whatever. i'm informed enough to know that this isn't a product i wish to purchase, which is ok. but because this lies at a nexus of many of my interests, i can't help but go back to examine parts of this design. i can't tell what is ideology, work-in-progress, inflated claims to get venture capital funding, or possibly a pyramid scheme? (this is not moral judgement, if it's a scam to do fun computer experimentation, i find that admirable. i'm just trying to figure it out.)

so, with that longwinded background to establish context, my question is - how would you, in conversation with a technically competent person - describe what you are working towards?

thanks
phoebe

[~forfel-norfel]

I'm just an enthusiast and I don't represent the project, but I figured I'd offer my opinion.

It's important to recognize that often the work towards a goal requires doing something that seems completely contradictory.

Bitcoin's goal is to be deflationary, but for its first 10 years it had far more inflation than the fiat currencies it's trying to replace. Bitcoin is pointless if it's not widely distributed and distribution is inflation.

People should have full control over the software updates they install, but first they're going to need to be running stable software that they want to be careful about updating. Developing useful and stable software requires many updates. You can boot a planet now and refuse to ever update it, but allowing it to auto update is going to offer you way more value for the foreseeable future.

Urbit's goal is to be useful. Text chat is one of the things that it's useful for right now, but people also like using images, and Urbit isn't good at hosting images yet. Do you take a principled stand to only rely on Urbit for everything or do you build something people want to use and gradually migrate as much as possible?

If Urbit is a scam, I've been scammed, and I really hope they keep scamming me.

--
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@urbit.org.

[Tyler Shuster]

Here’s my story:

Modern computing has used the same model for 50 years — the one invented at Bell Labs in the 70s.

MacOS, Linux, and Windows all use this same model. MacOS and Linux even use the same *software* (basically).

This model no longer works — partially because it assumed things like “people will share computers because computers are too expensive” — partially because it could not have anticipated the developments it made possible, like the internet.

We could not have achieved what we have without this model, but it has become clear that we can no longer use it to think about what a computer is.

A computer is not a stationary, isolated box, accessed by multiple people. The most ubiquitous computer — a mobile device — is handheld, connected, and personal.

So, Urbit reimagines computing *from scratch* — but with the lessons learned of the last 50 years.

Right now, it’s just text communication, but people like to say that Urbit is “Speedrunning the Internet” which means that we’re trying to reinvent all of the affordances we’ve grown used to at 10x speed. Right now we’re at the email stage, basically.

Urbit builds from the ground up while using the current stack to bootstrap itself. Currently Urbit runs in a virtual machine, but it *could* run on real circuits. The processor architecture just hasn’t been written yet. 

The whole system is in a similar state where the fundamentals are solid, but the implementation details haven’t crystallized yet.

I think there are some questions about specifics buried in your message, but I hope that this generally addresses your questions about what urbit *is*.

[p. j.]

>> It's important to recognize that often the work towards a goal requires doing something that seems completely contradictory.

that's fair - perhaps i should word it like this then: what is the goal? i recognize that the s3 is a hack, but there are a number of fundamental design issues that seem contrary to the goals of the site as-stated (nock/hoon/networking hierarchy/hierarchy in general/the identity system/"digital land").

another interpretation of this project i had was that is was beuys-esque social sculpture - but there is generally not much to support that notion

>> If Urbit is a scam, I've been scammed, and I really hope they keep scamming me.

i apologize for offense with that, there's really no tactful way for me to ask that question. in general though, this struck me as the most likely explanation as an curious outsider.

[Mark]

Good faith assumed and accepted, thanks. Hi! (:

I've been working on Urbit full-time for ~5 years now, have been up and down the stack, and consider myself an "urbit maximalist". I'll give you my personal perspective and thoughts here. Note that not everyone working on the project (let alone hanging out on/around it) shares these exact views. Urbit is big enough to mean different things to different people.
I'd encourage others to share their own perspective if they deem it useful, or just pedantically correct the generalizations and simplifications I'm about to make below!

You do certainly sound like like you'd easily slot into the O.G. Urbit target audience. Some have described Urbit as "contrarian computing", because it essentially says "computers in general are garbage, we need to do away with *everything*."

The tldr answer to your question of "what are you working towards" is, uh, somewhat necessarily vague. I'd say "Urbit is a computer" and mean "computer" in the broadest sense of the word, encompassing the entire (hardware and) software stack. I assume you've already read about this. I'm personally working towards a world in which my entire computing experience lives exclusively on Urbit. I don't want to see or touch any Linux, any C, any Webkit. Urbit-native all the time. Why? Urbit, from a technical perspective, is smaller and easier to understand, more _actually mine_ than anything that exists today, and this ripples out to my user experience.

Now, you're correct in seeing multiple different Urbits. I'll use the ones you listed as a framework for my explanation, giving one-line summaries and then expanding a little bit. I won't skip over 1 and 2, just in case we aren't already on the same page.

> 1. the urbit yarvin wrote (and/or intended?)

The Urbit Yarvin wrote on his own was a proof of concept, showing a new way of computing.
The Urbit Yarvin wrote with the company (Tlon) was a usable alpha for a technical crowd.

> 2. the one that currently exists

The Urbit that currently exists is a young yet robust from-scratch computing stack that desperately wants a software distribution story so it can stop being confused for its one big userspace product.

> 3. the one that urbit.org talks about, the one described in radio interviews - the PR urbit

The Urbit that gets talked about in marketing materials is a blurring between Urbit proper, Urbit's userspace experience, the things being worked on, and the vision for the future.

> 4. the urbit of the future that has aspirations beyond the one that exists now

The Urbit of the future is the only legal form of computing.


Let's talk about those Urbits (rather, phases of Urbit) in a bit more detail.

1. Yarvin's Urbit

You've probably read about the fundamental pitch by now: the internet is fscked because the software it's built on is fscked. If you want to fix this, you need to do away with the whole thing, learn what you can from the smoking ruins, and build anew from the bottom up.

Yarvin was bad enough a dude to actually attempt that. Many years later, he emerged from his garage with Nock ("assembly replacement"), Hoon ("C replacement"), and a prototype Arvo ("kernel replacement"). The craziest thing: it actually worked. He had built a peer-to-peer operating system from nothing.

That prototype contained a lot of interesting ideas, and many of those we're still moving forward with today. Of course, the thing wasn't perfect, nearly all components of it have been written many times over since the olden days. Some ideas abandoned, some transformed, some put in the freezer for later. Rome wasn't built in a day, and an as-perfect-as-possible software stack isn't built in a single iteration.

The minimal prototype was interesting enough to get funding, letting Yarvin start a company that he'd leave and entrust the fate of the project to not many years later.

2. Tlon's Urbit

Tlon was originally established for the purpose of developing Urbit, plain and simple. But Urbit is a research project, how do you even begin to make money off of that?

I assume you've read about the address space, and can conceive of that as a limited source of income. Nobody will want to buy address space for a network that's all abstract and technical though. You can get by on that for a couple of years, but eventually people will ask you what you have to show for all the work. "Look at this kernel!" you say, but the world sees some nerds in a basement.

Luckily, you have this peer-to-peer operating system, at a time where BTC-USD is still in the lower triple digits. This world is about to become booming, and you already have all the tools you need!

So you build a web interface for your cli chat app. You realize you want a forum, and build that too. Maybe you make these things accessible over the public internet somehow. Now it's *real*. And you do it all in a matter of months. $2 billion company for a chat app? No thanks, just have the intern do it.

This continues and repeats for a little while. You get good at figuring out what to build, how to play to your strengths. Sometimes weaknesses in lower layers of the system come to light. You spend half a year redesigning the thing, and it's worth it.

After a while, Tlon ended up with an entire suite of userspace applications, and a fancy web client for interacting with them. They're good, but they're also "the Urbit experience" for many people. When you use Urbit today, you rarely see the OS. In some sense, you never really did. You're seeing the applications.

This isn't bad in and of itself. But Urbit doesn't have a software distribution story yet, meaning you're kind of locked into whatever has been deemed acceptable to ship with the distribution that you're subscribed to.

At this point, rectifying that is on the top of the list. Relatedly, you may or may not have noticed some distinction between "Tlon" and "Urbit.org" (aka the Urbit Foundation). The former is in the business of staying alive as a company of developers and making products/services on top of & around Urbit. The latter is in the business of making Urbit itself and the ecosystem around it flourish.
This separation is very young and still incomplete in many ways. It's a gradual process, but a necessary one. Landscape has S3 integration, but Landscape is not Urbit. We're working on making it not feel that way.

3. The news' Urbit

It's easy to overpromise. We do that sometimes, or even more often we just don't communicate clearly enough. Talking is hard!

More seriously, it's generally just the case that there's overlap between the way we talk about Urbit, and the vision we have for it. Yes, indeed you can choose exactly who you get your OS updates from! But it's also the case that in the current moment, there's only one party pushing them out, and you need theirs to stay connected to the rest of the network that gets theirs.

4. The Martians' Urbit

In the future, Urbit will be a vast and diverse network of peer-to-peer personal servers. Various forks of the operating systems will run side-by-side. Many applications, clients and runtimes will be there for you to choose from. Writing peer-to-peer software will be simple (actually, I think we're already 80% on this), your data will be durable, and your computing experience will be fully yours.

Nearly all of the things we promise, we want to deliver on. As others have already mentioned, staying alive in the present demands sacrifice in the short-term. But I certainly refuse to lose sight of the long-term vision, and I'm sure most everyone else feels the same way.


...Was that too much? Maybe that's a bit too much prose and too little substance. Let me address some of your stated concerns (that haven't been included above) to close this out:

> alright. my iphone basically does this, who cares: except for the stressed concepts of ownership and sovereignty(?) that this seems to negate

Does it negate ownership and sovereignty if you choose who to trust?

Urbit is a high-trust network. You've probably read about how identities are scarce, and how this incentivizes people to behave well with it. There's of course all kinds of game-theoretic rabbit holes you can dive down here, and ultimately people aren't rational actors after all... but you're always in control.

Right now, your *practical* range of control is choosing between "I pick someone to spoon-feed me the same updates as everyone else" and "I don't get updates at all". As previously stated, this will improve in many different ways.

(Actually, that's not entirely right. There's already a small amount of people pushing out lightly-modified distributions with new applications in them!)

> the announced goal of getting people's cloud-independent personal servers back into the cloud

I definitely agree this flies in the face of the old-school marketing copy that said Urbit should be simple enough for your mother to administer.

Is it simpler to run than a full Linux server? Yes. Do you still need *some* knowledge of Linux servers to run Urbit? ...Also yes.

You can imagine a world wherein Urbit is a .app or .exe or some such thing that anyone can trivially install on their laptop or phone. I believe a community member is working on just such a thing!

But that doesn't invalidate the *option* for someone to offload the self-hosting risk to some other party. For example, for my work machine, I keep backups on an external drive. The external drive is in my house, where my work machine lives. If my house burns down, I'm screwed. If I was a smarter man, I'd pay someone to keep a copy of my backups off-site.

> or possibly a pyramid scheme? (this is not moral judgement, if it's a scam to do fun computer experimentation, i find that admirable. i'm just trying to figure it out.)

The detractors are right. Urbit is literally a pyramid scheme. It's also performance art. And all of that is actually good. (;

(You might also find some useful counter-arguments on the "common objections" page, in case you haven't seen that yet.)
https://urbit.org/blog/common-objections-to-urbit/


Hope this is a useful perspective to you. Again, from your background, Urbit seems right up your alley. But it's also initially opaque, and heavily in development, and dealing with mulitple-personality disorder.

If you ever feel like starting your comet back up, don't hesitate to DM me (~palfun-foslup) if you want to chat. Thanks again for enquiring in good faith, that's the Urbit way. (:

—
~palfun-foslup
https://urbit.org

[Philip Monk]

I'll give a philosophical answer because, while it's maybe not quite what you're looking for, I've been trying to vocalize it recently and this is a good writing prompt.

I constantly feel the whole "it feels like there is at least four urbits".  The modern urbit.org version of Urbit is a very particular way of looking at Urbit.   It's not wrong, and it's not secondary, it's just a particular perspective.  I can see that perspective, but I have to sort of cock my head and close one eye to see it, because when I look straight, it looks like it's primarily a clean-slate rewrite of the whole stack under a foreign set of principles and with an unusual engineering methodology.

I've said before something like "you can ask ten people what Urbit is and you'll get ten different answers, and they'll all be right".  We lack the context for me to convince you that they're (almost all) right, but it's worth thinking about the classes of things which are consistently described differently by/to different people.

Scams do this -- morph yourself to be whatever the mark is looking for.

Big projects often have this property too.  What is the internet, and what is it good for?  Some view it as a political project, giving voice to the masses, and spreading information.  Others as a way to take ownership of their life by starting an internet-enabled business.  Others see it as a way to meet new people and keep track of old friends.  I'm not claiming we're anything like as big a deal as the internet was -- I'm just listing archetypes.

Spirituality too: Catholics may have a catechism answer for "what is christianity", but among Christianity in general you'll get a lot of different responses.  Some are due to genuine doctrinal differences, but also religion is *big*, and some parts will be much more salient for certain people, according to their situation, experiences, personalities, and values.  I speak of Christianity because I'm most familiar with it, but this is true of many religions.

A city is another good example.  San Francisco in the 2010s was a magical place for me, because it was a place with an incredible concentration of technology talent and a culture which could take advantage of that.  A friend would pitch his startup idea to you in a restaurant and someone at the next table would ask to invest.  Anyone you interacted with in the park was probably connected to tech.  When I talk about SF, that's what I talk about.  Lots of people talk about the crime, the dirt, the mismanagement, the destruction of older ways of living by faceless short-lived companies with massive coffers.  All of these things are true too, maybe even *more true* than my own experience, if there are gradations of truth.

The common ground here is that these are general-purpose concepts.  A city supports an incredible variety of experiences, religion is meant to apply to everyone in every context, the internet can be used for everything, and, yes, scams work best if they can take in anyone.  Sometimes people (myself included) say "big" when they mean "general-purpose", which causes confusion.

Urbit is general-purpose both in the sense that it's a platform to run lots of different apps and in the sense that it's a school of software engineering that can apply to lots of different software.

*My* answer to "what is Urbit" is that it's a discipline of how to build things, and that results in a particular type of output.  Some engage in this because they like the output, others because they like the discipline.

This is a super grandiose answer (though you did ask for the "for the most holistic and broad definition of is-ness").  The down-to-earth way to think about it is that we got tired of all the muck in normal software and decided to do it right, and then we took it way too far.  I never would have had the ego required to think it *could* be rewritten from scratch, but when I saw how far Curtis had gotten, I realized it could be done.  This realization happened over a period of years for me, but I didn't have the common ground that you already do.

Of course, "do it right" is very opinionated!  Some have joined the project and left because, while they shared the belief that we can and should redo everything, we didn't agree on the right way to do it.  They might turn out to be correct in the end.  Or maybe it'll turn out that you can't practically rewrite it all.

An example of the kind of principle we have that nobody else has, is that everything on your Urbit has rigorously-defined semantics.  Urbit OS is a function from [event old-state] -> [effects new-state], and that function is defined by nock (a page of text) and then a few tens of thousands of lines of hoon, which includes a compiler from hoon to nock.

And this goes all the way up to your app.  If your app depends on a couple libraries, then you can understand its entire rigorous semantics by reading the nock spec, 14,000 lines of stdlib+parsers+hoon compiler, 2000 line kernel, 8000 more lines of stdlib, 2000 lines for the userspace application runner, and then whatever other libraries or kernel modules you utilize, which is not likely more than a few thousand lines.

It's not trivial, but those are not big numbers, they're not fake, and most of them are the same for every app.  If you tried to precisely specify what the "ping" command does on Unix, it would take you ages, which is why nobody has done it, and certainly not *constructively* in terms of how it's actually implemented.

Of course, academics love to specify stuff rigorously and have never gotten close to this scale of a rigrously-specified project.  You may have heard accusations that we're anti-academic, but it took Nixon to go to China.

And specification is not even a core principle of ours, it's just an example of the kind of thing we thought would obviously be a nice property.  And then we're stubborn enough to apply it to everything.

I'll stress that this is my answer because of my experiences and values.  The pitch that Urbit is a personal server to take back ownership of your data from megacorps is also correct.  From my perspective the causation is "we wanted to build good software that has more natural properties, and to do that right everyone should have their own server".  From another perspective the causation is "we wanted digital freedom, but megacorps exist because the stack is so complex, so we rebuilt it."  These have roughly the same effect, and you can't even give a "historically true" answer because the people working on the project have always had different motivations.

We constantly hammer the idea that Urbit should be "simple, durable, yours".  Someone jokingly asked "which one is your favorite?" I'd love to see the distribution of answers, because it's a great question.  I'm on team "durable".  The website is clearly written with a bias toward "yours".  Nock enthusiasts skew toward "simple".

We make a good team because complex things cease to be under your control, anything not under your control can't last as long as you want it to, and anything built to truly last must be simple, like the pyramids.

[~forfel-norfel]

The goal is all of the stuff that you read. It just doesn't look like that yet and the final result probably won't match either just because this is R&D to reinvent computers and the internet in a way that fixes the problems with the current one. If you build something and it matches the plan, you're probably assembling furniture.

My understanding of the goals:

-remove unnecessary complexity in operating systems and software

-make PCs reliable

-build a foundation that includes locally running replacements for common services that currently require depending on a company like Google or Facebook

-make it easy for developers to extend those local services and build new ones that allow people to remain in control of their digital lives

-provide a native identity system that solves problems with spam, DoS attacks, conventional user accounts and passwords, reputation, changing IP addresses and networks, DNS, and NAT

-prevent computers and the internet of the future from having the same concentration of power that exists today

I've been meaning to write a guide to Urbit because I don't think any of the existing information is good enough for new users and anyone who's only casually interested. Maybe I'll do that soon.

And I'm not at all offended by the idea that it's a scam. Anything that's so obviously not a scam probably wouldn't keep me interested for very long.

[Matilde Park]

Happy to pick up where we left off, p. But yeah, note this is all my opinion, etc etc. I run Landscape team, have worked on project for almost two years.

> so, whatever. i'm informed enough to know that this isn't a product i wish to purchase, which is ok.

I’m on team “your Urbit should be a cube you run in your house” or “your Urbit should *be your computer* talking to other computers directly”. Tlon as a Corporation has had direct experience with many “normies" who cannot do this from CLI; and while we can and do now have the way to have some Electron web app interface boot and resume your ship for you, it’s still not amazing latency. We prioritised UX for a holistic consumer-oriented product.

But importantly, the option is open to run it however you like. It’s about the choice that makes stuff like email cool; it’s not a tragedy that one provider dominated for normal people. You don’t have to give us or anyone else money. You shouldn’t even have to use an ISP, you should be able to just have a buddy ship who passes your packets on for you when you visit his house, or steal the cafe wifi or whatever. But you should also expect a bumpy ride without these conveniences!

This is why the multiple entities stewarding Urbit instead of one corporation providing a product is important for an ocean this size — and why I stressed such in the presentation I gave just last week.

If we’re asking “why Urbit” for me personally then I’m also happy to expand on my love of weirdness. I grew up watching Hackers and reading the manifestos and screeds about a very cyber-libertarian, gray tribe freedom. I think that whole culture is sort of dead and I mourn it. What I loved about both Curtis and Edward Snowden is that they were both interested in the same thing for the same reason: remembering the feel of Usenet, and seeing how clearnet provides a “chilling effect”. One was surveillance by “everyone watching everyone else”; the other was literal surveillance by Leviathan. And both seeked to destroy the chilling effects with their own specific analysis.

Landscape as a product thinks that a natural fit on top of Urbit’s inability to have a central server cataloguing all people is a labyrinthine, human-scale party; you walk from group to group, stumble into person by person, and each one is practically invisible unless you know the words. Each one curates and creates together. Each one has personal space, cannot have the data they download forcibly removed by a foreign entity.

The efforts I see in remedying these problems does so by a sort of retrofuturist restoration of older projects; the simple fact is that innovation in operating systems hasn’t happened in at least twenty years, but it can totally be done again. Urbit is the first time I haven’t felt like I was in a LARP; that I was using what was available in the present to build something in a logical way, that altogether patiently considered an incentive model that averted rentierism. The more I have experienced the world, the more rentier everything is — a gigantic pyamid of plugged flows of “wealth” spawning wealth for the reason that you had some to begin with. If you buy a galaxy, it’s not going to be worth anything unless you put in the work to make the network better. You are incentivised to give stars or sell stars to parties who will, in turn, not be freeloaders. There is a speculation event horizon where Urbit becomes useless. So Tlon only even sells to people who understand what the thing is.

All in all I encourage you to get as technical as possible here, though I can’t promise I can reliably attest to *everything* in turn myself.

Best —

—
~haddef-sigwen
https://urbit.org

[p. j.]

firstly: thank you all for contributing responses to this. it's helped immensely, and i appreciate that effort.

>> I'll give a philosophical answer because, while it's maybe not quite what you're looking for, I've been trying to vocalize it recently and this is a good writing prompt.

while all of the answers have been helpful in their own right, this is /exactly/ what i was looking for, and i appreciate it a lot. i did the somewhat asinine thing of explaining my background to indicate that, hey, i'm clearly aligned with you all for a lot of the way - i use plan9 as my main operating system, then osx for all the junk ;) experiments with inferno, oberon, forth, VMs written by friends, you don't have to waste much breath telling me that unix and the current internet is a disaster. the tagline i wrote for one of my sites is "all of our computers are connected with each other and this state of affairs should be more interesting than what we seem to have now"

i realized after the first few responses that the better phrasing may have been "why urbit?" in light of this. in some sense, i'm understanding that it comes down to "it's there". after all, that's why i'm using 9front - it's there, it works, it's not perfect but it's promising to me.

then with most human choices, it comes down to aesthetics. urbit certainly has done well with that through the stack, so i understand the attraction to it.

though, ultimately here, i feel i am in the category of "[sharing] the belief that we can and should redo everything, [but not agreeing] on the right way to do it", but feel a lot more confident that i understand where you all are coming from

and again - thanks

[p. j.]

hello Matilde :)

>> Urbit is the first time I haven’t felt like I was in a LARP; that I was using what was available in the present to build something in a logical way, that altogether patiently considered an incentive model that averted rentierism. The more I have experienced the world, the more rentier everything is — a gigantic pyamid of plugged flows of “wealth” spawning wealth for the reason that you had some to begin with.

i find it interesting that you bring this up, because i have had an identical experience with the world, and from everything i had gathered urbit was deliberately turning this from a de facto to a de juro state of affairs. eg - i can open up something that monitors nft trading and see that stars can trade hands for thousands of dollars, so certainly galaxies have /some/ social or economic capital inherently, gained from being in the right place at the right time. i think the urbit website might actually use that language verbatim.

so, if i was, say, a tlon employee owning some of this property, of course i would want to champion urbit, drive people to gobble up digital land, and profit ;)

[Matilde Park]

Do we really align with that reading, though? Urbit people are almost annoyingly idealistic in my experience. Tlon especially. 

— 
~haddef-sigwen
https://urbit.org

On Mar 26, 2021, at 9:34 PM, p. j. <pho...@slub.co> wrote:

hello Matilde :)

[p. j.]

>> Do we really align with that reading, though? Urbit people are almost annoyingly idealistic in my experience. Tlon especially.

i do regret wording it that way - i didn't mean hostility, but i figured since you share the same viewpoint you'd understand my skepticism of your claim.

while what you say is true (i've seen more than one person pondering publicly about what it'll be like when every human alive is clamoring for an identity), that doesn't seem mutually exclusive with my skepticism. you're a company, yarvin had a philosophy, scarcity is a profit model. so yes.

i don't think that's a bad thing. research needs to be funded. it is just not intuitive to me how what is happening - at least presently - is not rentierism. i suppose i can see how incentives could cause a trend away from rentierism on a long enough timeline and adoption level though.

[Philip Monk]

There's a common assumption that being against SaaS megacorps means being against property rights in any form, as though owning something or making money leads directly to the world we have today.  Some people involved with Urbit aren't so hot on modern property rights, but they existed in some form or another for a really long time before anyone invented SaaS, and with little correlation to how free people are.  What works poorly is when you can't own something you depend on, and can't be sure to have access to it, usually due to a monopoly.  The problem with SaaS is not that they make a lot of money, it's that they own your data and online experience, and you can't exit.

Stars have value from two sources: one is that they can spawn planets.  If you accept the need for a finite number of planets (sybil resistance, both for in-band spam and for the PKI itself, since if it's too big you have to depend on central sources of truth), then they need to be distributed somehow.  There aren't many better ways than for them to go to the people involved early on.

This doesn't lead naturally to centralization or rentierism, since the only way to make money on these planets is to sell them, at which point you have no more rights to them.  There's no way to lock someone in.  If someone tries to *rent* you a planet, I recommend you turn them down!  (Unless it's a temporary thing because of high gas prices...)

The second source of value is that stars provide various services to the planets they sponsor.  Ultimately, there are a few services you'll need that you (or most people) won't want to do for yourself.  The two we bring up most commonly are peer discovery and software updates, since they're what stars and galaxies are used most for right now.  When someone wants to find my planet ~wicdev-wisryt, they ask its star/galaxy where it is (ip/port) and then talk to it.  If one or both sides are behind a NAT, the whole conversation might be proxied through a star/galaxy.  You need a standard way to find the parent (and be able to change your parent if they stop servicing you), and the galaxy/star/planet hierarchy works for this.

Some things require so much hardware that people don't want to run it themselves, but you do need to trust who's running it.  Running a bitcoin/ethereum node is an example.  This is the sort of service a star might provide, and since you have a pre-existing relationship with that star (financial or otherwise), your incentives will aligned so they won't need to inject ads or whatever.

This is somewhat speculative, though.  Stars a natural place for these services to be, but I wouldn't be shocked if they ended up not being connected to stars, except the bare services required for peer discovery, which should be quite cheap.

These services should be priced according to the benefit you derive from them, and the safety for this is that there are 65k stars, so even if most of them are colluding to fix prices, if one defects you can just use them for all your services.  As long as nobody corners the market on stars, you should be able to just buy whatever services you don't want to do yourself.

> so, if i was, say, a tlon employee owning some of this property, of course i would want to champion urbit, drive people to gobble up digital land, and profit ;)

So yes, this incentive exists, and (1) when evaluating the sincerity of the people involved, you should take this into account alongside all the other factors (eg how long people spent on it before they become exposed to the price of stars, and whether they compromise for short-term gains), and (2) if you accept that Urbit is good, then this incentive is good because it makes Urbit more likely to succeed. 

[p. j.]

>> There's a common assumption that being against SaaS megacorps means being against property rights in any form, as though owning something or making money leads directly to the world we have today.  Some people involved with Urbit aren't so hot on modern property rights, but they existed in some form or another for a really long time before anyone invented SaaS, and with little correlation to how free people are.  What works poorly is when you can't own something you depend on, and can't be sure to have access to it, usually due to a monopoly.  The problem with SaaS is not that they make a lot of money, it's that they own your data and online experience, and you can't exit.

sure, i don't disagree with this really. particularly the latter part we are entirely aligned on. i do have radical opinions on property and ownership, but recognize them as radical and have set them aside for the conversation.

>> This doesn't lead naturally to centralization or rentierism, since the only way to make money on these planets is to sell them, at which point you have no more rights to them.  There's no way to lock someone in.  If someone tries to *rent* you a planet, I recommend you turn them down!  (Unless it's a temporary thing because of high gas prices...)

this is what i meant in the above when i said i could see how it trends away from this as time goes on. and about urbit idealism :)

i don't think this is a particularly constructive line for this discussion, as i feel like this might be an emotional point for everyone involved, but i do appreciate hearing that my intuitive take is at odds with others', and will spend some time thinking about it. (i am still in no rush to purchase a planet at this time). people should still feel welcome to give me more information on this matter though and i'll think through it.

(a side note - was just re-reading another thing yarvin had written, as it related to distribution of galaxies and stars, and came across this sentence: "I even made an embarrassing bet with Raph Levien as to which of us would win the Turing Award – my money is definitely on Raph at this point." despite being a fair bit younger than those involved, i am pals with raph and have a memory of us sitting in a berlin park discussing urbit. small world.)

[Jonathan]

P.J. what are your radical opinions on property and ownership?

~minder-folden

[Ted Blackman]

As I sit here in my dinner jacket, chomping on my cigar, basking in the warmth of cognac and the companionship of my fellow digital landowners -- ah, the life of a rentier-- my valet interrupted my languor (how boorish of him; hard to find good help nowadays, wouldn't you agree?) to inform me that the urbit-dev mailing list had a new thread, so I donned my monocle and perused it.  Despite its somewhat uncouth opening missive, I shall deign to try my hand at a response of my own.

I like to think of Urbit from the following perspective: if you could standardize an operating system that would last forever without ever needing to be changed, what would that look like?

A bunch of design decisions come from this:

- versions should eventually stop, to indicate that the permanent standard has been reached (Kelvin versioning)

- you should own it cryptographically, control it with a private key, and anyone should be able to find your public key

- the network should be able to find your machine even as it moves around (need NAT traversal)

- it needs to stay the same as hardware evolves, so it should be like an OS without a hardware abstraction layer, which we sometimes call an overlay OS (another way to look at this is as abstracting over hardware even more generally than modern OSes)

- it should have a tight spec, including all dependencies, so Nock, which depends only on natural numbers and ordered pairs, and the Arvo/Vere event/effect protocol, which has about six channels, a simple calling convention, and not that many possible requests and response types (maybe fourty or so?)

- determinism, pure functions, transactionality (either an event happened, or not), and orthogonal persistence (single-level store) are nice, and basically fall out of the Nock model

- networking should reflect the underlying transaction model and give you exactly-once message delivery; every packet should be idempotent

- can upgrade on the fly without needing to serialize or lose type safety; the cryptosuite needs to be upgradeable forever

- needs to be easily portable from machine to machine, also made much easier by Nock, transactionality, and orthogonal persistence

- the programming language should be a thin layer over Nock that maintains its good properties and makes it relatively convenient to write code

- building a program from source should be purely functional, reproducible, and tightly specified

- infrastructure nodes that relay packets and sign kernel updates should be fungible to prevent lockin, monopolies, or abuse (hence why you can "escape" to a different star)

Sure, you could build it some other way, but I have yet to see an alternative design that seems clearly better in all, or even most, of these dimensions. Try solving these problems on Linux, using Haskell, or WASM, or Rust; or try using Docker.  See how it compares.  Try a different arrangement for the PKI, and solve the Sybil problem and key revocation some other way.  Or just use TLS certificate authorities, they're ... trustworthy ... right?

I've been meaning to study plan9 and inferno at some point.  PJ, are there lessons those systems have learned that you think could benefit Urbit?

—

~rovnys-ricfer

https://urbit.org

[p. j.]

>> if you could standardize an operating system that would last forever without ever needing to be changed, what would that look like?

it never occurred to me that this is a property i might want in an operating system, and i'm surprised to hear that this is desirable - isn't the agreed problem with unix that it won't die?

>> Try solving these problems on Linux, using Haskell, or WASM, or Rust; or try using Docker.

i would rather die (point taken)

>> Try a different arrangement for the PKI, and solve the Sybil problem and key revocation some other way.  Or just use TLS certificate authorities, they're ... trustworthy ... right?

in general, i'm seeing the appeal of this approach and getting to understand at what it offers (and how what it offers, and what people are taking away from this project, has differed so much even within this thread). i'm realizing that the set of constraints i have in my head ends up differing mainly at the last mile - clearly, what i need to do is go write some plan9 p2p networking software and see how i fare :)

>> I've been meaning to study plan9 and inferno at some point.  PJ, are there lessons those systems have learned that you think could benefit Urbit?

don't design your UI entirely around mid-90s tk (you have already transcended above this lesson).

the notion of the 'overlay os' and how urbit operates - as far as a non-technical end-user might be concerned - makes me think a lot about inferno, particularly in hosted mode. a crucial technical difference being the dis vm making the deliberate decision to mirror itself as a generalization of extant hardware and nock - among other things - deliberately trying to be something different, while also being very simple. 

there are legitimate performance concerns with nock. these are resolved by jets - i don't think this is a cop-out, this feels nice to me because it allows the system to be more declarative - but it causes efficiency to lag behind, potentially very far behind, but allows you to get something working easily. dis is apparently remarkably performant for a vm, but inferno struggled a lot because the vm is nontrivial to port to 64-bit architectures. i don't know what the lesson here is. everything's a tradeoff, maybe.

more generally, though, i decided i wanted inferno to look nice so a few days ago i forked it and started hacking away. i spent a while doing a similar process to 9front, and have found it real rewarding. i feel a sense of ownership around this entire ritual - this is /my/ operating system because i'm down, understanding everything, throwing out the parts that are old cruft (why are there 3 ui libraries? why is there DES compatibility?) and reworking what's there to suit me.

urbit feels like a diamond someone handed to me. it's perfect, or will be, but is it mine? what's my relationship to this thing? y'know?

[Ted Blackman]

I can't do a better job justifying freezing an OS than this (see the section about Mars):  http://moronlab.blogspot.com/2010/01/urbit-functional-programming-from.html?m=1

> don't design your UI entirely around mid-90s tk

Sure, we've transcended that; we use entirely mid-2010s React in our UI (and ~palfun-foslup is revivifying the terminal UI, because he's a Mensch).

Vere uses a 32-bit allocator for the Nock VM.  We might switch that to 64-bit at some point, or maybe add another memory arena for large atoms; eventually we'll have to do something to let us store big files in there.  Do you know what the hard part was to migrate plan9's VM to 64-bit architectures?

As for Urbit eventually being perfect and frozen, even after that happens you can always modify your own kernel however you want (it's Yours, after all), and if you do it in a way where you still maintain Ames networking semantics, nobody else will even know.

—

~rovnys-ricfer

https://urbit.org

—

~rovnys-ricfer

https://urbit.org

[Matilde Park]

I feel as though I added a “political flair” by accident; I didn’t mean to introduce the whole notion of property rights here!

I guess what I specifically was referring to by “rentierism” is a combination of 

1 - aligned incentives and a level power dynamic between consumer and provider; ie. it’s not coercive in one direction due to the number of sponsors and the actual benefits of entering into the arrangement with a sponsor, and 

2 - skin in the game for early adopters and network stakeholders. Urbit is hostile to grift if only because it requires you to be on good behaviour to pay off your speculation. The community itself is pretty sincere and, I guess, on a spectrum of potential profit motivation. I, at least, have no expectations of becoming rich. We’re a long tail, baby!

The amount of thought that went into the incentive alignment seemed like absurdly elegant when I started at Tlon, so it’s still notable to me. Everything is designed for high trust, competitive markets for how one decks out their lifelong computer appliance.

But anyway, yes all in all, we should keep it out of emotionally charged waters. We want to understand each other!

— 
~haddef-sigwen
https://urbit.org

On Mar 27, 2021, at 12:28 AM, Ted Blackman <t...@tlon.io> wrote:



[p. j.]

>> Vere uses a 32-bit allocator for the Nock VM.  We might switch that to 64-bit at some point, or maybe add another memory arena for large atoms; eventually we'll have to do something to let us store big files in there.  Do you know what the hard part was to migrate plan9's VM to 64-bit architectures?

i've only just started messing around with inferno in particular, but this is my understanding from what i've seen/read:

since it was built to be a generalization of popular hardware (eg, 32-bit register machines, at the time), the basic types assumed 32-bit register sizes. not all of the values are 32-bit (there are 64bit longs, for example), but importantly, pointers are. and there is some magic around pointer logic to mitigate some of the common pitfalls of, say, c pointer usage.

so the vm is low level enough to where something like "the size of the cpu's registers" affects quite a lot. there's a compiler for the limbo language, and there's also a jit. because of the jit in particular (i think), part of porting inferno from, say, openbsd amd64 to macosx adm64 is that you will have to write a number of functions in assembly itself to do things like "save the current state of the floating point unit" and "trampoline from one function to another", so i end up considering a lot of things like "do the abi differences between these two target oses matter? am i going to have to disable aslr or stack cookies in the compilation process? were the original designers expecting or not expecting some certain behavior that is laying implicit here, since a lot of this highly low-level code is not particularly well documented?"

god, one benefit from this conversation is that i'm now feeling like writing a vm from scratch might be more productive - or at least educational ;) there are still lessons i'd like to learn from inferno specifically though.

9front is still brainmelting from someone coming from the world of unix. eg: when installing 9front on a new system, the driver for the usb ports did not work properly. however, instead of writing a driver for them, i have the option of plugging my mouse into a different 9front laptop across the room. i can then mount the mouse device over the network on the original laptop, and use the mouse on the original laptop despite it being plugged in somewhere else. it is unbelievably straightforward to do this, and felt and still feels like literal witchcraft to me.

but 9front's networking capabilities are weirdly rigid. it's designed to work with the datacenter architecture that bell labs was using, and you can feel it. while many things are transparent, not everything is - i feel like ideally i should be able to have a massive abstraction of a disk that can grow and shrunk as other computers it is aware about go online, etc. i don't know if inferno does anything like this specifically, but since it was effectively targeting IoT devices i think that it is more generally willing to accommodate mercurial networks

>> I can't do a better job justifying freezing an OS than this (see the section about Mars):  http://moronlab.blogspot.com/2010/01/urbit-functional-programming-from.html?m=1

thank you! i am excited to read this tonight. for right now, it's a lovely day outside and i'd like to go to the park. i hope you all are enjoying the lovely weather as of late (if the weather in your areas has been as nice as it has been in nyc).

phoebe

[Frances He]

ftzse

On Sat, Mar 27, 2021 at 6:49 AM p. j. <pho...@slub.rerrtry segyzzeazeco> wrote:

my endless confusion re: urbit and seeking answers got me 先sent to this mailing list, provided i ask in good faith, which i'm more than willing to.

it is very hard for me to understand what urbit /is/, for the most holistic and broad definition of is-ness i can muster.

i'm a chi researcher and software engineer who also reads a lot of philosophy/critical theory, horror comics, pulp sci-fi or whatever; i hack on 9front and inferno in my free time, generally an intense contrarian that constantly aches for the new and the different in computing. i sort of figured i would be your target audience, but i'm... not exactly sure?

--

[p. j.]

i feel like a lot of my philosophical confusion has been satisfied
(thank you all for your time! it helped a lot), but i still have some
technical ones

when i learned about the OTA relationship between planets and stars, i
was quite shocked and brought this up to Matilde, but i don't think i
conveyed the idea well at all. i sat down a bit with the whitepaper
and think i can describe the catastrophe situation i'm thinking of.
also, being familiar with arthur whitney's style of c, reading through
urbit c did not phase me ;)

the basic idea:
- i run a star, and offer some star services excellently and for
cheap/free, motivating a lot of planets to hop over
- after getting a lot of connections, i go rogue and send out an OTA
update to all connected planets
- these updates seem like they can rewrite effectively anything except
the lifecycle function, so i can just do whatever.

depending on the motives in doing this, the goal here could be a few
different things:
- force the ship to breach, get the person to lose all data and spend
money (since resetting state seems to require an ethereum
transaction?)
- silently route all contents of clay to the star, for whatever reason
(blackmail? idk)
- cause the planet to behave deranged, spam garbage to all friends,
try and ddos a specific other planet, who knows.

as far as i can tell the main defense against this is pointing to game
theory and saying there's no economic incentive to act this way, but
humans are complicated - saudi arabia presumably didn't buy iphone
implants from nso because this was economically profitable, and
meepsheep likely could've sold his tumblr exploit for some amount of
money (though maybe this was before the days of bug bounties) instead
of flooding the place.

[Philip Monk]

Your understanding of how OTAs work is correct.  Right now we're pretty cavalier about passing around OTAs, but the solution is for the OTAs to be signed by the developer's ship.  Then the stars can pass along the OTA, but if they change it they'll need to sign it themselves.  Then ships can decide whether they want to apply updates signed by their sponsor or ~zod or whoever.  This work hasn't been scheduled, but it's not too big — the hardest part is making a clear interface for it.

On Sat, Mar 27, 2021 at 9:01 PM, p. j. <pho...@slub.co> wrote:

i feel like a lot of my philosophical confusion has been satisfied
(thank you all for your time! it helped a lot), but i still have some technical ones

when i learned about the OTA relationship between planets and stars, i was quite shocked and brought this up to Matilde, but i don't think i conveyed the idea well at all. i sat down a bit with the whitepaper and think i can describe the catastrophe situation i'm thinking of. also, being familiar with arthur whitney's style of c, reading through urbit c did not phase me ;)

the basic idea:
- i run a star, and offer some star services excellently and for cheap/free, motivating a lot of planets to hop over
- after getting a lot of connections, i go rogue and send out an OTA update to all connected planets
- these updates seem like they can rewrite effectively anything except the lifecycle function, so i can just do whatever.

depending on the motives in doing this, the goal here could be a few different things:
- force the ship to breach, get the person to lose all data and spend money (since resetting state seems to require an ethereum transaction?)
- silently route all contents of clay to the star, for whatever reason
(blackmail? idk)
- cause the planet to behave deranged, spam garbage to all friends, try and ddos a specific other planet, who knows.

as far as i can tell the main defense against this is pointing to game theory and saying there's no economic incentive to act this way, but humans are complicated - saudi arabia presumably didn't buy iphone implants from nso because this was economically profitable, and meepsheep likely could've sold his tumblr exploit for some amount of money (though maybe this was before the days of bug bounties) instead of flooding the place.

On Sat, Mar 27, 2021 at 1:55 PM Frances He <hesiyun1996@gmail.com> wrote:

ftzse

On Sat, Mar 27, 2021 at 6:49 AM p. j. <pho...@slub.rerrtry segyzzeazeco> wrote:

my endless confusion re: urbit and seeking answers got me 先sent to this mailing list, provided i ask in good faith, which i'm more than willing to.

it is very hard for me to understand what urbit /is/, for the most holistic and broad definition of is-ness i can muster.

i'm a chi researcher and software engineer who also reads a lot of philosophy/critical theory, horror comics, pulp sci-fi or whatever; i hack on 9front and inferno in my free time, generally an intense contrarian that constantly aches for the new and the different in computing. i sort of figured i would be your target audience, but i'm... not exactly sure?

for someone like me who has a pretty robust technical background, who read the urbit whitepaper and has combed through a number of parts of the source wondering how functionality x is implemented - this only causes more dissonance about what this project is, what it is trying to accomplish. it feels like there is at least four urbits:

1. the urbit yarvin wrote (and/or intended?)
2. the one that currently exists
3. the one that urbit.org talks about, the one described in radio interviews - the PR urbit
4. the urbit of the future that has aspirations beyond the one that exists now

i think i have a decent-enough understanding of 1 and 2. there are a number of design and implementation decisions that jump out at me as total show-stopping problems, but perhaps this is due to a severe ideological difference, which is fine and understandable.

3 and 4 are what really confuse me. every claim seems, to me, to be either nakedly disingenuous or an outright lie. eg, i spun up a comet to do some feature analysis, and the first thing i clicked on told me to link an s3 bucket. like, ok, fine for anything else, but your copywriting says with little room for ambiguity that you are not doing precisely this.

the other day i was thinking about the processes of planets receiving updates from stars, and went to seek out if there was a notion of consent or negotiation here. finally finding an answer in the whitepaper (i truly had to dig), i see: "Normally, the child automatically syncs and loads source updates from the parent. Subscribing to an update server requires almost complete trust; this problem is not unique to Urbit, however." alright. my iphone basically does this, who cares: except for the stressed concepts of ownership and sovereignty(?) that this seems to negate

the examples are endless - just scrolling through this list to judge the milieu before posting i found the announced goal of getting people's cloud-independent personal servers back into the cloud

so, whatever. i'm informed enough to know that this isn't a product i wish to purchase, which is ok. but because this lies at a nexus of many of my interests, i can't help but go back to examine parts of this design. i can't tell what is ideology, work-in-progress, inflated claims to get venture capital funding, or possibly a pyramid scheme? (this is not moral judgement, if it's a scam to do fun computer experimentation, i find that admirable. i'm just trying to figure it out.)

so, with that longwinded background to establish context, my question is - how would you, in conversation with a technically competent person - describe what you are working towards?

thanks
phoebe

--
To unsubscribe from this group and stop receiving emails from it, send an email to dev+unsubscribe@urbit.org.

[p. j.]

>> Right now we're pretty cavalier about passing around OTAs, but the solution is for the OTAs to be signed by the developer's ship. Then the stars can pass along the OTA, but if they change it they'll need to sign it themselves. Then ships can decide whether they want to apply updates signed by their sponsor or ~zod or whoever.

i'm not convinced - the attack now becomes that i add all sorts of
cool bonus features to my star to lure in customers, get them used to
receiving software updates from me to make use of them, then send the
death update afterwards. maybe the idea that these are entire OS
updates is suspicious to people - then the thread model moves to a
tlon employee, or trusted community member, or something like that.

yes, a lot of operating systems have similar issues. but they're not
designed to last forever ;)

i am not sure if apps in general can wreak havoc. i'm trying to figure
out the exact security model of urbit right now - it's kind of a lot
of effort so bear with me :) it is possible that gall has some
sandboxing, but i haven't been able to totally conclude one way or
another on that yet.

On Sun, Mar 28, 2021 at 1:36 AM Philip Monk <phi...@tlon.io> wrote:
>
> Your understanding of how OTAs work is correct. Right now we're pretty cavalier about passing around OTAs, but the solution is for the OTAs to be signed by the developer's ship. Then the stars can pass along the OTA, but if they change it they'll need to sign it themselves. Then ships can decide whether they want to apply updates signed by their sponsor or ~zod or whoever. This work hasn't been scheduled, but it's not too big — the hardest part is making a clear interface for it.
>
>
> On Sat, Mar 27, 2021 at 9:01 PM, p. j. <pho...@slub.co> wrote:
>>
>> i feel like a lot of my philosophical confusion has been satisfied
>> (thank you all for your time! it helped a lot), but i still have some technical ones
>>
>> when i learned about the OTA relationship between planets and stars, i was quite shocked and brought this up to Matilde, but i don't think i conveyed the idea well at all. i sat down a bit with the whitepaper and think i can describe the catastrophe situation i'm thinking of. also, being familiar with arthur whitney's style of c, reading through urbit c did not phase me ;)
>>
>> the basic idea:
>> - i run a star, and offer some star services excellently and for cheap/free, motivating a lot of planets to hop over
>> - after getting a lot of connections, i go rogue and send out an OTA update to all connected planets
>> - these updates seem like they can rewrite effectively anything except the lifecycle function, so i can just do whatever.
>>
>> depending on the motives in doing this, the goal here could be a few different things:
>> - force the ship to breach, get the person to lose all data and spend money (since resetting state seems to require an ethereum transaction?)
>> - silently route all contents of clay to the star, for whatever reason
>> (blackmail? idk)
>> - cause the planet to behave deranged, spam garbage to all friends, try and ddos a specific other planet, who knows.
>>
>> as far as i can tell the main defense against this is pointing to game theory and saying there's no economic incentive to act this way, but humans are complicated - saudi arabia presumably didn't buy iphone implants from nso because this was economically profitable, and meepsheep likely could've sold his tumblr exploit for some amount of money (though maybe this was before the days of bug bounties) instead of flooding the place.
>>

>> On Sat, Mar 27, 2021 at 1:55 PM Frances He <hesiy...@gmail.com> wrote:
>>
>> ftzse
>>
>> On Sat, Mar 27, 2021 at 6:49 AM p. j. <pho...@slub.rerrtry segyzzeazeco> wrote:
>>
>> my endless confusion re: urbit and seeking answers got me 先sent to this mailing list, provided i ask in good faith, which i'm more than willing to.
>>
>> it is very hard for me to understand what urbit /is/, for the most holistic and broad definition of is-ness i can muster.
>>
>> i'm a chi researcher and software engineer who also reads a lot of philosophy/critical theory, horror comics, pulp sci-fi or whatever; i hack on 9front and inferno in my free time, generally an intense contrarian that constantly aches for the new and the different in computing. i sort of figured i would be your target audience, but i'm... not exactly sure?
>>
>> for someone like me who has a pretty robust technical background, who read the urbit whitepaper and has combed through a number of parts of the source wondering how functionality x is implemented - this only causes more dissonance about what this project is, what it is trying to accomplish. it feels like there is at least four urbits:
>>
>> 1. the urbit yarvin wrote (and/or intended?)
>> 2. the one that currently exists
>> 3. the one that urbit.org talks about, the one described in radio interviews - the PR urbit
>> 4. the urbit of the future that has aspirations beyond the one that exists now
>>
>> i think i have a decent-enough understanding of 1 and 2. there are a number of design and implementation decisions that jump out at me as total show-stopping problems, but perhaps this is due to a severe ideological difference, which is fine and understandable.
>>
>> 3 and 4 are what really confuse me. every claim seems, to me, to be either nakedly disingenuous or an outright lie. eg, i spun up a comet to do some feature analysis, and the first thing i clicked on told me to link an s3 bucket. like, ok, fine for anything else, but your copywriting says with little room for ambiguity that you are not doing precisely this.
>>
>> the other day i was thinking about the processes of planets receiving updates from stars, and went to seek out if there was a notion of consent or negotiation here. finally finding an answer in the whitepaper (i truly had to dig), i see: "Normally, the child automatically syncs and loads source updates from the parent. Subscribing to an update server requires almost complete trust; this problem is not unique to Urbit, however." alright. my iphone basically does this, who cares: except for the stressed concepts of ownership and sovereignty(?) that this seems to negate
>>
>> the examples are endless - just scrolling through this list to judge the milieu before posting i found the announced goal of getting people's cloud-independent personal servers back into the cloud
>>
>> so, whatever. i'm informed enough to know that this isn't a product i wish to purchase, which is ok. but because this lies at a nexus of many of my interests, i can't help but go back to examine parts of this design. i can't tell what is ideology, work-in-progress, inflated claims to get venture capital funding, or possibly a pyramid scheme? (this is not moral judgement, if it's a scam to do fun computer experimentation, i find that admirable. i'm just trying to figure it out.)
>>
>> so, with that longwinded background to establish context, my question is - how would you, in conversation with a technically competent person - describe what you are working towards?
>>
>> thanks
>> phoebe
>>
>> --

>> To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@urbit.org.
>
>

[Basile Genève]

I get the attack, and I think it is real. In your mind, what differentiates this threat from the same thing happening to, say, Bitcoin Core?

I suppose that there are more features to add and lure people in with?

If you have a Bitcoin Core-like norm in terms of the seriousness of updating the Urbit OS, and there are ways to compartmentalize userspace so that random apps don't get full access, then it seems like you could limit the scope of this attack.

[p. j.]

> I get the attack, and I think it is real. In your mind, what differentiates this threat from the same thing happening to, say, Bitcoin Core?

i had to gain a bit more insight for this one (i found
https://blog.lopp.net/who-controls-bitcoin-core-/ as a great article
for background).

i think there are two sides to this, one of which i guess is a "normal
problem" and the other is a "really hard problem"

the normal problem:
when you choose a star to be your sponsor (i think that's the right
term?) you are also saying "this star can do anything it would like to
my ship and anything my ship can see" eg clay, the pier, etc. this is
maybe less limited by what functionality is lying around to be
utilized, eg i'm not sure if there's a way to just like,
straightforwardly delete files, but i think the construction of event
log digests implies the existence of something like this. i could be
wrong.

philip's solution shifts this trust from stars to whoever those
keyholders end up being. it's not obvious to me who would get this,
but in the most conservative case let's say it's the tlon core
development team only. this doesn't seem desirable because it would
restrict urbit's growth, saying it is now "tlon's product" and not the
community's, but there still are some subtle issues. i think it would
be fair to compare it to openbsd's development process here, because
i'm most familiar with it. with that, you have to assume that the
group of extremely angry men who have been checking things for decades
aren't going to miss anything. it tends to be a safe enough bet for
most people, if tlon were to employ a group of equally angry men to
review every change on your behalf ;)

from what i can tell, bitcoin-core seeks to push this model as far as
it will go. it seems pretty unlikely to me that someone could slip
something through there because they've made such a huge web of checks
and balances. it's still possible i guess if someone like, captures
someone who has a committer pgp key and forces them to do evil on your
behalf, but it's about as good as i feel like things could get

the really hard problem:
it feels like this issue decays to the classic "trusting trust"
problem. the "Perfect World" solution is nobody trusts anyone. before
you run any code update, you review each change by hand and then feed
it into your handwritten SMT solver to make sure you didn't miss
anything. this isn't remotely feasible, so people tend to solve this
issue with things like permissions and sandboxing and os security
models

so on an iphone (since it's the most locked-down consumer device i'm
aware of), every component of the os treats every other component as
an enemy. if you are a process, if the browser asks you to do
something, you behave like you aren't sure if it is the browser or a
mountain of weevils in a browser-suit, but you need to do your job so
you do it as cautiously as possible - eg, all inputs you get from the
browser you go through with a fine-toothed comb, even though it's your
coworker down the hall that made it. it's not perfect, people still
are making iphone jailbreaks, they're just worth too much money to
throw online now. but now it's at least way harder for a browser to
mess up rendering a font so badly that someone's website has the
ability to brick your phone (or, a bug in eyre/iris letting clever
strangers delete your pier).

the point being, i guess, is damage mitigation and user awareness.
this can look like locking down the people that can send out kernel
updates, running a trusted suite of unit tests, constantly running
concolic execution solvers to make sure no path lets an http message
delete a pier, doing the urbit-equivalent of stack cookies and aslr to
contain hijacking of programs when the urbit-equivalent of stack
smashing or UAF occurs (i know nock is a combinator machine, but i
hope this conveys the idea - the u3 side of things still has plenty of
this stuff anyway). and simultaneously letting a user know exactly
what 'trust' entails when a user decides to trust someone.

(sorry, i went on for a while. infosec is a special interest of mine.)

[Liam Fitzgerald]

The solution to this is likely distributing kernelspace and userspace
separately, in addition to a stronger security model for running
'apps' (we call them agents). As kernelspace is designed to freeze,
having a master key held by the Urbit Foundation is not really a big
issue, as kernelspace updates should slow to a crawl and eventually
stop. On the userspace side of things, you could imagine defining a
collection of agents, including their dependencies, distributed as a
package. Each package would be signed and totally isolated by default,
in a manner not dissimilar to cgroups, i.e. 'Allow app X to read data
from package A, and write to collection B'.
——
~hastuc-dibtux

https://urbit.org

[Ted Blackman]

A hash of new kernel source could be voted on by the galaxies, on a blockchain. Planets can listen to an ethereum node for those transactions (along with Urbit PKI transactions, to which they already listen), validate the signatures to confirm the votes on that hash, download the files from their sponsor (or anyone else), and confirm the hash matches.

Trusting trust is more feasible in Urbit than in many other systems because there are multiple implementations of the Nock deserialization function, written in different languages -- and multiple Nock interpreters, also written in different languages. You can already deserialize a pill (a Nock bootloader, which installs and configures an Arvo kernel in the first few events that boot a ship) in C, Haskell, Common Lisp, and I think JavaScript, and boot off a pill in C and Common Lisp.

Unless an attacker pwned all the deserializers and interpreters, an auditor could inspect the Nock that will be run to boot a ship and place a high degree of trust in any result agreed on by multiple implementations.

New kernel source could be verified similarly, although that's even easier, because it's textual, short enough to inspect visually, and you can build it on your own dev ship. Building the Arvo kernel, vanes, and userspace from scratch just takes a few minutes, and should probably be faster.

We need this sort of auditing at a few layers for this to be really bulletproof, but because pills are finite, tightly specified, inspectable pieces of data that can be interpreted by multiple other programs, it's much harder to evade detection if you try to tamper with something.

Another way to think about this is that disassembly of Nock code is just noun serialization, performed by the interpreter (and all nouns use the same serialization function). So there's no way for the Nock code itself to pretend to be something else -- you'd have to pwn the interpreter. If the interpreter gets pwned, all bets are off, generally speaking (other than your ownership key, which you could use to reassert control and reset your networking keys, as long as you keep it in cold storage as recommended). OTA updates don't replace the interpreter, though, and the interpreter must be hard to pwn (it's not yet hard enough, but we are currently working on getting it to drop privileges, and it should be amenable to more hardening).

We do also need a secure distribution channel for interpreter binaries. In general, a user is going to have to trust *somebody* in order to download code -- they can't write the code themselves, so they have to trust whomever they get it from.

For Arvo, I think that should eventually be the galaxies (or maybe galaxies and stars, since stars will likely bear the brunt of network load and want to have a say in kernel dev).

For userspace agents, it will probably be whatever third party distributes them, possibly with the addition of some other reputation models, such as "app store"-style registries that attest to the safety of their published agents. Tlon and the Urbit Foundation could maintain their own such registries. Also, as Liam mentioned, the kernel should protect itself from userspace, like any durable OS.

There are potentially many interpreters, in which case the trust model would be multipolar like for userspace, although the galaxies might also recommend a standard one that they've vetted. A binary could be authenticated and distributed as an atom through the Ames network, or sent over HTTP but signed by an Urbit ship's key.

I'd like to note that the network governs itself, through its Ethereum contract. Tlon owns only a shrinking plurality of galaxies, so it can't strong-arm the network very effectively. Right now most development is conducted through Tlon, and we run a lot (but certainly not all) of the infrastructure nodes, so there's still quite a bit of de facto control.

This is fine for the time being, and the system is decentralizing at a pretty good clip. The recent creation of the Urbit Foundation seems to be accelerating that too.

—

~rovnys-ricfer

https://urbit.org