Acess Control In Hypercore

Allow Lists

One way to revoke access to a hypercore is to control who is allowed to replicate a hypercore.

WHen you create hypercore replication stream you can control when feeds can be added or removed.

As well, after a replication stream is created you can see a peer's remote public key which can be used to securely identify a peer in the network.

With this in mind I propose a flow like this:

Define a group for access control using a hypercore (controlled by a central writer?)
Alternately you can hardcode the list of remote public keys in memory
Replicate the group feed over any connection after the handshake
Once successfully replicating with the peer get the latest list of peers from the hypercore
Then check if the peer's remote public key is within the set
If it is, iterate through all the protected feed and replicate them
Might be able to use separate corestores for protected and non-protected feeds

const swarm = hyperswarm()

const protectedFeeds = new Set()

const groupFeed = feed('group key')
protectedFeeds.add(feed('exampl-feed1'))
protectedFeeds.add(feed('exampl-feed1'))

swarm.on('connection', (connection) => {
  const replication = new HyperswarmProtocol()
  
  groupFeed.replicate(replication)
  
  groupFeed.once('peer-add', () => {
    const peersKeys = getLatestPeerKeys(groupFeed)
    
    if(peerKeys.includes(replication.remotePublicKey)) {
      for(let feed of protectedFeeds) feed.replicate(replication)
    }
  })
})

With this in place, one can distribute and update allow lists and prevent data being leaked to peers that aren't allowed to get access to the data anymore.

Changing keys

Another approach would be to change public keys for hypercores and to mark them as being invalid.

First, you'll need to change the key for a hypercore.

For that you'l need to do something like this:

Generate a new hypercore keypair
Initialize the hypercore with the old keypair
Go through each block and make a new signature with the new keypair
Save new signatures for each block on the signature storage file
Once all the signatures are saved overwrite the public key and private key files with the new keys
Close the feed and re-open it and run audit to make sure it works
From then on the feed will only be able to replicate on the new key
For peers that aren't writers, once they know that a feed has been updated, they should open a fake feed for the new key
Then send Requests for data and set the flag to only requst the signatures
Save the signatures in the Response over the existing signature file storage for the feed
Once you've downloaded all the signatures for your local data, update the public key file
Then close and re-open the feed and audit it
Now it can be replicated using the new key

You'll need some mechanism for notifying trusted peers that is secure against whoever isn't allowed to see the channel. In addition you'll need to makr a hypercore as being "destroyed" or invalid so that peers will stop replicating them

This has similar security constraints to the previous method, but still depends on how you notify peers of the changed hypercore.

RangerMauve/hyper-access-control.md

Acess Control In Hypercore

Allow Lists

Changing keys