Js-ipfs: Implement IPNS

[pfista]

Do you have plans to support ipns publish and resolving?

[daviddias]

@pfista currently not. It is not part of js-ipfs milestone one, it will come when we get to move go-libp2p to the new libp2p spec (and then matching in JS)

[victorb]

Update: Once we have DHT working in js-ipfs (ref: https://github.com/ipfs/js-ipfs/pull/856), work on IPNS can begin

[florianlenz]

I need the IPNS in a project i am working on (i can't proceed until the IPNS is implemented). Can i somehow support you?

[MirceaKitsune]

I am very interested in this functionality, which is essential to one of my plans. Is there any news and progress since the issue was last updated?

The project I wish to attempt involves a website with user functionality: The site itself would serve as an interface, which people use to create and manage a profile. The profile itself is stored as a json file, containing all of the user's settings and references to other files. When changes are made to the profile, a new json database with fresh settings is generated, and the profile reference is updated to reflect this new file. For such to be possible, two things are needed:

1. For browser JavaScript to be able to edit the IPNS address assigned to the profile, discarding the old json file and pointing to the new one after each update.
2. In order to do so and edit the IPNS, the script must decrypt its password or key. I'm unaware whether changes to an IPNS domain can currently be secured behind a password or private key.

If anyone has more information, please let us know what the current status of this ability is.

[RangerMauve]

@MirceaKitsune

Before IPNS can be implemented, we need the DHT to be finished. And for the DHT to be finished for the browser, we need Circuit-relay to be finished.

The DHT is needed so that users can publish changes on IPNS
Circuit-Relay is needed for the browser to be able to participate in the DHT because browsers lack a stable way for a connection to dial into them (and don't support most transports in general), and thus have trouble participating in the DHT.

I think if you want to help speed this up, you should look into helping out with the go/js/browser interop here

As for your actual implementation, once IPNS is available, your "password" for publishing will be a private key. IPNS lets you publish updates that are tied to a given public key, and those are verified to check that it's using the valid public key.

In the meantime, if you want mutable data, you could probably implement something ad-hoc using the pubsub functionality.

[ghost]

And for the DHT to be finished for the browser, we need Circuit-relay to be finished.

That part's not quite accurate: we can totally have the DHT work without circuit relay.

As for the DHT itself, there's a bug that prevents it from working across js-ipfs/go-ipfs boundaries. Within go-ipfs, and within js-ipfs, it works fine, but it doesn't currently interoperate. If you want to get into the ipfs/libp2p stack knee-deep, this would be a great bug to figure out.

[RangerMauve]

@lgierth So the DHT works in the browser with websocket-star right?
What's the specific issue or PR tracking the interop so that I can read up on what has been done so far?

[ghost]

IIRC it's these two failing tests: https://github.com/ipfs/js-ipfs/pull/856#issuecomment-325133094

It's likely that you'll have to disable transport encryption for the daemon (ipfs daemon --disable-transport-encryption, not sure what the flag is for js-ipfs), and look at the actual traffic between peers to make sense of what's going wrong there.

It smells a lot like very subtle multiplexer or transport issues, but we don't know for sure.

@diasdavid is that accurate?

[MirceaKitsune]

Thank you for your responses. I'm still new to IPFS and only an average programmer, I doubt I could contribute code as much as I wish to support this lovely project. I will wait until support for IPNS in js-ipfs is achieved, which I hope isn't too far away. I can see why this is essential for any sites with dynamic content and user accounts, as you can only keep a constant reference to a changing settings file using IPNS given file immutability.

[linonetwo]

Complex applications can't work without IPNS!

[camelmasa]

The team will start to implement IPNS on Q2. https://github.com/ipfs/js-ipfs/pull/1281#issuecomment-379324287

[amark]

@diasdavid @camelmasa @vasco-santos per https://github.com/protocol/research/issues/8#issuecomment-398044835 , we'd like to integrate with IPFS and partner with you guys. To do so, we need IPNS (we can hack around it though), is there any status update on this with js-IPFS?

[vasco-santos]

Hello @amark

I am currently implementing IPNS working locally feature. Now I am polishing some edges and I intend to create an initial PR for review today, or tomorrow. Then, I will have also to work in the testing.

With this first step released, I will focus on integrating routing to the IPNS!

[vasco-santos]

@amark here we go https://github.com/ipfs/js-ipfs/pull/1400

[amark]

@vasco-santos this is AWESOME and very timely! @mmalmi I know your traveling internationally next week, maybe we should sit down and look at this the week after, like early July (I'll email you directly, just wanted to tag you so you saw the js-ipns commit).

@vasco-santos excellent work, keep it up! :)

[ghost]

Will IPNS at this point use the DHT or Delegated Routing? There used to be Go/JS interop issues with the DHT (https://github.com/ipfs/js-ipfs/pull/856#issuecomment-325133094) and I'm wondering whether these got fixed by the recent multiplexer fixes (libp2p/mplex#3).

[vasco-santos]

@lgierth at this point and in this PR, we are only using the local datastore of the peer.

But thanks for reaching out in this issue, because I also want to know if those interop issues that you mentioned above are fixed or not. @diasdavid and @Stebalien do you have information on this?

[Stebalien]

I don't know if anyone has tested DHT interop since the fix.

[daviddias]

@vasco-santos can you share a quick update on this thread?

[vasco-santos]

We divided the implementation of IPNS in three steps, IPNS working locally, followed by integrating the network for sharing the records, where get in the scene IPNS over Pubsub and IPNS over DHT.

IPNS working locally is currently ready in js-ipfs since [email protected].

Regarding IPNS over Pubsub, there is a PR ready that can be used for testing by potential interest people ipfs/js-ipfs#1559. It went through a first review pass and it is working in JS land. However, it is still not ready to be shipped as we are facing an interop problem described in ipfs/interop#39. TLDR the topic used by go-ipfs is not a utf-8 string, which is not compatible with us. Once the topic is changed, both in GO and JS lands, we will be ready to ship this feature. This is currently blocked waiting for a decision on the topic, as well as to be fixed and released in GO land, in order for us to be able to get interop before shipping it in our side.

Finally, the IPNS over DHT will hopefully be ready for a review by the begining of the next week. I have some work on it, and once ipfs/js-ipfs#1701 gets merged and released, I am a small effort away for creating the PR with it.

cc @pgte @jimpick @aschmahmann

[vasco-santos]

IPNS over Pubsub and IPNS over DHT are now merged 🚀

Stay tuned for the next awesome release of js-ipfs

[daviddias]

@vasco-santos looking forward to see a video demo! pretty please 🙏🏽 :D

[vasco-santos]

Will do it!