So... I'm kind of curious about how this is built. Here's what I'm guessing...
1. The actual "drawing" is all the JavaScript frontend.
2. The Urbit stuff handles a few things...
3. Serving up resources (JS, HTML, etc)
4. Saving the strokes that make up the drawing
5. Communicating those to other clients
6. Communicating peer stokes back to the browser
There's not many conflict issues here, and to the degree there are you can almost ignore them, so I'm assuming the peer-to-peer part is mostly just about communication.
I poked through the Hoon source some, and most of it looked like wiring. Three files seem to actually do interesting things:
This is the sort of application that would usually be familiar to me. The server is serving up static files, and keeping a kind of shared log of strokes with communication across peers to share that log. But the source feels like reading cyrillic: I can't even construct a mental AST.
The drawing app is more complicated, so it's split into a few different files. `lib/server.hoon` is a shared library, and `app/canvas.hoon` and `app/canvas-view` are separate apps with different responsibilities -- the former handles the state and p2p stuff, and the latter talks to the frontend.
(not the author, but I'm an Urbit core developer, so I can read this pretty easily)
You're pretty much correct. lib/server.hoon doesn't "set up" the server exactly, that's built into Urbit. In general, apps communicate by sending commands ("poke") and subscribing to data ("watch"). A normal HTTP request is just a poke of type "handle-http-request". The js frontend can also subscribe to your app.
lib/server.hoon is a (mostly standard) library of helper functions that mostly convert from various internal types to HTTP responses, so they add the the HTTP response code, mimetype, octet-stream length, etc. There's also a function that wraps an HTTP response handler to redirect to the login page if they're not logged in. Most apps that have a web interface use these functions, though I think the author may have added a few more filetypes.
app/canvas.hoon, as you guessed, manages the main state of the app and syncs it to other urbits. An app's commands can be seen in +on-poke, which in this case calls +handle-canvas-action, where you can see all the different commands this app takes. For example, %join subscribes to the "canvas" app on another urbit on path /canvas/foo where "foo" is the name of the image. The rest of the commands can be traced in the same away. +process-remote-paint is the part that actually processes a new list of strokes from either another ship or the %paint poke; it updates its own state and gives updates on /canvas/foo.
app/canvas-view.hoon is the app that serves the html/cs/jss and handles browser requests. It has a similar set of pokes, and most of them are just forwarded to app/canvas.hoon, but some of them are handled directly. This is a different app from canvas.hoon to keep separate the essential logic of the app from the work needed to serve it to a browser. One could imagine writing a command-line app which used canvas.hoon, and it wouldn't need to talk to canvas-view.hoon.
This is awesome, good job! I like how the interface blends so smoothly with the other existing Landscape apps. What's stopping Urbit from saving these canvas images more quickly, though?
Saving here means generating a (svg/png) file (each stroke is automatically saved on the backend). There is a chunking of the canvas on the frontend when the image is too big, so that adds a bit of time (multiple http requests... etc) This in a super alpha state, so plenty of room for performance improvements on my end, but I believe that this is probably pushing the limits of what Urbit can handle in terms of networking and file system a little bit for the current status.
For me, it's the language that it's advocates use to describe it, I have yet to see an explanation of what it does, let alone what it is or how it works or what problems it's supposed to solve.
Every discussion of Urbit clips my bullshitometer.
I thought this stuff was so silly too until I read Yarvins resignation letter.
It goes someways to explain the esoteric nature of the tooling.
He sets out quite eloquently the reasons for it;
1. Laziness (which I think is a modest way of saying it wasn’t a priority to make the names good while they still tinker on it).
2. It’s not ready for prime time - urbit is becoming popular before it’s anywhere near ready for consumers. The esotericism helps keep people away who would be burned by an unpolished first experience.
3. Some of the things are conceptually new and given placeholder names that will be changed later when their purpose is better understood.
I actually think while building this stuff the reasons given make a lot of sense, especially the part about laziness - the idea of urbit contains some new concepts and it’s probably not a good idea to wed names to tools before they have been given time to be fleshed out.
i understand it as a pure functional OS running on a pure functional VM with a pure functional memory model (tree not buffer). IO is event sourced and thus the computer is deterministic. That makes possible some new stuff on top that any sensible person would do, so they did it.
It's an esoteric language artificially coupled to a finite pki designed to enrich early founders.
The language part doesn't allow anything new, nor does it do anything better - it's most similar to a lisp machine, but written in a much, much less expressive language.
It would be harmless if not for the pki part. It lives on ethereum anyway, it has no excuse to exist. Eth addresses or ens would work as well, but without the ponzi mechanics.
What does this response even mean? How can a language be coupled to PKI? Does the language implement it, or is it predicated on some implementation? How can that even "live on" ethereum in the first place?
What kind of fucked up problem statement results in this jargon bingo card being applicable?
The language itself is not coupled to the PKI. The PKI ("azimuth") is implemented as a contract on Ethereum. The OS ("arvo"), implemented in the language ("hoon"), has a networking module that respects the PKI, but also affords for (practically) infinite not-PKI-registered identities.
A lot of people have written, fairly persuasively, about this on HN over the years ('lisper in particular has some good stuff). I'd just use the search bar rather than recapitulating the whole thing ever time this system comes up; better to keep this conversation about the work this person did, and not about whatever it is Yarvin is trying to do.
Probably a few months for a really usable version of it, though seeing stuff like this makes me really want to finish that work. I'm working on it, but first we're reworking the software update process in general. That work is getting pretty close.
I recommend trying out stuff like this on moons, so you can just throw them away if it breaks.
It's not hard to get there, but the right thing to do is just to flag the comment, so that every thread on Urbit projects doesn't become a referendum on Urbit and its problematic founder.
I don't know about libertarian, but "Feudalist" is actually not only true, but is the core principle of how Urbit works. They actually use feudalist terms in the whitepaper.
And I mean this not in a derogatory manner, because I thought it was interesting concept.
I've seen the terms used regularly with regard to Urbit, and I believe they're derived from:
Feudal - your computing is connected to the larger network by sitting under a larger scale host entity. Pyramid/hierarchy structure, essentially, where you're dependent on your host for visibility and connectivity.
Libertarian - Urbit very intentionally distances itself from much of existing tech in order to maintain independence from it, and to deter the platform from being co-opted by a mob in the way the internet was during Eternal September.
(Not my opinions, but my understanding of arguments I've seen. Correct as necessary.)
1. The actual "drawing" is all the JavaScript frontend. 2. The Urbit stuff handles a few things... 3. Serving up resources (JS, HTML, etc) 4. Saving the strokes that make up the drawing 5. Communicating those to other clients 6. Communicating peer stokes back to the browser
There's not many conflict issues here, and to the degree there are you can almost ignore them, so I'm assuming the peer-to-peer part is mostly just about communication.
I poked through the Hoon source some, and most of it looked like wiring. Three files seem to actually do interesting things:
https://github.com/yosoyubik/canvas/blob/master/urbit/lib/se... : I think this mostly sets up the server, including resources and maybe some peer authentication?
https://github.com/yosoyubik/canvas/blob/master/urbit/app/ca... : This seems to handle the server part that is specific to drawing
https://github.com/yosoyubik/canvas/blob/master/urbit/app/ca... : I guess this is all the peer to peer logic?
This is the sort of application that would usually be familiar to me. The server is serving up static files, and keeping a kind of shared log of strokes with communication across peers to share that log. But the source feels like reading cyrillic: I can't even construct a mental AST.