matrix-org / pinecone

Peer-to-peer overlay routing for the Matrix ecosystem

Pinecone

Pinecone is an experimental overlay routing protocol suite which is the foundation of the current P2P Matrix demos. It is designed to provide end-to-end encrypted connectivity between devices at a global scale over any compatible medium (currently TCP, WebSockets, Bluetooth Low Energy etc), allowing multi-hop peer-to-peer connectivity between devices even in places where there is no Internet connectivity.

Pinecone builds two virtual topologies: a globally agreed spanning tree, like Yggdrasil, and a virtual line (or snake) arranged sequentially by public key. This gives some rise to the routing scheme perhaps being called SNEK (Sequentially Networked Edwards Key) routing, but perhaps we can come up with a better acronym. 🐍

Intersecting paths between keyspace neighbours provide the bulk of the routing knowledge, whilst the spanning tree provides greedy routing for some bootstrap and path setup traffic. In addition, Pinecone also implements source routing and an active pathfinder, although these are currently not used by the P2P Matrix demos.

Pinecone is incredibly experimental still. There might be bugs, vulnerabilities or architectural problems that we don't yet know about. If you spot anything that doesn't look right, we are very happy to welcome issues and pull requests, or you can join us in #p2p:matrix.org.

Requirements

Go 1.18 or later.

Questions

Is there any documentation?

The best documentation today is the code itself, which is reasonably well commented. There is also some documentation on how the protocol works here.

Does Pinecone perform well?

Generally yes! However, this implementation isn't terribly well optimised yet so there will almost certainly be improvements that can be made.

Will Pinecone scale?

It's a primary goal of ours to build something that will scale up to Internet-like proportions in order to help us with our plans for Matrix world domination. We think Pinecone should scale well, but ultimately we will find out and make changes accordingly.

Is Pinecone secure?

All traffic transported over Pinecone is end-to-end encrypted using TLS, therefore intermediate nodes will not be able to inspect packet contents. Many of the protocol messages are also cryptographically signed for authenticity. The protocol is still in its infancy, however, so there may be theoretical attacks that we don't know about yet.

Can I run Pinecone on my platform?

This implementation is written in Go which has excellent support for a number of platforms and cross-compilation for mobile devices. We've successfully seen Pinecone running on macOS, Linux, Windows, Android and iOS. We aren't aware of any specific reasons that it wouldn't work on other platforms supported by Go.

Why not Yggdrasil?

We did in fact experiment with Yggdrasil in earlier P2P Matrix demos, and in many ways, Pinecone is directly inspired by Yggdrasil. However, the spanning tree topology alone is not a suitable routing scheme for highly dynamic networks. Peerings that represent parent-child relationships on the spanning tree can result in entire parts of the coordinate system becoming temporarily invalidated, interrupting connectivity.

Why not libp2p?

We experimented with that too! libp2p worked well for local-only scenarios but currently assumes in many places that nodes will be directly routable to each other over (either over a LAN or the Internet), which is not necessarily going to be the case for P2P Matrix. Other components that would be useful (such as NAT traversal and overlay routing) are still quite early. If Pinecone overlay routing is a success then we will hopefully to be able to assist with adding support into libp2p in the future.

Does Pinecone provide anonymity?

No, it is not a goal of Pinecone to provide anonymity. Pinecone packets will be routed using the most direct paths possible (in contrast to Tor and friends, which deliberately send traffic well out of their way) and Pinecone packets do contain source and destination information in their headers currently. It is likely that we will be able to seal some of this information, in particular the source addresses, to reduce traffic correlation, but this is not done today.

Does Pinecone work on mobile devices?

Yes, we actually have two P2P Matrix demos for Android and iOS today. Node mobility is an important problem for us to solve, as not many routing schemes today respond well to topology changes. We believe that the SNEK routing within Pinecone should respond well to topology changes.

What is a static peer?

Pinecone nodes can automatically discover each other depending on the platform (for example, Android and iOS nodes can discover each other over Bluetooth without any further configuration). However, you might not be physically close to any other Pinecone nodes, so instead you can join the wider Pinecone network by connecting to a static peer over the Internet or an existing network. Traffic to distant nodes will be routed over this peer connection.

Can I run my own static peer?

Sure, the cmd/pinecone binary will help you to do that. You will need to provide the -listen command line argument to specify which port to accept connections on, and you will probably also want to specify the -connect flag to connect your node to an existing peer so that your node is not isolated from the rest of the world. Unless, of course, isolation is what you are aiming for.

Does Pinecone work through firewalls or NATs?

Yes. Pinecone peering connections look like regular TCP or WebSocket connections and will work fine through firewalls or NATs. If you make an outbound connection to a static node, you will still be able to receive incoming Pinecone traffic over that peering.

pinecone's Issues

Spanning Tree selectNewParent logic doesn't match the parent selection logic in Update

The current selectNewParent logic doesn't always grab the best parent. The parent it does select depends on the order of peers stored in the switch.
(ie. If Peer B at switch[2] has fewer hops than Peer A at switch[1] then Peer B will be selected as parent even if it has a weaker root key than Peer A, just because Peer B is connected later in the switch)

pinecone/router/tree.go

Lines 129 to 140 in 74f8856

	switch {
	case ann.RootPublicKey.CompareTo(bestKey) > 0:
	fallthrough
	case hops < bestDist:
	fallthrough
	case ann.at.Before(bestTime):
	bestKey = ann.RootPublicKey
	bestDist = hops
	bestPort = p.port
	bestTime = ann.at
	bestAnn = ann
	}

This doesn't really matter because the node will eventually converge on using it's best parent due to the Update logic called when receiving tree announcements from peers. The only downside being more intermediary parents may be selected before converging on the best parent.
From this I gather the best parent should be the peer with the best root key and shortest number of hops to that root:

pinecone/router/tree.go

Lines 319 to 340 in 74f8856

	case globalKeyDelta == 0:
	// The update is from the same root node, let's see if it matches
	// any other useful conditions
	switch {
	case newUpdate.Sequence < lastGlobalUpdate.Sequence:
	// This is a replay of an earlier update, therefore we should
	// ignore it, even if it came from our parent node
	return nil
	case len(newUpdate.Signatures) < len(lastGlobalUpdate.Signatures):
	// The path to the root is shorter than our last update, so
	// we'll accept it
	globalUpdate = true
	}
	case globalKeyDelta > 0:
	// The root key is stronger than our existing root, therefore we'll
	// accept it anyway, since we always want to converge on the
	// strongest root key
	globalUpdate = true
	}

Should the selectNewParent logic be updated to match the Update logic?

Such as:

var newBest = false
if ann.RootPublicKey.CompareTo(bestKey) > 0 {
	newBest = true
} else if ann.RootPublicKey.CompareTo(bestKey) == 0 && hops < bestDist {
	newBest = true
}

if newBest {
	bestKey = ann.RootPublicKey
	bestDist = hops
	bestPort = p.port
	bestTime = ann.at
	bestAnn = ann
}

ERROR: type *TUN has no field or method setup

Describe the bug
TUN error while building pineconeip on windows.

To Reproduce

C:\Pinecone\pinecone>go build -o pineconeip.exe cmd\pineconeip\main.go

go: downloading golang.zx2c4.com/wireguard v0.0.0-20210927201915-bb745b2ea326
go: downloading nhooyr.io/websocket v1.8.7
go: downloading golang.org/x/net v0.0.0-20210927181540-4e4d966f7476
go: downloading golang.org/x/sys v0.0.0-20210927094055-39ccf1dd6fa6
go: downloading github.com/klauspost/compress v1.10.3

# github.com/matrix-org/pinecone/cmd/pineconeip/tun
cmd\pineconeip\tun\tun.go:64:14: t.setup undefined (type *TUN has no field or method setup)

Spanning Tree announcement interval may be too fast

This comment is incorrect:

pinecone/router/tree.go

Line 31 in e692df1

const announcementInterval = PeerKeepaliveInterval // time.Minute * 15

The current value is this:

pinecone/router/peer.go

Line 32 in e692df1

const PeerKeepaliveInterval = time.Second * 2

I'm guessing that 15 minutes is the intended value.

The PeerKeepaliveInterval value, as is, is also being used for the peer connection read deadline. I tried it out in the simulator and these values definitely need to be coupled to prevent connection timeouts.

I don't think there would be any negative side effects to extending the spanning tree announcement interval since new peer's immediately obtain the current tree state already thanks to this bit:

pinecone/router/peer.go

Lines 342 to 345 in e692df1

	// The very first thing we send should be a tree announcement,
	// so that the remote side can work out our coords and consider
	// us to be "alive".
	send(p.generateAnnouncement())

Sim Feature: Event capture mode

Sim users should be able to record the commands they send to the server to be used in future sequence imports. For this to work the following needs to be added:

• record the events as they happen
• allow the user to save this somewhere upon stopping the capture

Sim Feature: Can start/stop the graph sim from running

The visjs graph can consume a lot of processor time when simulating large networks. This results in two potentially undesirable behaviours.

1. simulation state update messages taking longer to be processed as they are received
2. processor usage gets really high

It would be beneficial to be able to "pause" the visjs simulation. This would greatly reduce the processing currently happening and allows the sim ui to quickly process new updates. Visjs already has this ability in the API, the sim just needs some added UI and to have it hooked up.

[Android] - Crash when trying to send message to desktop pinecone

Describe the bug
Sending a message to a desktop pinecone user make the application crash at start.

Smartphone:

• Device: Android
• OS: Lineage
• Version 1.1.7 - dev

Stacktrace

Here is the stacktrace at start

FormattedJsonHttpLogger: <-- 200 OK http://localhost:65432/_matrix/client/r0/pushers (30ms, 14-byte body)
03-19 20:30:19.846 14094 14153 V FormattedJsonHttpLogger: <-- 404 Not Found http://localhost:65432/_matrix/client/unstable/room_keys/version (66ms, 53-byte body)
03-19 20:30:19.848 14094 14108 I r.app.p2p.debu: Background young concurrent copying GC freed 105732(6731KB) AllocSpace objects, 63(3440KB) LOS objects, 88% free, 6235KB/54MB, paused 273us total 157.462ms
03-19 20:30:19.848 14094 14094 I r.app.p2p.debu: WaitForGcToComplete blocked ClassLinker on ClassLinker for 11.416ms
03-19 20:30:19.858 14094 14151 E DefaultGetKeysBackupLastVersionTask: Exception when executing request GET http://localhost:65432/_matrix/client/unstable/room_keys/version
03-19 20:30:19.869 14094 14150 V AsyncTransactionKt$awaitTransaction$$inlined$withPermit$lambda: Execute transaction in 64 millis
03-19 20:30:19.877 14094 14175 V QueryStringValueProcessorKt: No condition to process
03-19 20:30:19.899 14094 14094 V UnknownDeviceDetectorSharedViewModel: ## Detector - Current Session first time seen 1647718219895
03-19 20:30:19.900 14094 14094 V UnknownDeviceDetectorSharedViewModel: ## Detector - Remembered ignored list []
03-19 20:30:19.902 14094 14140 V VectorUncaughtExceptionHandler: Uncaught exception: java.lang.NullPointerException
03-19 20:30:19.908 14094 14140 E VectorUncaughtExceptionHandler: FATAL EXCEPTION Element Build : 4010107
03-19 20:30:19.908 14094 14140 E VectorUncaughtExceptionHandler: Element Version : 1.1.7-dev [4010107] (F--)
03-19 20:30:19.908 14094 14140 E VectorUncaughtExceptionHandler: SDK Version : 0.0.1 ()
03-19 20:30:19.908 14094 14140 E VectorUncaughtExceptionHandler: Phone : SM-G935F (eng.ivanme.20210621.061307 11 REL)
03-19 20:30:19.908 14094 14140 E VectorUncaughtExceptionHandler: Memory statuses 
03-19 20:30:19.908 14094 14140 E VectorUncaughtExceptionHandler: usedSize   6 MB
03-19 20:30:19.908 14094 14140 E VectorUncaughtExceptionHandler: freeSize   47 MB
03-19 20:30:19.908 14094 14140 E VectorUncaughtExceptionHandler: totalSize   54 MB
03-19 20:30:19.908 14094 14140 E VectorUncaughtExceptionHandler: Thread: Crypto_Thread, Exception: java.lang.NullPointerException
03-19 20:30:19.908 14094 14140 E VectorUncaughtExceptionHandler:        at org.matrix.android.sdk.internal.crypto.algorithms.megolm.MXMegolmEncryptionFactory.create(MXMegolmEncryptionFactory.kt:56)
03-19 20:30:19.908 14094 14140 E VectorUncaughtExceptionHandler:        at org.matrix.android.sdk.internal.crypto.DefaultCryptoService.setEncryptionInRoom(DefaultCryptoService.kt:562)
03-19 20:30:19.908 14094 14140 E VectorUncaughtExceptionHandler:        at org.matrix.android.sdk.internal.crypto.DefaultCryptoService$encryptEventContent$1.invokeSuspend(DefaultCryptoService.kt:644)
03-19 20:30:19.908 14094 14140 E VectorUncaughtExceptionHandler:        at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
03-19 20:30:19.908 14094 14140 E VectorUncaughtExceptionHandler:        at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
03-19 20:30:19.908 14094 14140 E VectorUncaughtExceptionHandler:        at android.os.Handler.handleCallback(Handler.java:938)
03-19 20:30:19.908 14094 14140 E VectorUncaughtExceptionHandler:        at android.os.Handler.dispatchMessage(Handler.java:99)
03-19 20:30:19.908 14094 14140 E VectorUncaughtExceptionHandler:        at android.os.Looper.loop(Looper.java:223)
03-19 20:30:19.908 14094 14140 E VectorUncaughtExceptionHandler:        at android.os.HandlerThread.run(HandlerThread.java:67)
03-19 20:30:19.910 14094 14094 I VectorBaseFragment: onCreateView Fragment HomeDetailFragment
03-19 20:30:19.913 14094 14170 I GoLog   : PINECONE: Connected to peer 3bf0258d23c60952639cc4c69c71d1508a7d43a0475d9000ff900a1848411ec7 on port 1
03-19 20:30:19.913 14094 14175 V QueryStringValueProcessorKt: No condition to process
03-19 20:30:19.914 14094 14198 V QueryStringValueProcessorKt: No condition to process
03-19 20:30:19.921 14094 14140 E AndroidRuntime: FATAL EXCEPTION: Crypto_Thread
03-19 20:30:19.921 14094 14140 E AndroidRuntime: Process: im.vector.app.p2p.debug, PID: 14094
03-19 20:30:19.921 14094 14140 E AndroidRuntime: java.lang.NullPointerException
03-19 20:30:19.921 14094 14140 E AndroidRuntime:        at org.matrix.android.sdk.internal.crypto.algorithms.megolm.MXMegolmEncryptionFactory.create(MXMegolmEncryptionFactory.kt:56)
03-19 20:30:19.921 14094 14140 E AndroidRuntime:        at org.matrix.android.sdk.internal.crypto.DefaultCryptoService.setEncryptionInRoom(DefaultCryptoService.kt:562)
03-19 20:30:19.921 14094 14140 E AndroidRuntime:        at org.matrix.android.sdk.internal.crypto.DefaultCryptoService$encryptEventContent$1.invokeSuspend(DefaultCryptoService.kt:644)
03-19 20:30:19.921 14094 14140 E AndroidRuntime:        at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
03-19 20:30:19.921 14094 14140 E AndroidRuntime:        at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
03-19 20:30:19.921 14094 14140 E AndroidRuntime:        at android.os.Handler.handleCallback(Handler.java:938)
03-19 20:30:19.921 14094 14140 E AndroidRuntime:        at android.os.Handler.dispatchMessage(Handler.java:99)
03-19 20:30:19.921 14094 14140 E AndroidRuntime:        at android.os.Looper.loop(Looper.java:223)
03-19 20:30:19.921 14094 14140 E AndroidRuntime:        at android.os.HandlerThread.run(HandlerThread.java:67)
03-19 20:30:19.925  4840 14199 I DropBoxManagerService: add tag=data_app_crash isTagEnabled=true flags=0x2
03-19 20:30:19.926  4840  4923 W ActivityTaskManager:   Force finishing activity im.vector.app.p2p.debug/im.vector.app.features.home.HomeActivit

TUN/TAP interface (like Yggdrasil)

Please add support for a virtual TUN/TAP interface, like Yggdrasil.

Intelligent switch queues

Currently we maintain two queues for each peer: a protocol queue and a traffic queue. They are fixed sizes.

We should instead implement more intelligent queues, sorted by source-destination at least, to ensure that one source node can't saturate the queues of a node on the path single-handedly, effectively denying service to others.

How well does pinecone scale?

Hello,

If I understand correctly then Pinecone is similar to Yggdrasil which seems to scale pretty good from what I can see.

Does Pinecone scale well?

netcat probe leads to panic

Describe the bug
nc address port leads to panic

To Reproduce
Steps to reproduce the behavior:

1. run a listening instance ./pinecone -listen 0.0.0.0:4567
2. in a different terminal / from a different machine run nc ip-address 4567
3. listener panics

panic: io.ReadFull: read tcp [fe80::942c:69ff:fecc:8251%feth1801]:4567->[fe80::94aa:78ff:fe5d:dac4%feth1801]:59994: i/o timeout

goroutine 24 [running]:
main.main.func3()
	/Users/phil/dev/pinecone/cmd/pinecone/main.go:101 +0x258
created by main.main
	/Users/phil/dev/pinecone/cmd/pinecone/main.go:82 +0x265

Expected behavior
pinecone should ignore the probe

Desktop (please complete the following information):

• Macos

Additional context
this is on 3512655

How is it different from Nats.io

Hello,

I am trying to get a feel for Pinecone and its capabilities and have read about the comparisons that you made with Yggdrasil and LibP2P but am trying to determine how it also compares to Nats.io in that this also seems to be similar and for scaling out to thousands of P2P nodes.

I am working towards some P2P projects and was actually initially considering Yggdrasil and LibP2P, but if Pinecone and/or Nats.io are better choices then I want to look into them as well.

Actually, I like what I have read about Pinecone and also do not mind if the project is cutting-edge since the P2P projects that I have in mind are also going to be cutting-edge and I expect a bit of development and evolution to happen.

thanks

Suggestion: remove spanning tree

Is your feature request related to a problem? Please describe.
Not a problem exactly, but a bit of a design inconsistency. At present, the softstate branch only uses the spanning tree in snek next hop lookups, and only in cases where a snek path is not known. This is what makes the root reachable to the rest of the DHT, but outside of that 1 node it's strictly optional. Building and maintaining a spanning tree of the network (with per hop signatures) is a lot of extra work, and increases the potential attack surface, just to make 1 specific node reachable.

Describe the solution you'd like
Remove the spanning tree entirely, and replace it with broadcast snek bootstraps from the "root" (now a misnomer). Basically, if you try to look up a next hop for a bootstrap, and you don't find any snek path that would lead to a valid next address in keyspace, then send the snek bootstrap to all peers (minus the one you received it from).

Describe alternatives you've considered
You could keep using the spanning tree.

Additional context
This is something I've prototyped in ironwood. In the ironwood/yggdrasil context, we also use the tree to do opportunistic greedy routing through treespace, so we have a good reason to maintain and use all that extra hard state, which is why I'm not going this direction in my own project for now. Pinecone doesn't use greedy routing through treespace, and (as far as I've heard) has no immediate plans to implement that. If you're not explicitly using the tree as a tree (and just using it as a way to ensure the root is reachable), then there's no technical reason why you couldn't remove it.

There are a number of benefits to removing the tree:

1. The code is simpler. In my code base, there was maybe a dozen or so lines of code involved in broadcasting the "root" DHT bootstraps through the network, instead of forwarding them towards 1 other node. That can replace all of the tree related code. Pinecone may need slightly more code to handle this, or to slightly change some behaviors about how DHT state is stored to minimize the amount of "root"-specific / broadcast code. Either way, I think this will make the protocol much simpler to describe and re-implement for other homeservers.
2. This removes the remaining hard state. In particular, it means that pinecone would no longer have any protocol traffic which requires reliable or ordered transmission (even if both properties are still nice to have). That would make it safer to run over networks where ordering isn't guaranteed (bluetooth?) and may open the door to other transport protocols (e.g. even plain old UDP, if you can handle message fragmentation).
3. It's probably more secure. There are likely some attacks that a root could execute, which other nodes could not, due to the way the root is treated differently from all other nodes in the network (being reachable only because of the hard state tree). I'd rather not go into detail about these here, but suffice it to say that removing the tree solves basically all of these issues. To be honest, in the context of matrix-over-pinecone, this would cover every remaining attack that I know of that isn't addressable more easily on the matrix side.

There are also some potential disadvantages:

1. You don't have the tree, so you can't use opportunistic greedy routing through treespace. If that wasn't on the agenda anyway, then this is no real loss. The main incentive to use greedy routing through treespace is to reduce stretch. For the matrix-over-pinecone use case, I think that's largely not an issue, since most nodes will still probably have an internet connection available (so they can directly peer with the home servers they care about, and have one hop paths to those nodes).
2. The lack of a tree means you can't use "my treespace coordinates changed" as a lazy way for nodes to determine that they are likely to be mobile (in the "moving around the network" sense, not the "running on a phone" sense). That could be useful information to know, so you would need to find another way to detect it (maybe by monitoring how your node's descending path changes -- if it times out, then you may have become unreachable due to mobility, for example). As far as I know, this is also not something pinecone currently cares about.
3. It may be slightly more expensive or slightly less performant in mobile networks. I spent exactly 0 time trying to optimize that in my ironwood prototype, so it's something you'd probably need to look into and experiment with.

I may try to throw together a PR for this myself, if nobody else has interest / gets to it before me.

Difference between pinecone and pineconeip?

Hello,

I am trying to figure out how to test pinecone for a project but the documentation is not clear.

I have been able to use Go to compile the "cmd\pinecone\main.go" and "cmd\pineconeip\main.go" and the resulting pinecone.exe seems to start up while the pineconeip.exe gives a TUN error:

C:\Pinecone\pinecone>pinecone.exe
Router identity: 4d1748d19537ed4815c9cc31a4b729e04b9cc282bc2b9103c256f33ccc13934f
Listening on [::]:21978
Listening on [::]:21979
Listening for WebSockets on http://[::]:21980
Multicast discovery enabled on Ethernet 2 (fe80::932c:e6f2:ede6:f978)
Multicast discovery enabled on Wi-Fi (fe80::4f1c:8b27:237e:c34d)
Multicast discovery enabled on Wi-Fi (192.168.0.23)
Multicast discovery enabled on Ethernet 2 (192.168.56.1)

C:\Pinecone\pinecone>go build -o pineconeip.exe cmd\pineconeip\main.go
go: downloading golang.zx2c4.com/wireguard v0.0.0-20220703234212-c31a7b1ab478
go: downloading golang.zx2c4.com/wintun v0.0.0-20211104114900-415007cec224
# github.com/matrix-org/pinecone/cmd/pineconeip/tun
cmd\pineconeip\tun\tun.go:64:14: t.setup undefined (type *TUN has no field or method setup)

How can I start up multiple pinecone.exe instances and that those instances are in the same mesh and are communicating?

Can I perhaps start multiple instances and then ping between them or something?

What are some simple steps to do it?
Thanks in advance

Sim Feature: Can configure maximum sim node/connection limits

When launching the simulator, it would be nice to be able to specify a max number of nodes and/or connections supported.
This is useful when hosting the simulator for other people to prevent excessive resource usage.
This should also include ui updates to ensure it is clear to the user when they can no longer add new nodes/connections.

Unexpected EOF on uTP sessions

We've seen this a few times on the WASM demo when dialling federation requests. This probably shouldn't happen as we should just start a new uTP session?

Sim Bug: Starting Play/Pause state should reflect the sim state

When starting the ui, the play/pause always starts with a preset state. This should be changed to start with the actual play/pause state of the simulator at that time.
This should include adding the play/pause state to simulator update packets as well as the starting state packet sequence.

Integrating with libp2p

I was very excited to read in https://matrix.org/blog/2021/05/06/introducing-the-pinecone-overlay-network

If Pinecone works out, our intention is to collaborate with the libp2p and IPFS team to incorporate Pinecone routing into libp2p (if they'll have us!) while incorporating their gossipsub routing to improve Matrix federation... and get the best of both worlds :)

and was wondering whether there are steps to take earlier, before one knows "whether Pine works out", to optimistically prepare for that integration ahead of time while not hurting (and ideally helping) development now.

For example, maybe there are deps from https://github.com/libp2p/go-libp2p/blob/master/go.mod that would help here?

Support Meshtastic/LoRa as a transport

Meshtastic is an open source, off-grid, decentralized, mesh network built to run on affordable, low-power devices.

It seems like a perfect fit for pinecone. It can work up to very long ranges (kilometers are pretty easy to hit) and already has users for testing and relays. It seems to be similar to a BLE mesh network.

It would be a great demo/PoC to run pinecone on top of Meshtastic

Dropped static peer connections may not re-establish properly

If you specify a static peer and the connection is interrupted, it seems that we don't always manage to retry a connection. We should look into why that is.

connection from a LAN machine to WAN machine trouble

Hello,

I am testing pinecone connections at the moment on a Windows (LAN) machine and a Linux (WAN) vps with public IP.

Up till now, I have been able to connect multiple local Windows LAN <-> Windows LAN machines with no trouble, but when connecting

Linux LAN<->Windows LAN
and
Windows LAN<->Linux WAN

systems then pinecone does not seem to connect.

Any thoughts

[FR] “Sparse” peerings

What

Peerings with “sparse” status, an explicit opt in on both sides go allow a connection more low-throughput, high-latency, more unreliable, or with less duty cycles than the current pinecone peerings require.

Why

Primarily, iot devices, to allow for power savings, yet stay connected to the network at times, allowing peers at the other side of the sparse connection to queue up packets and send them through whenever the underlying transport allows.

Secondly, resiliency in unreliable conditions, where a peer wants to accept high-latency costs, at the benefit of not becoming disconnected from the network at large. (Think remote outposts in unfavourable weather conditions resulting in unreliable uplinks, or network operators in hostile environments requiring prolonged connectivity over intermittent outages)

Usage question

Hello,

I am looking at various Golang project for a massively scaling P2P project. For this work, I have been looking at:

Pinecone
Yggdrasil
Go-Libp2p

and others if I can find them, but so far these "seem" to be the best for what I need.

I am wondering if Pinecone can be compiled in as a library for the core application that I am making of which part of it will have a DHT for some KV data passing for consistency.

Can Pinecone be compiled in as a library?

Would it make sense to use Wireguard and Pinecone together?

Hello,

I am researching mesh networks like Yggdrasil and QuantumGate that can pass packets through other nodes across multiple hops to deliver the packets.

This made me wonder about the possibility of marrying Pinecone with Wireguard as it seems to have the best performance available.

Any thoughts?

Switch local peer discovery to multicast DNS

That way we can take advantage of the NetService APIs on iOS and don't need specific multicast entitlements. It's also a well-known and well-understood standard.

Abuse resistance

(I wrote about this long ago in a matrix room, but someone reminded me to record it here.)

Would be nice to specifically record the possible attack scenarios and how pinecone handles, planned to handle, should handle or fail to handle them. Possibly it is an useful detail whether something depends on the protocol itself, or on an implementation detail which SHOULD be considered and specified.

Suggestions:

• single point flood (DoS)
• distributed flood (DDoS)
• abusive connections to the network
• deliberate/repeated splitting, joining
• nodes dropping, corrupting traffic (especially bootstrap)

(Some or all could be invalid or already described; some of them indeed are described in the wiki but isn't centrally collected. And possibly many more should be added.)

Sim Feature: Add the simulator view into the URL anchor

Currently refreshing the page when viewing the simulator results in being returned to the physical peer view.
Refreshing the page should result in returning to the previous view of the simulation.

Passing data through pinecone

Hello All and @neilalexander

I am exploring Pinecone again and am able to set up connections between a few nodes.

If I understand correctly, then pinecone functions sin a "similar" but a bit different way than Yggdrasil but pinecone also will self-adjust and change its routing for which I am guessing that this implies that it can do datagram/packet relays through some nodes to get the data to a destination node. Is this correct?

Also, now that I have the ability to make connections and start forming a relay mesh network, what is a simple way to test sending a message or packet to a node that would normally not be reachable if pinecone was not active?

For this, I am just seeking to determine if packets are being sent through pinecone in the overlay network.

Any guidance would be appreciated.
Thanks

Nameing conflict with commercial product called PineCone made by Pine64

In Matrix Live S07E01 Matthew mentioned this repo, but you guys seem to have overlooked that there is a nameing conflict with a commercial product called PineCone which is made by Pine64. Links to Pine64 Wiki and Store for reference: https://wiki.pine64.org/wiki/PineCone https://pine64.com/product/pinecone-bl602-evaluation-board/

Simulator UI can optionally specify node priv key when creating new nodes

When creating a new node instance in the simulator it would be beneficial to be able to optionally specify the node's private key.
This would allow for more reproducible event sequences and further testing.
One such use case would be to test what happens when two nodes are using the same keypair.

Algorithm description: Spanning tree parent selection

Overview

Hi, thank you for this awesome algorithm and this detailed description! During my attempt at writing an implementation of this algorithm I came across small inconsistency in algorithm description (spanning tree part)

Short description

When node receives a root-update it has already received (with the same public key and root sequence), but from another peer (after reparent timer), it runs parent selection algorithm. And this parent selection algorithm returns no suitable parent and the node switches it's state to root!

But I think that staying as a regular node without updating our parent is the right option!

And I think that iterating over the list of latest root announcements from all peers is not even necessary!

Long description

Consider following topology where

  B
 /|
A |
 \|
  C

which means that every node has all other nodes as it peers

Let's assume that public keys are ordered the same way as the nodes are named (which means A.public_key < B.public_key)

And let's assume the C is root and A and B are regular nodes. C sends root update to A and B. A receives valid root update from parent with higher root sequence and stays in the same state with the same parent and sends this root update to B

Then two situations can happen:

1. B receives root update from A faster than it receives it from C:
   In that case, B sets A as a parent, then it receives update from C it runs parent selection algorithm

2. B receives root update from C faster than it receives it from A:
   In that case B sets C as a parent, and then when it receives update from A, it runs parent selection algorithm

Let's run the parent selection!

I'll run this for the first case, because for the second it is exactly the same, just switch C and A

Legend:

B node already has these fields

• B.root_public_key = C.public_key
• B.root_sequence = 1

And B has received update from A, let's call it update_from_a
This update has fields

• update_from_a.public_key = C.public_key
• update_from_a.root_sequence = 1

And it was received at 12ms, let's store it inside update

• update_from_a.received_at = 12ms

And now B receives update from C, let's call it update_from_c
This update has fields

• update_from_c.public_key = C.public_key
• update_from_c.root_sequence = 1

And it was received at 15ms (3ms later than update from A), let's store it inside update

• update_from_c.received_at = 15ms

---

Running the algorithm

We start with the

best_public_key = C.public_key;
best_root_sequence = 1;
best_timestamp = 12;
best_candidate = empty

And we iterate peers A and C

Iteration over A

1. Does last root announcement received from this peer exceed the announcement timeout interval? No
2. Does the last root announcement received from this peer include our own public key in the Signing public key field of any of the signatures? No
3. Is the Root public key of the last peer update higher than the best key? No
4. Is the Root public key of the last peer update lower than the best key? No
5. Is the Root sequence of the last peer update higher than the best sequence? No
6. Is the Root sequence of the last peer update lower than the best sequence? No
7. Was the last peer update received before the best candidate? No

We stay with exactly the same best candidate as before

Iteration over C

1. Does last root announcement received from this peer exceed the announcement timeout interval? No
2. Does the last root announcement received from this peer include our own public key in the Signing public key field of any of the signatures? No
3. Is the Root public key of the last peer update higher than the best key? No
4. Is the Root public key of the last peer update lower than the best key? No
5. Is the Root sequence of the last peer update higher than the best sequence? No
6. Is the Root sequence of the last peer update lower than the best sequence? No
7. Was the last peer update received before the best candidate? No

So no best candidate was found, and we switch state to root (according to the docs)

---

Suggestions and questions!

Question about having no best candidate result in parent selection

Can you provide any situation where this is possible?
I thought that this can happen when the node didn't receive any root update in last 45 minutes, but the parent selection is triggered when the node has just received the root update.

Suggestion about iteration

Instead of iterating through all the peers, we can compare received root update to the root update we have just received from our parent:

• If we switch parent, we schedule sending root update to other peers (and unschedule all previously scheduled root updates)

• If we do not switch parent, we do nothing

endless "Multicast discovery enabled"

Describe the bug

I'm guessing it should only be enabled once per interface.

[...]
INFO[2021-05-06T16:22:09.098191182Z] [/build/source/cmd/dendrite-demo-pinecone/main.go:270] func8
         Sending wake-up message to known nodes
Connected port 1 to 104.20.201.37:443 (zone "static")
New coordinates: [1]

Multicast discovery enabled on docker0 (172.17.0.1)
Multicast discovery enabled on virbr0 (192.168.122.1)
Multicast discovery enabled on br-9b3256d96abe (172.18.0.1)
Multicast discovery enabled on virbr0 (192.168.122.1)
Multicast discovery enabled on docker0 (172.17.0.1)
Multicast discovery enabled on br-9b3256d96abe (172.18.0.1)
Multicast discovery enabled on docker0 (172.17.0.1)
Multicast discovery enabled on virbr0 (192.168.122.1)
Multicast discovery enabled on br-9b3256d96abe (172.18.0.1)
Multicast discovery enabled on virbr0 (192.168.122.1)
Multicast discovery enabled on docker0 (172.17.0.1)
Multicast discovery enabled on br-9b3256d96abe (172.18.0.1)
Multicast discovery enabled on virbr0 (192.168.122.1)
Multicast discovery enabled on br-9b3256d96abe (172.18.0.1)
Multicast discovery enabled on docker0 (172.17.0.1)
Multicast discovery enabled on docker0 (172.17.0.1)
Multicast discovery enabled on br-9b3256d96abe (172.18.0.1)
Multicast discovery enabled on virbr0 (192.168.122.1)
Multicast discovery enabled on docker0 (172.17.0.1)
Multicast discovery enabled on virbr0 (192.168.122.1)
Multicast discovery enabled on br-9b3256d96abe (172.18.0.1)
Multicast discovery enabled on docker0 (172.17.0.1)
Multicast discovery enabled on virbr0 (192.168.122.1)
Multicast discovery enabled on br-9b3256d96abe (172.18.0.1)
Multicast discovery enabled on br-9b3256d96abe (172.18.0.1)
Multicast discovery enabled on docker0 (172.17.0.1)
Multicast discovery enabled on virbr0 (192.168.122.1)
Multicast discovery enabled on docker0 (172.17.0.1)
Multicast discovery enabled on virbr0 (192.168.122.1)
Multicast discovery enabled on br-9b3256d96abe (172.18.0.1)
Multicast discovery enabled on docker0 (172.17.0.1)
Multicast discovery enabled on virbr0 (192.168.122.1)
Multicast discovery enabled on br-9b3256d96abe (172.18.0.1)
[...]

To Reproduce
Steps to reproduce the behavior:

1. run dendrite-demo-pinecone -peer wss://pinecone.matrix.org/public

Expected behavior

Screenshots

Desktop (please complete the following information):

• OS: NixOS
• Version:

Additional context