[Discussion] Support for authoritative server

[obezzad]

Problem

Decentralized local-first apps are still not mature enough for industry as there are many active areas of research in CRDTs and we still need a whole paradigm shift in how we handle business logic and security. Particularly, finality of local writes is not ideal for when data validation is computationally expensive for some consumer devices or invalid state only emerges when merging multiple valid operations/states (e.g. moving 2 nodes independently induce a cycle, although each of the 2 move operations were valid). We still need to have a "peer" to coordinate and reject or compensate for some local writes.

Use case

Personally faced several, but the movable tree one is notable. Evan Wallace's Movable Tree Hierarchy demo seems to have some edge cases from my testing. Kleppmann's undo-do-redo is robust, but it may not play well with non-move operations (afaik they mentioned something about this in their paper), notably when it comes to undoing operations. Also, none of the current solutions are simple enough to implement and scale compared to server-centric algorithms.

Proposal

To be determined. Inspired by Figma and Linear, my tentative plan is to use client prediction pattern; we still apply the operations optimistically but require server acknowledgement for them to be considered final. The server can reject operations and/or append other operations.

[danilaplee]

You actually can do that check using rsa-pss certicificate directly on the client and ignore all transactions that not been signed by the proper authority

…

On Sun 13 Oct 2024 at 10:34, Oussama Bezzad ***@***.***> wrote: Problem Decentralized local-first apps are still not mature enough for industry as there are many active areas of research in CRDTs and we still need a whole paradigm shift in how we handle business logic and security. Particularly, finality of local writes is not ideal for when data validation is computationally expensive for some consumer devices or invalid state only emerges when merging multiple valid operations/states (e.g. moving 2 nodes independently induce a cycle, although each of the 2 move operations were valid). We still need to have a "peer" to coordinate and reject or compensate for some local writes. Use case Personally faced several, but the movable tree one is notable. Evan Wallace's Movable Tree Hierarchy demo seems to have some edge cases from my testing. Kleppmann's undo-do-redo is robust, but it may not play well with non-move operations (afaik they mentioned something about this in their paper), notably when it comes to undoing operations. Also, none of the current solutions are simple enough to implement and scale compared to server-centric algorithms. Proposal To be determined. My tentative plan is to use client prediction <https://en.m.wikipedia.org/wiki/Client-side_prediction> pattern; we still apply the operations optimistically but require server acknowledgement for them to be considered final. The server can reject operations and/or append other operations. — Reply to this email directly, view it on GitHub <#492>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSB45FFIICHUFQYDVB32CDZ3IWCLAVCNFSM6AAAAABP3G3WE2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGU4DGNZYGE3DCNA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[steida]

One concept of an "authoritative server" I had in my mind is having yet another client that runs somewhere all the time.

The server can reject operations and/or append other operations.

I would not call that a "server" because any client can technically do that. The only difference is that it runs all the time, IMHO.

Let's talk about the case I will need soon. I want to make an Evolu app for invoices. Invoices need a counter. The decentralized counter is hard, but not because of incrementing/decrementing, which is a simple feature I want to implement soon, probably with this API: update('todo', { id, counter: { type: 'increment } },, but because if Evolu allows users to create invoices offline, then after the sync, some already created invoices will need to update their numbers. The DX is hard. Technically, it's easy.

With movable trees, it's a similar issue. If users can modify trees offline, then an invalid state will happen. If an invalid state is forbidden, mutation can be done only online, and any server can be used for that. I don't see how Evolu could help in that situation.