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

Support add-only clusters #966

Open
v696973 opened this issue Nov 30, 2019 · 2 comments
Open

Support add-only clusters #966

v696973 opened this issue Nov 30, 2019 · 2 comments
Labels
kind/enhancement A net-new feature or improvement to an existing feature need/review Needs a review

Comments

@v696973
Copy link

v696973 commented Nov 30, 2019

As per discussion at discuss.ipfs.io it may be a good idea to add support for add-only clusters, with disabled (or otherwise restricted) pin removal. It is important feature for certain use-cases, especially in scenarios with open public clusters (where all peers may be trusted to add new content to the cluster, but shouldn't be allowed to remove anything).

From the end user perspective, it feels like the best way to control who can pin/unpin items is to separate trusted peers config into several roles, with each role corresponding to a certain action (adding/removal/setting the replication factor other than the default one etc). This way it will be easy to set up public clusters where everyone can share their content over the cluster and still support some level of moderation (trusted-to-remove peers will be able to unpin any unwanted content).

Right now, the verification of trusted peers happens on receiving of the broadcasted update (crdt/consensus.go#l163). It may seem straightforward to extend trusted peer validation here and filter updates based on the role of the peer and the type of the update, but unfortunately, it looks like the nature of the update is obscure to the pubsub topic validator. Possible solutions would be to force topic validator to download the broadcasted state and examine it before accepting/rejecting (which, intuitively, will make things slow), or modify the broadcaster to include the type of the update to the message being broadcasted (which may be insecure, since the type of the update may not match the actual update).

@v696973 v696973 added kind/enhancement A net-new feature or improvement to an existing feature need/review Needs a review labels Nov 30, 2019
@RubenKelevra
Copy link
Collaborator

How about having a folder for each peer, which is a ipns, where he can update the content by publishing a new CID to the ipns.

This way the user can update his content and share it with the cluster, while the moderator can add and remove user folders by trusting the ipns key and add a folder name.

@kuzdogan
Copy link

Can a folder be an ipns? But what happens when the CID behind the IPNS changes? If I was trying to pin/sync the top level folder, I won't recognize the contents of the IPNS folder changed right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement A net-new feature or improvement to an existing feature need/review Needs a review
Projects
None yet
Development

No branches or pull requests

3 participants