> It pains me to see people paint the project and its people in this light. I don't know if I'm taking the bait here or playing into your cards or whatever, but I want to try and clear some things up.

Indeed not. I looked at Urbit as a way to do untrusted computation spread across multiple nodes. Think of a distributed Lambda not dissimilar to that of IPFS, but for computation. I tried to give it a fair shake. However roadblocks were everywhere. I would have to throw out most of my computing knowledge and start over to even analyze it. And writing programs in Hoon is ridiculous. My current tooling - nonfunctional. It not only disregards current nomenclature, but any sort of tooling I have to develop, make, and troubleshoot.

In the end, the further I try to get the 10,000 mile view, its just a federated system with a screwy network topology. And as tptacek has noted, the base code has very strongly written "bad choices", CS-wise.

> I don't know what communities you've been in that people just go "you're stupid" when you don't understand something. In my experience with Urbit's chat rooms (and the forums, subreddit, etc.), people are generally friendly and understanding of the struggles that come with jumping into an entirely new stack like this. We know things can be confusing, we know it's hard when you're just starting out. We're also very much ready to help, and do care about discussing concerns and criticism.

My experiences with Urbit have been primary documentation (which I am told elsewhere is the last place to look ?! ), people who show up from the "woodwork" on any thread that mentions Urbit, and some very hostile conversations on the 'web primarily discussing Yarvin's statements.

And unlike libraries like JQuery or Node.js , I can use them without being "part" of the community. I import them, load them, and use them. No muss, no fuss. Whereas, Urbit's community is inexorably tied to the foreign code and systems. I cannot simply download and use it - there's tons of content that is shared within the community. In coded language of Urbit, no less.

To understand, I have to use. To use, I have to understand. Both of these are going to take a great amount of time; and the knowledge here is non-transferable.

And strangely, once people start using that language, they seem to fail to explain the fundamental principles on which they rest on. I note this as the same type of trap that esoteric and religious cults use. They fail to explain what their terms really mean - and then it is a mixture of giving up, ignoring them, anger, or derision.

> And you can reach us without even installing Urbit on your machine. Take a look at http://urbit.org/stream/

Thank you. I saw that earlier. It looks something like Disqus or IRC on a website. It's obviously done with Urbit, but alas, it still doesn't help with deciphering any of the nomenclature.

> "Disable" isn't the right word here. A higher class can choose to stop helping a sub-user with peer discovery and to stop providing software updates to them. But if a sub-user is not content with the service their parent is providing, and/or they feel like they were unjustly blocked, they are free to find a parent that wants to adopt them.

So it's not true that Tlon can't just say $user's compute node is hereby expelled? Because my initial understanding was that Yarvin implemented instead of Galaxies/Stars/Planets, it was Dukes/Generals/Earls, and his compute node was the unique role of "Prince" - with the ability to expel anyone he saw fit.

> Doesn't this apply to pretty much anything happening in the decentralization and crypto spaces right now?

Indeed.. But that's a whole other ball game there. And yes, some of the cryptocurrencies most certainly have their own very cult-like status and effects. But you and I digress. I'm only here speaking of Urbit.

Ideally, what I want is the following:

1. Provide first principles how the system works. Use standard topologies, algorithms, and other established analytical methods.

2. Disambiguate the coded words describing primitives in the language. If the VM is emulating a non-Von-Neumann architecture, discuss it!

3. Network Protocol analysis: these should be well documented and established. I'm guessing they're also written in Hoon, which means they're nigh unreadable and excludes any existing tooling.

4. Fully document and vet the mathematical principles in the implemented crypto. Because I dont trust black box systems - and yes, Hoon is most certainly "black box" for 99.99% of programmers.

I'm sure there's something in Urbit that isn't documented elsewhere, or a algorithm that the world outside Urbit hasn't seen. Im interested in seeing they get their rightful place as part of mathematical tools we all use. In that end, Urbit is a neat project.

But for the reasons I've highlighted, I believe it would be an error to put any sort of time in this system outside of a curiosity.