Allow / Deny Bitswap replication based on peerID and CID

[laurentsenta]

Checklist

• My issue is specific & actionable.
• I am not suggesting a protocol enhancement.
• I have searched on the issue tracker for my issue.

Background

Right now, the only way to store personal/private data on the network is to:

• Use a private network (with swarm keys for example),
• Use semantic security (by encrypting the data).

For some use cases, this is too restrictive:
"I wouldn't store my passwords or my medical records on the IPFS network, even encrypted."

For these use cases, decentralization might still be necessary, but they would require a permissioned approach:
ideally, we'd let a user define who can replicate their data / what can be replicated from their node.

There are a lot of discussions around the question of authorizations (see below), @kylehuntsman and I have been working on the smallest step forward we could find: let a node accept/reject a bitswap request based on peerID and CID.

(one might find a certain resemblance with libp2p's ConnectionGater.)

Stories / Plan

1. As a developer, I can define a filter predicate (policy). This lets me filter requests based on the requester's ID and the content requested.
   • Add an optional configuration to go-bitswap that lets a user define this peer-block filter,
   • Add ipfs-related plumbing to pass this configuration down to the bitswap instance.
2. As a regular user, I can configure a default policy with a few allow, deny commands, similar to the IPFS filter proposed for gateway operators.
   • TBD

Current State

• Bitswap PR
• IPFS PR

Related Issues and discussions

• IPIP-270: Bitswap 1.3.0 - Tokens (and auth) support specs#270
• [Feature Suggestion] - CID deny / allow API #7871
• Bitswap auth specs#260
• [2021 Theme Proposal] Content Permissioning roadmap#75
• [ipfs/go-bitswap] Allow configurable prioritization of requests boxo#82
• Content Filter Plugin #6842
• IPFS filtering to allow node operators to decide on content they are willing to serve #8492
• Add functionality for advanced control over peer set #6097
• Peer whitelist #6565

[welcome]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

[bertrandfalguiere]

Sounds like the Block-level acces control by peergos : https://peergos.org/posts/bats

[kylehuntsman]

@bertrandfalguiere We actually came across that implementation while researching the idea.

We felt Peergos's implementation was great, but was a bit heavy in terms of spec changes. We ended up taking a more general and lightweight approach that we felt could be immediately useful without the burden of reviewing and merging something like a block spec change to the protocol. Not as robust or as specifically targeted as a feature, but it is harmless and could have some great potential to be built on top of.

[ianopolous]

To be clear, the extension we've built is more general than this (it allows arbitrary allow functions as described in #7871 and you could do the same thing without any bitswap protocol changes.

This is the allow signature here, though you would remove the string which is the auth token, and likely could remove the block data as well: https://github.com/Peergos/go-bitswap-auth/blob/master/auth/blockstore.go#L42

We set the allow function to a configurable http endpoint which returns true/false in https://github.com/peergos/ipfs-nucleus

[laurentsenta]

To be clear, the extension we've built is more general than this (it allows arbitrary allow functions as described in #7871 and you could do the same thing without any bitswap protocol changes.

👍 That's the first task in the description: Arbitrary predicate function, no protocol change.
Here is the go-bitswap PR as a reference; feel free to review!

If you refer to the second story, the goal is to expose the feature to users who won't compile their node. So it is one default implementation on top of step 1.

Remember this is a special case of the general approach (ipfs/specs#260, #7871, ipfs/specs#270) on purpose. We're looking for the smallest contribution we could make to move this forward without making specifications & protocol changes. These require more time and more familiarity with the stack.

[ianopolous]

I think we're suggesting the same thing. A configurable allow function. I was mainly disputing the "more general" claim.

[kylehuntsman]

This is the allow signature here, though you would remove the string which is the auth token, and likely could remove the block data as well: https://github.com/Peergos/go-bitswap-auth/blob/master/auth/blockstore.go#L42

Oh nice, thanks for pointing that out. I didn't see that previously. I was referencing the idea of the continuous access-control across nodes when I wrote that.

[BigLep]

Closing because this functionality now lives in bitswap: ipfs/go-bitswap#549

We don't expose configuration for this in go-ipfs, but one can make their own ipfs distribution if they want.

If anyone wants this in go-ipfs itself, we should talk about plugin support. That should be a new issue please.