Live data from Hacker News

Jazz – Apps with Distributed State

jazz.tools

171–179 of 179 posts

Re: Jazz – Apps with Distributed State

#171

Not sure if this question belongs on this post but kinda interested in how validation and e.g data schema enforcement work in local first / distributed infrastructure. Assume this is built into the way you think about the model (and my mental model definitely isn't there yet), but having read the permissions part of the jazz docs (on/off?) and thinking about how client-first platforms like firebase do it with private…

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…

Hey, thanks for the response. This does make sense. The group roles do seem relatively powerful.

I guess what I'm probably getting at is how does it hold from a threat perspective? What is to stop an actor distributing something extra large or unscrupulous between nodes. TS is notoriously hard to use for validation within types (e.g. string of max length, number between), but clearly covalues go beyond this.

Anyway, I'm writing this having not yet tried the framework. So I'll do that first and then do some further reading, and then jump onto the discord if I have more questions. Cheers.

Re: Jazz – Apps with Distributed State

#172
post #94

Earlier quoted context omitted.

Not to go off topic but isn't performance metrics your responsibility ? Those are small numbers in reality, but if you are not performing your own tests and trusting the maintainer/publisher instead then you're not doing your 'day-job' properly.

Yeah, I hear you. Which is why we assessed and designed our own platform for handling the above stated traffic (and much more) for multi-user real-time chat sessions. The commenter seems to know a lot about Jazz, so I took the opportunity to ask further questions.

Good stuff, and I hope I didn’t come across too rude but 10k parallel is not a problem for even basic setups to manage, it’s a problem solved many different ways some out of the box some not. Maybe your question was phrased wrong. But hit into 10kk parallel, there’s an interesting metric to discuss optimization.

I’m reminded of the quasi meme “You have designed an infinitely scalable service for 10 clients “

Re: Jazz – Apps with Distributed State

#173

Earlier quoted context omitted.

Yeah, I hear you. Which is why we assessed and designed our own platform for handling the above stated traffic (and much more) for multi-user real-time chat sessions. The commenter seems to know a lot about Jazz, so I took the opportunity to ask further questions.

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.

I like the idea, I have some implementation questions but I’ll catch you on GitHub. Nice work so far though.

Re: Jazz – Apps with Distributed State

#174

Earlier quoted context omitted.

Looks like it's not load that brought it down but someone posting a 340kb individual message that's triggering a bug because we didn't account for that sort of thing somewhere. The good thing is we now have an easily reproducible case, thanks HN :)

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

what was the other thing that brought it down!? Please don't leave us hanging!!

Re: Jazz – Apps with Distributed State

#175

Earlier quoted context omitted.

Yeah, I hear you. Which is why we assessed and designed our own platform for handling the above stated traffic (and much more) for multi-user real-time chat sessions. The commenter seems to know a lot about Jazz, so I took the opportunity to ask further questions.

Good stuff, and I hope I didn’t come across too rude but 10k parallel is not a problem for even basic setups to manage, it’s a problem solved many different ways some out of the box some not. Maybe your question was phrased wrong. But hit into 10kk parallel, there’s an interesting metric to discuss optimization. I’m reminded of the quasi meme “You have designed an infinitely scalable service for 10 clients “

10k parallel users I agree, but 10k receiving all updates from the other 9999 and vice versa can become quite a complex problem to solve.

Especially within time (latency), monetary hosting cost, and accuracy constraints.

For example, an MMO town with 10,000 connected clients all viewing the same complex session state of all other users and entities in one town.

That’s a lot of room for error. Or am I missing something?

That scenario is complex to me and has remained complex to me despite my various times building it out for various products.

Re: Jazz – Apps with Distributed State

#176
Hi! So wondering how did you solve collaboration issues using CRDTs exclusively. So I suppose that for a db you have an encryption key and then you have users with different rights, some of which can remove the other ones (let's call them admins or whatever). If your db has a certain encryption key then it should be known to all current members. Also if you remove a person he/she should not be able do decrypt new messages in the db.

So suppose you have 4 people, Alice, Bob, Clark and David, where Alice and Clark are "admins". A network partitioning happens and Alice removes Bob, so Alice changes an encryption key to X and sends a message to everybody, concurrently without knowing about the Alice's removal Clark removes David and also changes and encryption key to Y and sends a message to everyone.

So in this case if we allow the generation of new keys to happen simultaneously (without consensus) one of the deletions will not be effective, because what we wanted is both Bob and David to be removed and not know the new encryption key for the db. But now Bob knows Y and David knows X. Thus neither X, nor Y can be the encryption key, because it is known by one of the deleted persons.

Sorry for the long explanation, but I am wondering what is your solution to such a problem.

Re: Jazz – Apps with Distributed State

#177
Looks cool! a bit of crypto hygiene though, I'd recommend passing the ECDH output through a KDF before using it in xsalsa20-poly1305.

Also, if you're using xsalsa20 anyway, why go through the trouble of doing incremental n0nces? One of the main benefits of opting for an extended-n0nce construction is that it simplifies n0nce handling greatly. Why not randomly generate the 24 byte n0nce and forget about the tricky and error prone project of ensuring n0nce uniqueness?

Re: Jazz – Apps with Distributed State

#178

It seems to be an InstantDB alternative that integrates more closely with React.

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

So it if I already have an app using instantdb, how hard would it be to switch to jazz? Does it work in a very similar way? Or would it likely require a lot of code modification?

Re: Jazz – Apps with Distributed State

#179

Neat work! Can the author provide any ideas around: 1) Differences from fire-svelte for core functionality? 2) For the beyond core aspects, like Group-WebRTC (great innovation btw), how will things like TURN/PEER servers work to manage the WebRTC connections?

What exactly does fire-svelte do? For me it looked like a frontend framework but without synced or persisted state?

Svelte-fire* allows you to basically sync state between frontend use (with optional chaining operators) and your firebase/firestore backend. You can basically call stuff as a variable and it gets it from the database and likewise updates it.

Specifically, once I load something (say a document), if I edit in on another tab, it will re-render on my original tab so long as the document it references (by key) is the same and firebase permissions allow me to read it as that firebase user.

It means all my permissions and schema goes in firebase/firebase rules (e.g. users can only access their own documents of type "Car" but can read all documents of type "Road"). Which is quite handy to do stuff quickly that syncs across users and works as a single source of truth.

It's an add on that works with Svelte (and Firebase). *(sorry, I got the wrong phrase)

Post reply on HN