Any reason for rolling a new p2p stack? 😅

[patrick-ogrady]

Source: https://x.com/peter_szilagyi/status/1821638941226987614?s=46&t=eGRNsJ9UUBdKbeXgtcMh9A

[patrick-ogrady]

commonware-p2p works differently than the other primitives I've looked at. I highlighted a few of the core features in the docs here: docs.rs/commonware-p2p

TL;DR it assumes:

1. all peers are connected to each other (or can at least message each other via a hosted but untrusted relay)
2. peers want to use their consensus identity as their peering identity (without some sort of translation to X.509 or Noise certs)
3. all peering messages need to be encrypted
4. only authorized peers are allowed to connect (using said consensus identity as the gating factor)
5. you never want to negotiate which protocol you'll use to communicate (there is one and you must use that)

As you know 😉, there are a TON of tradeoffs to make on the p2p layer and hope to create different "dialects" of commonware modules over time but figured I'd start with a unique approach that works best for building a fully-connected mesh that doesn't allow entry of random participants (best suited for deployment in high-capacity, low-latency chains -> any message is only one network hop from/to any participant).

Source: https://x.com/_patrickogrady/status/1821648842569478483?s=46&t=eGRNsJ9UUBdKbeXgtcMh9A

[patrick-ogrady]

some cool niceties:

1. automatic chunking of messages over multiple channels on the same connection (can limit the frame size to something small even for multi-MB messages)
2. configurable rate limiting of each user-defined channel
3. an application can prioritize sends across all channels (i.e. consensus messages can always go before any other type of message)

Source: https://x.com/_patrickogrady/status/1821649479281655932?s=46&t=eGRNsJ9UUBdKbeXgtcMh9A