You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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.
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?
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).
The text was updated successfully, but these errors were encountered: