This project is reinventing a bunch of stuff that's completely orthogonal to the goal of a decentralized app platform. They've written an OS, a filesystem, a networking layer -- all in a completely new language that looks incomprehensible (https://github.com/urbit/arvo/blob/master/arvo/clay.hoon).
I doubt very much this project will get much traction due to the enormous conceptual overhead of working within its ecosystem. There's a huge learning curve approaching something like this from the Unix/C ecosystem, and I don't think it's merited.
“[I]n many ways nonsense is a more effective organizing tool than the truth. Anyone can believe in the truth. To believe in nonsense is an unforgeable demonstration of loyalty. It serves as a political uniform. And if you have a uniform, you have an army.”
― Mencius Moldbug (a.k.a. Curtis Yarvin author of Urbit)
The language designer must be a fan of writing assembly language, combined with some LISPy syntax, or something... that's the closest analogy I can think of from looking at it. Maybe it requires some IDE type of editor to make it comprehensible.
From the authors:
Its syntax is entirely novel and initially quite frightening.
[...]
If I can summarize Hoon's goal, it's to be the C of functional
programming.
[...]
On the other hand, the apparent complexity of Hoon is very high.
When you open a Hoon file, you are confronted with an enormous
avalanche of barely structured line noise. Again this reminds us
of C, which makes no attempt at the kind of abstract prettiness
we expect from a Pascal or a Haskell. Learning Hoon involves
learning nearly 100 ASCII digraph "runes."
Is this a harsh learning curve? Of course it is. On the other hand,
it is not a mathematical task, but a mechanical one. It is trivial
compared to the task of learning the Chinese alphabet, memorizing
the Qu'ran, etc, all rote mental tasks routinely performed by normal
human 11-year-olds.
My current pet theory is that they obfuscated Urbit so much because otherwise, the artificial scarcity of address space would be unenforceable. As it is, you have to make a huge investment in learning their tech to understand everything, and if you wanted to launch a competing network, no one would help you establish your network effect. Everyone else who has gone through the same elaborate hazing ritual has developed enough camaraderie to keep the defection rate low. The profitable strategy is to cooperate, buy a star, and build software people will want.
I have some skepticism, but if Urbit and its peer-to-peer network are actually useful things, the incentive system for building useful apps for it exists. It might be strong enough.
There's no reason a more
comfortable language can't be implemented on Hoon; it's just that no one has done it yet, because no one has come along who both understands Hoon well enough to do it and finds Hoon unpleasant enough to bother.
This may mean Hoon once learned is easier to cope with than it looks (which I doubt, because it looks like vaguely Lisp-flavored assembly) or it may just mean that nobody like that has come along yet.
Worse, there is no formal spec or particular commitment to either the jets or the means by which the VM communicates with its host environment or nodes communicate with each other; this makes it impossible, not just impractical, to replace the environment with an alternative rather than merely wrap what exists - Nock on its own is simply not enough to build on.
Instead of the stated intent of giving you control of your own environment, the actual goal appears to be the opposite.
Communication between urbits appears to be well defined, although my lack of close familiarity with the codebase makes it impossible for me to point at precisely where; ask someone at Tlon, or someone in Urbit :talk. Communication between an urbit and its host is precisely defined by the u3 implementation.
The C standard library lacked a formal specification for over a decade after its creation. Lisp lacked one for almost thirty years. At least one of these should be an argument in favor of "build it first, formalize it later".
What did they sell? Apparently, some (all?) of their potential user ID space.
Urbit, under all their jargon, is a base for a federated social network. Sort of like Diaspora. (Right now, they say they have chat, so it's sort of like IRC.) They recognize that a big problem with social networks is spam. If you can freely create user IDs, it's hard to stop spammers. But if user IDs cost money, then spam blocking costs spammers money (their purchased online identities lose value) and spamming is no longer cost-effective.
So their solution is to create a market in user ID space. It's not clear if this will work out, but it's something. If you buy an ID, you own it, in the Bitcoin sense. That is, you're not at the mercy of some service provider, and can freely move from one service provider to another without their permission. (I think this is right. Not entirely sure.)
It's not clear if this will work in the social space. They have the underlying machinery, but nobody has built the Facebook or WhatsApp or Dropbox killer on top of it yet, so it's useless to end users at this stage. The concepts are interesting; it's good to see people trying original ideas.
If someone builds an easy to use social application on this and gets some services to host it (like Wordpress hosting), this could get actual users. Right now, it's a developer toolkit.
No it doesn't. The marginal price that people are willing to pay diminishes as the supply goes up. There may not be enough buyers in the world to saturate demand for the entire address space.
"Implicit valuation" is not the same as the "actual value", it's just a calculation that is customary to make in situations like this whether or not the result has any bearing on reality. In fact, that was kind of my point: somehow, Curtis was able to get 500 people to buy a pig in a poke for $205. That in and of itself is an impressive accomplishment.
For a stupid example, say someone makes electricity stop working. But there's lots of things that could make it less valuable in the future than the value implied by the recent sale.
I'd like to offer you the chance to buy one of my personal rock collection for $15m. As my rock collection contains only 5 rocks, this offer represents 1/5 of the total number available worldwide. This is a chance to get in on the ground floor of something big!
If you had spent a small amount of time and energy propping up the general sentiment that your rock collection was the next big thing, yet had bountiful positive results in the the rock hype cycle, and the rock hype cycle regularly paid out considerable profits on such investments, I would indeed consider buying one of your rocks had I the $15m.
People regularly spend millions on sculptures which are indeed just special rocks. The Guennol Lioness comes to mind.
Then, if you made the rock cost a negligible amount of money given the regular payouts on such ventures, I would really start considering it. Don't be a boob.
Because it sold out in 4 hours from their mailing-list-only announcement. So from a purely supply and demand perspective, it seems they could have gone higher.
Or maybe just a little higher. Their mailing list is comprised of the people most likely to buy this sort of thing. Selling to the general public might not result in many more sales than the mailing list alone, especially considering that the purpose/use of Urbit is so opaque.
Quite possible. Personally my decision to buy was based on a desire to finance the development of an interesting new operating system and p2p network -- so I paid cash to a company that is doing that -- so the purpose was clear from that angle.
Is there a verifiable record of which real-world entities bought in? It would be nice to have a way to rule out the possibility that they sold it to themselves to create the perception of demand.
In new schemes, you sell 10%, but claim you sold 100% in 4 hours so that you can start a new sale due to the "high demand" and try to really sell with fakely boosted "interested" abusing the greedy human nature.
urbit dev here: we completely agree that we need to have useful apps on top of it. We have an alpha for super simple wordpress-like hosting (in fact, the urbit.org site uses it!). All you have to do is drop a few md files into a tree and you're ready to go. See http://urbit.org/docs/using/web/
Joey Krug, founder of Augur, had a great post on how he could see Urbit as being a great compliment to the blockchain[0]:
"If the blockchain is useful in those areas where [almost] no trust exists, Urbit has the potential to be useful for essentially everything else.
To give a concrete example, this would be useful for any Ethereum app that doesn't want to store data on a central server (which most cannot do whether for legal, security, or ideological reasons). The idea to me is that the internet wasn't built very well to run decentralized apps [which is definitely the case if you've ever tried building one without having to rely on central servers for caching, storing accounts, comments, etc.]. It's, imo, a nice complement to blockchain tech like Ethereum and Bitcoin. Long term once it's out and running I see dapps like Augur [a decentralized prediction market which I work on - http://augur.net] using it so users can securely store their private keys, report data, market data, trade history, etc. and easily go across/between devices as opposed to just using localstorage [which is a pain to migrate using] or fetching it from ethereum every time [which is very time consuming and has lots of overhead].
If we're going to seriously move in this direction of decentralization, at scale we need something like urbit. No one else is really tackling the same set of problems.
Came across this quote on it by Alan Kay: "They have verve, and that's generally a good thing. In this case there are a lot of details that need to be grokked to make any reasonable comment. The use of combinators (a kind of dual of lambda calculus) harks back to an excellent thesis by Denis Seror at the University of Utah in the 70s that produced a safe, highly scalable and parallel implementation. I haven't looked at it more deeply (and probably should)." [https://news.ycombinator.com/item?id=11810177] - very cool!"
> We have an alpha for super simple wordpress-like hosting
And what is the advantage of this over wordpress? Or even just raw nginx?
I don't necessarily mean what is the advantage of urbit in its current state -- I get that this is an alpha release. What I'm asking is: when urbit becomes what you envision it to be, what tangible advantage should I as a user expect to see from using Urbit over using Wordpress or nginx?
The combination of personal ownership of data, worldwide visibility (if you want it), and iPhone/Facebook-tier ease of use.
Right now, you can only have two of those at a time. You own your Wordpress install and it's world visible, but your mom needs you to administer it. (Not every mom is lucky enough to have a kid like you.) Your Facebook is world visible and your mom can set one up, but you don't own it (quite the converse). You own what's on your iPhone and your mom can use one, but you can't publish anything with it - you need a separate service with its own set of tradeoffs.
Urbit's USP is that it's designed to be able to provide all three, along with a cryptographically verifiable identity system that can make spamming and shitposting costly enough to be economically inviable.
All this is ambitious as hell, of course, and it's very early days yet - there's every chance Urbit will go down in history as a curious but ultimately doomed also-ran, if it goes down in history at all. But it's easy to understand why people find its design goals appealing.
> The combination of personal ownership of data, worldwide visibility (if you want it), and iPhone/Facebook-tier ease of use.
OK, I am totally down with that set of goals. But...
> You own your Wordpress install and it's world visible, but your mom needs you to administer it.
That's not clear. Have you ever actually used Wordpress? It's actually pretty friendly to non-technical users. But OK, let's accept as a premise that Wordpress is beyond Mom's ability, and that this is a problem that needs to be solved. There are two possible ways to solve it:
1. Modify Wordpress to make it more mom-friendly
2. Throw out everything that has been done in computing to date and start from scratch, rebuilding everything from the ground up (well, except that we're still going to run on unix and hand-compile Hoon to C when performance matters, but we'll let that slide).
Why is approach #1 so unlikely to succeed that we should even try #2?
> It's actually pretty friendly to non-technical users.
To use, sure. To install and administer? Not so much. You can get a Wordpress.com account, but that doesn't solve the ownership problem.
Sandstorm.io goes some way toward fixing the specific problem of Wordpress being impossible for non-technical users to install and administer. (Probably quite a long way, in fact.)
And that's great! For Wordpress. But it doesn't do anything to solve the larger problem of ownership of data, which - and I appreciate I didn't make it clear in the comment to which you're responding, but see [1] - is in this case a cipher for ownership of identity, which right now belongs to social media networks, which is another way of saying it belongs to Facebook.
It's not clear that something like Urbit is necessary to solve this problem. But it's also not clear that something like Urbit is not necessary, and I don't know of anyone else who's even trying to attack the problem directly.
Not for people already comfortable with VPSes and firewalls and SSH keys and command lines and apt-get. For everyone.
And that matters, because as I learned the hard way, being able to do it just for yourself isn't enough. A social network is social. If you're not on it and everyone else is, you still lose.
The Ethereum crowd is a good marketing target. They love unique jargon and excessive complexity.
(Although tying your fate to Etherium may be a mistake. The contract technology turned out to be insecure, and very hard to secure. Etherium needs to go back into the shop for a major redesign.)
> If the blockchain is useful in those areas where [almost] no trust exists,
It is entirely unclear this has been demonstrated. Mostly what we see in the cryptocurrency space in practice (not hypotheticals) is scams upon scams: it turns out that a "trustless" system attracts people who can't be trusted.
No, you own it in the cryptographic sense. As in, even math proves you right.
Comparisons to Bitcoin are bound to fall apart upon closer examination. For instance, Urbit has no blockchain, and Bitcoin's ownership structure is based on computer power, not federated cryptography.
Digging a bit deeper, Urbit is actually more free than Bitcoin, because the latter is easily eaten by the biggest fish in the sea. Urbit, on the other hand, could only ever de-decentralize if all 255 galaxies were owned by a single person, which is about as likely as all of the Eastern Hemisphere being owned by a single person.
> So their solution is to create a market in user ID space.
How is this supposed to work when some advertisers are willing to spend more on a single ad impression for certain keywords (e.x. "mesothelioma") than the average monthly wage for people in some parts of the world?
Why the downvotes? In their video, it looks like they don't provide any computing power or storage - you need to host it yourself, i.e. run the VM somehow. Who in their wrong mind would replace a secure and redundant centralized system with unreliable and self-maintained (or more like - self-neglected) one? This would never be mass market! Plus, you think Facebook would integrate with them or any major service that hopes to keep you hostage?!
If Urbit fails to become as easy to run as an iPhone, Urbit fails. That's an explicit design goal. It seems improbable, but who knows?
I don't have a Facebook account, but my understanding is that it supports app integrations, and that connected apps have access to the account information you choose to share with them. Why wouldn't this work for Urbit? And why, in theory, wouldn't Urbit be able to support a distributed Facebook in the same way that GNU social supports a distributed Twitter?
The concerning part would seem to me to be how you cope with a situation where you have some people hosting their stuff on their urbits, and others still on Facebook; I don't see a solution here that does not require technical cooperation from Facebook, which as you rightly note will not likely be forthcoming.
As I know to my cost, people stick to Facebook because Facebook owns their social lives, so people aren't going to risk trying to emancipate themselves from Facebook unless they can do so without maybe losing all their friends. No one at Tlön has articulated anything like a clear solution to this problem, and I think it would be a very good idea if they did, because it will kill them if they don't watch out.
And yet it manages to retain the enduring interest, both cognitive and financial, of other people who are no less likely to be of above average IQ than Hacker News commenters. Perhaps there's something about Urbit that makes it unappealing to people who are likely to hang out on Hacker News, or vice versa. Or perhaps it's doomed and those people just haven't noticed yet. Or something else might be going on. There's really no telling just yet.
You're missing the difference here between "useful" and "interesting", the latter being a techie jargon word meaning "what the hell even is that" or "I ain't even mad, that's amazing."
Urbit is provably effective at generating techie amazement, and I can well believe it created enough for well-off people to spend money on address space for the amusement value (at least one has explicitly said that's why he bought some). Urbit is a legitimate mad art project, an untrammelled 200-proof expression of its creator's personality; that is in fact interesting.
Can someone give a synopsis of Urbit? Every time Urbit comes up, I skim their website but get pretty lost in marketing-speak. I see a lot of "control your data", "digital freedom", and "general purpose computing" without any short, to the point explanation of what the heck it's all about.
It has the cult-like approach of Xanadu - use new terminology, tie it to an economic model, and re-invent everything. Also, there seems to be a cult leader.
Jargon: noun (data), nock (interpreter), mint (compiler), span (type), twig (expression), gate (function), mold (constructor), core (object), mark (protocol). It's Newspeak for programmers.
The overall concept seems to be a federated social system, like Diaspora. Everybody has a online presence which they own. But you can take your ball and go home, moving your online presence somewhere else, and it still gets found by others. Somehow. (That's a hard problem at scale.)
There's a claim that nobody can create vast numbers of identities for spam purposes because there are only 2^32 possible human identities. (That number should have been at least as big as the population of the planet. 2^36, maybe.) Apparently you have to buy address space, which is a profit center for somebody.
There's a download, which gets you their "OS" (which runs on top of another OS), an interpreter for their Hoon language and access to their chat environment.
Not sure what to think of this, but someone put in a lot of work.
Re: the jargon, there's a technical reason for it. Urbit atoms—which are the Nock runtime's only non-product "type"—are a lot of things, but they're basically a union-type between a bit-string and a bignum (i.e. a way to talk about a set of packed bits and an arbitrary-length number interchangeably.)
Bignums themselves are somewhat expensive data structures to pass around, so runtimes that use them usually don't use them for everything; instead, they have an Integer type that has Bignum (data-structure on the stack, or pointer to data structure on the heap) and Fixnum (regular integer machine-register) implementations, and write a glue layer to treat the two interchangeably.
So, you've got a runtime where your only "type" is an integer, but it breaks down into "cheap integers" and "expensive integers."
Now, in most dynamic-language runtimes (i.e. runtimes where type-tagging and pattern-matching doesn't all happen at compile-time), you want a type that "represents itself" to use for type-tagging, dictionary keys, function references, etc. This is usually a Symbol or Interned String (or Atom!) type, with the runtime keeping a symbol table mapping fixnums ('cheap integers') to strings (which are effectively, in Nock, 'expensive integers'). You need this table, because dynamic language functions manipulate/build/pass around/compare a lot of symbols, and the interpreter would be really slow if you were passing and comparing 'expensive integers' by value.
But Nock can't really keep a symbol-table, because every "atom" ID embedded in a Nock program is a universal ID, a handle any other Nock runtime might be passed and attempt to manipulate. (And you can't even use a global symbol-table that uses hashing—i.e. a DHT—because Nock doesn't differentiate the "Symbol" atoms from any other atoms, so you'd have to treat every atom the same and hash them all—and, even pretending that's cheap, you're eventually going to get collisions that way.) The only symbol table that works in a globally-distributed system is one that maps bitstrings to themselves. And that's as good as no symbol table at all.
So what do you do when you can't make your strings ('expensive integers') into interned strings ('cheap integers')? Just use the cheap integers from the start! In Nock, this means that all the runtime-defined symbols—all the atoms in the language and the stdlib—are bitstrings that are short enough to be encoded directly as fixnums. Since Nock has the requirement of running on 32-bit machines, that means 32-bit bitstrings: four-ASCII-character strings. Thus most of the jargon.
Do note, it's not required to use four-letter names for "symbols" you manipulate in the Nock runtime; but doing otherwise means passing around 'expensive' handles instead of 'cheap' ones.
---
I find Urbit's solution here interesting—but they probably chose it for purity's sake.
I would like to contrast it to the implementation in Erlang's BEAM runtime (which also, coincidentally, has 'atoms', but where these are simply its particular symbol type):
• an atom table is kept by each "node", with no need for the atoms in each node to have identical mappings;
• atom IDs are mapped back to their original bitstrings when serializing any data structure including them, even if just for internal persistence;
• each distributed-RPC connection between nodes is stateful, keeping its own atom table (kept synchronized on both sides by additional messages) as a cache to speed up communication between nodes. This can be seen to be similar to a streaming compression algorithm's Huffman tree cache, but it's interesting to look at it as the connection being its own virtual 'node' that has this particular atom table, which both nodes are then modelling and translating to/from.
In summary: the runtime desires you to call things four-letter-words. So the creators have decided to make up new four-letter words for everything they have to refer to in code, rather than just, say, abbreviating perfectly good non-four-letter words.
You only covered atoms, actually. Nouns are a union between an atom and an ordered pair of nouns, which means that they shaped like binary trees. A struct of `[a b c d]` is actually laid out as `[a [b [c d]]]`
>That number should have been at least as big as the population of the planet.
Addresses can actually be up to 128-bit. I think the idea is that addresses longer than 32-bit are just assumed to be bots, but that convention would probably be changed if Urbit gets popular enough for the 32-bit limit to matter.
The stated reason is that Urbit addresses are for "responsible adults", and that each responsible adult will have 1 address. Each address has 96 bits worth of subordinate addresses, so you should be able to give all of your devices, dependants, etc an address.
I find the original blog posts [1] a really interesting read. Nowadays Urbit is indeed full of buzzwords, “your personal cloud computer” and the like. But initially, Urbit was this [2]:
> Urbit is a new programming and execution environment designed from scratch. Any resemblance to existing languages or operating systems is coincidental, cosmetic, or inevitable.
It was based on this idea: suppose that a different civilization (Martians specifically) had invented computing long before humans. Then by now they would have perfected it. What would their system look like? Urbit is an attempt to rethink computing without the bias of human research and our current intuition. At the heart of Urbit is Nock, a “functional assembly language”. Zero is intentionally used to denote “true” to defy programmer intuition.
The C language and the standard library are distinct things. C originally did not define any values at all for booleans (true / false), but later implementations did and even in the oldest C compilers (0 == 0) would evaluate to '1', which caused the most repeated lines of C preprocessor input ever written:
#define TRUE 1
#define FALSE 0
Guarded by some #ifdefs if your compiler supported that.
Some standard library functions return nonzero on error (which can be < 0 or > 0), zero on 'success' which is not the same as true, and others (annoyingly) return 1 on 'success' or 'true' (such as the isalpha function/macro).
So this is some kind of art project? I was trying to figure out why someone would actually want to use it, but maybe it is meant to be looked at and discussed instead of being used?
It definitely started out as one but--and this is one of my favorite things about programming-- it's very possible to be an art project and a... not-art project at the same time.
* Everything on the VM is purely functional, and inputs essentially cause transactions which can fail/succeed - the result being that it's supposedly easier to implement certain types of network protocols, specifically the ones that Ames implements
* A somewhat decent revision-controlled filesystem with push/pull/merge, static typing of files, and a built-in build system of sorts
And last but not least...
* Feudalism built into the core p2p protocol as an explicit design decision
That's like saying a snowmobile is a horse on skis. This is more like a total re-implementation of computing based on a functional model and a re-implementation of networking based on a feudal/federated shared/distributed/content-addressable model.
The gist is it's some sort of distributed datastore network vaguely similar to IPFS [1], Freenet [2], but instead operates at a different level of abstraction from files. It ships with several other components, like an OS and a programming language, to flesh out that ecosystem.
My understanding is that the founder has some elitist ideas about separating and isolating the supposedly smarter people from everyone else. The opaqueness and complexity is a feature designed to keep out the riff raff.
The earliest Moldbug screeds I came across, nearly ten years ago, were accusations of elitism towards academic computer science, and he's continued espousing that view ever since, interleaved with his other political writings. An early iteration of the Urbit website was one long anti-elitist screed against the functional programming community.
A core axiom of Moldbug's philosophy is that the mathematicalization of computing is an elitist conspiracy. As an example, he thinks that the lambda calculus is intrinsically mathematical, hence elitist, whereas his own concatenative language is non-mathematical, hence non-elitist, by conforming to human nature. It's bizarre to say the least given that his proposed language has an obvious relationship to combinator calculi like SKI calculus, and you'll have to look long and hard to find anyone who thinks the SKI calculus is more intuitive than the lambda calculus.
Interesting take: technical obscurantism as a kind of "captcha."
I'm jumping through the hoops of "Debianizing" something now, and I have to say the Debian project uses similar techniques to limit participation to the committed. The Debian packaging guidelines are very arcane and the docs are kind of scattered and the whole "experience" seems (probably unintentionally) built to keep casual "spam" out of the repo. Not necessarily a bad thing.
Oh, I misunderstood. Urbit just seems hard because it's weird. Having watched people learn the system, there are real advantages. Honestly writing documentation is just hard and we need to do a better job of it. We don't want to keep anyone out.
It's a functional (as in functional programming — immutable data, no side effects and so on) server/OS and (peer-to-peer, I think?) networking protocol, written in a dialect of APL[1] I call EOPL[0]. So far I believe there isn't any software on it besides a chat app, but the rather ambitious goal appears to be to eventually replace Unix and the TCP/IP stack.
> fwiw, the clearest explanation of the point of urbit is this 5-minute talk by yarvin from 2013. (how he will actually get from point a to point asdfghjkl666 is another matter of course.) https://youtu.be/6S8JFoT6BEM
Though I don't have a whole lot of confidence in this project...I do appreciate the Borges reference in the company's name. Truly a wonderful story, and highly relevant to the project they are attempting to undertake.
I'll never forget the first time I read the opening few sentences. I don't think i've ever had a literary experience like it before or since:
> I owe the discovery of Uqbar to the conjunction of a mirror and an
encyclopedia. The mirror troubled the depths of a corridor in a country
house on Gaona Street in Ramos Mejia; the encyclopedia is fallaciously
called The Anglo-American Cyclopaedia (New York, 1917) and is a
literal but delinquent reprint of the Encyclopedia Britannica of 1902.
The event took place some five years ago. Bioy Casares had had dinner
with me that evening and we became lengthily engaged in a vast
polemic concerning the composition of a novel in the first person, whose
narrator would omit or disfigure the facts and indulge in various
contradictions which would permit a few readers - very few readers - to
perceive an atrocious or banal reality. From the remote depths of the
corridor, the mirror spied upon us. We discovered (such a discovery is
inevitable in the late hours of the night) that mirrors have something
monstrous about them. Then Bioy Casares recalled that one of the
heresiarchs of Uqbar had declared that mirrors and copulation are
abominable, because they increase the number of men.
Their take on namespace management is interesting. The trouble with most kinds of online namespace (IP addresses, domain names) is that somebody has control over it, and they can jack prices up. You don't really own it; you're just renting.
[What follows is how I think Urbit works. This may be incorrect.]
Urbit seems to actually sell user IDs. Once you own one, some blockchain like system registers this, and you own them forever (unless and until you lose your private key, as with Bitcoin wallets). So Urbit doesn't have the problem of domain registrars raising renewal prices.
Your user ID leads to an online presence on some hosting service, but the system enforces number portability - you can move to another service without the consent of the leaving service. So having an online presence will be price competitive.
Somehow, the hosting services which host user IDs have a distributed directory system so that they can find any given user ID. Unclear how this works, and if it both scales and is secure against attacks.
If Urbit can actually do all that, it's useful as a distributed directory management system. This is useful. Once you have that, you can do chat (this is apparently supported now) and that can be extended to voice and video calls. All without central control.
So, is this a Skype killer? You have to buy a user ID, and then you have to buy hosting. That's going to cost a few dollars a month. It's nice that it's federated and presumably ad-free, but it competes with everybody else's ad-supported chat program. It's hard to compete with free.
"The project is composed of several parts: a virtual machine (dubbed "Nock"), an operating system ("Arvo"), a programming language ("Hoon") and a peer-to-peer network ("Ames")."
You can introduce any one of those and possibly survive. Doing all four at once? You're doomed. Sorry.
Interestingly, their whole "thing" seems to be that you can't re-invent one of them well without doing the others, so they appear to see themselves as doomed if they don't re-invent all of them.
Personally, I prefer this quote from Hannessy and Patterson:
> The level below main memory contains rotating magnetic disks that take millions of clock cycles to access. Because of the great discrepancy in access time, no one has yet built a virtual memory operating system that writes through main memory to disk on every store by the processor. (This remark should not be interpreted as an opportunity to become famous by being the first to build one!)
"As an older friend, I must advise you against it, for, in the first place you will not succeed, and even if you succeed, no one will believe you" (Max Planck to Einstein on his pursuit to develop a new theory of gravity).
I'm not saying it isn't worth trying, but for every additional disruption built into this offering the probability of success plunges dramatically.
Do we really need a new everything? What problems do these new things solve that couldn't be addressed through other mature technologies used in new and novel ways?
Maybe we do, but if that's the case they've done a terrible job of articulating why.
Most importantly: How can you possibly secure all these things given the complex nature of interactions between all of them?
I don't think so. I struggle to understand the things they are building, but one of the very nice features is that each of them is structured in a way to make them provably correct. That's definitely a potential value-add, and it needs to be in at least Nock, Arvo, and Hoon.
I thought this was going to be real estate and bitcoin merged together. Would be interesting to see how those two concepts might merge. Maybe the ability to buy land using bitcoin, and instead of holding a deed/title issued by the state, it remains with a holding company and you prove ownership with a digital private key. Useful for people who want to be anonymous but still sort-of-directly own real estate.
I'm curious to know how the Urbit team went about choosing the stars to distribute, it seems the 1020 stars amount to almost the address space of 4 galaxies. Have 4 galaxies been picked or are said stars distributed across various galaxies. If the galaxies have been hand picked, could we know their names?
Since we have buyers in the order they came in, I think it'd be fun to distribute stars sequentially across sequential galaxies. But we really aren't sure yet.
Every galaxy is an apex in the PKI, with the apex of apexes being the hardcoded public keys for each one in the kernel. ~zod is not special (well, it's a tiny bit special, because it's the parent of things without parents).
I might be misunderstanding Urbit (quite easy it seems), but this idea of selling off what is essentially "land" seems to go against some of the ideas that it pushes - i.e. the democratisation of the web. Also, they appear(?) to have sold off rather large chunks/the address space seems small, is it going to need a "v6" to bring it out of beta like the internet did?
... I don't know the Urbit team all that well, but Yarvin is in particular publicly anti-democratisation of anything. So I'm assuming this is in fact according to plan.
Democratization is I think a poor metaphor; a better one would be emancipation.
Right now, if you use Facebook, Facebook owns you. If you don't use Facebook but all your friends do, Facebook still owns you, but you're worthless to it, and it punishes you for failing to generate value by making you as close to socially invisible as it can - which is pretty damn close. (Ask me how I know!) None of this is deliberate, in the sense of an evil conspiracy cooked up by cackling villains. But all of it is true.
The purpose of Urbit is to make it possible for people to own themselves. Doing so is not free of charge. (Should it be? Are you worth nothing?) But it is, or will be once (if) it's possible at all, as cheap as can be made practical - which is very cheap indeed, or free, if you don't mind opting out of guaranteed and durable identity. The tradeoff is that people who don't opt out may not be as quick to trust people who do. But that's a choice you get to make, instead of, as now, a choice that Facebook makes for you. I can't speak for anyone else (especially Tlön), but I've had enough of Facebook making choices
for me. Have you?
The classes were renamed shortly before leaving "unlaunch" status. They felt that having everyone own military class vessels instead of neutral celestial bodies gave the wrong impression.
Also, saying "destroyers" a billion times outloud would probably get annoying. "Planets" is easier.
No, and they're kind of discouraging it. "We're resistant to any technical measure that would effectively "securitize" or "monetize" Urbit ships — either rendering them fungible and/or trivially transferable, or defining them as fractional claims against some shared asset."
On a more practical level, since most of the address space is unallocated it seems simpler/cheaper to buy fresh space from Tlon than secondhand space. Like how nobody was buying IP addresses when ARIN was giving them out for free.
When transferring ownership of a planet, is it done through a cryptographic transaction like in Bitcoin, or is it a plain transfer of a private key that manages the planet?
If it's the latter I can see how 'second hand space' really is a bad idea as there's no way to enforce the transfer of a private key.
Namespace transfer is more like creating a new PGP key and revoking the old. You broadcast the new key and can prove that the old key is invalid via the revocation certificate, but there is no distributed consensus mechanism, e.g. a blockchain; the new information simply is propagated throughout the routing network.
I get their goal of users having control over their data but limiting the identities artificially sounds pointless to me. Spam accounts are part of the internet and it's time we acknowledge and consider them as part of the overall user base. Or maybe I'm misunderstanding their reason for limiting the identities.
urbit dev here: the sale site is sale.urbit.org. Unfortunately, we're sold out for now. There will be another crowdsale, but we do not yet know the details. The first announcement will always go out to our mailing list (see urbit.org). This sale sold out before we announced it anywhere other than the list.
I got your email, but not until I checked after dinner so missed the very brief window.
A couple observations -- The stars were underpriced, by how much it's hard to know. If your goal is to seed the owner class with random giveaways, this was a success, I suppose. Second, 1020 stars was a HUGE amount to give away. I thought perhaps you would pre-sell one star's share of planets for $1 /ea. $205 for a star is nothin.
From my armchair, what I would suggest is to focus on developing a secondary market for urbit addresses PRIOR TO any further crowdsale. That way you can get some indication of demand before pricing another Tlon-organized event.
Presumably $209k is not interesting money, even to Tlon. It's a shame you gave away 1% at that price but maybe will work out in the end as a way to bootstrap the network with early enthusiasts.
Just a heads-up, I signed up for the mailing list a few weeks ago and didn't receive the notice. I suppose there could be some kind of filter on my end blocking it, but just wanted you to be aware! Tried a different email address yesterday and didn't get a confirmation email, so not sure if it worked.
Urbit being already able to host website, I presume it's possible for me to get a web domain name that will somehow direct to urbit.org and resolve through the planet name to my Urbit?
If you start an urbit, it binds a webserver to localhost:8080. You can just point a DNS entry to the server hosting the urbit, plus a cache and reverse proxy or whatever so it doesn't die (*.urbit.org is behind a Varnish cache). No need to use urbit.org as a resolver, which proxies all HTTP traffic through ~doznec.
Weren't people on the mailing list supposed to receive notifications about sales of Urbit land/namespace?
The article doesn't say where this crowdsale took place. The articles makes it sound like it was offered to the public, if so this is the first I've heard of it.
We did send a notification out to our announcements list (see urbit.org), but have heard that it went to some people's spam or promotions folders. In retrospect, we should have also sent it out to urbit-dev (https://groups.google.com/forum/#!forum/urbit-dev), but the sale was over before we got around to it.
The email announcing it from the mailing list said not to talk about it publicly until today; it was supposed to be an early backer pre-sale type deal yesterday, with a price of $205 instead of $256. Instead, it sold out entirely hours in, before the actual sale started...
All things considered, that's a pretty awesome problem to have.
They specifically asked for it to not be publicly posted until this morning; yesterday was mailing-list-members-only. See also this subthread: https://news.ycombinator.com/item?id=11997925
The sale was initially announced only via email to those who subscribed to a specific list, and the announcement included a request to keep it quiet until 9pm PDT (midnight Eastern).
Wall Street accounting, and a lot of other accounting besides. "Market capitalization" is a bit of a fiction. If you understand it, it's not a lie, but it's a bit of a fiction.
> Urbit is a clean-slate system software stack defined as a deterministic computer. An encrypted P2P network, %ames, runs on a functional operating system, Arvo, written in a strict, typed functional language, Hoon, which compiles itself to a combinator interpreter, Nock, whose spec gzips to 340 bytes.
I doubt very much this project will get much traction due to the enormous conceptual overhead of working within its ecosystem. There's a huge learning curve approaching something like this from the Unix/C ecosystem, and I don't think it's merited.