theanzelm

Thank you! Disclaimer: as of recently I have funding but the approach will stay the same!

You’re right, I was just being short. Will give you a longer and more concrete answer tomorrow

There might be a vendor neutral comparison page between technologies soon that we’ll be part of

It’s a tough problem! I think 90% of it is solved with GraphQL/ protobuf like rules (“only ever introduce new fields”)

There are some edge cases where you might loose easy access to some data if two clients migrate concurrently, but we’re hoping to provide patterns to mitigate these

Edit: Right now it all depends on you to implement migrations “the right way” but we hope to provide guardrails soon

I made Jazz, that's why I know a lot about it ;) (I now have people helping me)

Let me know if you'd like to know anything else.

If you only share data with Europeans, it should only end up on the cache server in London and the main central server in Prague.

I was planning to add a second main server in the US that would also receive everything but will think about how to keep data separate for users/companies that need that.

In any case all the data is end-to-end encrypted, but I guess some of the metadata that is stored could still be considered sensitive for your scenario.

Yes, from my quick understanding of Orleans!

In the web world, this is starting to be known as "local-first"

yes a simple version of it is!

npx jazz-run sync

Well the version of the Mesh that we offer would go away, but the framework is open source as is a simple but fully functional version of the sync server, so you could somewhat easily host your own mesh. Not having lock-in here is super important for us

Partykit is mostly an abstraction on top of Cloudflare Durable Objects and offers simplified Websockets for room-like multiplayer.

Jazz is a framework for building apps around locally mutable collaborative values which are granularly synced (you don't have to worry about data transport or coordinating sync between collaborators, you just set permissions and edit data)

Right now, we're not doing complex validation very well, we basically rely on all clients having the same schema or backwards-compatible schemas and prevent errors at the type level.

But because the schemas are runtime constructs as well, we might be able to do more complex stuff in the future. Basically any rule you can express as a function of (previous history, new transaction) -> is new transaction valid? can be a rule in theory, and each client will verify it in an eventually consistent way.

For the time being, the Group abstraction with it's reader, writer and admin roles, plus composition of CoValues in different groups is sufficient for most permission-like rules, which is what most apps need most of the time.

Let me know if that makes sense

Yes, plus it’s actually local-first (works offline) and you don’t have to trust the syncing & persistence infrastructure because only encrypted edits are synced!

Also you can use it as blog storage as well

Just making sure that you saw the point where we will do an impartial third party audit!

Update: it was something else entirely, that we worked around for now and will fix soon