5 ms·
Peer-to-peer canvas app for Urbit
- nemo1618 6y agoWow, this is super polished! Really raises the bar for Urbit apps. I love how the demo mirrors the original Urbit CLI demos as well.
- sergiomattei 6y agoI've called "BS" on Urbit for a looooong time. This actually made me interested in trying out the project. It's very beautiful.
- zaphod420 6y agoWhat is it about urbit that you think is BS. I just finished hoon school 101 and I thought urbit was pretty interesting.
- qppo 6y agoFor 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.
- AJRF 6y agoI 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. https://urbit.org/blog/a-founders-farewell/ https://urbit.org/blog/a-founders-farewell/
- dustingetz 6y agoi 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.
- nootropicat 6y agoIt'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.
- qppo 6y agoSee even this triggers my bullshitometer 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?
- Fang_ 6y agoNot sure what nootropicat is on about. 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.
- tptacek 6y agoA 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.
- dmix 6y agoThe other commenter links to a post where Yarvin left the project over a year ago...
- yosoyubik 6y agoThanks! I'm happy that you liked it :)
- Fang_ 6y agoHaving this on Urbit seems like a great way to start an Oekaki community.
- st-isidore 6y agoThis 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?
- yosoyubik 6y agoThanks! That's something I'd like to improve. 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.
- mdszy 6y agoSo tired of this feudalist shitcoin for libertarian techbros getting posted as if it's anything worth caring about. Flagging and moving on, ugh.
- api 6y agoFeudalist libertarian... how do people even get there? I remember when words meant things.
- Fellshard 6y agoI'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.)
- d883kd8 6y agoWhat the sibling comment says, plus personal dislike of the founder(s), most likely
- Jotra7 6y agoUrbit founder advocates some pretty problematic politics.
- cocktailpeanuts 6y agoI 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.
- deleted 6y ago[deleted]
- jlehman 6y agoWhoa! This is great! My compliments to the author.
- yosoyubik 6y agoThanks! :)
- deleted 6y ago[deleted]
- nyolfen 6y agoi'm guessing this came out of the recent hackaton. it's insanely cool! big props. 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?
- pcmonk 6y agoProbably 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.
- ianbicking 6y agoSo... 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/server.hoon 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/canvas-view.hoon 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/canvas.hoon 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.
- nemo1618 6y agoIf you want a line-by-line breakdown of an Urbit app, I wrote one here: https://github.com/lukechampine/rote/blob/master/urbit/app/rote.hoon 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.
- pcmonk 6y ago(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.