Problem
A peer-to-peer, agent-centric network of computers such as a Holochain DHT creates a ‘commons’ among all members. Much of the data is held in public, where there is no reasonable way to control access to any given piece of data. Therefore, there is no ultimate way for any agent to prevent any other agent from performing an action in the shared DHT. But a successful commons needs to collectively enforce rules governing privileges in order to stay healthy.
Solution
Using public-key cryptography, create a means for agents to recognise other agents’ actions as valid if they can present a certificate that authorises them to take those actions.
Implementation
Create a ‘certificate’ entry type. This type should contain:
- The agent who is being given a certain privilege (the ‘subject’),
- The conditions of the privilege being granted,
- The signature(s) of the agent(s) granting the privilege,
- (Optional) Address of certificate proving that the grantor has the power to issue this certificate (parent certificate).
The conditions can include:
- A specific role or privilege, such as:
- permission to join a DHT (see the Membership by Invitation pattern),
- permission to create, edit, or delete a certain entry type,
- permission to create, edit, or delete a certain entry (including the address of the entry),
- permission to name other agents as authorities,
- permission to change a global value,
- permission to eject others from the network (moderation),
- etc
- A time period of validity (expiry date),
- Permission to act on behalf of another agent or group of agents,
- Power to delegate the granted privilege to others,
- etc
In Holochain, all public actions are performed by publishing entries to the DHT. When an agent wants to perform an action that requires a certain privilege, the entry representing the action must embed, or reference, a certificate that is valid for that action. The validation function for the privileged entry type ensures that the certificate is valid.
If a certificate points to a parent certificate as proof of validity, it forms a certificate chain. In that case, all certificates in the chain must be valid.
Consequences
This pattern doesn’t specify any particular way to recognise whether an agent should have the power to create a certificate — that is, how a root certificate should be considered valid. You can use the Progenitor pattern to designate ‘root’ authorities for a DHT, from which all other powers are derived. This pattern can be extended to privileges other than merely being a member of the DHT.
Warnings
Some might consider this a Holochain anti-pattern. Holochain is designed to balance individual and collective agency in a sort of ‘mutual sovereignty’. It may be better to create small DHTs for groups, give them full privileges inside those DHTs, and control membership using some sort of membrane such as Membership by Invitation or Member Whitelist instead.