THE PROJECT MAP:

Summer 2013. Somebody broke the Internet. Actually it was broken all the time, but now everybody knows it. We think there are several wonderful projects working to fix it. We painted a map of these projects and placed them according to the architectural space they seem to be filling (click to see at full-size):



Last Change: 2018-06-12

Color coding:

Green: Projects that are available today.
Dark green: Projects that are available, but aren't fully protective of metadata.
Blue: Projects in development.
Dark blue: Projects in development which will have little or no protection of metadata (but that doesn't mean they can't be an excellent piece in the general puzzle).
Yellow: Projects that may be okay but depend too much on the security of servers.
Orange: Products whose end-to-end encrypting client side has been open-sourced but whose server side remains proprietary (still the UIs may be very well worthwhile to re-use).
Red: Brands that currently occupy the respective layers with unsafe technology.
Dark red: Possibly cool but unsafe technologies that we need to replace.

Some projects appear on certain layers while leaving out others (in that case the beam passes under the grey box of the layer). The new Internet needs a complete GNU protocol stack equivalent to a connected light green beam across all layers, and then some more aspects that the map does not show.

Updates

Recent changes:
  • "Ethereum" has been replaced with the more generic term "Blockchain" to classify all projects applying 'Byzantine Consensus' on top of simple IP-based broadcasting.
  • "Secure Scuttlebutt" has been added to the group of projects using 'Opportunistic Replication', albeit without any metadata protection.
  • Matrix.org has been added to the box of legacy federation technologies.
  • pEp has moved on top of GNUnet.
  • Yoctoproject deserved mention for its adherence to reproducibility.
  • Netzpolitik, Wauland, NLnet and NGI have been added to the political layer.
  • EFF has been "downgraded" for their bad recommendations regarding MIME/PGP usability issues and metadata protection in messaging applications.

Projects that should be considered for inclusion:

  • PeerSM (DHT, blockchain and onion routing in Javascript over WebRTC)
  • Mathematical Mesh (special efforts to attain OpenPGP compliance, written in C#)

Known inaccuracies:

  • Since none of the Tor projects use 'Multicast + PubSub' for scalability, the entire Tor column on the left should move close to RetroShare and Briar which have both migrated to Tor for metadata protection and are both using 'Opportunistic Replication' as a basic scalability strategy.

Questions & Answers

Why so much focus on "social" ?

You could argue that the largest amount of traffic on the Internet is of social nature. Not just mail and chat, also web access traffic and file exchange follows patterns of popularity. When data becomes popular, a lot of people want to have it. The current Internet achieves scalability for social contents by massive use of cloud technology. A Next Generation Internet needs to compensate for the unviability of the cloud by using efficient decentralized distribution schemes.

A pubsub API on top of Multicast trees is scientifically known to be the fastest method, but some technologies prefer to optimize for file exchange (BitTorrent) or take a database replication approach. Some are on-demand- oriented like Maidsafe, whereas others replicate opportunistically like Retroshare. The latter approach has the drawback that you cannot subscribe to interesting content if your neighbors aren't interested in it and therefore won't store it for you.

Blockchain-like consensus technologies typically use a near-broadcast mechanism which has plenty of overhead and can only scale when split into several streams the way Bitmessage does it.

Why the web browser? WebRTC? AJAX!?

Because the web browser is so overladen with surveillance functionality such as cookies, invisible counters, e-tags and plenty of Javascript doing what the server tells it to. See also WebRTC which relies on web servers for authentication and thus enables them to run a person-in-the-middle attack, and AJAX, which took off as the foundation of the web 2.0 and landed as a surveillance tool. Should we want to do web-based user interfaces, we'll have to use a custom browser with disabled HTTP support. Or at least disable third party object inclusion.

Why X.509, DNS, DANE, SMTP and XMPP federation?

X.509, the certification system behind HTTPS and S/MIME, is broken and allows most governments and even many companies to run man in the middle attacks on you. The trust chain between the cryptography and the domain names is corrupt. Even if DNSSEC and DANE try to improve the security of DNS, they still expose your interest for certain resources. SMTP is so hopeless, you shouldn't even use it with PGP and XMPP fundamentally has the same problems: as long as all involved servers know all about who is talking to whom, it is already by far too much exposed knowledge — even if the mere encryption of the connection, which again depends on X.509, hasn't been undermined by a man in the middle, which is hard to find out if there is no human intervention and no reporting to the actual users when servers pass messages between each other.

Why IRC? NNTP!?

They're historic. It is about time they get superceded but it hasn't happened yet. No multicast technology has come to take their place. But you can have cloud services instead.

Why Intel ME?

Read about "Active Management Technology" and you'll understand.

Why BATMAN and OLSR?

They're amazing stuff. Real works of art. Unbeaten at what they do. But they are unencrypted and as easy to subdue as a walnut.

Disagree?

Meet us on the platforms mentioned on the start page to discuss the details if you disagree.

Credits

Thanks to enki without whom this map would've been impossible to fit on a screen.