mesh-p2p / mesh

A P2P standard based on the fact that your contacts likely share at least some of yours

Mesh

A P2P standard made for realtime communication based on the fact that your contacts likely share at least some of yours (In development)

Standard

• Specification.md

Implementations

• rust-mesh - WIP - current official implementation
• node-mesh-core - abandoned - first implementation, even partly functional

mesh's Issues

[Spec Change] Use public key (hashed?) as id

This would eliminate attacks based on impersonating nodes, but potentially increase the message length and need a few more features like a key type byte attached to the ID, moving to new IDs, certificates signed via the old ID referring to the new ID and potentially more.

[Spec Change] Subtractive "Distance"

Is your feature request related to a problem? Please describe.
Additive "Distance" leaks more Information. (not much but more)

Describe the solution you'd like
Instead of direct contacts having a "Distance" of 0 and their contacts 1 to a node, the node gives a starting "Distance", that its contacts have, their contacts have one less.

Additional context
I would only add this if #12 is added

[Spec Change] Use separate encryption and signing keys

Is your feature request related to a problem? Please describe.
Encrypting and singing with the same EC key pair, while possible, might compromise security.

Describe the solution you'd like.
Use separate key pairs. To get the public key for encryption, a route message requesting the key may be sent.

[Project] Onion routing

Existing Onion routing services have many drawbacks: Tor relies on relatively few publicly known servers, I2P takes a long time to build connections.

The Onion routing would happen in two steps:

1. Random selection of layer nodes
2. Layer creation

The node selection process would happen via a Mesh message that is either answered or forwarded to a random compatible contact. The response would include the UUID and public key of that node.

The Layers would be established through a DiffieHellman (or ECDH) key exchange via already established nodes. The first node would be directly connected to then the first layer would be established. The UUID and public key of the next node would then be sent to the current. It would then connect to that node, after which its layer would be established. This would continue to the last node to which is then treated as a contact.

[Spec Change] Rewrite the "spec" to be more organized and fit the conventions of "specs"

Is your feature request related to a problem? Please describe.
The spec is not written as a real spec (no teminology defenitions, chapters, etc.)

Describe the solution you'd like.
Rewrite it.

[Project] Tunneling

Connect to nodes over mesh without a direct connection.

The connection would have two main Phases:

1. Establishing a tunnel (and forwarding the request)
2. Response and further communication

The establishing of a tunnel would happen similarly to IP and Contact Request messages, the only difference being the contents of the message (in this being a key exchange) and the communication not being limited to one requests and response.

[Feature] electron client

[Feature] IOS client

[Project] Find my device over Mesh

Is your feature request related to a problem? Please describe.
Current Find my Device services use a server that the device to be found is constantly connected to via the internet. This has multiple problems:

1. It enables tracking by the service operators (if done well only ip history of account)
2. If the servers go offline, you can't find your device
3. It only works if the device has an internet connection (with this solution the device still needs to be near other devices to be reachable without internet)

Describe the solution you'd like

Location requests:

A node sends an authenticated and encrypted route message asking for the location of the device to be found, if the authentication is legitimate, the precise location (gps) is sent back.

Play sound, Lock device, etc.

A node sends an authenticated and encrypted route message asking for an action to be taken, the device adressed does that action and sends a status (accept/reject) back.

[Security] DOS of route messages

What vulnerability did you find?
A node could stop route messages from reaching the intended recipient.

How do you attack using the vulnerability?
A node could report their distance to the victim as 0 or even set their UUID to that of the victim, so that route messages intended for the victim would be routed to them instead.

How might you fix this

1. A broadcast subtype could be added as a fallback, that would be used if responses to route messages, that aren't "not reachable" (status 1), all have the wrong signature.
2. If a node that has a distance of 0 to the recipient of a route message or is the recipient of a route message, responds with (only) "not reachable" (status 1), the node relaying the route message to them will calculate the distance without them, internally set their distance to on higher than itself and send the route message again.

[Feature] mesh-core node module

[Feature] android client

[Project] Offline messaging

Sometimes Internet outages happen, this would allow for continued communication.

There are two parts to allow for this:

1. connection to nearby nodes via Bluetooth and/or wifi
2. forwarding of small messages over mesh

The first part is definitely possible as seen in briar.

The forwarded messages would be limited in size to reduce leeching.

[Project] Onion Routing over tunnels

This would combine #6 and #7.

It would mostly work like #6 the difference being the way of connection between nodes. The reason for this being Protection of privacy (not having to give your ip to everyone who asks)

[Feature] cli client

Maybe in C/C++