Hacker News new | past | comments | ask | show | jobs | submit login
Urbit in 2017 (urbit.org)
141 points by alfredxing on Feb 7, 2017 | hide | past | favorite | 147 comments



I appreciate the design notes, but there is a strange dissonance in the concept.

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.


I really don't think that worrying about what symbols Hoon uses is productive. There are tons of worse things to say about Urbit than "once it becomes bigger than C, how will Japanese people code it"

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.


Japanese is actually not the best example of "bracket pain" - in order to type in Latin script at all, you need to shift completely away from "native" input, as the various methods for typing kanji and kana tend to be some variant of lookup (via eg pronunciation) - select (like tab completing identifiers).

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'd actually have to check if Urbit supports utf8 code. I want to say yes, since the compiler internals technically can, but it's probably not hooked up correctly.

Are there any languages do this right? Even if identifiers can be utf8, they still have English reserved words. Maybe something like Forth, where the entire language is redefinable. Or, I dunno, Smalltalk.


There's always APL!


Haskell.


It's not just Arabic and Japanese. My Swedish/Finnish MacBook keyboard doesn't have the | and ~ characters printed anywhere on the keyboard. To type them, you just have to remember where they are. That's ok for me as a programmer, but doesn't work for anyone closer to a general user, which Urbit seems to expect because these symbols are used extensively in the command line UI.


Realistically there's no reason the interface can't simply autoconvert some arbitrary unicode character into a |, and leave that as an extension for anyone to add to whatever arbitrary language

It matters for reading/writing code, having uniform syntax, but it hardly matters for a general user's usage (in fact, I'm just talking about an alias, and its not so troublesome).

And regardless, this special character issue likely exists for any character; I imagine few are consistent among all languages, appearing on all keyboards.

So its just a pick your poison and stick with it situation, and whaddyaknow, English is still the most common internet language, and perl/bash have already ensured that most programmers have had to deal with these characters for decades


I agree on the dissonance, that rankled me too. What does "as usable as any widely used app" mean, in the context of a hobbyist OS for hackers who have already committed to learning a weird new functional programming language?

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.


I read the point as being to move on from that interface style.


> It doesn't seem like non-English users were ever considered when the decision was made to "make ASCII great again".

That turn of phrase sure is pretty revealing in this case.


I wanted to like Urbit (I write p2p software), but their connection with alt-right and ant-democratic reactionary movements is a deal breaker. To say it doesn't affect technical decisions is naive. Have you ever wondered why their network layout is like little hierarchical fiefdom? And not flat p2p? It's no accident and deeply related to political and social beliefs. It's dystopian and isn't the future I want.


That network topology is actually quite logical and doesn't say much about politics.

P2P connectivity almost always requires a third party to do a three-way handshake. In IPv4 this is because of NAT, and in IPv6 it's usually still needed due to stateful firewalls. Having stable upstream nodes allows rapid bootstrapping of a P2P network by providing known stable points to act as introducers. You can do it in a less hierarchical fashion, but at the expense of performance and stability and possibly security unless you are very careful (see: sybil attacks).

Curtis' political views are what they are. I fundamentally disagree with the core thesis myself-- while I do have problems with pure democracy I see no evidence that aristocracy is in any way superior. But at the same time I believe in treating others' views with respect and respecting their right to hold them. I also must point out that Curtis' views are often hysterically misrepresented and exaggerated, and I doubt he has much to do with today's alt-right which is more of a populist phenomenon. In fact I could see a neo-reactionary calling the alt-right "demotic", which as far as I recall is the term they use for rhetoric of that style.


Neoreactionaries/Dark Enlightenment bloggers are fellow travelers with the alt-right. There's always a verbose woolly-headed (pseudo)intellectual movement that accompanies the vulgar street brawlers and vandals.


Didn't say they weren't, but you don't win conflicts like this by blacklisting. Ideological blacklisting makes you appear intellectually weak and leads people to think the opposition must have something to say that you can't counter. Censorship and blacklisting is something people do when they can't win the argument on merit.


I agree with you. Monarchists and HBD and so forth need to have their views dragged out into the order and debated vigorously with. I'm just saying that NRx and alt-right are on the same side of the spectrum.


I am not sure that the network layout of the present is less dystopian -- more or less everything is owned by Google, Facebook, Amazon, etc.


If that network layout is unsuitable, then that's reason to dislike Urbit. If not, it seems weird to complain that their political opinions are causing them to make unobjectionable technical decisions.


As a way to signal not taking themselves too seriously? :)


I've been (rightly) downvoted for pointing this out on HN in the past, but one of the main developers associated with the Urbit/Hoon/Tlön/Uqbar/etc project is someone active in the alt-right (although there may be something to say about whether or not that has anything to do technically; I wouldn't know or particularly care).


It doesn't make sense to call him active in the alt-right since his blog finished in 2011 and the alt-right didn't exist back then. You probably mean neo-reaction which is highbrow right-wing idiocy and not populism.


NRX is heavily associated with the alt-right. The term has more to do with ethnonationalism than pure populism.


For a toy project of mine, I needed a way to encode small programs to send around. I originally wrote a interpreter for the MIPS instruction set, but then I encountered Urbit's functional machine language, "nock", and switched right over to that. It ended up being a much much simpler interpreter with more compact program encodings and a lot fewer arbitrary-feeling decisions involved. Nock also turns out to be a really straightforward compile target for lisp-like languages. Nock is confusing to approach, but it is really very clever. I would recommend learning it if you are in the mood for a puzzle!

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


Neat! Are you compiling Hoon for the programs, or did you make your own language that targets it? How are you handling infinite loops or calling potentially unsandboxed jets? Reading over your code, it looks like you expanded Nock a bit with opcodes for e.g. hashing. instead of having a base stdlib context you are calling against with a jetted gate for it. Any reason?

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.


I cut out jets entirely. The programs that I anticipate having to execute are mostly simple compositions of retrieving data, storing data, transmitting packets, and cryptographic operations, so being able to do heavy computations did not seem worth the complexity. It is still early days in this project, though, so I might change my mind.

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)]
    )
  )
But I will probably learn Hoon instead.

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.


This is one of the reasons I included all arithmetic operations in ax:

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.


I get that Nock is half philosophical perfection, so it makes sense to me. All those operations can be trivially defined without any cost, but they muck up the spec (Does your language gzip to 340 bytes? Can I wear it on a t-shirt?).

Not that there's anything wrong with defining a language that is usable out of the box, but at the same time muh intellectual purity.


You might have to use the back of a t-shirt.

A spec which includes the term 'natural numbers' but not subtraction might even be argued to be incomplete, rather than minimal. Ymmv.


You can synthesize subtraction from recursion and addition. Peano numbers really only have successor, but is still a valid encoding.

Really, you aren't wrong. But then how would we be able to advertise how stupid Nock is for those sweet internet points? It can't even do subtraction! Come see, tickets one dollar!

Addition is kinda the prime operation that is needed - everything else can be dissolved into it, but without it the jet system doesn't hold up because your language can't really /do/ anything. If you didn't require jets to be transparent to the reduction, you could just have /all/ operations be jets and not even pretend Nock was useful without them.


Check out https://github.com/tibru/tibru No primitive arithmetic operations at all, no need for jets but the same time complexity as arithmetic in C just with a higher constant factor.


> For a toy project of mine, I needed a way to encode small programs to send around.

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.


It's a wonderful luxury to craft such a sufficiently vast work of nonsense that no one possessed of sufficient reason to craft an informed critique will ever feel it worthwhile to invest the time to do so...one can putter away indefinitely in such a self-crafted safe space


you-have-just-experienced-things on Tumblr is both a functional programming nerd and someone who has taken an interest in Urbit. Here's the tag:

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.


Must all creation be judged? Subject to code review? Criticized and torn apart? Next, let us ban the child's doodle, for it is a self-crafted safe space, free of criticism and the harshness of reality.


Yes. Yes. Yes. And Exalted, Loved, and Adored. Critique is not the same as banning. The Child's doodle is always critiqued, which is why we say "Good Job!" to the child who shows us the doodle. The doodle is not created in a self-crafted safe space by any measure.

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.


The child's doodle is something one ca see and understand. You can even try to psychoanalize it or whatever.

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.)


The creator of this project published a website, took on volunteers to help build it, and held meet-ups to discuss it. In other words, they went well out of their way to publicise it. So yeah, at that point anyone has the right to say anything they like about it. If the author didn't want that to happen, they could have just kept it a private project, never to see the light of day.


I remain unsure whether Urbit is a real thing or simply an incredibly long-running satire. Their missives do nothing to clarify this point.


Well, you can run it and it does things, which effectively puts the question of "real" or "satire" into our hands. At this point, it is what we make of it.


You can use an onion article as a force to motivate activism, unleashing a very real effect upon the world. But it remains satire.

Your post is more about real vs. not real, while I think the question was supposed to be satire vs. not satire.


The parent post from jff was explicitly framed as "real vs satire" and not as "satire vs not satire".


It used the word "real", but I'm pretty sure it was a synonym for "not satire", not the more philosophical meaning that callahad took. It's very common to use the word "real" that way, for something that isn't just extant to demonstrate an idea.


That was gloriously poetic.


I've said this before but one of the very cool things about programming is that it can easily be both.


I get the feeling that they are going to work on it come hell or high water until it lives up to their intentions. So while it might read like satire today, it probably won't in the future. But yeah, I don't have a non-costly use for it today despite reading the docs...


That's how I feel about Unix, too.


Reading urbit, I feel like I've stumbled upon some ancient alien artifact, that no one has any idea what its purpose is.


the 'alien artifact' characterization is one used by popehat in his explanation of urbit from a few years ago, which i recommend to those curious as to what exactly urbit is: https://www.popehat.com/2013/12/06/nock-hoon-etc-for-non-vul...


That's ClarkHat, not PopeHat.


aha! apologies


Much of the communication has in the past been meant to convey exactly that feeling. It's not uncommon for people on the urbit network to refer to themselves as martians :-)


Personally, I would describe the feeling as somewhere in between reading SICP and reading Momo. That's a great feeling, and it's kind of the opposite of the feeling you get from the mess that much of computing is today.


What's Momo?


Urbit really feels like a case of aesthetic-oriented programming. I'm not sure what problems (if any) it's intended to solve, but HEY IT LOOKS COOL.


...still no "Urbit for mere mortals guide" or something like this?

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.


Bitcoin is digitally manages money, ethereum digitally manages laws (in the form of autonomous contracts, in the form of code is law) and urbit digitally manages real estate (in the form of hierarchical address space).

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.


Urbit's not meant for mere mortals, it's meant for the philosopher-kings of a bizarre neoreactionary future.


>"Urbit for mere mortals guide"

How about this? https://www.popehat.com/2013/12/06/nock-hoon-etc-for-non-vul...


Yarvin's having a laugh at all of you.

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.


How is this different from many other approaches like Sandstorm, or any other effort to "decentralize the web" by giving people their own servers?

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")


It provides an application framework and reinvention of the world to have decentralized apps work, instead of just providing packaging apps like Sandstorm.

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.


Sandstorm does a whole lot more than "just packaging apps", and compared to most other things in the space is ridiculously ambitious... but Urbit does indeed go far further.


This doesn't answer my question. In fact, it's the opposite of what i asked. I said:

> 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")


I'm not really sure what else to say, then. Can any project with similar ideas answer anything other than "no, nothing different"? The idea for all the different projects is to make self-hosting sufficiently easy and usable, just different ways to come about it. You could ask the same thing about IPFS or even Bitcoin, and the disregard it when you don't get a yes.


Bitcoin does have a use case--you can buy drugs with it. I'm not going to judge whether this is moral or not, but the point is it's serving a previously unmet need. There have been tons of attempts at cryptocurrency before Bitcoin, but Bitcoin came and it just worked to serve this purpose. And it enabled whole new type of transactions online. Currently it's definitely not mainstream currency but at least it has a clear set of customers from which they can expand.

Which means, it's not like Bitcoin invented a non existing demand. It already existed, and Bitcoin came and served the previously unmet demand.

My question was whether this urbit technology is something like Bitcoin where it serves a previously unmet (AND significant) demand. All previous attempts at this approach failed NOT because the technology was bad but because not enough people used them, which is different from Bitcoin.


Urbit is a network where you can, by default, trust the other party you're communicating with. It does this by making identities hierarchically controlled; if you behave badly, the rest of the network will blacklist you and your master. Thus, your master has a strong incentive to police your behavior.

tl;dr; it should be a spam free network.

Note that this is already a mechanism used in the public stock markets; your broker polices your behavior because if you screw up, the broker is on the hook for your losses, and the clearinghouse is on the line for the broker's losses.


I think the answer, the unmet need Urbit is trying to meet, is "I wish I could install apps on a server as easy as I do on my phone." On your phone, the security comes from a crack team of engineers paid by Google or Apple or MS to make sure no bad apps get in, and on Urbit it would come from Urbit's architecture.

But to be clear, none of those apps exist yet; at this point it's just barely functional enough to start developing real apps.


Honestly? Probably not then. You can make social networks that can't be censored, like GNU Social, or other decentralized apps easily. But then you have the problem you mentioned of "but who actually wants that". All the things that Urbit can do is already possible, just not easy, and each product in the same sphere has to reinvent certain subsystems to do it. Nothing is stopping you from writing Facebook-on-BitTorrent. The identity on it wouldn't be able to talk easily with Twitter-on-IPFS, but that can be fixed with elbow grease too. It's just easier to have them both powered by frameworks that provide stuff from them both, and preferably easier for your grandmother to join.

Sorry, I kinda lost the plot, didn't I? I'm not actually a believer that Urbit will do any of this, or that it's answer to the question of how to get people to switch to a decentralized platform. I just think it's a neat project to play with. But, fundementally, it doesn't do anything new, just connect several things together.


> 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.


The concept of data portability has existed forever. It's definitely not "just started", and that was what I was pointing out.


A couple thoughts from an early backer who really, really wants Urbit to succeed (and fears it won't):

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.


Thank you for the comment. It is nice to be able to talk to someone who believes in Urbit ideal. I have a question for you: there are many advantages of running things on huge scale. How do you see Urbit will solve it? For example:

- 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?


Thanks for responding! Sadly the signal:noise ratio on HN really plummets when urbit gets mentioned. Zaphar's response is good but I'll go in to more detail (as I see it):

- 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.


I don't think the acerbic swipe at HN here was merited; as threads about programming environments go, this one seems pretty high-signal, with less flamage than any of the recent large threads about Go or Rust.

If your expectation about threads for Urbit is that they center on its real-world applications or potential, the project itself has done you no favors. It doesn't so much beg as howl madly for the kind of meta discussion that dominates this thread.


That's a fair point, I was complaining about past Urbit threads, which sometimes spend a lot more time on the founder's weird-but-irrelevant politics than on the technical merits of the project. I expect and welcome flaming about why it's built the way it's built! I would so love a big deep thread between the urbit devs and some really smart people who have deep misgivings about its architecture, because the outcome of that would help me decide whether it's worth investing time learning hoon.


You say his politics are irrelevant. I disagree: the only person in the world who probably has a complete picture of what this system is meant to be is Yarvin, and there are troubling indications that his political principles influence the design. See, for instance:

http://web.archive.org/web/20131014210123/http://www.urbit.o...

But that's neither here nor there, because this thread hasn't really centered on his odious politics, but rather on the dubiousness of its design and the steps the team has taken to conceal the basic details of the design behind a wall of obfuscation. We generally don't like distributed systems that go out of their way to make themselves harder to reason about.

I'd further add that a lot of basic support Urbit receives on places like HN seems premised on the idea that there's something intrinsically novel about it. But that's not so: overlay networks are a relatively well-trodden topic in CS, including overlays based on what we used to call "mobile code", including functional mobile code overlay networks.

I'd like to see more discussion of decentralized overlay networks, including compute overlays, on HN. I find it unfortunate that all those discussions for the past year or so have more or less been captured by this goofy system.


shrug As you like. If whoever wrote Jira revealed that the reason "stories" and "bugs" and "epics" all have the same default fields was because he thinks capitalism is better than socialism or what have you, I would entirely ignore it, and I don't think I'd be any poorer for it.

I would also wish for more projects in this vein. If something came down the pike with similar aims but minus the spooky political baggage and the eccentric syntax, believe me, I'd subscribe to their newsletter. But AFAIK there is nothing in the offing even remotely similar to urbit other than urbit.


That's because Jira is just a bug tracker. None of us need any assistance understanding the implications of a bug tracker, even one as sprawling as Jira.


> - bandwidth : ... More generally, if Urbit got even moderate adoption, the hosted-server companies would fall over themselves supporting it.

I am highly skeptical -- the Wordpress has pretty high adoption, and it is useful for "non-techy Mom", but there are very few companies which support wordpress integration, and if they do, it is at a much higher price (bluehost: $3/mo regular hosting, $20/mo wordpress hosting)

> - mail : ... 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.

This blackhole mechanism is very much like spam problem, so it has all the usual questions: Is it going to be managed by someone? Does identity get un-blackholed after some time with no spam? Can you pay $$$ to make this process faster? Can someone blackhole whole galaxy? What if your computer gets malware which spams other users on your behalf?

I am not asking for immediate answers to these questions, I just wanted to point that having "federated identity" will not fully solve spam problem.

> - viruses : Urbit is designed to be essentially impervious to malware. ... 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, ...

That's not the worst case scenario. The worst-case scenario is bitlocker reaches in your urbit (via whatever mechanism you use) and encrypts all the your data there, slowly over time (so your backup is corrupted, too) and starting with least-recently accessed files first, to minimize chance of early detection.

Looks like in this situation, your only hope is that your hosting provider kept your backups, and this is not guaranteed at all. So basically not much better than existing self-hosting systems.

Note: I have not actually checked, but I suspect that Urbit may keep all the previous versions of the files around. This will help against bitlockers, but:

(1) Is there a mechanism to permanently remove data, say because you accidentally uploaded 25GB blue-ray movie? If yes, this is what bitlocker will use.

(2) Are you sure that every user will have different urbit credentials and admin credentials to the hosting provider? Because if not, then bitlocker will ssh into your hosted machine and damage the files directly.

(3) There are other things other than bitlockers. Malware will use your account to send SPAM, use your webserver to sell illegal drugs, use your CPU to mine bitcoins, and generally make a botnet out of your urbit.


> Wordpress has pretty high adoption, but there are very few companies which support wordpress integration, and if they do, it is at a much higher price (bluehost: $3/mo regular hosting, $20/mo wordpress hosting)

What's stopping you from getting the $3/mo package and installing wordpress yourself? The pain of learning how to administer and secure and update it, right? Urbit is (or claims to be) painless enough that you would install it yourself and not need to do any maintenance afterward.

> This blackhole mechanism is very much like spam problem, so it has all the usual questions: Is it going to be managed by someone? Does identity get un-blackholed after some time with no spam? Can you pay $$$ to make this process faster? Can someone blackhole whole galaxy? What if your computer gets malware which spams other users on your behalf?

This is all up to apps and users to handle. If you did write an app that defaulted to "accept messages from anyone" then you'd need to include some sort of "report spam" feature in it I suppose, but I think it's assumed that most apps would just ignore unsolicited messages. You could also do more nuanced rules, like "Ignore messages from accounts that are less than a week old; if the account is older than that, you can show me one message, but ignore any subsequent ones unless I respond to the first one." Up to the developer of the app.

> Looks like in this situation, your only hope is that your hosting provider kept your backups, and this is not guaranteed at all. So basically not much better than existing self-hosting systems.

"Your hosting provider might not do a good job of managing backups" is a) well outside of urbit's purview, and b) something I thought was pretty much a non-issue these days.

> Are you sure that every user will have different urbit credentials and admin credentials to the hosting provider?

At the end of th day, urbit is just an executable. You log in to your shell, you run ./urbit, and you tell it what to do. Anyone who can log in to your shell can run your urbit and tell it to do something you don't like. So of course you need to keep your login and password safe, and the host OS needs to be secure, and so forth.

But, if the claims of the people who made it are true, it should be impossible for J. Random Cracker to send a message to an urbit over the network that makes it do something bad. Not "we think we found all the buffer overflows" impossible, I mean "mathematically proven to be impossible" impossible. That's why they rewrote the thing from the ground up in such a hokey way. Whether they succeeded in, or whether that claim is laughably deluded, is something I'm hoping someone much smarter than me will definitively determine someday...


So we started from this ideal picture of urbit:

> Urbit is the server-app-container thing that would make my non-techy Mom want to pay $5/mo for a hosted server instance.

> Want to see what Bill Smith is up to? finger bsmith. Want to argue about politics? talk.politics. God, how simple things were!

> Urbit is designed to be essentially impervious to malware.

... and we ended up with:

> but one presumes that if you host an urbit on EC2, you'd also be putting cloudflare in front of its webserver

> If you did write an app that defaulted to "accept messages from anyone" then you'd need to include some sort of "report spam" feature in it I suppose,

> "Your hosting provider might not do a good job of managing backups" is a) well outside of urbit's purview,

> So of course you need to keep your login and password safe, and the host OS needs to be secure, and so forth.

So what are then advantages of urbit over, say, wordpress install with some plugins? So far I have heard:

- Universal identity system for other urbit users

- Automatic application update

- Some subset of security bugs has been eliminated

- Simple application installation

Wordpress (with plugins):

- Has OAUTH and facebook/g+ auth plugins

- Has auto-update functionality

- Written in PHP, which entirely eliminated at least buffer overflow bugs and concurrency bugs from the user-written code.

- I can find EC2 images with wordpress already installed -- just create a machine based on them and you are all set! And wordpress provides somewhat easy interface to install new plugins!

And apparently neither Urbit nor wordpress take care of the hard stuff:

- How to set up backups and make sure they will not fail 6 month in (and no, most hosting providers will not do this automatically for you)

- How to prevent malware on your personal computer from destroying all your digital life

- How to prevent SPAM while still allowing messages from people you did not know before

- How to monitor the server and fix it (restart?) when it fails

- How to select the hosting plans to optimize cost for the resources you want to use

Now, you may say that urbit does [will do] much more that wordpress, but so far you have not mentioned anything like that. Your original comment mentioned: mail server, minecraft server, and apps that "let you upload a file to the cloud and they let your friends access it". Wordpress does the last one, and from I understand, urbit will not be that great for the first two ones.

So it does not make sysadmin's life much easier, nor does it give you some killer features you cannot find anywhere. What's the point then?


Dude, it's an os, a container, a thing you write and run apps in. You want it to select a hosting plan for you and help you if you forget the password to the box it runs on?

Look, if you're a hacker, and you've got some time to kill, just download it and run it and spend an evening with the "Getting started" doc and writing a little bit of hoon. You'll figure out what it is and what it might be a lot faster than by asking questions on a forum. And if you're not, ignore it, it is nowhere near being useful for end users yet.


urbit won't necessarily solve the personal web server costs too much to run piece of this although with the right specialized for urbit hosting provider it is solvable.

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.


> Keeping the software updated on your urbit is automatic and done without interrupting service. Maintenance is almost non-existent.

Wow, this sounds scary. It will be just like Chrome extensions turning into malware, but for EVERYTHING:

https://arstechnica.com/security/2014/01/malware-vendors-buy...


No more scary than when you use apt on a debian machine to keep things up to date. However this time you have the added benefit of being able to rollback to a previous version of the software with the same ease and also of being able to trace the source of your software to a cryptographically verifiable entity.


I disagree. I actually know that debian's system:

1. Has a limited subset of people who can upload packages. Becoming one of these people is hard.

2. Has strict rules about package quality. A detected attempt to upload malicious package will cause uploader's privileges to be removed.

3. There a is trusted group of people who have the authority over all packages and who can remove the bad ones. Anyone can contact them and point out that the change is malicious, and they will listen.

4. There are enough people who look at the package changes who will detect malicious packages.

None of them are true for Chrome extensions / urbit code (unless there is something I have not noticed):

1. Anyone with (google account | urbit identity) can upload packages.

2. There are no rules about package quality (until recently, google support did not care about ad injectors for example).

3. There is no trusted third party to deal with bad packages (again, until recently google support did not care except for most obvious cases)

4. Since number of packages is so high, and it is for "everyone", most package changes will never be looked at.


All of your points in favor of debian's system really only apply if only use Debian's official package repositories. Something that you can absolutely do in Urbit as well. Nothing says you have to pull packages from every possible location out there. Urbit can absolutely have it's share of official repositories of applications with the same quality and safety guarantees that Debian has. And indeed many of the apps you get already come from a default official source. The star or galaxy you got your ship from.


    > How can personal server compete with CDNs?
It wouldn't, it'd use them. My urbit will keep my blog content in a database, and on my command, compile me a bunch of html pages and send them to surge.sh.

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:

https://indieweb.org/POSSE


Interesting, I appreciate this explanation from an "outsider". This actually sounds very similar to what I recently posted[0] on the sandstorm thread. Also, something I picked up from that thread, but haven't looked into much myself is Cloudron[1].

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/


> ...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.

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?


> 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.


One thing I really want to know is what data can apps access. Is it like most phone apps where my data in one app is secure if some random game would like to read it?

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.


Someday I hope to understand what urbit actually is :-)


This is probably our best general overview: https://urbit.org/posts/overview/

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.


Urbit is a VM/library/io it runs programs, sometimes local, sometimes remote, sometimes distributed.

It's Jboss.

If you want to be generous it's Inferno.


I never could work out what JBoss was meant to be either.


Lets go see what their website says. How bad can it be?

> Red Hat® JBoss® Middleware is a family of a lightweight, cloud-friendly, enterprise-grade products that help enterprises innovate faster, in a smarter way. The ideal middleware portfolio for open hybrid cloud environments, our products and services help you accelerate application development, deployment, and performance, integrate data and applications efficiently, and automate business processes across physical, virtual, mobile, and cloud environments.

Its bad.


You're not alone


Let's start with this... If you ran your own server, what sort of uses do you think you'd have for it?


Email, document sharing, custom web apps, etc, does urbit do this?


Not well, yet. But that's the plan. All in the blog post.


> All in the blog post.

Email and file sharing aren't mentioned. What can it do now?


It has a webserver and networking and it can access the filesystem and it can send messages to other users securely. There's also an ntalk kind of app and a simple threaded discussion things but they're more like demo apps than things you'd use intrinsically.

I think it's fair to say the only reason to run this is to develop for it right now, it's not something end users have a use for.


Is the idea behind urbit that you have one place that stores all your data and then you can use different services to access and use that data in whatever way they want?


Correct-ish - you can run other people's applications against data you own to get things done.


Why did they go with 32 bit addresses for planets? Seems short sighted given the woes of the ipv4 -> ipv6 transition.


They address this is a way to cut down on spam.

    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.


Artificial scarcity helps them make sure that only the "correct" people get planets.

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.


It's not just about gatekeeping. My reading seems to imply that its design also ensures they have economic and political power if the thing ever becomes popular. Their long game seems to be a pyramid scheme at best.


This is just grousing; If urbit got so popular that addresses were sparse, a big if, planet owners would just vote to add more.


Now you're faced with exactly what the GP said: address spaces are hard to change later.

What part of Urbit involves voting?

Even if Urbit were a democracy, which sounds improbable, why would the people who have the scarce thing vote to open it up to more people? Look at Bitcoin right now: they can't increase the block size because large miners benefit from the small block size.


I shouldn't have said "planets". I think only the top 256 "galaxies" (owned by the founders and investors) really get a vote. Maybe? That might not be right, I don't remember the details.

But there are two other misconceptions to clarify.

First, the defense against "What if the people who run urbit turn out to be jerks?" is not to have democratic voting. And it's not Bitcoin-style "51% of us agree" forks either, urbit is a top-down hierarchy. The defense is that Urbit is open source, and anyone could go out and start their own Urbit network and ask people to join it.

Second, planets have (theoretical) value, but they're not fungible, they're identities. A good analogy is: imagine if Reddit were designed to only have 2^32 handles, and they each cost a dollar. In that scenario, if Reddit said, "Hey, we've sold all our handles, hooray! Now we're going to issue an update that makes some more available", would existing Redditors lose anything?


Why would they each cost a dollar when they're running out? How could you possibly defeat economics like that? Scarce things are expensive.

The Redditors who are paying lots of money for the scarce handles, and the people they are paying lots of money to (the feudal lords or whatever, I don't know what to call people in this hypothetical Reddit/Urbit mashup), would absolutely lose out if more became available. They would be like taxi medallions, or houses. Urbit itself makes the analogy to real estate, and real estate owners do not have the tendency to say "yay, more neighbors!"

And I don't need to fork Urbit given the people who run it are jerks; I can just run my own normal Linux server, which runs reasonable well-designed programming languages, and can subtract in constant time.


> Why would they each cost a dollar when they're running out? How could you possibly defeat economics like that? Scarce things are expensive.

The "urbit is land" analogy is, like any analogy, only so useful; don't carry it so far that it breaks. Urbit addresses are numbers, and numbers aren't scarce. They're only limited by convention, and conventions can change.

I think the devs like to trot out that "land" analogy for BTC users, to help illustrate that urbit addresses aren't fungible, but it only holds if you imagine that land in this scenario can be created out of thin air by the king when he feels like the kingdom is getting crowded, and if polluting your land makes other landowners pretend your land doesn't exist, and if used land on the secondary market is all presumed to be polluted.


For those using Nock and seeking an alternative take on Urbit check out this open source project https://github.com/tibru/tibru A few willing devs could take this forward with open libertarian ideals. There is nothing special about Nock and Urbit technically or mathematically.


I find Urbit very confusing. It uses a bespoke virtual machine for a bespoke programming language, uses a bespoke approach to optimisation, uses another bespoke programming language which compiles down to the first, has a bespoke OS written in that second language, connects these OSes into a bespoke p2p network, all in order to.... what?

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.


Interesting thoughts. I'll just weigh in on the ones I feel confident answering:

> 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.


Needs a GUI to be useful for any non-enthusiast users. Does urbit need any non-enthusiast users at this point, though?


There is a well-integrated web api/interface to the shell-based services.


An interesting idea confounded by inexplicably strange design choices, and the regressive, odious politics of its creator.

Would love to see a similar idea done by a different team.


Poor old Urbit! Learning curve so steep that nobody has the time to figure out that it's bollocks on its own terms, and they are obliged to dismiss it purely on the grounds of who it was created by.


What makes it bollocks on its own terms?


Urbit is totally new to me, but from what I understand, the hierarchical identity layout and restricted address space are instant red flags for any distributed system. Oh, and the founders assert ownership over a non-trivial block of addresses.

Looking in from the outside, this looks like a fairly transparent attempt at bootstrapping a fiefdom: Create a type of digital "property", artificially restrict supply, reserve a huge chunk for yourself, and hope it becomes popular (making you "digital rich" and "digital powerful").


The funny thing is that, after dismissing criticism based on the creator and his politics, you just made a technical criticism that is basically reaches the exact same co conclusions about its intent and effects as are frequently made by those reasoning from the author's publicly stated political views (including those directly attached to Urbit docs before those were cleansed to make the product more commercially viable.)

Which is not to say you are wrong to prefer technical criticism, only that in this case the telegraphed political intent seems to match precisely the technical criticism.


Not speaking for the parent comment, but maybe the two aren't so inseparable after all. I would rather not immediately dismiss this project, since there are multiple contributors to it and it seems cruel to bash their hard work just because of Yarvin's presence. However, it seems like there definitely is a similarity between the product of the man and his ideology- especially the same inscrutable, esoteric, unconventional nature.


Is that really so surprising? The same biases and assumptions that influence our software must surely influence our politics. It's all systems design, after all.


Be that team and take https://github.com/tibru/tibru forward




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: