Trying to figure out if I should add trusted peer IDs to the service.json or leave it as [“*”].
The base cluster consists of two nodes both have each other added as trusted.
The thing I have a hard time getting my head around for the follower node service.json is people could just change it as they want, so what does it matter if trusted nodes are defined or it is a wildcard?
I will have the service,json publicly available on a webserver.
Hello,
you should add trusted peers to service.json if the cluster has non-trusted peers.
Sure, people/followers can change service.json any way they want, and they are responsible for what their peer does. But everyone else that keeps the right set of trusted_peers in service.json ensures that they will ignore any updates to the pinset that are not coming from that set. If a follower uses [‘*’], potentially its pinset will take updates from anyone that sends updates.
Makes sense, so would the following be a valid and good service.json for no trusted peers to join the cluster?
{
“peer_addresses”: [
“/ip4/199.223.164.279/tcp/9096/p2p/12D3KooGN5nnhiVcFePUapL9tL4j765dSZy7yqPAUHSkRynwhH54”,
“/ip4/41.59.21.122/tcp/9096/p2p/12DgKooWEW7vXxbt6ZgcG7WKMqz1erTbhSXEiyz5TbdLM8YJxtGZ”
],
“cluster_name”: “DVM-ipfs-cluster”,
“follower_mode”: true
}
Yes, should work? Try it out
It does not work, at first when running ipfs-cluster-follow it errored saying multiaddress was missing. So I have added that. Now the error it gives is:
could not determine the consensus component
Current follower service.json
{
“peer_addresses”: [
“/ip4/199.223.164.279/tcp/9096/p2p/12D3KooGN5nnhiVcFePUapL9tL4j765dSZy7yqPAUHSkRynwhH54”,
“/ip4/41.59.21.122/tcp/9096/p2p/12DgKooWEW7vXxbt6ZgcG7WKMqz1erTbhSXEiyz5TbdLM8YJxtGZ”
],
“cluster_name”: “dvm-ipfs-cluster”,
“follower_mode”: true,
“cluster”: {
“listen_multiaddress”: “/ip4/0.0.0.0/tcp/9096”,
“consensus”: “crdt”
}
}
It also warns about cluster secret being empty, but I don’t want this peer as “trusted”, so I am assuming that is fine to ignore.
You need to provide a full service.json, you can’t just place some random options in a json and expect things to work. I suggest a throughout reading of Collaborative Clusters - Pinset orchestration for IPFS.
Start with a default service.json and then adjust it for follower peers.
I am not placing random options, they are options based off the documentation, which I have read thoroughly. For example on this page:
This implies to me that only these are required for a peer to follow. Yes, I am missing cluster secret. Apparently it is needed even for “untrusted” peers, so it is not really a secret. The naming is a bit misleading?
Checking for examples here:
Half of them are missing txt record, the others hang on lookup. Can you confirm if any of those are currently accesible?
I can change this to be more explicit, but the previous section tells you to use ipfs-cluster-service init --consensus crdt, then to followers can use exactly the same configuration as your trusted peers, but we recommend tailoring a specific follower configuration as explained in the next section.
So what that means is what I am telling you, you need to distribute a full service.json that can be more or less customized as long as the trusted_peers, their multiaddresses, the secret, and the crdt/cluster_name are set correctly.
Security and ports - Pinset orchestration for IPFS. Collaborative clusters did not exist at the beginning when the nomenclature was set.
I don’t maintain the clusters themselves and it’s been a while I have looked into them…
