I created cloud-data-module as an experimental library to abstract away use of local storage and logos core modules: messaging and storage, while providing a CRUD interface to interact with the data in a familiar way.
Checkout out the readme (and known limitations). I’m open to small, thought-out PRs.
The library in the cloud data module was integrated into this sample forum sample app.
Curious what others have thought about this.
Background
Once upon a time I tested Google’s AI, Gemini, to one-shot a simple Android app. It worked. I then prompted it to add functionality to store data (deliberately vague to see what path it took)… Google’s Gemini suggested Google Firebase! What a surprise!
In my exploration for better alternatives I came across “web 3.0” (not web3) and work done on Solid Protocol (Socially Linked Data) from Tim Berners-Lee. Which was interesting but unfortunately quite clunky at the time I looked at it.
Around the same time I came across Logos. Basecamp made it easy for a Logos App to use it’s core modules (messaging, storage, blockchain, …), which is a different interface to what a centralised app would integrate:
Web 2.0 - each app for itself, dependent on a server(s) owned by a single company
Logos - p2p messaging and distributed storage to recreate the same reliability guarantees
I wanted a web2.0 familiar interface to help devs with data in their Logos apps.
The following scenarios show how Logos can satisfy data capabilities that web2 devs take for granted.
Parameters may be tweaked per app, eg local storage (what/how-much), size to archive (what/when).
hey @JamesZaki , you got me on this “token cost reduction while vibecoding”. I was working on a similar project mainly a web2 project which helps people to get persistent memory of the codebase just by initialising it inside.
As of now I integrated a few providers. They are mainly cloud providers and I do have a local provider as well, where the persistent memory is stored in the form of local JSON but yeah, by looking through this cloud-data-module, I realize that I can also use this cloud-data-module as an additional provider for the project, along with existings, so that I can store all the persistent memory of the codebase inside Logos storage and query it afterward using this library.
Yeah I just want to know: is it stable to build upon right now?
Spent a couple evenings going through cloud-data-module and how it sits
inside the forum app. Genuinely enjoyed it, the lib/src split especially.
Keeping the engine framework-agnostic and letting the embedding app bring its
own appName for the LIP-23 segment is a small decision that pays off big.
It’s what lets someone vendor the engine without taking cloud-data-module as
a runtime dependency. That’s the difference between a library and a module
that happens to have a library inside it.
The CRDT choice is the one I keep coming back to. I get the appeal of
hand-rolling over Automerge/Yrs. You get per-field type inference at put()
time, the merge stays cheap because it’s three known shapes, and the API
stays ergonomic. The trade I’d want to hear your thinking on is the OR-Set
tombstone one (limitation #2). For the forum it’s fine, few fields and mostly
registers so the tombstone pile stays small. But it’s the kind of thing that
bites later, quietly, on a heavier document.
Honest question for you, which of the limitations do you think gates real use
first? The tombstone GC, or the op authenticity one (#1)? My instinct says #1, because “anyone on a bucket topic can forge ops” is the line between
experimental and something you’d actually tell people to build on. Curious if
you read it the same way.
One small thing I noticed that the README could call out more: the Transport
and BlobStore traits are outbound-only, and inbound event routing lands on the
embedding module. The forum backend wires messageReceived into handleDocumentChanged by hand. That’s the right call given delivery_module
fires node-wide, but it means swapping a transport isn’t quite a one-adapter
job, the embedder owns the inbound glue too. Took me a second pass to see
that, so figured I’d mention it.
It was created as a personal experiment, so not a focus of development. If you find it helpful to use/build on, then great
That said, I do think it’s important to continue experimenting with middleware.
More libraries/modules will emerge from people building similar things. Or like in this case, we can foresee obvious libs/modules that lower the entry barrier for more devs.
