Comment by ianbicking | Hacker News Reader

Comment by ianbicking | Hacker News Reader

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:

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.

If you want a line-by-line breakdown of an Urbit app, I wrote one here: https://github.com/lukechampine/rote/blob/master/urbit/app/r...

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.

I'm going to defer to pcmonk's comments since they are 100% correct. Thanks btw! :)

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.

Reply on news.ycombinator.com