-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Comments
Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
Finally, remember to use https://discuss.ipfs.io if you just need general support. |
Sounds like the Block-level acces control by peergos : https://peergos.org/posts/bats |
@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. |
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 |
👍 That's the first task in the description: Arbitrary predicate function, no protocol change. 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. |
I think we're suggesting the same thing. A configurable allow function. I was mainly disputing the "more general" claim. |
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. |
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. |
Checklist
Background
Right now, the only way to store personal/private data on the network is to:
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
allow
,deny
commands, similar to the IPFS filter proposed for gateway operators.Current State
Related Issues and discussions
The text was updated successfully, but these errors were encountered: