Dynamic Membership in absence of finality

[andrewzhurov]

As shown in this diagram, Document Membership is a CRDT.
How will it fare in absence of finality?
In the diagram Bob removes Carol, but what stops Carol from issuing removal of Bob as of some past (so her commit does not transitively refer to "Bob removes Carol" commit), say, once she learns of it?

flowchart TB
    subgraph StatefulAgent[Stateful Agent]
        direction TB

        _groupPK["Group Root (Public Key)"]

        subgraph membership[Group Membership]
            rootAddsAlice[Group Root - Add Alice] --> groupRoot[Group Root - Self Certifying Init]
            rootAddsBob[Group Root - Add Bob] --> groupRoot
            aliceAddsCarol[Alice - Add Carol] --> rootAddsAlice

            removeCarol[Bob - Remove Carol] --> rootAddsBob
            removeBob[Carol - Remove Bob] --> aliceAddsCarol
            removeCarol --> aliceAddsCarol
            bobAddsIas[Bob - Add Ink & Switch Group] ---> rootAddsBob
        end
    end

    groupRoot -.->|implied by| _groupPK

Loading

I'd assume that one possible way is for parents to have authority over their children (so, if Alice added Carol she's has authority to remove her / revoke this authZ).
Where root member is the ultimate authority for that document, and by allowing addition of members by a member we can have a tree.

flowchart TB
    subgraph mermaid DelegatedAuth[Delegated AuthZ]
        direction TB
            Root[Root] --> Alice[Alice]
            Root[Root] --> Bob[Bob]
            Alice --> Carol[Carol]
    end

Loading

(a DAG, rather, since Alice and Bob can add Carol)

I got the impression that that's the way it was meant to be, but then, in the diagram, Bob removing Carol who's been added by Alice got me confused.

(Also, why did Bob create parallel commits? 🤔
I guess removal of Carol been meant to be issued by Alice.. then it'd all make sense and nevermind ^.
If so, the materialized view diagram may benefit from showing root -authority-over-> Alice, etc.
As presently all members seem to have ultimate admin right over each other)

---

Btw, reffing from member removal commit to the last meant-to-be-authorized contribution by that member is is one interesting approach!
Does mean that "authorized contributions" of a repo is eventually consistent though, as one can receive contributions from Carol and only later learn that a prefix of those is now authorized due to her removal. Hm. But that's another story.. Neat project!