Skip to content
This repository has been archived by the owner on Jul 21, 2023. It is now read-only.

Add message forwarding capabilities #172

Open
raullaprida opened this issue Feb 4, 2020 · 1 comment
Open

Add message forwarding capabilities #172

raullaprida opened this issue Feb 4, 2020 · 1 comment
Labels
kind/support A question or request for support status/ready Ready to be worked

Comments

@raullaprida
Copy link

Some distributed applications (e.g, swarm) require to forward messages to a certain peer via the DHT, instead of looking for closest peers and finally send the message directly to the recipient.
Also, there's a requirement to use a partial recipient address instead of the full address.
The recipient will know the message is for him/her because it can be decrypted successfully.

a new RPC Message type is added to the existing ones (SEND_MSG I proposed in my solution).

The recipient will also forward the message to avoid eavesdroppers to deduct which node is the recipient.

When to stop forwarding the message might be encoded in the message itself and could be some type of TTL. But new ideas can be discussed here.

What this brings:
No direct connection is required to send a message to a peer.
Routing of the message is done through kademlia
Ony the peer public key is required to send a message, the ID can be put partially, the whole ID is not required.

I have a reference implementation I made for my project ( I forked the module) and I will happily provide it as a PR if this feature is interesting for the community.

@vasco-santos
Copy link
Member

Thanks for reaching out @raullaprida

We are currently working on some experiments in the go-libp2p implementation of the dht, which will then be ported to a specification document that we will eventually port to this JS implementation. So, I would say that we should wait for that before adding more features here. As you can use your own fork it will not be a problem for you, so I will let you know in a better timing

@vasco-santos vasco-santos added kind/support A question or request for support status/ready Ready to be worked labels Feb 26, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/support A question or request for support status/ready Ready to be worked
Projects
None yet
Development

No branches or pull requests

2 participants