go-threads icon indicating copy to clipboard operation
go-threads copied to clipboard

Investigate IPNS-over-PubSub

Open sanderpick opened this issue 6 years ago • 1 comments

(pulling part of this convo from the whitepaper draft into its own ticket)

From @aschmahmann

IPNS-over-PubSub and Persistent PubSub summary

The main change that enables this to work is that when a node first connects to another node in a persistent pubsub channel it asks/pulls from them the latest state of the channel

This is great. We will definitely play with it. By way of finding some concrete points of integration, you can consider Threads to be operating under the assumption that:

We could just know which peers to connect to because we have some system like a peer log, or record of previous users

Currently, "joining" a thread is done by simply navigating to a host's adresss, e.g., /ip4/127.0.0.1/tcp/4006/p2p/12D3KooWGiFcF3Ey1knau6UszUgwdQ3K1BUJQmiUUcs4z4shMWj3/thread/bafkufevg3bqezf3mx7vmloyezupzkdx5ozsfudwky3o3c6kiqvqsldy, which will serve all the logs. Now you know the writers and can simply poll each log address for updates. If you start writing, you will receive direct pushes. However, it would be very nice to layer on an additional DHT-based discovery mechanism. I think this would be achievable by using an ipns-based multiaddress for logs in addition to p2p-based addresses. Then each peer is able to "pull" (and receive pushes) from an IPNS address.

sanderpick avatar Nov 19 '19 20:11 sanderpick

mark

bitcard avatar Mar 01 '21 19:03 bitcard