So much this. Please don't call this IP. We already have an Internet Protocol and this project seems to work as a layer on top of it, much like a P2P-VPN.
I'm all for funny names but this one seems like it would just cause more confusion than it's worth. The fact that they list it as the sole FAQ probably means that many folks have been confused.
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.
A lot of valid criticism (the name, lack of specs, poor development support). Still I want to give this one the benefit of a doubt! It's from the Tribler folk[1], who have long long been doing by-far the most interesting & practical P2P work on the planet for well over a decade, notably around Bittorrent extensions on everything from fairness, to high durability, to search (by far some of the best/first to really get a win here in Bittorrent space), video on demand, & live-streaming (again a massive early pioneer that very much succeeded, albeit with low adoption). Recently some of their (longstanding) work on trying to add better economic/game-theory incentives in bitctorrent (far beyond simple private trackers with ratio limits) was on HN too[2][3].
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.
It's not even the first IPv8. There was an IPv8 doing the rounds in the late 1990's for a while. I had some trouble finding references, but I think this is the sanitized version:
https://tools.ietf.org/html/draft-terrell-ip-spec-ipv7-ipv8-...
I have fond memories of reading about how stargates, galaxy routers etc, etc were going to solve all our problems. The IPv8 in the link is a far more pedestrian read.
I've been playing around with ipv8 recently (just for DS fun), and it definitely can work and is pretty cool. Unfortunate that it's currently Python-only, and the examples really lacked depth / practical coverage.
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.
Trying to ignore the name issue, what even is this? The security goals are totally unstated, the network routability goals are unstated. I dont see any links to an actual project objective.
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?
Came here to say this. The Libsodium dependency suggests they're using bog standard cryptography that should be easy to implement in a gazillion contexts (which is great). But we do need a spec so independent implementations can arise.
It doesn't really matter. What does is the process: how their protocol came into being.
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.
Very good points. I suggested the RFC because it usually forces you to think about those very things. What is the protocol? What do you need to make it work? How do you setup a call? How do you tear one down? What bits are in the payloads? Which side has which responsibility? What happens when there is an error? What sort of errors should I expect as a client/server? What if the other side is a different endianness?
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.
Hmm, the RFC process seems to cover more than my suggestion to do C. I'll revise my position slightly, and agree that we need to do something like an RFC at some point.
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.
Yeah, they probably should abstract and write it down at this point. 20 years is a long prototype :).
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.
Hopefully you still see this late reaction by IPv8/Tribler team. There is now Kotlin code, Android Trustchain app and expired IETF draft. On top of the pretentiously named IPv8 overlay, we now have tamper-proof accounting and trust function operational. Took a mere 20 years of my life:-)
If you can discover a peer who is willing to help and not behind NAT, they can act as your rendezvous server, and either relay traffic, help with NAT traversal, or help you find another peer that might help instead.
Skype did something like this when it first came out.
Only if you have no way of bootstrapping. There are numerous ways to get hold of some initial likely IPs. You only need one well-connected peer to start with, because they will tell you where to look next.
- 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.
GNUnet & RINA seem like two far more likely candidates for something that'd actually deserve eventually becoming IPv8. As others have said, naming this project that when it ain't even an IETF draft seems pretty daft.
Seems like an Android client and a distributed key value store with phone numbers tied to public keys is all you would need and probably an erlang app like that written for Whatsapp back in the day to build something useful from this.
Do we really need a separate IP-based protocol? I was thinking a protocol parallel to hyper-text transfer like https but upgraded with the features being proposed here.
I think a bit more as ambition. If a standards body doesn't want to rescue us from the surveillance state, is it surprising that someone hopes to do better?
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.
