Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> totally separate from any legacy system

It most certainly is not. It's a macOS and Linux userspace application, no more no less[1].

How on earth do you consider that totally separate from any legacy system?

[1] https://urbit.org/using/install/



Urbit runs as a VM with a translation layer for things like networking, file system, etc. Using a host OS is expedient to build a working OS that the user actually wants to use, since hardware support is an uninteresting implementation detail. Eventually, one could write a native hardware kernel in Nock/Hoon, and do networking without TCP/IP/DNS between Urbit computers.


> that the user actually wants to use

Only a handful of people would rather use something like Urbit than established systems.

> Eventually, one could write a native hardware kernel

When it does, you can call it an OS. For now, it's a user space application.


Definitely agree with you. The practical implementation that it is, vs what it advertises itself as visionary-wise.


> what it advertises itself as visionary-wise

All puff. The amateurs over at /r/osdev are much closer to running directly on hypervisors or bare metal than Urbit will ever be.


I hear you - I'm in a similar opinion.


It hardly any different than Inferno or Android for that matter.


Android bundles a Linux kernel, or it won't run, it doesn't expect you to supply your own. It also doesn't try to reinvent DNS or TCP, the VM bytecode format or all the other things that Android leveraged to make itself into a useful platform so quickly.

The other difference is that Android has millions of users, Urbit, not so much.


Inferno can run on bare metal, so I'd say it's different. Urbit -- I'll believe it when I see it.


> Eventually, one could write a native hardware kernel in Nock/Hoon

Sounds like the dream of the "lisp machine". Is it more viable than that?


I think it's what Urbit markets itself as, but the implementation is "just a VM" - with the potential to innovate further. The networking layer is where I thought they'd make a difference but they ended up settling just for the same address space issue we have today IMO without trying to disrupt TCP/IP/BGP/DNS. I severely dislike the Ethereum decision.


Urbit disrupts IP/DNS in that it replaces IP and DNS addresses with cryptographic identities.

Identities aren't limited as anyone can create a comet, an identity without a parent (self-signed identity). There is a hierarchy of limited identities which serve as a routing network to propagate software updates and network packets. Since in reality you need to choose some computer to receive software updates from and send network packets to. Comets could communicate without the galaxy/star/planet hierarchy but they would have to choose some other way to route packets (DHT or something).

Urbit can function without Ethereum. AFAIK galaxies (super nodes/identities) participate in Ethereum as a consensus mechanism voluntarily. Nothing is stopping them from changing that.


I have no idea why those chose Ethereum as a backing cryptographic protocol. It stains the project in my opinion.

I don't see it disrupting IP/DNS with cryptographic identities. I'd argue that Kademlia DHT does that in a more significant way.

Not really sure what Urbit does uniquely in that regard really.

I do crave some one-time use generated address that maps to a DHT/Kademlia cluster to provide deterministic privacy against p2p networks that doesn't depend on BGP autonomous centralized entities.

Know of anything like that out of curiosity? Ha.


> I do crave some one-time use generated address that maps to a DHT/Kademlia cluster to provide deterministic privacy against p2p networks that doesn't depend on BGP autonomous centralized entities.

It's not "one time use", but I believe BrightID[1] might be of interest to you. It allows applications to verify that you're a real person without looking into all your metadata and such. And it's not tied directly to your finances, etc like some other ID solutions are.

[1]: https://www.brightid.org/


Ethereum is just used as consensus for key revocation and title transfer between galaxies. They don’t need to use Ethereum or can switch to another method of consensus, it’s just convenient at the moment to both distribute stars and planets and avoid having to build a blockchain or other method of consensus for the PKI.

DHTs do not have a solution to Sybil attacks. In reality, they depend on super nodes. That’s what Urbit’s spanning tree (galaxies/stars/planets) provides, a system of reliable routing. Nothing stops Urbit nodes from using a DHT to communicate, as the network protocol is addressed by identity.


Yggdrasil seems to solve that fine https://yggdrasil-network.github.io

It's not "Ethereum is just..."

Urbit is sacrificing accessibility by adding complexity which Ethereum is, on top of the reputation of what cryptocurrency is, while also additionally requiring the complexity of wallets and ERC-21 (or w/e it is these days) to prove you have address space.

That's bs in my opinion. It should be completely automated like Ygg does it and allow any peer to participate and connect and discover routing deterministically and dynamically.

I hear Urbit can switch at any time, yeah, easier said than done when you've built a lot of expectations on a significant piece of the stack including the wallet and auth parts which are pretty integral. Then shifting the conceptual model? Not likely.


After more thinking the solution I'm looking for is some hybrid between PJON/Yggdrasil




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

Search: