ipns over pubsub: howto?

[DougAnderson444]

Hi @aschmahmann,

I saw your talk at IPFS camp and wondering if you can elaborate on exactly how to use ipns over pubsub.

Specifically:

1. I presume the peers need to actively subscribe to the IPNS topic? Or does this magically happen behind the scenes when one does ipfs resolve QmIPNSHash (with --enable-namesys-pubsub = true)?
2. Do peers simply do a regular ipfs pubsub sub QmIPNSHash to get ipns updates? Or is it ipfs pubsub sub /ipns/QmIPNSHash ?
3. I saw your post that says IPNS over PubSub topics look like /record/L2lwbnMvEiCGC1J-0c8fai1qZlZ8I5fg8BYN36Tn6tPXsodDl3PTig ... but where does this topic come from?
4. Follow on to Create Sjenica1 #3, do we do ipfs pubsub sub L2lwbnMvEiCGC1J-0c8fai1qZlZ8I5fg8BYN36Tn6tPXsodDl3PTig
5. Why is the pubsub topic not simply the ipns hash?

Hopefully answers will clear up some confusion! I'd love to try the ipns over pubsub, but cannot find the command to get it rolling.

Thanks

[aschmahmann]

Hey @DougAnderson444, thanks for checking in. Happy to answer the question and glad you tagged me. In general you may find answers faster on the IPFS discuss forum (discuss.ipfs.io) or IRC (https://docs.ipfs.io/community/irc/), which is bridge to Matrix and Discord if you find those platforms more convenient.

Now, onto the answers 😄

I presume the peers need to actively subscribe to the IPNS topic? Or does this magically happen behind the scenes when one does ipfs resolve QmIPNSHash (with --enable-namesys-pubsub = true)?

It happens magically. Basically go-ipfs has a pluggable system for finding content, IPNS records, other peers, etc. Enabling namesys-pubsub basically adds in the pubsub router from https://github.com/libp2p/go-libp2p-pubsub-router so that we find/publish to both the DHT and the pubsub channel.

Do peers simply do a regular ipfs pubsub sub QmIPNSHash to get ipns updates? Or is it ipfs pubsub sub /ipns/QmIPNSHash ?
...
I saw your post that says IPNS over PubSub topics look like /record/L2lwbnMvEiCGC1J-0c8fai1qZlZ8I5fg8BYN36Tn6tPXsodDl3PTig ... but where does this topic come from?

First an aside that there exists the ipfs name pubsub set of commands. However, they don't really give you as much introspection as you might want during debugging that's partly why this tool his here.

The spec that describes converting /ipns/QmIPNSHash to (and from) a pubsub topic name is described in the IPFS specs repo at https://github.com/ipfs/specs/blob/master/naming/pubsub.md (with some references to the IPNS spec at https://github.com/ipfs/specs/blob/master/IPNS.md).

Summary: QmIPNSHash is the base58 representation of the IPNS Hash. The pubsub topic ID is /record/base64url-unpadded(/ipns/binaryRepresentationOfIPNSHash).

Follow on to #3, do we do ipfs pubsub sub L2lwbnMvEiCGC1J-0c8fai1qZlZ8I5fg8BYN36Tn6tPXsodDl3PTig

Not quite, that's the base64url-unpadded portion. You're missing the /record/ in front. You can confirm this in IPFS by just doing a publish and then performing an ipfs pubsub ls.

Why is the pubsub topic not simply the ipns hash?

This occurred before my involvement in the project and while I had some context, these answer are generally best found via github sleuthing 😀. ipfs/interop#39 (comment). I think it's pretty clear from the comment there what's going on, but I'll try and rehash below.

Recall that QmIPNSHash is just one representation of the hash.

1. To avoid tying the wire representation of an IPNS key to a particular base internally the key /ipns/BINARY_ID was used as the key when putting in the DHT.
2. To make the DHT and PubSubRouter both just implementations of the routing interface the same /ipns/BINARY_ID representation needed to be processed by PubSub
3. PubSub requires that the topic be represented in UTF-8. While /ipns/QmIPNSHash is representable in UTF-8 and it's simple enough to convert to/from /ipns/BINARY_ID it's pretty hacky since you have to:
   a) leave the /ipns part alone
   b) decide which base to use for representing the key
   c) figure out how our now abstract pubsub router would represent /myrecord/binaryRepresentationOfXYZ
4. We can make things consistent and UTF-8 compliant by having the pubsub router use topics of the form /record/unpadded-base64(key). Now, no matter what the format of the key is it can be used as a pubsub topic.

There certainly are alternative design decisions that could've been made here, but overall it does the job of keeping the individual routers (DHT and PubSub) independent and spec compliant which is convenient.

[DougAnderson444]

Awesome answer, than you so much!!