Muni Town
Leaf & CRDTs
Welcome to the Leaf SDK! Leaf is an opinionated wrapper around CRDT tools for building local-first apps!
Leaf is very work-in-progress and is developing for the needs of weird.one and roomy.chat specifically and local-first, inter-operable apps in general.
Learning Resources
https://muni-town.github.io/leaf
Keyhive
Keyhive is the upcomming sync and encryption protocol that we are planning on using.
https://www.inkandswitch.com/keyhive/notebook/
Background
Leaf has evolved slowly as we've boiled down our needs and attempted to satsify them. An early prompt for it was the limitations of ActivityPub and questions on federation:
https://zicklag.katharos.group/blog/how-to-federate/
In short, while the existing solutions have gotten 80% of the way there, they leave a crucial 20% left unsolved.
...
Wouldn’t it be awesome if your data could be stored locally on your own computer, you could author posts offline, and even host your profile right from home if you wanted, too, just by keeping a tab open in your browser, or installing a normal app!
Servers could become optional. They would be very handy for keeping your data backed up, and for hosting your public data when your computer isn’t on, but they wouldn’t need to have any power over you as a self-sovereign agent on the web.
As we continued we thought about the need for simplicity and inter-operability of our data.
https://zicklag.katharos.group/blog/a-web-of-data/
Nearly complete post reproduced below
Today: The Internet of Pages
Today the internet is made up primarily of a web of HTML pages. The HTML usually contains or references CSS and JavaScript that is largely concerned with the presentation or interactivity of that page. We need massively complicated web browsers and web standards to actually view these pages as they are meant to be viewed.
The idea is to lean away from this web of complicated pages and towards a web of simpler data.
For example, while there have been many iterations on the concepts of blogs, chats, microblogs/tweets, etc. the data hasn't changed that much. And yet, we still depend on complicated web browsers or diverse protocols and APIs in order to access that data.
Entities & Components: An Internet of Data
Imagine an alternative internet protocol were each "thing" on the internet is an "Entity". Entities might represent blog articles, chat messages, tweets, comments, or anything else. Each entity also has a path to that entity, like a URL.
All the data for the entity is stored in "Components".
Each component has a schema that describes the data in the component.
Some of the most common components would be things like:
NameDescription: a component that has a name and description for the entity.Image: a component that contains a single image for the entity. I.e. a feature image for a blob post or an avatar for a profile.
Note that these components give you what is necessary to create a link preview for the entity.
Significantly, apps can understand these two components even if they don't understand any other components on the entity. The components provide independent slices of meaning.
Platforms on top of Components
Many more components can be added, and each can be standardized independently.
This means we are not limited to putting simple data in our web. We could expand our components to include platform-related enhancements.
For example, we could add a WebView component that contains HTML, CSS, and JavaScript that may be
used to display the entity in a browser or webview such as Tauri or Blitz.
We could create components containing WASM modules and standards for how they interact with the environment or other entities.
You can even add app-specific components without preventing other apps from understanding the non-specific data in the entity.
Instead of forcing everybody to agree on an enormous, backward-compatible web browser standard, we are free to incrementally develop new components and standards that can live side-by-side for enhancement.
This might help us converge on one shared, flexible data protocol, similar to the internet of HTML pages that exists today, instead of having to make new protocols and APIs every time we want to let other people create custom frontends to our data.
It will inherently be a web of data, and presentation will be an optionally configurable layer on top, not an inescapable necessity for delivering your content.
Sound Familiar?
This starts to sound somewhat similar to the old idea of semantic HTML and keeping presentation separate from the content.
It's not necessarily a new idea, but I think we are starting to feel how important it is to get back to owning data and the way that we browse/access it.
It would be best if we could do this in a simple, extensible way that doesn't force us to have an entire web browser, and yet doesn't stop us from taking advantage of the great developments browsers have made.
I think the Entity-Component model might be able to provide for that, but that's a big might. Let's try it. 😉
Finally we had our first draft of the Leaf Protocol specification:
https://zicklag.katharos.group/blog/introducing-leaf-protocol/
As we've continued, though, we realized that CRDTs we going to be really important for our offline-first use-cases. Automerge was brough to our attention in addition to the Keyhive project which solved a lot of the same problems that we were previously planning on solving with the Willow Protocol.
That has brough us to our current experiments with an Entity-Component model on top of Loro, which was switched to from Automerge for Loro's performance benefits.
Experimentation and development of the new Leaf SDK is currently underway.