Peer-to-peer canvas app for Urbit
github.com
github.com
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.
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.
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.
Also, nemo1618's app is both a very nice flashcard app and one of the best ways to learn and get started developing apps for Urbit.
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.
This actually made me interested in trying out the project. It's very beautiful.
Every discussion of Urbit clips my bullshitometer.
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.
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.
if i read it correctly, the readme mentions a not-yet-shipped install command. is there a projected date that is going to roll out?
I recommend trying out stuff like this on moons, so you can just throw them away if it breaks.