Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow / Deny Bitswap replication based on peerID and CID #8763

Closed
3 of 8 tasks
laurentsenta opened this issue Mar 4, 2022 · 8 comments
Closed
3 of 8 tasks

Allow / Deny Bitswap replication based on peerID and CID #8763

laurentsenta opened this issue Mar 4, 2022 · 8 comments
Assignees
Labels
kind/feature A new feature

Comments

@laurentsenta
Copy link
Contributor

laurentsenta commented Mar 4, 2022

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

Related Issues and discussions

@laurentsenta laurentsenta added the kind/feature A new feature label Mar 4, 2022
@welcome
Copy link

welcome bot commented Mar 4, 2022

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
Copy link

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

@kylehuntsman
Copy link
Contributor

kylehuntsman commented Mar 4, 2022

@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
Copy link
Member

ianopolous commented Mar 9, 2022

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
Copy link
Contributor Author

laurentsenta commented Mar 9, 2022

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
Copy link
Member

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

@kylehuntsman
Copy link
Contributor

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
Copy link
Contributor

BigLep commented Mar 25, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature A new feature
Projects
No open projects
Archived in project
Development

No branches or pull requests

5 participants