You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 21, 2023. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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
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.
The text was updated successfully, but these errors were encountered: