Add 'answer' message type

[whyrusleeping]

I think it would be really valuable to add an 'answer' type message.

Imagine a pubsub swarm where someone publishes a message asking for a certain value. That message gets propogated to the entire swarm as usual. Now if a peer wants to respond to that question, they essentially have to broadcast their answer to the entire swarm. Instead, i propose they send an 'answer' msesage, referencing the question message, back to whatever peer they received the question message from. The peer they responded to should check if they were the asker, and if not, continue sending the answer back until it reaches its target. Since we already keep a cache of recent messages to prevent cyclic propogation, this shouldnt require too much (if any) extra overhead.

Usecases that this would be great for:

• Orbit, new peers join, ask for the latest head, other peers answer.
• IPNS queries through pubsub
• Latency updates for self adjusting pubsub swarms (once we move away from flooding)

[whyrusleeping]

cc @haadcode @dignifiedquire @diasdavid @lgierth

[Stebalien]

To keep this up-to-date, an alternative I've been working on is storing the "latest" valid value sent on any pubsub channel.

[Stebalien]

Latency updates for self adjusting pubsub swarms (once we move away from flooding).

@whyrusleeping could you expand on this?

[dignifiedquire]

@Stebalien similar to this libp2p/js-libp2p-floodsub#32 or a different approach?

[Stebalien]

Very similar; I need it to implement IPNS over floodsub.

Unfortunately, floodsub doesn't currently have an concept of message order and/or message validity/authenticity so I'm trying to fix that first; if we want to use floodsub for IPNS lookups, it needs to be secure and reliable. My preferred solution would be IPRS (gives us both order and validity) but that will take a lot of design work. Instead, I'm working on a solution that I hope can be extended into a flexible IPRS scheme (kind of like CIDv0 -> CIDv1 but designed to be upgradable from the start).

[film42]

NATS solved this using a "reply-to" field to perform request/response pub-sub: https://github.com/nats-io/nats-site/blob/9b4db80b292beca52e19447c9e4c9821068bb361/content/documentation/internals/nats-protocol.md#pub

In other words, a peer making a request would do something like:

# generate a random id for the inbox
randomInbox = "INBOX-12345""
# subscribe to the new inbox
subscription = Subscribe(randomInbox)
# publish a question with the inbox as the "reply-to" topic
Publish(topic: "questions.ask", reply-to: randomInbox, message: "add 3+5")
# wait for a response
subscription.nextMessage

And a peer answering the question would do something like:

subscription = Subscribe("questions.ask")
request = subscription.nextMessage
Publish(topic: request.replyTo, message: "answer is 8")

Picking a random inbox is probably good enough for go-floodsub, and wouldn't require a new "answer" message type. Maybe you guys had something different in mind, but the NATS protocol is simple and works really well for composing more complex protocols.

[vyzo]

We concluded that such functionality should be implemented out of band at the application layer.