Generalizing the Counter type

[deluksic]

I am very new to the local-first / CRDT world, having heard of it and started exploring just a few days ago, so might be that this proposal is already solved by Automerge in a different way.

The problem I'm trying to solve is quite simple: multiple users, say doctors, are collaborating on a workflow. In that workflow, there are items that need to be approved, e.g. typescript type { approved: true | false | 'not-reviewed-yet' }. Assumption is that if one doctor approves and another un-approves, the field should be resolved with un-approved because that's a safer assumption.

Having looked at the docs, it seems like there is no way to do this today. But, a small perspective change could allow such a solution to exist. If we consider the Counter type as simply a sum merge strategy on number changes, we could as well invent new CRDT-reducers like min or max for numbers, or any other custom operator for complex types. In this case, if I represent the approved state as 0 | 1 | 2 meaning false | 'not-reviewed-yet' | true, the original issue is solved by a min merge strategy I believe.

PS. Love CRDTs and local-first ideas I've seen so far.

[pvh]

You can emulate this in application logic by using a map where each doctor is either missing, approved or unapproved. If all values are approved: good to go. If any are unapproved: hold off. This would have the added benefit of making it clear who to talk to! Note that of course you can't be sure if anyone has revoked their approval. They might have been in a basement without WiFi.

On Sun, Dec 11, 2022 at 09:05 deluksic ***@***.***> wrote: I am very new to the local-first / CRDT world, having heard of it and started exploring just a few days ago, so might be that this proposal is already solved by Automerge in a different way. The problem I'm trying to solve is quite simple: multiple users, say doctors, are collaborating on a workflow. In that workflow, there are items that need to be approved, e.g. typescript type { approved: true | false | 'not-reviewed-yet' }. Assumption is that if one doctor approves and another un-approves, the field should be resolved with un-approved because that's a safer assumption. Having looked at the docs, it seems like there is no way to do this today. But, a small perspective change could allow such a solution to exist. If we consider the Counter type as simply a sum merge strategy on number changes, we could as well invent new CRDT-reducers like min or max for numbers, or any other custom operator for complex types. In this case, if I represent the approved state as 0 | 1 | 2 meaning false | true | 'not-reviewed-yet, the original issue is solved by a min merge strategy I believe. PS. Love CRDTs and local-first ideas I've seen so far. — Reply to this email directly, view it on GitHub <https://github.com/automerge/automerge/discussions/520>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAWQEIHQ6ULIGEHOZPFZ3WMYCT3ANCNFSM6AAAAAAS3C5NLI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Peter van Hardenberg "Everything was beautiful, and nothing hurt."—Kurt Vonnegut

[deluksic]

Super clear, and I get additional features, thank you!

Two more questions for a deeper understanding, if you don't mind:

• in general, would having a Min or Max type make sense at all?
• is per-user map a common pattern for collaborative editing of documents? Wouldn't one user be theoretically able to write into another's field? (I guess we must assume reasonable users / application code)

[ept]

Hi @deluksic,

• I believe some CRDT implementations allow min/max to be used as merge function, and sometimes also allow a custom ordering of values to be defined (such as 'rejected' < 'unreviewed' < 'approved' in your example). However, I think this creates API usability problems (how do you tell the CRDT what merge policy you want to use?) and the result doesn't seem to be any better than what @pvh proposed. Therefore I'm inclined to stick with @pvh's approach.
• Yes, you would have to trust that a user only updates their own field. Automerge currently has only very limited ability to tolerate misbehaving users. There is some discussion in Claims-based authorization #419 on how an authorisation feature might work, but nothing is decided yet.

[deluksic]

Thank you for the detailed answer!