Hello everyone,
My question is about IPFS Cluster.
Is there any reliable way for a peer to get the history of all pin and unpin actions on the cluster?
Is that information stored in the Merkle-CRDTs of the node?
Thank you very much in advance!
It would be possible to get the history out of the CRDT chain, although without timestamps or without information about who issued the calls, so the list would only tell you that certain pin/unpin happened before some other pin/unpin.
Another place to get information information would be logs.
Now for the sake of the exercise, you could add crdt.PrintDAG() here: ipfs-cluster/consensus.go at bfe179e94343321484f423d882b8770a6ecd4354 · ipfs/ipfs-cluster · GitHub
And you would start seeing info. Although the payloads are protobuf and the keys are binary cids encoded in base32, but knowing this information, it would not be difficult to implement a custom PrintDAG that shows things nicely.
Ok! Thank you!
I’m definitely going to look into this !
I am building a dApp using IPFS Cluster as a backend and basically, I don’t want anything to be ever unpinned. Hence my app would then send a new pin request each time it detects an unpin request.
So no information about the issuer of each request is stored by ipfs cluster? Is that a design choice?
In my case, knowing that information would help detect “cheating” nodes…
Thank you again for your answer,
You are better off simply disabling unpinning.
There is no way to avoid a cluster peer from removing something from the cluster-state when an unpin request is received, but there is failsafe option called unpin_disable that can be set to true in the ipfshttp section which will auto-fail any unpin attempt so that any unpin operations will not be passed to IPFS.
From time to time, you can then compare ipfs pin ls --type recursive on a trusted node against ipfs-cluster-ctl pin ls and re-pin whatever was unpinned from the cluster.
Ah that’s great thank you!
Sorry I’m just confused: why would I need to re-pin if I set unpin_disable to true? unpin_disable does not discard any unpinning attempt?
Thank you!
When there is an unpin operation, after the pin has been removed from the cluster state etc, the final step is to tell IPFS to unpin the item. unpin_disable causes that final step to fail (it is a failsafe).
There is no way in cluster to allow pinning only, but ignore unpins. The reason is extra complexity with little upsides in an adversarial scenario:
i.e. If a bad node has access to the cluster (is a “trusted” node) and wants to cause havoc, they can also do it by pinning inexistent items etc.
In general fine-grained access control it is something to be handled at a higher layer. disable_unpin is a last resort because it ultimately prevents the unpinning from data on the ipfs daemon if there is a bad-behaved node.
To me, having a potentially bad-behaved node that can “pin” is as problematic as having one that can “unpin” in the end.
Ah!
I get you, it makes perfect sense.
Thank you very much for taking the time, I’m going to dive into the code and get a better understanding of the CRDT structure.