related work
related work

I think this is a cool way of framing, though it constrains the building blocks to be talking to each other via a network protocol.

There’s another way: blocks could simply be one “import” statement or library call away.

Reasons for using an import could be

(a) lower latency: a network call takes time which could hurt or kill the usability;

(b) simplicity: using a library (or even embedded code) is usually just simpler than connecting on the network, paying tokens, etc;

We have awesome Unix libraries going back decades, even Python and JS blocks going back 15+ years.

⁠

its layer of blocks serve applications (blocks for messaging, storage, consensus, governance, ..)

actually mixing three things: apps, the “what”, and the “how”.

To me, blocks should be the “what”.

So, messaging is an app (should be at the application level);

storage needs to be more fine-grained;

consensus is part of the “how” (hidden within some blocks);

and governance is also part of the “how” (therefore also hidden).

It also has [network] protocols as a separate lower-level block,

though I see those as one of the possible ways that blocks can talk to each other, alongside library calls.

⁠

to be continued...

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.

related workrelated work