I’m trying to figure out a way to maintain a list of IPFS nodes that i maintain to do status checking by some external service. Now i want to periodically query those nodes. If i have one central server i can just maintain a list of the current nodes in my network, no problem. The list can easily change with nodes being added or removed.
In a decentralized world this proves to be really tricky. How can i maintain a list of nodes where i can access it by one fixed identifier?
An example of the issue in a tree format:
| <CID root (hash)>
| - child 1
| - child 2
Then when a node gets added:
| <CID root (different hash)>
| - child 1
| - child 2
| - child 3
I cannot get a common root node in this example, the hash is different when a child node gets added or removed.
In reality this list is of real peer id’s and always a flat list like above. But nodes can be added and removed and being able to traverse the list would be vital too.
Now the easy way would probably be to put this structure in a json file, add that to IPFS and publish that to get an IPNS. Problem solved …
Now i’ve seen tons of awesome stuff in IPLD and the mutable filesystem which make me think that IPFS has way better mechanisms to do this. I just don’t know. I’m guessing a solution with IPLD would still have to use IPNS on top?
Any help here on what’s the best advised way of doing such a thing?
And please with pointers on how to use it! I’ve tried looking up how to use IPLD, but i can’t quite find documentation on how to play with that. But then again, it might not even be the proper thing to use in this case, i just don’t know.
Could you please explain that a lot more?
I don’t see how that, seemingly totally irrelevant function, is apparently very relevant?
The IPFS docs don’t tell anything useful either. Yeah, well, they tell what the commands do (as docs should do) but i can’t find anything about the key commands and what their intended usecase is.
IPNS publishing uses by default each peer’s Identity (private key) to publish the IPNS reference.
You have several peers that might want to publish to the same reference. If this is the case, you can use ipfs gen to generate a new key. You can then copy that key to other peers (they are stored in .ipfs/keystore/ folder), and re-use it.
In order to use that key, you need to pass --key to the name publish command. If you do not wish to re-use keys and can work with single publisher-node, then you can just ipfs name publish directly.
Ohh, it now just hits me.
All this time i was under the impression that your response was an alternative approach to what i said in my initial post. That is why i had a hard time understanding how i would add multiple servers in the key, that made no sense to me. But you meant to solve just the part where multiple servers would do an ipfs publish on the same data.
Awesome
I wasn’t even thinking of that being a potential issue. I would’ve probably found that out if i made it like that though. Thank you for being far ahead of me!
But that still leaves the data structure. Is adding a json file really the way to go here for a simple list? I’m fine if it is, but it seems so simple where i was expecting things to be (far) more complicated.
…