Sometimes only a small list of members should have access to a DHT. Membership by Invitation isn’t appropriate for all use cases; it’s too complex for situations where the list of members is small and fixed.
Solution
Using the Benevolent Dictator pattern, whitelist a public key or set of public keys that are authorised to join the network.
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 allowed to join the network. The agent ID validation function checks against this whitelist. If an agent is not whitelisted, validation fails and they aren’t allowed to join.
Warnings
This pattern is not as versatile as Membership by Invitation , especially for cases where there are a lot of members or 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.
Sort of. The way that public/private key pairs work is that the public key is mathematically derived from the private key, in a way that anyone who holds the public key can verify that a signature created by the holder of the private key is correct. If the signature isn’t correct, then the person who shared the public key doesn’t actually hold the private key they claim they do.
i understand DPKI very well. I’m saying we could hash the private key hash so that we can track individual activity without exposing the underlying primitive
ie know which account is doing what and that its unique, but not exactly who they are
tell me more; sounds like you see an advantage in hashing the private key and using it as an identity rather than the public key. I don’t quite follow; I feel like both offer similar risks of traceability, because they’re just random numbers that are persistent over time.
