yjs VS cardi

One idea is just to use fewer random bits in peerIDs. Yjs (https://docs.yjs.dev/) gets away with just 32 random bits. If you compromise and use 64 random bits, then even a very popular doc with 1 million lifetime peerIDs will have a < 10^-7 lifetime probability of collision.

I've seen it come up often in collaborative text editors.

Also see: https://github.com/yjs/yjs

You are absolutely right that XML is better for document structures.

My current theory is that Yjs [0] is the new JSON+XML. It gives you both JSON and XML types in one nested structure, all with conflict free merging via incremental updates.

Also, you note the issue with XML and overlapping inline markup. Yjs has an answer for that with its text type, you can apply attributes (for styling or anything else) via arbatary ranges. They can overlap.

Obviously I'm being a little hypabolic suggesting it will replace JSON, the beauty of JSON is is simplicity, but for many systems building on Yjs or similar CRDT based serialisation systems is the future.

https://github.com/yjs/yjs/

Note: https://github.com/yjs/yjs for collaborative "document edition, and user cursors"; has WebRTC, web socket, matrix.org backend

CCP needs to revamp proto anyway, due to recent exploits... practically, nothing really prevents 'em from using some sort of CRDT's to make the state of the sig view eventually consistent (yjs lib, if we're speaking frontendian).

Yjs framework: Because it is a CRDT implementation which provides collaborative editing and offline-first capability.

No problem. The database CRUD features are just helpers as an abstraction on top of yjs: https://docs.yjs.dev/. Eweser adds schemas in the form of typescript types to make using it simpler, more structured, and interoperability easier.

> Deta Space made it really easy for me as dev to build something like WebCrate quickly and it's also awesome for users. The app keeps running even if I disappear and hosting, auth etc. is all handled for me

Ah yeah, love the concept, I had similar goals in mind when making Cardi (although I wasn't aware of many options at the time for putting data in control of the user -- I ended up just having people log in with AWS access keys and it stores data in DynamoDB, which is weird but has actually been working great so far).

https://github.com/pickledish/cardi

Anyways Deta seems interesting, looking forward to seeing where it goes from here! Would love more/better options in this space.

Ha, I'm very interested in this!

I had this same problem for my own app[0], I ended up solving it by just using dynamodb in my personal AWS account as the storage. Generous free tier, great uptime, and no users, security, etc to manage for me, like you mention.

It's way more technical than I'd like of course, since anyone who wants to use it needs to have a personal AWS account. And it isn't "synced", like you say, it's just using the AWS JS SDK to speak to dynamodb directly. But still it's been a real pleasure to build a web app this way -- the fact that anyone can use the app by plugging in their own storage is kind of the web development holy grail IMO.

[0] https://github.com/pickledish/cardi

Hey thanks! I wouldn't say it's a hard dependency, in fact it can work with other things that are API-compatible with DynamoDB, like Scylla for example if you wanted to self-host everything:

http://scylla.docs.scylladb.com/master/alternator/alternator

And in terms of using something like Firestore, the storage needs of this are very simple so it wouldn't be very hard to add that in. I tried to keep all the persistence-related functionality separated off for this purpose:

https://github.com/pickledish/cardi/tree/master/src/dynamodb