Oddbean

Our blog posts and documentation are coming online a little more every week, and a good explanation of the SSI is much-needed topic, but I'll give a brief taste here. SSIs are a novel computing model and therefore are still tough to describe at first... An SSI is a purely functional, single-level store VM and programming environment. Rather than "operating system", think "single operating function". There is a single, frozen top-level function that takes as it's input the "computer's" state as an append-only event log. The net result of that is you have a highly portable SINGLE value that describes the entire state of a computer's storage AND active computation with zero external dependencies. What I mean by "single level store" is that the Operating Function makes no distinction between memory and disk, such that you can take an entire running computer, turn it off instantly, put its representation on a USB drive and ship it across the world, plug it in and start it and it'll be running exactly as it was. (This has happy implications for "durable execution" style cloud services, as well as ridiculous peace of mind for local, personal compute). You get this persistence for free in the programming language: there's no DB interface to import and rely on. The whole persisted state of the VM and every running application is a single closure. Other similar systems (like Urbit, introduced in the paper below) have very limited storage capacity, while our system can easily handle terabytes of data. Which means that an individual running a VM like this in the cloud can be their own S3-style static file host. Or a network of similar instances can act as a replacement for something like IPFS. okay well I've rambled far too long now and only scratched the surface, but I'll leave you with: our "VM" is stupidly easy to run. It's not like installing Linux. You just start the binary and it's going. So an exciting bit of low hanging fruit in my mind is making it trivially easy for every nostr user to have their own personal relay, either on their own hardware or in the cloud and optionally behind a proxy to preserve IP privacy. The whitepaper that originally introduced the concept of the SSI: https://media.urbit.org/whitepaper.pdf We've got new posts and podcast episodes coming every week: https://blog.vaporware.network My company's brief landing page: https://vaporware.network I should also mention that all our work is free and open source and all the code that is analogous to regular systems' "compiler binaries" is actually human-readable, so our VM 's entire stack from hardware interaction to userspace applications doesn't ever ask you to trust, but instead to verify. Happy to answer any questions!

This seems like a crazy awesome idea in theory but that it could run into a million problems in practice. How much setup is needed to run this on any random machine and how do you boot into it exactly? I might actually like to chat with you out of band about this just to get a better idea of things if you have some time. Mind if I DM?

Naming conventions in this are all over the place. Making it sound kinda ridiculous, imo. Ships, and plunder, Sire, all make it more confusing, not less, imo. No offense, just trying to give honest feedback.

Maaaan did you guys put a damn token in this thing? If that’s what this is, I don’t think you realize how much this ensures the project has no future. And just how quickly it’s going to turn off a *ton* of people up here, all while ruining the incentives of the very project. Am I reading that right? https://i.nostr.build/dwBrY.jpg

There are no tokens in our stack or dependencies on blockchains of any variety, including Bitcoin. The token stuff you see on that landing page was an early idea for handling trustless software versioning and provenance. We aren't working on that now; building core OS primitives currently.

As a cofounder of the company I commit this note to my personal relay and many others: The core OS primitives that we build are now and will continue forever to be trustless, permissionless, open source, and not dependent upon tokens to operate. Given that it is FOSS, I can't determine what other people will build on top of the system - nor do I have any interest in making it possible for my opinions and principles to dictate what others can do with my software.

To elaborate a bit, since you're asking about it: we were not going to launch a token. We experimented with attaching software to ethereum NFTs such that purchase of an NFT meant the author of the software would distribute the source code to you. And reselling the NFT meant the new owner would receive the software (statefully! Meaning if you had a "Pokemon" app containing a highly trained Pikachu and you sold that app to someone else, he would have that trained Pikachu now.) The app data wasn't stored onchain, nor was the source code, both of those were local to the VM and transferred to the new owner as a serialized value. just the ownership record was stored onchain via NFT. ...but as I said, that was an early demo to prove some things about code and state distribution. There's nothing in our current code that has anything to do with blockchains. If two people can peer with eachother, they can distribute software (or any other arbitrary digital content) to eachother in an uncensorable manner. Pirate app stores from the future!

Completely agreed! The fuller story on our current messaging is that current users and developers of the Urbit platform are most familiar with the technologies involved in our stack, and our messaging is mostly directed pretty narrowly at them. We absolutely owe a more readily understandable explanation to a wider audience and we're working on that. (As well as building demos for a general audience. We've already built an S3-style service that was shared with a small beta testing group). We are extremely busy and are trying to direct our energies where they are most fruitful, as I'm sure you understand :)

I’m keeping the DM inbox warm for you. To answer some of the questions you asked here now: - How much setup is needed: exactly zero. There are a couple different runtimes in the works right now, but with the C runtime it’s literally just getting a hold of the compiled binary and running it. There are zero host machine dependencies - How do you boot into it: **for now** “you don’t” (boot INTO it). You interact with it via the CLI or more robustly via the browser (either on the host machine or over HTTP from a remote machine, if you’re using the web server aspects). For the moment, the easiest way to create UIs is via standard web stack, and we have a number of examples of that (group chat, image board, S3 bucket, a MUD with randomly-generated maps, etc. etc.) Working with native graphics is a consideration, but we’re more interested ultimately with running our OS natively on devices - starting off something like an Android fork and going from there (the @daylightco is a good mental model. basically a new device type category).