DHT on pubsub and general pubsub improvement

Ecosystem
1

I’m currently developing an app which heavily relies on pubsub. Yet its primitive implementation is holding me back quite a bit. As I understand for now:

  1. pubsub doesn’t use DHT or any routing to find peers for channels
  2. doesn’t have auth or encryption
  3. doesn’t guarantee sequencing of messages
  4. has no way of knowing which peers received messages (although there is a way to know who’s connected)
  5. there’s no relay mechanism for messages, as they’re delivered only on direct connect between nodes.

Is there any ideas if this situation will change or some or these features will be implemented?

1 Like
2

Go take a look at the pubsub in the go-floodsub repo.

pubsub doesn’t use DHT or any routing to find peers for channels

This is planned but not yet implemented. So, “soon” (probably).

doesn’t have auth or encryption

Definitely planned but getting this right is non-trivial. Lots of discussion around this:

doesn’t guarantee sequencing of messages

We’ll may never guarantee sequencing or reliability. In many cases (multiple publishers, partitioned networks) we can’t. If you want to do that, use IPLD. That is, make every message link to the previous message and, if you receive a message out-of-order, fetch the previous message (e.g., using bitswap).

Related (go-specific for now):

has no way of knowing which peers received messages (although there is a way to know who’s connected)

This will never happen unless the peers somehow announce that they’ve received the message. Building this into the protocol will add a lot of overhead even when unnecessary.

there’s no relay mechanism for messages, as they’re delivered only on direct connect between nodes.

I’m not sure about the javscript implementation, but the go implementation does relay messages. If your node receives a message on a topic to which you are subscribed, you’re node will re-broadcast it to all known subscribed peers.

1 Like