search

Fierro-Labs / Fierro

IPNS API and pinning service
https://www.fierro.io
MIT License
34 stars 4 forks source link

IPNS Pinning - Republishing/reviving #13

Open mrodriguez3313 opened 2 years ago

mrodriguez3313 commented 2 years ago

a) Create endpoint that accepts a IPNS Path ("/ipns/k51...") and private key, then resolves it. This function should return the data that was resolved as confirmation (think gateway.ipfs.io/ipfs/Qm....). Then behind the scenes, node continues to keep record alive by republishing.

AND

b) Create endpoint similar to PutKey() (aka PutKeyV1), that accepts a IPFS Path and a private key. This function should publish for the first time and return the IPFS Path as confirmation. Does not delete key, thus allowing node to automatically keep record alive by republishing.

In practice, changes must be made: 1) Endpoints will need to renamed and reworked to be scoped tighter. a) PutKeyV2 - take provided private key and store it in node. Does not delete key. b) PublishV1 = PutKeyV1 - This allows for publishing updates w/o running their own node. And allows others the opportunity to implement their own republishing mechanics and key management systems. c) PublishV2 - take ipfs path and name of key (string) and basically runs ipfs publish <ipfs_path> <key_name> to publish IPNS Record and republish automatically. d) PublishV3 - take ipns path and private key, resolve data, if resolved, store key, and allow node to republish automatically.

PutKeyV1 currently gets a key&ipfsCID, stores key, publishes an IPNS record, and deletes key.

mrodriguez3313 commented 2 years ago

Okay first implemented here: https://github.com/mrodriguez3313/IPNSGoServer/pull/17

mrodriguez3313 commented 2 years ago

Publishing and republishing as well as get have been implemented here https://github.com/mrodriguez3313/IPNSGoServer/pull/20

The last thing that is needed to be done (which will be easier) will be

c) PublishV2 - take ipfs path and name of key (string) and basically runs ipfs publish to publish IPNS Record and republish automatically.

This way to publish makes sense because of the fact that someone can use PostKey() to add their key to own node and now they just need to supply the content to publish. aka they don't need to send the key over the web again.

mrodriguez3313 commented 2 years ago

PostRecord works as expected where if one publishing a record through the service. Then the remote node will handle republishing automatically.

PutRecord accepts a private key and key ID to allow for republishing in the future. The problem with the state of this endpoint as it is today is: just having the data hosted and the key for that data is not enough for the remote node to handle republishing automatically. For the node to know to automatically republish the record on users behalf, the remote node is the one that needs to do the publishing.

Im thinking to solve this, I can peek at the record's expiration time, and attempt to republish the content at that later time. The problem arises that the user's node may also be online and thus two nodes would republish the content and now there would be a major nonce conflict and even content version problem.