-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Peer to Peer Architecture #32
Comments
@ll-aashwin-ll Relevant: https://spacemesh.io/use-p2p-lib/ Critique on both libp2p and ethereum's p2p. So that means they wrote their own while basing on inspirations from both. Maybe we could learn from all 3? |
For p2p architecture and sharing vaults, its possible to do it in 2 ways using existing libraries:
Both of the above are not always 100% debuggable and we have little to no control over the implentation of these two. So it is worth looking into building our own p2p architecture from scratch. This would involve two phases:
We can take some ideas from libp2p such as multiaddr and multihash and look into Kademlia for the DHT implementation. Here is the Kademlia paper: |
I managed to get a preliminary connection setup with inspiration from node-git-server. It basically acts as a node backend for a git http server. The good thing about this is we can adapt it to use EFS to serve the git repo from upperDir (virtualfs). The reason I had to go this far out is because isomorphic-git does not yet support server like functions: isomorphic-git/isomorphic-git#464. Perhaps once it does, we can use the isogit implementation but I think we will want to tightly control this part of the p2p architecture anyway. We will need to adapt it to a pure JavaScript implementation. I think this is possible, the main thing is looking at streams (for this there is readable-stream) and http support (for this there is axios) |
I have a multicast DNS peer discovery mechanism working now, all you need is the public key of the node you wish to connect to and the handshake occurs over UDP multicast address ( The requesting node broadcasts a message encrypted with the target node's public key and thus is only decrypt-able by the target node. The message consists of some random bytes as well as the requesting nodes public key and address ( Successful handshake occurs when the target node sends a return message back to the requesting node consisting of the decrypted random bytes and the address ( The return message is re-encrypted with the requesting nodes public key so communications are always secure. I'm not sure if it needs to be this secure since its only the pubkey and address so perhaps its something we can reconsider down the line. |
Inspirations:
The peer to peer architecture is the architecture in which Polykey Keynodes can discover each other and connect to each other. Note that communication between Polykey keynodes happens over this p2p network. But social discovery occurs via social providers like Keybase which facilitate discovery of human profiles to automated keynodes.
The text was updated successfully, but these errors were encountered: