IPv8: Authenticated Private P2P Communication
github.com
github.com
I hereby request that they change the project name to one of the not-too-perilous-but-frequently-selected-references-to-Monty-Python for a very silly name indeed.
IMHO, the libp2p specifications [0] are much more interesting.
I'd be cautious about disregarding these IPv8 efforts. As difficult as it is to wander into a single-language semi-documented thing that calls itself an Internet Protocol. I believe the future is exciting, and so should you, and sometimes that comes from humble (and hard to decypher) beginnings.
I ran into IPv8 about a month ago, but had to jog my memory. There is very much some seeming overlap with other p2p overlay networking, like I2P, EdgeVPN, a more general purpose WireGuard. I too am curious about differentiation / comparison.
[1] https://news.ycombinator.com/from?site=github.com/tribler
[2] https://github.com/Tribler/tribler/wiki#tribler-an-attack-re...
Biggest complaint: The wire object serialization for messages was a major PITA and I ended up resorting to packing everything into a single JSON-encoded string.
On the topic of distributed secure networks, I've continued on to combing through 0x-mesh, which is compelling to me because it's go and they've reused other open source libs as much as possible. A neatt approach with some higher level facilities compared to ipv8.
It sounds like an encrypted overlay network over the internet. Does it even aim to provide anonyminity? Is it just an abstraction over network addresses to replace DNS and do NAT hole-punching? Something else? What even is the goal here?
This kind of thing really benefits from a clear explanation of how it works.
That being said, https://py-ipv8.readthedocs.io/en/latest/reference/serializa... seems to provide at least part of what we need.
If they just did what was most convenient to implement in Python, that can easily have a huge negative impact: a good protocol has to take into account all the complexity, not just the ease of picking up whatever is on Python's very comprehensive standard library.
For instance, would you serialise your messages in JSON? It sure is convenient. Works with many languages. You can send out text streams, or even binary streams if you encode them in base64. Though it takes some space, so you might want to compress the whole thing before you send it. Possibly over an HTTP tunnel, there are lots of HTTP client & server implementations out there. And all of a sudden you are depending on JSON, gzip, and some http stack. Which is crazy.
If you start from the wire format, and make sure it is as simple as possible, you will get simplicity for most implementations, without dragging it huge dependencies just because it was convenient, you will get performance because you're not wasting your time juggling between formats and compression and whatnot, and you will get security because your stack just got much smaller.
What I fear about IpV8 is that it appears to be Python only. Which is a strong clue that this protocol wasn't designed, but grown on top of what Python provides. At the very least, we need a C implementation with no third party dependency to measure the true complexity of the protocol, and maybe simplify whatever needs to be simplified. I know, C is a underpowered, unsafe language. That's kind of the point: if the C implementation itself is simple, then we know this protocol can be implemented in anything.
Starting in python is not a bad one to do. I think it is a great prototype language. Your suggestion of going to something simpler like C is not a bad idea. It would shake out those dependencies they did not know they had. Python is sneaky about that, as it has some very nice tools just to manage its own data (looking at you dictionaries). But those same tools do not exist in C without some external lib or extra code.
I also agree with starting with a prototype in whatever high level language you have. Python is a good prototype language. However, I see that the first commit is 20 years old? They should have outgrown Python by now.
Moving to C is not a bad idea at all. It would shake out those issues. The RFC bit is more to get it so you can rip it apart and do the thing in any language. I have done a few of these sorts of things over the years. It is very easy to tie yourself to a particular language library without realizing it. Sometimes just writing down what bits go back and forth and responsibility helps shake out those oddities. If I were doing it I would probably start with a port with something like C just so I could understand what is really needed and what is cruft. Then doc it into the RFC format as I went along.
[1] https://github.com/Tribler/kotlin-ipv8/ [2] https://github.com/Tribler/trustchain-superapp [3] https://tools.ietf.org/id/draft-pouwelse-trustchain-01.html [4] https://dicg2020.github.io/papers/devos.pdf
I'm a bit confused about this claim:
>No infrastructure dependency
How is this possible? To pierce NAT you need a rendezvous server at the least.
Skype did something like this when it first came out.
- Hard-code some bootstrap IPs of contributors who agreed to that in the shipped software. The list can be updated with each new release. Even if the list has some wrong entries, it doesn't matter.
- Hard-code some bootstrap DNS names of contributors who agreed to host IP lists. Even if the DNS list has some wrong entries, it doesn't matter.
- Multicast locally in search of neighbours. Not available on all networks, but works on some.
- Encourage users with active, long-lived nodes, to register themselves on some well known service belonging to someone else, for example any of the free DNS services, DynDNS etc. and hard-code these well-known locations in the software.
- Encourage users with active, long-lived nodes, to publish endpoint information somewhere that will be indexed by Google, Bing, Duck Duck Go etc. such that a search by a client with the right string will find these in results.
- Have people publish long-lived node info to Freenode IRC, Discord, Slack, Google Groups, etc.
- Don't hard-code or encourage anything, just tell the users "find someone with an active peer" and leave users to find someone by whatever means works for them. This seems best for robustness, in places where the internet might be blocked or you depend entirely on a mesh network, even if it's more work for individuals. To ensure this route is always available, make sure your software has an option to specify bootstrap addresses, even if it has something hard-coded as well.
- You can also, as you say, scan random IPs, and also random DNS names. This is not as heavyweight as it sounds. Once the network has a good number of peers, the number of random IPs you need to try to find just one active peer diminishes. You would improve on that by using topological information, reverse DNS hints, try to detect when you are probing a whole block of IPs that are all behind NAT (so skip the whole block), and ideally have encouraged the best connected peers to publish a DNS record indicating availability.
At some level there is always infrastructure. But it doesn't have to by your own infrastructure.
I look forward to a real IPv8 standard that respects user privacy, but I look forward to it in a way that recognizes that it's pretty damn unlikely at this point.