IPNS advanced tooling

[npfoss]

Type: Features + Questions

Severity: Medium

Description:

Disclaimer: this may be the wrong place to put this; if so, let me know and I'll be happy to relocate it.

Background:
I'm implementing a social network which runs completely in the browser, where the entirety of a profile is wrapped up in the root hash of some big IPLD DAG, so updating and passing those root hashes around is how posts/messages are disseminated. Obviously IPNS is the right tool for the job, since the network depends on each person having their unique public key, and it provides a natural way to have mutable content in the simple pubkey: profile-hash form I need.

However, the current capability and practicality of IPNS is unclear. Is this diagnosis of what is and isn't possible as of 0.37.0 correct?

• Publish IPNS records to the DHT.
  • possible via name API or misc API or all this DHT stuff? what's the relationship of these three?
• Pin IPNS records
  • I'd like friends to be able to pin each other's IPNS records, so that when one goes offline the other can keep their most recent profile version available.
  • Also, DHT lookup would be WAY faster if you're peers with someone who's pinned the IPNS record (right?)
• Alerts on IPNS record update. There are many ways this could be implemented, and it might really make sense to do it as an overlay, at the application layer, which is my current plan. However, that relies on the next point, more advanced tooling.
  • see also: ipns name follow IPNS pinning: ipfs name follow kubo#4435 and partial PR [WIP] Implement ipfs name follow kubo#4462 . this is pretty much exactly what I want, but I'd also like to augment it with pinning and deliberate pings from friends with updates
• More advanced tooling (similar to requests in this go-ipfs issue):
  • Ability to generate a record and send it around independent of the DHT and whatever else. update: this seems to do the trick: https://github.com/ipfs/js-ipns
  • Ability to ingest a (valid) record that came from who knows where (i.e. the above point)
    • including the ability incorporate it into the existing IPNS pins to replace older records and serve back to the network in the standard (DHT) ways
      • bonus effect: it would allow much lighter weight nodes to run in the browser and participate fully (read via gateway and write via this) but only be connected to a single server that need not be trusted with the node's keys to make their IPNS records and data available to the rest of the network.

I'm not sure how IPNS over pubsub fits into this, what its state is, how it works, and whether it solves any of these open problems... If someone could explain/point me in the right direction for that I'd appreciate it. (potentially relevant links: ipfs-shipyard/integration-mini-projects#4 and ipfs/kubo#6447)

These are all critical features for my social network, so I'm willing to build/contribute to whatever doesn't exist already.

[npfoss]

actually, since the DHT is so resource intensive and there are some application-specific things I can leverage, it seems like it'll just be easier to do a lot of this as a overlay