IPNS Pinning - IPNS watching/listening/following

[mrodriguez3313]

Create endpoint that accepts a IPNS Path ("/ipns/k51...") and resolves it. This function should return the data that was resolved as confirmation. (think gateway.ipfs.io/ipfs/Qm....)

Expectations: This will take a while to resolve, for example: if you publish anything to IPNS, then try to go to gateway.ipfs.io/ipns/<k51...>. It will not resolve it, and may not ever resolve it. One way to mitigate this would be to enable IPNSPubSub. As I understand it, that would enable quick discovery, but will auto download everything published to IPNS by anyone as well. This would obviously not be the best solution because then storage would fill up extremely quick and be costly (thinking about web2 cloud storage costs).

For the purposes of putting a name of this functionality I will call it IPNS Following (giving credit to Jorropo where I first saw it being mentioned here discuss.ipfs.io.

Theoretically, the functionality should be as follows:

• User notifies us of a record they want tracked for updates (pinning)
• User updates their record and keeps it alive on their own accord. We just watch for updates and download content. No need for them to send us their key
• We keep updating our own record until user says otherwise (opportunity for financial model)

Spit balling solutions:

• Custom DHT? Holds only IPNS records?
• Web3.Storage IPNS solution for storage (charge user fee + storage cost in FIL) :eyes::eyes:
• Create API Skynet style, any user can be a host and get paid in token for it? Enable via layer 2 smart contracts?
• enable pubsub (NOT IPNS PubSub) and if I see an IPNS path on a topic, I will resolve content, this will make sure I don't download EVERYTHING that gets published to IPNS (need more information on IPNS PubSub experimental feature)
• Traditional DB on backend (user IPNS key -> content) {also eeww}

The easiest way to resolve and follow IPNS records is if they were to be originally published by the API, then user can take their key and publish later on on their own OR optionally choose for us to keep alive for them. (IPNS Republishing)

[mrodriguez3313]

Okay first implemented here: #18

[mrodriguez3313]

One idea for keeping track of only specific IPNS records to be tracked is. Whenever someone hits the "Follow()" endpoint that IPNS name will be added to a queue. The record at HEAD, once resolved, will move to the end of the list. And this will happen indefinitely until user says otherwise or 't' amount of time has passed or content has come back unresolved x times. This will can be a go-script running at all times.

[mrodriguez3313]

I need to add delete support for the queue. but basic IPNS following has been implemented here https://github.com/mrodriguez3313/IPNSGoServer/pull/20

[mrodriguez3313]

Basic delete support added here https://github.com/mrodriguez3313/IPNSGoServer/pull/22