Really interesting. Looking over their github, seems that at its core is a CRDT JSON structure with encryption and permissions built in. Storage, transport and auth are agnostic, but they offer some flavors (sqlite, websockets, clerk, react, nodejs). We're interested in svelte and rust support for now. Looks like the local-first space is gaining traction. Probably this is the most interesting execution so far.
Jazz – Apps with Distributed State
71–80 of 179 posts
Re: Jazz – Apps with Distributed State
#72I'm more than a little worried about the following all being `Coming Soon`: - Cursors & carets - Two way sync to your DB - Video presence & calls - both the Group and BinaryCoStreams All of these are the key reasons I would be evaluating this framework to handle my data. All of these are not fully implemented yet. It is these key topics of live reloading/updating data that make or break an app. In my opinion, if you…
Plus the sync only works between clients AFAICT — literally all the listed backends are also “coming soon”. Which is troubling, I’d guess that almost all local-first applications need some sort of trusted verification server, at the very least. But maybe I’m biased/unimaginative; I suppose some kinds of collaboration apps (figma, google docs, etc) might work fine serverless? Certainly not games or AI agents, right? T…
1. The sync is not just between clients, it by default works over a central backend infrastructure that syncs and persists. Plus you can create server workers (with jazz-nodejs) that also are clients to the same infrastructure and can do side-effects like API calls and interacting with “normal” databases in response to react state changing. And they can also mutate Jazz state.
2. The next version will. I like to think of Jazz as distributed state, of which local-first is a special case.
3. Shared memory to me sounds like concurrency is handled with locks, while Jazz uses CRDTs
Re: Jazz – Apps with Distributed State
#73Earlier quoted context omitted.
It is already persisting and syncing data (fully encrypted) between the cloud and other users. You can think of Jazz as a distributed database itself. The coming-soon badges are about interop with traditional systems and higher level features we will add later. The fundamentals are solved and you can build full multiplayer, local-first apps with it. Does that make sense?
Does it store data persistently anywhere (on servers?). If so where?
The Jazz Mesh stores everything you sync through it in geographically distributed and redundant servers (with backups to S3)
Re: Jazz – Apps with Distributed State
#74Nice abstractions. Though I worry they’re going to be too rigid for some applications. - how can I setup delivery receipts for messages in your chat app? I want to know if they got my message and when it was sent. - how can I create a chat group where the entire list of access permissions is not transparently available to everyone? For example, customer support: I don’t want to give out a list of every employee becau…
- add a “read” property to Message that the other person sets
- groups not only allow adding exact accounts, but also allow for “invites” which in your example only one employee could accept for a new support chat
- devices aren’t synced p2p by default but through the syncing server like everything else. Right now, all devices in one account use the same keypair for signing, so people you collaborate with can’t tell (except that they’re using different anonymous session ids)
Re: Jazz – Apps with Distributed State
#75Nice, but react.
I’m only showcasing the react bindings because that’s mainstream, but they are only a very thin wrapper over jazz-browser, which you can use in vanilla JS or to build your own framework bindings
Re: Jazz – Apps with Distributed State
#76Really interesting. Looking over their github, seems that at its core is a CRDT JSON structure with encryption and permissions built in. Storage, transport and auth are agnostic, but they offer some flavors (sqlite, websockets, clerk, react, nodejs). We're interested in svelte and rust support for now. Looks like the local-first space is gaining traction. Probably this is the most interesting execution so far.
Thanks for sharing your overview and for the kind words.
I recently hired someone who is a big svelte fan so we’ll have bindings for that soon. Rust is coming a bit later.
Re: Jazz – Apps with Distributed State
#77I'm jazzed about Jazz, I think Anselm got the priorities right and I'm excited to use it soon. If you get the chance to hear him talk about it, I highly recommend that too!
Re: Jazz – Apps with Distributed State
#78[dead]
Re: Jazz – Apps with Distributed State
#79I'm more than a little worried about the following all being `Coming Soon`: - Cursors & carets - Two way sync to your DB - Video presence & calls - both the Group and BinaryCoStreams All of these are the key reasons I would be evaluating this framework to handle my data. All of these are not fully implemented yet. It is these key topics of live reloading/updating data that make or break an app. In my opinion, if you…
It is already persisting and syncing data (fully encrypted) between the cloud and other users. You can think of Jazz as a distributed database itself. The coming-soon badges are about interop with traditional systems and higher level features we will add later. The fundamentals are solved and you can build full multiplayer, local-first apps with it. Does that make sense?
What plans do you have for a third-party audit/review of your backend to verify the claims being made?
Its one thing to use this service on the basis of encryption claims - its another thing to have to clean up the mess from a forgotten API key being leaked somewhere... is there, therefore, a third party involved in an audit of Jazz?
Re: Jazz – Apps with Distributed State
#80Earlier quoted context omitted.
It is already persisting and syncing data (fully encrypted) between the cloud and other users. You can think of Jazz as a distributed database itself. The coming-soon badges are about interop with traditional systems and higher level features we will add later. The fundamentals are solved and you can build full multiplayer, local-first apps with it. Does that make sense?
What plans do you have for a third-party audit/review of your backend to verify the claims being made? Its one thing to use this service on the basis of encryption claims - its another thing to have to clean up the mess from a forgotten API key being leaked somewhere... is there, therefore, a third party involved in an audit of Jazz?
First it's all open source so even without knowing that my paid service uses the same open source libraries, you can verify yourself that nothing leaves the client unencrypted.
Of course we will also do public audit(s) with security companies to make sure our cryptographic protocols are sound and implemented correctly.