
Peer-to-peer canvas app for Urbit - networked
https://github.com/yosoyubik/canvas
======
st-isidore
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?

~~~
yosoyubik
Thanks! 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.

------
nemo1618
Wow, this is super polished! Really raises the bar for Urbit apps. I love how
the demo mirrors the original Urbit CLI demos as well.

------
ianbicking
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...](https://github.com/yosoyubik/canvas/blob/master/urbit/lib/server.hoon)
: 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...](https://github.com/yosoyubik/canvas/blob/master/urbit/app/canvas-
view.hoon) : This seems to handle the server part that is specific to drawing

[https://github.com/yosoyubik/canvas/blob/master/urbit/app/ca...](https://github.com/yosoyubik/canvas/blob/master/urbit/app/canvas.hoon)
: 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
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...](https://github.com/lukechampine/rote/blob/master/urbit/app/rote.hoon)

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.

------
sergiomattei
I've called "BS" on Urbit for a looooong time.

This actually made me interested in trying out the project. It's very
beautiful.

~~~
zaphod420
What is it about urbit that you think is BS. I just finished hoon school 101
and I thought urbit was pretty interesting.

~~~
qppo
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.

~~~
nootropicat
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.

~~~
qppo
See 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_
Not 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.

------
nyolfen
i'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
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.

------
Fang_
Having this on Urbit seems like a great way to start an Oekaki community.

------
jlehman
Whoa! This is great! My compliments to the author.

~~~
yosoyubik
Thanks! :)

