The text reads: "Urbit has to be just as usable as any widely used app in 2017. For a personal server, the usability bar can't be Unix."
Just above this, there is a screenshot of a browser displaying the following: "OK, ~ravmel-ropdyl is coming online. Ping 734ms, DNS Waiting, :talk Waiting"
...which, well, looks exactly like '70s Unix usability.
I also find it odd that Urbit wants to conquer the world, yet the design is so attached to entering ASCII sequences on a command line. This severely limits the platform's international usability. Their programming language's syntax page even proclaims "To make ASCII great again, we've mapped each punctuation glyph to a syllable": https://urbit.org/docs/hoon/syntax/#-glyphs-and-characters
The problem with using all these ASCII punctuation marks is that many of them are hard or even impossible to type on various international keyboards. It doesn't seem like non-English users were ever considered when the decision was made to "make ASCII great again".
On a more conceptual level, marrying a supposed futuristic redesign of the Internet to a 1960s character set just seems off. Today's computing increasingly happens on touchscreens, but Urbit's I/O model is happy to settle for the ancient paradigms of teletype terminal emulation and ASCII streams.
The whole thing has a weird retro-futuristic vibe to it, like it's more of an art project about a computer system that the Mad Men would have used to update their websites in some alternate reality.
Arabic and Japanese people have been using C and Javascript just fine, so I'm not sure even in the hypothetical future it would be a problem. And if it is - Hoon has keyword style now ("|- a/@ (add 5 a)" can be written (":gate a/@ (add a 5)"), or barring that the language rune parser can be replaced with a simple gsub in the source.
Hoons runes are really just names for which AST node it is, so it would be trivial to make a smartphone Hoon editor that works like Scratch or Lisp instead of textual.
Hell, Hoon compiles down to Nock, so you don't even have to use it, just write another language that targets Nock instead.
Thus, it makes a lot of sense to simply switch input modes and maybe even keyboard layouts.
Now, for something as close to English as Norwegian - you have a rather different touch layout due to having 29 letters. This is actually one reason I like python - less gymnastics due to less curly brackets.
Another problem with using ascii, is that now even code comments need to be in English character set in practice. Never mind function names etc.
Utf-8 by default is actually great in the programming languages that support it.
Don't mistake "have been tolerating absurd limitations of C" with "greatly enjoying the backward limitations of ASCII".
I interpreted that whole bit to mean "We tried to make a commandline-free UI frontend for it and failed." But I am glad they're trying to make it more usable! Last time I installed it, using the commandline from the web interface was really clunky, you pretty much had to be at a shell.
That turn of phrase sure is pretty revealing in this case.
1. What is Urbit?
I'm not involved with it and don't speak for the devs, but this always comes up, so I'll just explain in plain terms what I think Urbit is, or what I hope it will grow up to be. Urbit is the server-app-container thing that would make my non-techy Mom want to pay $5/mo for a hosted server instance.
Imagine if every man, woman and child had their own server. Nothing fancy, just a cheap ECC instance or DigitalOcean droplet or something. What would they do with them? Well, host a webserver I suppose, maybe a mail server, maybe a Minecraft server, stuff like that, right? But, these would have to be accessible to non-sysadmin types, so all of these server applications would have to be easy-as-an-iphone to set up and administer. Right now, such apps don't exist, because there's no market for them. But if the market were there, millions of people with hosted servers just sitting around, you can imagine how quickly they'd get made.
What about a social media? At a high level, every social media app is essentially the same app - they let you upload a file to the cloud and they let your friends access it and they show you ads. The differences between Twitter and FB and Instagram and Snapchat are nothing more than differences in how those three features are implemented. So why do they all use the cloud? Because there aren't a million people with server space just sitting around on which to host their IG pictures and FB arguments and Twitter profundities. But if there were, a good self-hosted social media app would make a lot of sense to build.
Urbit is intended to shortcut this chicken-and-egg problem by making a container in which it is easy to build those things. My Mom can afford a hosted server, but she has nothing to run there. If there were great things to run there, like a Facebook with no ads and a webserver with no hassles, she might rent one. Urbit is intended to be the thing in which those great apps are easy to build.
2. Why I want it
Those are all abstract reasons why something like urbit might succeed. As we all know, the mark of a good startup is not whether you can explain why it might succeed, it's whether there are users who want to use it right now. Well, I do want to use it, but it's hard to explain why. I'll take a stab at it.
If you're over 40, you may remember getting your first shell account. Wasn't that the shit? You want to host some files for colleagues? Just make a directory, chmod it to world-readable. You want to run a web server? Go ahead, and don't worry about security, the only people that can see this are inside your college/company. Want to see what Bill Smith is up to? finger bsmith. Want to argue about politics? talk.politics. God, how simple things were! Playing with Urbit feels like those days to me. It makes a handful of things, like identifying users and sharing files between them, trivial. You could probably write a Twitter clone in less than 1K LOC.
Or at least you could, if Urbit does everything it says it does. That's a big if. Which brings me to...
3. Isn't it really weird and fucked up?
Yes. Oh yes. It is incredibly eclectic, the fevered result of an insane genius toiling away in obscurity on his dream project when he wasn't busy writing interminable political screeds. It is an attempt to combine a bunch of things (a ground-up OS, two new languages, and a novel networking architecture) that might be too much for such a small team. The Hoon language is weirder than you've heard. Some people swear it's great once you get used to it, but the docs are sparse and I haven't invested the effort. And if you do invest the effort, it could well be that it has non-obvious architectural flaws that will doom it to be a buggy mess for all eternity. And on top of that, the founder is primarily known for political rantings that are... well, not racist per se, but close enough to get Urbit boycotted by the sorts of people who boycott obscure open source projects due to things in the founder's blog.
But if it fails, I really hope someone builds something less weird that accomplishes the same thing, because at the end of the day, I want it. I want a cheapo server with a cheapo self-hosted Twitter clone and a cheapo self-hosted FB clone, and I want to share pictures of my kids with my Mom without running them through some enormous corporation's billion-dollar machine-learning advertising algorithm, and I want to host my own website and server apps without taking on "sysadmin" as a night job. And it seems like, right now, Urbit is the fastest way from here to there.
- webserver: I used to run a personal web server, and then I noticed that I have to throttle the speed to avoid ending up with a huge bill, and when the colo is down, the server is down. I keep all my data in the cloud now, and due to economy of scale, I do not have to worry about availability, ping times, or bandwidth limits. How can personal server compete with CDNs?
- I also used to run my own mailserver, and it was always a pain to keep spam away. This is a complex process which includes tuning spam filters, deciding which DNS blacklists to use (oh controversy!), deciding if I want to use DCC and at which stage. And I had to re-tune periodically, otherwise it would eat my automated messages... At the same time, Google (for example) has it easy -- at their scale, they have all the information they need to decide if the mail is spam or not.
- Social media: no, I have not run my social media server :) But I cannot understand how do you get started. The main point is network effects, and even Disapora, which has been around for a long while, is not that popular. Plus spam and viruses, of course -- how do you prevent that? If my friend gets a trojan on her machine, will her account be able to spam entire network?
- bandwidth : there's nothing in Urbit itself to address this, but one presumes that if you host an urbit on EC2, you'd also be putting cloudflare in front of its webserver. More generally, if Urbit got even moderate adoption, the hosted-server companies would fall over themselves supporting it, because it's a new customer base for them.
- mail : Agreed, I would never want to run a mail server, on urbit or anywhere else, due to how convoluted it is. However, Urbit uses a federated addressing system that would make spam unprofitable. Read their page on identities if you want details, but the short version is that full-fledged identities on the Urbit network cost a couple of bucks, and it is assumed that anyone who spammed from one would get blackholed before they recouped the investment.
- social : From a user's perspective, I think the big difference between Diaspora and the-yet-to-be-made-facebook-clone-on-urbit is that the latter is not the only thing you can put on an urbit. It's unlikely that Urbitbook would be so popular that anyone would run out to host an EC2 just to join it. But Urbit is supposed to be useful in and of itself. And if it does take off on its own merits, it seems very likely that a self-hosted social media clone would be one of the popular apps.
- viruses : Urbit is designed to be essentially impervious to malware. (Which is not the same as saying it is impervious - kind of depends on whether the people who architected it are as good as they think they are. I'm not qualified to weigh in on that.) In a worst-case scenario (say, your whole urbit got bitlocker'd), recovering would require you to a) get your hosting provider to restore from a backup, and b) notify your "galaxy" (your parent in the distributed network architecture) that you have lost continuity, and convince them that you are your urbit's rightful owner. That last bit would be nontrivial (because this is exactly how someone would go about stealing your identity) so it is assumed that the most galaxies would have stringent requirements, or if Urbit is as stable and unhackable as its supposed to be, not allow it at all.
urbit does help solve some of the mailserver woes though. Since identity is a first class citizen spam is theoretically more controllable. No one can spoof an address in urbit because your address is cryptographically verifiable. If your urbit get's blacklisted you lose a real investment so it's in your economic interest to not be a bad citizen.
urbit in theory will make distributed true peer2peer social networks possible in a way that the traditional attempts have not. Mostly because they move identity ownership out of the application and into the networking stack itself. In urbit you own both your identity and your data and can run any application you want against them without having to give up your control over either of them. No one can pretend to be you. No one can remove your ability to login or access your data. The most anyone can do is refuse to accept networking traffic that comes from you. They can ignore you and that's it.
In urbit a social network can have automatically sharded data by user since allowing each urbit ship to store that data but still use the same social networking application to operate on it really is trivial.
Keeping the software updated on your urbit is automatic and done without interrupting service. Maintenance is almost non-existent.
> How can personal server compete with CDNs?
Re: getting started with social media. The first step is to continue to use Twitter and Facebook using their APIs, from inside my urbit. Scooping up posts from my inbound feed, and/or using the POSSE model:
They're certainly less, um, ambitious than urbit, but sound like they might be on the same continent. At any rate, I really agree with the vision: "Imagine if every man, woman and child had their own server. Nothing fancy, just a cheap ECC instance or DigitalOcean droplet or something."
[0] https://news.ycombinator.com/item?id=13589471 [1] https://cloudron.io/
I don't know about this. People have phones and computers, too, but we still have gmail instead of personal mail servers, and we still have reddit instead of usenet. As a developer I definitely prefer serving web pages to shipping iphone apps (never mind physical CDs) because the deployment and maintenance stories are so much simpler. In other words, even if millions of personal servers existed already, why would a developer prefer to write Self-Hosted!Instagram instead of just Instagram?
Because urbit is designed to make that an easy thing to do. Say you've got a webserver, and you want to put a picture of your kid on it, but you only want the server to serve that picture to your Mom. On unix, that's really complicated, you need to do a lot of things to make that happen - not just implement a web app that includes authentication and give your Mom a new login and password to memorize, but also configure the web server properly and make sure your server is locked down and stuff like that.
On Urbit, that would be really easy, the equivalent of "mkdir mom; chmod +r mom; mv pic.png mom", because it abstracts away things like cryptographically verifying identities in the same way that unix abstracts away sending a file to a printer.
Do the apps or the users manage security choices like these?
They want the ease of use and security of a phone OS and app store, but they also don't want the data stuck in separate silos. I'm not sure if the idea is to have isolation between apps like iOS has or what.
Your post is more about real vs. not real, while I think the question was supposed to be satire vs. not satire.
http://you-have-just-experienced-things.tumblr.com/tagged/no...
He notes bone-lisp:
https://github.com/wolfgangj/bone-lisp/ http://you-have-just-experienced-things.tumblr.com/post/1455... -
- which he considers basically a lot of what Hoon should have been, i.e. sensible.
Creative works are not delicate embers that need to be protected from the elements. They are divine sparks, each one illuminating the darkness. That light is meaningless without eyes to see it.
What I'm afraid is that there are some really powerful and valuable ideas in Urbit but they will evaporate away from humanity's gasp because there's no way to practically connect them to anything.
Also a child's doodle is something you can ignore or throw away and nothing will be lost... while this has some value in it...
(Edited because I saw they actually have an understandable mathematical formalism for all of it. Sorry for guessing otherwise.)
I'm asking in terms of actual benefit it provides, not the technical part. I think at this point it's pretty clear that these efforts have failed due to lack of traction in that department (not enough people care about "owning their own server" or "controlling their own destiny")
Urbit has an identity system with limited space to prevent Sybil attacks. The network pretends to expose exactly-once networking that Just Werks so that apps don't have to worry about it. All apps are purely functional state machines to make it easier to handle them and transparently upgrade them from code updates. Sending RPC messages so your own apps I exactly the same as sending them to remote hosts, the same with reading files, with peer discovery happening for you by the kernel.
> I'm asking in terms of actual benefit it provides, not the technical part. I think at this point it's pretty clear that these efforts have failed due to lack of traction in that department (not enough people care about "owning their own server" or "controlling their own destiny")
Er, the whole effort has just started. What's happening right now is that people are experimenting with various UX'es. Many are failing (as expected) but I am confident a winner will arise. Just give it some time.
We just did a podcast with Software Engineering Daily also: https://softwareengineeringdaily.com/2017/01/20/urbit-with-c...
But the blog really highlights well what we're trying to accomplish in the near-term.
It's Jboss.
If you want to be generous it's Inferno.
Nock: https://github.com/cgyarvin/urbit/blob/master/doc/book/1-noc... My project's nock VM: https://github.com/PeterReid/hoplight/tree/master/vm
The problem with Nock as an embedded language is that you need a certain critical mass of jets before it's usable, unfortunately. How has that worked out for you?
I thought that Nock would be a cool language for this type of stuff, or replacing Bitcoins/Etherums embedded stack languages due to the purely functional, its-just-reduction aspect.
Infinite loops are covered by a general cost-tracking system. A computation begins with a certain number of ticks allocated to it, which an agent will use to weigh the CPU/storage space/network usage of what they're executing against the benefit of maintaining a relationship with the agent for whom it is executing. Infinite loops will just run down the tick counter and terminate.
I am not compiling Hoon. I have not actually learned it well yet! Since the programs involved are simple, I have mostly just been writing Nock slightly programmatically, like this: https://github.com/PeterReid/hoplight/blob/3971f7c7e45bceed9...
But I did write an abomination to make that a little easier. I am programmatically constructing a the AST here, since I have not gotten around to writing a parser.
lett(vec![
("decrement", lambda(vec!["target", "possible_antecedent"],
iff( equal(var("target"), increment(var("possible_antecedent"))),
var("possible_antecedent"),
invoke("decrement", vec![ var("target"), increment(var("possible_antecedent"))]))
))
],
invoke("decrement",
vec![var("~"), literal_u8(0)]
)
)
Edit: I thought to add, after reading the sibling comment, that another reason I cut out jets was that basic arithmetic operations were less obviously in scope, because the atoms are byte sequences instead of natural numbers.
https://github.com/mnemnion/ax/blob/master/ax%20spec.md
Also because once you say 'natural number', the arithmetic operations are already in scope, so to speak.
There are a few languages springing up in this space, often as something like "JSON + functions". I hadn't thought of Nock in that way. Some of those I find most interesting at the moment:
- Scheme: always nice, although should be limited to a pure subset, maybe without call/cc
- annah/morte/dhall: I love the ability to use URLs as identifiers, and using IPFS to prevent mutation. A a less-cluttered syntax like plain s-expressions would be nice; maybe a version for untyped lambda calculus too.
- Binary lambda calculus: a very nice representation, suitable for all the same church-encoding tricks as annah/morte/dhall. Wouldn't make sense to be so minimal if URLs are being used as identifiers though.
- For something fast or imperative, Forth (maybe Joy), APL, Lua, etc. might be better, although they'd have to be interpreted without arbitrary side-effects.
A crucial difference between Urbit and other networks is that planets are
scarce. Even when the network is fully populated, there are only 4 billion.
Early in Urbit's life, most stars and galaxies are not yet operating, so
far fewer are available. No one will ever be able to get planets trivially
and for free.
Urbit is a friendly network: a network on which you can assume that a
stranger is nice until proven nasty. Friendliness is a direct consequence
of scarce, individually owned identities. We're not changing human nature,
just creating the right economic incentives.
Most forms of network abuse are "Sybil attacks": they rely on an infinite
supply of fresh identities. Scarcity makes reputation work. Spam is a
business; if the cost of a new planet exceeds the amount of money you can
make by spamming from that planet until its reputation is trashed, there
will be no spam.
Shady stars and galaxies that sell blocks of planets to spammers will also
develop reputations as "bad neighborhoods," damaging the value of the whole
block. Abuse at any level is designed to be counterproductive and
economically self-terminating.
Urbit has no reputation system at all at the moment, simply because we're
so small that friendliness is automatic. The clear and rigorous structure
of the address space is not a reputation system; it is a platform on which
any number of such systems can and should be built. But we can't build one
until we need one.EDIT: You think I'm making a random political dig at Urbit that isn't borne out by the actual system, don't you. No, I am making a political dig at Urbit about something that is actually designed into the system. The design is about ownership, and about how not everyone can have it.
Or even a "how to do X with Urbit" where X could be anything.
Sorry, but no matter how great the ideas, until they can show an explanation anyone can understand it's all worthless. If you try hard enough you can explain block-chain and bitcoin and ethereum to a poet or painter or politician. Won't be easy, but you'll get somewhere.
Whereas their:
> If Bitcoin is money and Ethereum is law, Urbit is land.
...makes absolutely no sense whatsover to anyone, despite the plain words used. What's the correspondence, analogy, what abstracts what, what does what?! No place for your mind to even start chewing this. With this you can't even explain Urbit to a mathematician or to a philosopher... let alone to Joe Average or Frank Underwood.
My understanding of Urbit is that its trying to solve the problem of identity management, while maintaining that all data begins with you, while using ie we give our information to facebook, and facebook is free to use that information as it wishes (including modifying it, or deleting it). Facebook thus becomes the source if truth. Ideally, the control structure should be inverted; our machine is the source of truth, and facebook gets to read from us when we let it. And since we're the source of truth, there's no issue with sharing that data to anyone else (ie google).
This is of course what we have when dealing with desktop applications reading from our personal files; vim and sublime can be used interchangeably because our files are ours, and we always have access to it. Use google apps, and you get access to your text file only when google chooses to let you have it. If they refuse to give it back to you in a format recognizable by anyone else, then, well, you're fucked. But if we choose the format, and google must follow..
The idea, as they express it, that using a cloud service a n:1 deal; many users on a single app. Urbit tries to provide the inverse, 1:n. Many apps working solely for you.
After that is a bunch of interesting implementation details; a purely functional os, language; the pretense that multiple servers are one unified machine, the pronouncable base-256 encoding, the astronomy-naming system for address space, the political governance of Urbit as a network, etc.
How about this? https://www.popehat.com/2013/12/06/nock-hoon-etc-for-non-vul...
Would love to see a similar idea done by a different team.
Their go-to example seems to be social networking with an interface to Twitter??
I absolutely get the 'own your data/compute' idea.
I think a bespoke OS is a decent approach, as it removes a lot of legacy complexity and allows a few carefully-chosen, simple, unified approaches to things like I/O and addressing.
I like the use of a functional language, as it's an extreme form of isolation/sandboxing/reproducibility which makes sense in an untrusted online world. I don't see why a new language was invented though, when something like a subset of Scheme, Joy, plain lambda calculus, etc. would suffice.
I have absolutely no idea why they've invented a custom p2p network/addressing system. I chalk this up to huris, along with their spiel about ASCII punctuation, etc.
I have absolutely no idea how this has anything to do with social media. I assume it's just for buzzword value. I don't use social media, but I imagine programming language theory isn't its main appeal?
Even if we assume that all of Urbit's ideas pan out: interacting with Twitter seems to completely undermine all of it!
- Twitter is centralised, whilst the point of Urbit's network is decentralisation.
- No matter how much elaborate language machinery you build, there's very little you can actually do with Twitter, since they keep their database secret.
- Despite all of the sandboxing, reproducibility, etc. Twitter will not execute any code that you try to send them. The only operations which can be performed are chosen by them, and exposed as API endpoints.
- Doing anything with Twitter throws purity out of the window, since they only interact via I/O requests.
- No amount of fanciness in OS interfaces or language semantics can do anything to prevent Twitter modifying/deleting/overwriting/etc. any of their data at any time, without any notification to anyone; hence there are very few guarantees that the OS or language can actually provide about such values (e.g. there's no referential transparency, no way to know if a cache is invalid, no way to know if someone else will receive the same data you did, etc.).
- Whatever the resulting API looks like, it will be a constant source of incompatibility and churn, since Twitter are free to modify their API at any time. If some operation gets dropped, any applications which rely on it may break irreparably.
I get that the Twitter example seems to be along the lines of a minimum viable product, but it seems like a bad choice considering that it can't really make use of any of Urbit's features. It could be implemented as a big string of Javascript, with Urbit only being used to get it into the browser; the result would be about as integrated as any other approach.
A more relevant example might be a multiplayer game with a shared leaderboard, player chat and non-critical use of external APIs (e.g. gravatar for player pics), e.g. a clone of Words With Friends or maybe something with more animation.
The game itself would be a decent test of the programming languages, rather than just shuttling strings in/out of Twitter. The interactivity and chat would test the latency. The leaderboard would test shared access to data. Using external APIs would test the data-shuttling, in a way that doesn't much affect the application if the provider shuts down the API.
> I have absolutely no idea why they've invented a custom p2p network/addressing system.
Part of what Urbit does is make it easy to identify people and exchange messages with them, so it has to have a built-in idea of what identity means and how to tell who someone is. If it didn't have its own identities, each application would have to do that itself, which is where we are today.
> I have absolutely no idea how this has anything to do with social media.
It's just a use case that everyone's familiar with which illustrates something that urbit makes easy to do. But I think the hope is that "Hosting continuously available cryptographically identified server apps is easy now, what shall we do with that?" would spawn genuinely new niches, in the same way that mobile phones have.
> Even if we assume that all of Urbit's ideas pan out: interacting with Twitter seems to completely undermine all of it!
I think the idea is that you'd have some app on urbit that sits between you and your social media. So, when you take a picture of your kid and want to share it, you'd use an app within urbit that would (say) post it to twitter, put it on facebook but only for "family", and store a copy in the "backed up monthly by the hosting provider" folder. As social media apps come and go, you could use them while they're useful and abandon them when you tire of them, without having to export or import things.
Early in the article:
> What is an app, anyway? It's shared computing. Everyone's data is one data structure, in one program, on one server, owned by one corporation.
This is a callout to the Nazi slogan Ein Volk, ein Reich, ein Führer: https://en.wikipedia.org/wiki/F%C3%BChrer#Ein_Volk.2C_ein_Re...
And then the only other time "shared computing" appears in the document:
> To paraphrase Walter Sobchak: say what you want about the tenets of shared computing, but at least it's an ethos.
In the movie The Big Lebowski, the protagonists are harassed by by nihilists that the sort-of militantly Jewish Walter initially assumes are Nazis. When it finally gets through to him, he says, stunned, "Say what you want about the tenets of National Socialism, at least it's an ethos."
Yarvin is a deliberate, meticulous writer who prides himself on his references. This is not a coincidence, this is a white supremacist laughing at programmers not recognizing that he's calling competing software Nazis. Well, I happen to be reading up on Yavin's buddies[0] and I understood that reference[1].
[0]: https://www.amazon.com/They-Thought-Were-Free-Germans/dp/022... [1]: https://www.youtube.com/watch?v=YIp-0V6YKfQ
He's laughing at you because he knows the technical and political are inseparable, and the longer you think so the longer he gets to use you.