Skip to content
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

Closed
CMCDragonkai opened this issue Apr 14, 2019 · 5 comments · Fixed by #43
Closed

Peer to Peer Architecture #32

CMCDragonkai opened this issue Apr 14, 2019 · 5 comments · Fixed by #43
Assignees

Comments

@CMCDragonkai
Copy link
Member

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.

@MeanMangosteen MeanMangosteen self-assigned this Apr 16, 2019
@CMCDragonkai
Copy link
Member Author

@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?

@robert-cronin robert-cronin transferred this issue from MatrixAI/Polykey-Desktop May 5, 2020
@robert-cronin
Copy link
Contributor

robert-cronin commented May 7, 2020

For p2p architecture and sharing vaults, its possible to do it in 2 ways using existing libraries:

  • using libp2p to setup a tcp connection between two polykey nodes and somehow exposing the git repository via a http connection over the tcp connection.
  • using IPFS to setup a http gateway and share a bare git repo for pulling on node B every time node A asks for it. Then isomorphic-git can just use the standard node http object to make a pull request on the address and port of node B.

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:

  1. Developing a tcp connection between nodes on a local network and serving a vault via isomorphic git. The tcp connection can be creating using the nodejs net module.
  2. Developing a distributed hash table for peer and content discovery and possibly even a circuit relay to get around firewalls and nat layers (ipfs does something like this)

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:
https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf
I will make notes on this as I enter phase 2.

@robert-cronin
Copy link
Contributor

robert-cronin commented May 11, 2020

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)

@robert-cronin
Copy link
Contributor

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 (224.0.0.251:5353).

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 (ip:port)

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 (ip:port) of the target node, then communications can be moved to the target nodes address. After the handshake, both nodes store each other's info as a new peer in their peerStore

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.

@robert-cronin
Copy link
Contributor

Multicast Peer discovery was added in PR #40 and the git server/client is added for p2p vault sharing in PR #43

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

3 participants