Benevolent Dictator

Learning Library Design Patterns
, ,
#1

Problem

Sometimes a certain agent or group of agents needs to have exclusive privileges in a DHT, such as the power to change a global variable or create entries. This is useful for things like:

  • A blog that allows one agent to post and multiple agents to comment
  • A DHT that supports a traditional corporate hierarchy

A Privilege Certificate system isn’t appropriate for all use cases; it’s too complex for situations where the list of authorities isn’t expected to change.

Solution

Whitelist a public key or set of public keys that are authorised to write certain entry types.

Implementation

In the properties section of the DNA bundle, create an element that contains a public key or set of public keys of agents who are authorised to commit a certain entry type. The validation function for this entry type checks the entry’s author list against this whitelist. If an author is not whitelisted, validation fails.

Warnings

  • This pattern is not as versatile as Privilege Certificate, especially for cases where authorised members may come and go.
  • If a privileged user’s device is stolen, it’s impossible to revoke their public key’s authority unless the DNA also understands DPKI revocation.
  • In a peer-to-peer, agent-centric paradigm, this might be an anti-pattern. Consider re-designing your authorisation structure to support collective governance.
2 Likes
Private vs Public DHT
Member Whitelist
Capability Delegation
#2

where could I find more information about this? I understand + like DeepKey but need a clarified way of how to incorporate it into Happ Bundle

#3

As said in the Warning section this pattern has a major flaw, since a dictator could be auto-kicked out of the DHT if it starts spamming invalid entries. The only work around I see would be to have some kind of “select new dictator protocol” that kicks in when the dictator is absent or kicked out by warrants.

1 Like
#4

@ddd-mtl oh, that’s a really great idea, thanks. Sounds like the seed for a new pattern! We need some good governance patterns.

@pqcdev DeepKey is still being built out, so it’s not well-documented yet (or not even documented at all maybe?) You can find a good, easy-to-read overview from David Braden, one of our core devs, here: https://blog.holochain.org/part-2--holochain--holo-accounts--cryptographic-key-management--and-deepkey/

#5

cool so David is still working with yall? since the world seems dead set on cryptography I’m going to build my own DeepKey perhaps he would be interested in collab

eventually im considering to deploy post-quantum solutions, altho im debating whether that would end up helping the wrong people and do more harm than good anyway

not really sure we actually need encryption at all (maybe just for nude photos lol)
but i like better the idea of approving each transaction with a fingerprint… is pretty difficult to hack that… ha! transparency sounds like the necessary step for the future. in the case of photo sharing a user could just implement a combination of each parties biometric login as a seed for a hash of the pixelation. each time someone tries to put the peices back together, the original owner would have to ‘approve’ the “transaction”

1 Like