The Hidden Drawbacks of P2P (And a Defense of Signal)

Online Life, , ,

Not long ago, I posted a roundup of secure messengers with off-the-grid capabilities. Some conversation followed, which led me to consider some of the problems with P2P protocols.

P2P and Privacy

Brave adopting IPFS has driven a lot of buzz lately. IPFS is essentially a decentralized, distributed web. This concept has a lot of promise. But take a look at the IPFS privacy document. Some things to highlight:

  • “Nodes announce a variety of information essential to the DHT’s function — including their unique node identifiers (PeerIDs) and the CIDs of data that they’re providing — and because of this, information about which nodes are retrieving and/or reproviding which CIDs is publicly available.”
  • “those DHT queries happen in public. Because of this, it’s possible that third parties could be monitoring this traffic to determine what CIDs are being requested, when, and by whom.”
  • “nodes’ unique identifiers are themselves public…your PeerID is still a long-lived, unique identifier for your node. Keep in mind that it’s possible to do a DHT lookup on your PeerID and, particularly if your node is regularly running from the same location (like your home), find your IP address…Additionally, longer-term monitoring of the public IPFS network could yield information about what CIDs your node is requesting and/or reproviding and when.”

So in this case, you have traded giving information about what you request to specific sites to giving it to potentially hundreds of untrusted peers, some of which may be logging this for nefarious purposes. Worse, you have a durable PeerID that can be used for tracking and tied to your IP address — a data collector’s dream. This PeerID, combined with DHT requests and the CIDs (Content ID) of the things you host (implying you viewed them in the past), can be used to establish a picture of what you are requesting now and requested recently.

Similar can be said from everything like Scuttlebutt to GNU Jami; any service that operates on a P2P basis will likely reveal your IP, and tie your identity to it (and your IP address history). In some cases, as with Jami, this would be limited to friends you add; in others, as with Scuttlebutt and IPFS, it could be revealed to anyone.

The advantages of P2P are undeniable and profound, but few are effectively addressing the privacy implications. The one I know of that is, Briar, routes all traffic over Tor; every node is reached by a Tor onion service.

Federation: somewhat better

In a federated model, every client connects to a server, and there are many servers participating in a federation with each other. Matrix and Mastodon are examples of a federated model. In this scenario, only one server — your own homeserver — can track you by IP. End-to-end encryption is certainly possible in a federated model, and Matrix supports it. This does give a third party (the specific server you use) knowledge of your IP, but that knowledge can be significantly limited.

A downside of this approach is that if your particular homeserver is down, you are unable to communicate. Truly decentralized P2P solutions don’t have that problem — thought they do have a related one, which is that clients communicating with each other must both be online simultaneously in order for messages to be transmitted, and this can be a real challenge for mobile devices.

Centralization and Signal

Signal is centralized; it has one central server farm, and if it is down, you can’t communicate or choose any other server, either. We saw it go down recently after Elon Musk mentioned it.

Still, I recommend Signal for the general public. Here’s why.

Signal brings encryption and privacy to meet people where they’re at, not the other way around. People don’t have to choose a server, it can automatically recognize contacts that use Signal, it has emojis, attachments, secure voice and video calling, and (aside from the Musk incident), it all just works. It feels like, and is, a polished, modern experience with the bells and whistles people are used to.

I’m a huge fan of Matrix (aka Element) and even run my own instance. It has huge promise. But it is Not. There. Yet. Why do I saw this about Matrix?

  • Synapse, the only currently viable Matrix server, is not ready. My Matrix instance hosts ONE person, me. Synapse uses many GB of RAM and 10+GB of disk space. Despite extensive tuning, nothing helped much. It’s caused OOMs more than once. It can’t be hosted on a Raspberry Pi or even one of the cheaper VPSs.
  • Now then, how about choosing a Matrix instance? Well, you could just tell a person to use matrix.org. But then it spent a good portion of last year unable to federate with other popular nodes due to Synapse limitations. Or you could pick a random node, but will it be up when someone needs to say “my car broke down?” Some are run from a dorm computer, some by a team in a datacenter, some by one person with EC2, and you can’t really know. Will your homeserver be stable and long-lived? Hard to say.
  • Voice and video calling are not there yet in Matrix. Matrix has two incompatible video calling methods (Jitsi and built-in), neither work consistently well, both are hard to manage, and both have NAT challenges.
  • Matrix is so hard to set up on a server that there is matrix-docker-ansible-deploy. This makes it much better, but it is STILL terribly hard to deploy, and very simple things like “how do I delete a user” or “let me shrink down this 30GB database” are barely there yet, if at all.
  • Encryption isn’t mandatory in Matrix. E2EE has been getting dramatically better in the last few releases, but it is still optional, especially for what people would call “group chats” (rooms). Signal is ALWAYS encrypted. Always. (Unless, I guess, you set it as your SMS provider on Android). You’ve got to take the responsibility off the user to verify encryption status, and instead make it the one and only way to use the ecosystem.

Again, I love MAtrix. I use it every day to interact with Matrix, IRC, Slack, and Discord channels. It has a ton of promise. But would I count on it to carry a “my car’s broken down and I’m stranded” message? No.

How about some of the other options out there? I mentioned Briar above. It’s fantastic and its offline options are novel and promising. But in common usage, it can’t deliver a message unless both devices are online simultaneously, and doesn’t run on iOS (though both are being worked on). It also can’t send photos or do voice or video calling.

Some of these same limitations apply to most of the other Signal alternatives also. either that, or they are encryption-optional, or terribly hard to set up and use. I recently mentioned Status, which shows a ton of promise, but has no voice or video calling capabilities. Scuttlebutt is a fantastic protocol with extremely difficult onboarding (lengthy process, error-prone finding a pub, multi-GB initial download, etc.) And many of these leak IP addresses as discussed above.

So Signal gives people:

  • Dead-simple setup
  • Store-and-forward delivery (devices need not be online simultaneously)
  • Encrypted everything, including voice and video calls, and the ability to send photos and video encrypted

If you are going to tell someone, “it’s so EASY to get your texts away from Facebook and AT&T”, then Signal is the thing you’ve got to point them to. It may not be in two years, but for now, it is. Do not let the perfect be the enemy of the good. It advances the status quo without harming usability, which nothing else does yet.

I am aware of all of the very legitimate criticisms of Signal. They are real and they are why I am excited that there are so many alternatives with promise, some of which I use actively. Let us technical people use, debug, contribute to, and evangelize the alternatives.

And while we’re doing that, tell Grandma to contact us on Signal.

39 thoughts on “The Hidden Drawbacks of P2P (And a Defense of Signal)”

  1. @jgoerzen This reminds me: I’d be interested in integrating peer-to-peer hosting into some of my projects to help more people publish online outside of GAFAM, but I don’t know who to trust to seriously consider privacy. I don’t understand the necessary tradeoffs well enough!I guess I’ll continue pushing that off…

    Reply

  14. > “Signal brings encryption and privacy to meet people where they’re at, not the other way around. People don’t have to choose a server, it can automatically recognize contacts that use Signal, it has emojis, attachments, secure voice and video calling, and (aside from the Musk incident), it all just works. It feels like, and is, a polished, modern experience with the bells and whistles people are used to.”

    Quicksy offer EXACTLY the same functionalities but it’s federated and standardized, based on XMPP : you can discuss with people that are not using Quicksy and its services, people outside Quicksy even can link their address to their phone to make it automatically recognize as contacts using quicksy/XMPP

    And instead of Matrix, Quicksy IT IS THERE YET :

    https://play.google.com/store/apps/details?id=im.quicksy.client

    Reply

    2. Last I used XMPP, a few years ago, there were real problems with delivering notifications to the correct devices and with not having history synced between devices. Jingle was also a nightmare. Are things better now?

      Reply

      1. Short answer: Yes.

        Long answer: You need to use a good client, such as Conversations or Quicksy on Android, and Gajim (>= 1.1.2) or Dino (>= 0.2.0) on the desktop etc. Not Pidgin nor Thunderbird, please.

        This is probably the same problem with Signal: If you are using some random client, you might run into problems.

        I assume, you can use a debian.org XMPP account, but most servers should be pretty OK nowadays.

        Reply

  16. @jgoerzen nice post. In my mind the main problem with Matrix is metadata. Any of the federated servers your communication travels through has it – who, with whom, when.Regarding Signal limitations and conversely P2P messengers needing both ends to be online simultaneously: Session addresses that. While not as well-rounded for normies, it’s already easy enough to use and has most of the quality of life details that Signal does.

    Reply

  21. 1. [__Element__](https://twitter.com/element_hq/status/1355290296947499013)
    [(883 comments)](https://news.ycombinator.com/item?id=25964226)

    2. [__CDC website built by Deloitte at a cost of $44M is abandoned due to bugs__](https://www.technologyreview.com/2021/01/30/1017086/cdc-44-million-vaccine-data-vams-problems/)
    [(507 comments)](https://news.ycombinator.com/item?id=25975110)

    3. [__Docker, Django, Traefik, and IntercoolerJS: My go-to stack for building a SaaS__](https://www.simplecto.com/docker-django-traefik-intercoolerjs-is-my-stack-for-2021/)
    [(252 comments)](https://news.ycombinator.com/item?id=25973242)

    4. [__Drawbacks of P2P and a defense of Signal__](https://changelog.complete.org/archives/10216-the-hidden-drawbacks-of-p2p-and-a-defense-of-signal)
    [(139 comments)](https://news.ycombinator.com/item?id=25976439)

    5. [__Personal experiences bridge moral and political divides better than facts__](https://www.pnas.org/content/118/6/e2008389118)
    [(138 comments)](https://news.ycombinator.com/item?id=25963589)

    6. [__Regular afternoon naps linked to improved cognitive function__](https://www.sciencefocus.com/the-human-body/afternoon-naps-linked-to-improved-cognitive-function/)
    [(128 comments)](https://news.ycombinator.com/item?id=25972342)

    7. [__A network analysis on cloud gaming: Stadia, GeForce Now and PSNow__](https://arxiv.org/abs/2012.06774)
    [(124 comments)](https://news.ycombinator.com/item?id=25972846)

    8. [__My 90s TV: Browse 90s Television__](https://my90stv.com)
    [(111 comments)](https://news.ycombinator.com/item?id=25973955)

    9. [__How to Turn an IKEA Coffee Table into a DIY Server Rack__](https://wiki.eth0.nl/index.php/LackRack)
    [(81 comments)](https://news.ycombinator.com/item?id=25978013)

    10. [__A vast web of vengeance__](https://www.nytimes.com/2021/01/30/technology/change-my-google-results.html)
    [(74 comments)](https://news.ycombinator.com/item?id=25972121)

    11. [__Chronicles of a Bubble Tea Addict__](https://www.newyorker.com/culture/personal-history/chronicles-of-a-bubble-tea-addict)
    [(65 comments)](https://news.ycombinator.com/item?id=25975428)

    12. [__Software Verification and Analysis Using Z3__](https://research.nccgroup.com/2021/01/29/software-verification-and-analysis-using-z3/)
    [(39 comments)](https://news.ycombinator.com/item?id=25973194)

    13. [__RV64X: A Free, open-source GPU for RISC-V__](https://www.eetimes.com/rv64x-a-free-open-source-gpu-for-risc-v/)
    [(35 comments)](https://news.ycombinator.com/item?id=25974757)

    14. [__Crun: Fully featured OCI runtime and C library for running containers__](https://github.com/containers/crun)
    [(30 comments)](https://news.ycombinator.com/item?id=25976982)

    15. [__Teaching a Bayesian spam filter to play chess__](http://dbacl.sourceforge.net/spam_chess-1.html)
    [(22 comments)](https://news.ycombinator.com/item?id=25970502)

    16. [__NumPy 1.20__](https://numpy.org/doc/1.20/release/1.20.0-notes.html)
    [(20 comments)](https://news.ycombinator.com/item?id=25977977)

    17. [__How does Clang 2.7 hold up in 2021?__](https://gist.github.com/zeux/3ce4fcc3a43072b4315abde95319ecb6)
    [(20 comments)](https://news.ycombinator.com/item?id=25976855)

    18. [__TeaVM: Build Fast, Modern Web Apps in Java__](http://teavm.org/)
    [(13 comments)](https://news.ycombinator.com/item?id=25978053)

    19. [__Show HN: alsa_rnnoise is a HQ noise filter for ALSA, powered by Xiph.Org RNNoise__](https://sr.ht/~arsen/alsa_rnnoise/)
    [(12 comments)](https://news.ycombinator.com/item?id=25978111)

    20. [__An Archeologist’s Guide to Beer Cans__](https://daily.jstor.org/an-archeologists-guide-to-beer-cans/)
    [(12 comments)](https://news.ycombinator.com/item?id=25976183)

    21. [__RFC 8959: The “secret-token” URI Scheme__](https://www.rfc-editor.org/rfc/rfc8959.txt)
    [(11 comments)](https://news.ycombinator.com/item?id=25978185)

    22. [__FM Reception with the GNU Radio Companion__](https://www.nutsvolts.com/magazine/article/fm-reception-with-the-gnu-radio-companion)
    [(7 comments)](https://news.ycombinator.com/item?id=25976599)

    23. [__Why I still Lisp__](https://mendhekar.medium.com/why-i-still-lisp-and-you-should-too-18a2ae36bd8)
    [(5 comments)](https://news.ycombinator.com/item?id=25978190)

    24. [__Building a personal data warehouse in Snowflake for fun and no profit__](https://www.thomasdziedzic0.com/blog/building-a-personal-data-warehouse-in-snowflake-for-fun-and-no-profit)
    [(3 comments)](https://news.ycombinator.com/item?id=25978000)

    25. [__Bringing Stack Clash Protection to Clang / x86__](https://blog.llvm.org/posts/2021-01-05-stack-clash-protection/)
    [(2 comments)](https://news.ycombinator.com/item?id=25977122)

    26. [__The Alan Turing Cryptography Competition__](https://www.maths.manchester.ac.uk/cryptography_competition/)
    [(0 comments)](https://news.ycombinator.com/item?id=25978394)

    27. [__Release__](https://www.workatastartup.com/jobs/41565)
    [(0 comments)](https://news.ycombinator.com/item?id=25978192)

    28. [__Respect Your Power Users__](https://tedium.co/2021/01/27/power-users-history/)
    [(0 comments)](https://news.ycombinator.com/item?id=25978396)

    29. [__A Model for Identity in Software__](https://christine.website/blog/identity-model-software-2021-01-31)
    [(0 comments)](https://news.ycombinator.com/item?id=25978511)

    30. [__Google union in turmoil following global alliance announcement__](https://www.theverge.com/2021/1/30/22256577/alphabet-workers-union-turmoil-global-alliance-announcement-google-cwa)
    [(0 comments)](https://news.ycombinator.com/item?id=25978665)

    http://dbacl.sourceforge.net/spam_chess-1.html
    http://teavm.org/
    https://arxiv.org/abs/2012.06774
    https://blog.llvm.org/posts/2021-01-05-stack-clash-protection/
    https://changelog.complete.org/archives/10216-the-hidden-drawbacks-of-p2p-and-a-defense-of-signal
    https://christine.website/blog/identity-model-software-2021-01-31
    https://daily.jstor.org/an-archeologists-guide-to-beer-cans/
    https://gist.github.com/zeux/3ce4fcc3a43072b4315abde95319ecb6
    https://github.com/containers/crun
    https://mendhekar.medium.com/why-i-still-lisp-and-you-should-too-18a2ae36bd8
    https://my90stv.com
    https://news.ycombinator.com/item?id=25963589
    https://news.ycombinator.com/item?id=25964226
    https://news.ycombinator.com/item?id=25970502
    https://news.ycombinator.com/item?id=25972121
    https://news.ycombinator.com/item?id=25972342
    https://news.ycombinator.com/item?id=25972846
    https://news.ycombinator.com/item?id=25973194
    https://news.ycombinator.com/item?id=25973242
    https://news.ycombinator.com/item?id=25973955
    https://news.ycombinator.com/item?id=25974757
    https://news.ycombinator.com/item?id=25975110
    https://news.ycombinator.com/item?id=25975428
    https://news.ycombinator.com/item?id=25976183
    https://news.ycombinator.com/item?id=25976439
    https://news.ycombinator.com/item?id=25976599
    https://news.ycombinator.com/item?id=25976855
    https://news.ycombinator.com/item?id=25976982
    https://news.ycombinator.com/item?id=25977122
    https://news.ycombinator.com/item?id=25977977
    https://news.ycombinator.com/item?id=25978000
    https://news.ycombinator.com/item?id=25978013
    https://news.ycombinator.com/item?id=25978053
    https://news.ycombinator.com/item?id=25978111
    https://news.ycombinator.com/item?id=25978185
    https://news.ycombinator.com/item?id=25978190
    https://news.ycombinator.com/item?id=25978192
    https://news.ycombinator.com/item?id=25978394
    https://news.ycombinator.com/item?id=25978396
    https://news.ycombinator.com/item?id=25978511
    https://news.ycombinator.com/item?id=25978665
    https://numpy.org/doc/1.20/release/1.20.0-notes.html
    https://research.nccgroup.com/2021/01/29/software-verification-and-analysis-using-z3/
    https://sr.ht/~arsen/alsa_rnnoise/
    https://tedium.co/2021/01/27/power-users-history/
    https://twitter.com/element_hq/status/1355290296947499013
    https://wiki.eth0.nl/index.php/LackRack
    https://www.eetimes.com/rv64x-a-free-open-source-gpu-for-risc-v/
    https://www.maths.manchester.ac.uk/cryptography_competition/
    https://www.newyorker.com/culture/personal-history/chronicles-of-a-bubble-tea-addict
    https://www.nutsvolts.com/magazine/article/fm-reception-with-the-gnu-radio-companion
    https://www.nytimes.com/2021/01/30/technology/change-my-google-results.html
    https://www.pnas.org/content/118/6/e2008389118
    https://www.rfc-editor.org/rfc/rfc8959.txt
    https://www.sciencefocus.com/the-human-body/afternoon-naps-linked-to-improved-cognitive-function/
    https://www.simplecto.com/docker-django-traefik-intercoolerjs-is-my-stack-for-2021/
    https://www.technologyreview.com/2021/01/30/1017086/cdc-44-million-vaccine-data-vams-problems/
    https://www.theverge.com/2021/1/30/22256577/alphabet-workers-union-turmoil-global-alliance-announcement-google-cwa
    https://www.thomasdziedzic0.com/blog/building-a-personal-data-warehouse-in-snowflake-for-fun-and-no-profit
    https://www.workatastartup.com/jobs/41565

    Reply
  24. Pingback: “Brave adopting IPFS has driven a lot of buzz lately. #IPFS is esse… | Dr. Roy Schestowitz (罗伊)
  25. Pingback: Links 31/1/2021: KDE Consistency and Bareflank 2.1 | Techrights

  28. Thank you for the very interesting thoughts about P2P messengers! Good ideas to think about and discuss!

    One comment about federation:

    “A downside of this approach is that if your particular homeserver is down, you are unable to communicate.”

    Not perfect, but: Many people have multiple email addresses (at least: private, work, maybe more), and so they can have multiple IM accounts. I have. This partially solves the communication problem, if one server is down.

    And one comment about Signal:

    If I recommend a chat progamme to my friends, colleagues or family, they somehow expect, that I would use the same system or would be reachable by it. But I can’t use Signal. It is not in Debian and I’m not a user of Android or iOS. The Signal desktop program seems to be not very usable. Maybe if the cross-platform Signal client Axolotl (axolotl.chat/) gets packaged for Debian, the situation might improve.

    Also, I live in the EU and I prefer a server in my legislation, which includes GDPR.

    And then there is the problem with the phone number as id, which Signal developers are still working on.

    So far, I was able to get friends and family, sometimes colleagues, to use Quicksy or Conversations (on Android) and SiskinIM or Monal (on iOS), so I can chat with them using Dino or Gajim (on Linux, both in Debian). Sure, those programs are not as polished as Signal – maybe because their funding is a joke compared to Actons 105 million USD – but not too bad.

    Btw. people can run a server (ejabberd or prosody, both in Debian) on inexpensive hardware.

    Reply

  30. Hi, I would like to mention Delta-Chat which is a decentralized group texting capable app, e2e encrypted, relying on emails. Si you choose your provider, you can host it yourself in a few clicks with YUNoHost or pick one off the shelf like Gandi.net to avoid GAFAM.

    Reply

  33. Note: This post is also available on my webiste, where it will be periodically updated.
    As I’ve been thinking and writing about privacy and decentralization lately, I had a conversation with a colleague this week, and he commented about how loss of privacy is related to loss of agency: that is, loss of our ability to make our own choices, pursue our own interests, and be master of our own attention.
    In terms of telecommunications, we have never really been free, though in terms of Internet and its predecessors, there have been times where we had a lot more choice. Many are too young to remember this, and for others, that era is a distant memory.
    The irony is that our present moment is one of enormous consolidation of power, and yet also one of a proliferation of technologies that let us wrest back some of that power. In this post, I hope to enlighten or remind us of some of the choices we have lost — and also talk about the ways in which we can choose to regain them, already, right now.
    I will talk about the possibilities, the big dreams that are possible now, and then go into more detail about the solutions.
    The Problems & Possibilities
    The limitations of “online”
    We make the assumption that we must be “online” to exchange data. This is reinforced by many “modern” protocols; Twitter clients, for instance, don’t tend to let you make posts by relaying them through disconnected devices.
    What would it be like if you could fully participate in global communities without a constant Internet connection? If you could share photos with your friends, read the news, read your email, etc. even if you don’t have a connection at present? Even if the device you use to do that never has a connection, but can route messages via other devices that do?
    Would it surprise you to learn that this was once the case? Back in the days of UUCP, much email and Usenet news — a global discussion forum that didn’t require an Internet connection — was relayed via occasional calls over phone lines. This technology remains with us, and has even improved.
    Sadly, many modern protocols make no effort in this regard. Some email clients will let you compose messages offline to send when you get online later, but the assumption always is that you will be connected to an IP network again soon.
    NNCP, on the other hand, lets you relay messages over TCP, a radio, a satellite, or a USB stick. Email and Usenet, since they were designed in an era where store-and-forward was valued, can actually still be used in an entirely “offline” fashion (without ever touching an IP-based network). All it takes is for someone to care to make it happen. You can even still do it over UUCP if you like.
    The physical and data link layers
    Many of us just accept that we communicate in a few ways: Wifi for short distances, and then cable modems or DSL for our local Internet connection, and then many people are fuzzy about what happens after that. Or, alternatively, we have 4G phones that are the local Internet connection, and the same “fuzzy” things happen after.
    Think about this for a moment. Which of these do you control in any way? Sometimes just wifi, sometimes maybe you have choices of local Internet providers. After that, your traffic is handled by enormous infrastructure companies.
    There is choice here.
    People in ham radio have been communicating digitally over long distances without the support of the traditional Internet for decades, but the technology to do this is now more accessible to anyone. Long-distance radio has had tremendous innovation in the last decade; cheap radios can now communicate over several miles/km without any other infrastructure at all. We all carry around radios (Wifi and Bluetooth) in our pockets that don’t have to be used as mere access points to the Internet or as drivers of headphones, but can also form their own networks directly (Briar).
    Meshtastic is an example; it’s an instant messenger that can form a mesh over many miles/km and requires no IP infrastructure at all. Briar is similar. XBee radios form a mesh in hardware, allowing peers to reach each other (also over many miles/km) with a serial or framed protocol.
    Loss of peer-to-peer
    Back in the late 90s, I worked at a university. I had a 386 on my desk for a workstation – not a powerful computer even then. But I put the boa webserver on it and could just serve pages on the Internet. I didn’t have to get permission. Didn’t have to pay a hosting provider. I could just DO it.
    And of course that is because the university had no firewall and no NAT. Every PC at the university was a full participant on the Internet as much as the servers at Microsoft or DEC. All I needed was a DNS entry. I could run my own SMTP server if I wanted, run a web or Gopher server, and that was that.
    There are many reasons why this changed. Nowadays most residential ISPs will block SMTP for their customers, and if they didn’t, others would; large email providers have decided not to federate with IPs in residential address spaces. Most people have difficulty even getting a static IP address in the first place. Many are behind firewalls, NATs, or both, meaning that incoming connections of any kind are problematic.
    Do you see what that means? It has weakened the whole point of the Internet being a network of peers. While IP still acts that way, as a practical matter, there are clients that are prevented from being servers by administrative policy they have no control over.
    Imagine if you, a person with an Internet connection to your laptop or phone, could just decide to host a website, or a forum on it. For moderate levels of load, they are certainly capable of this. The only thing in the way is the network management policies you can’t control.
    Elaborate technologies exist to try to bridge this divide, and some, like Tor or cjdns, can work quite well. More on this below.
    Expense of running something popular
    Related to the loss of peer-to-peer infrastructure is the very high cost of hosting something popular. Do you want to share videos with lots of people? That almost certainly is going to require expensive equipment and bandwidth.
    There is a reason that there are only a small handful of popular video streaming sites online. It requires a ton of money to host videos at scale.
    What if it didn’t? What if you could achieve economies of scale so much that you, an individual, could compete with the likes of YouTube? You wouldn’t necessarily have to run ads to support the service. You wouldn’t have to have billions of dollars or billions of viewers just to make it work.
    This technology exists right now. Of course many of you are aware of how Bittorrent leverages the swarm for files. But projects like IPFS, Dat, and Peertube have taken this many steps further to integrate it into a global ecosystem. And, at least in the case of Peertube, this is a thing that works right now in any browser already!
    Application-level “walled gardens”
    I was recently startled at how much excitement there was when Github introduced “dark mode”. Yes, Github now offers two colors on its interface. Already back in the 80s and 90s, many DOS programs had more options than that.
    Git is a decentralized protocol, but Github has managed to make it centralized.
    Email is a decentralized protocol — pick your own provider, and they all communicate — but Facebook and Twitter aren’t. You can’t just pick your provider for Facebook. It’s Facebook or nothing.
    There is a profit motive in locking others out; these networks want to keep you using their platforms because their real customers are advertisers, and they want to keep showing you ads.
    Is it possible to have a world where you get to pick your own app for sharing photos, and it works even if your parents use a different one? Yes, yes it is.
    Mastodon and the Fediverse are fantastic examples for social media. Pixelfed is specifically designed for photos, Mastodon for short-form communication, there’s Pleroma for more long-form communication, and they all work together. You can use Mastodon to read Pleroma content or look at Pixelfed photos, and there are many (free) providers of each.
    Freedom from manipulation
    I recently wrote about the dangers of the attention economy, so I won’t go into a lot of detail here. Fundamentally, you are not the customer of Facebook or Google; advertisers are. They optimize their site to keep you on it as much as possible so that they can show you as many ads as possible which makes them as much money as possible. Ads, of course, are fundamentally seeking to manipulate your behavior (“buy this product”).
    By lowering the cost of running services, we can give a huge boost to hobbyists and nonprofits that want to do so without an ultimate profit motive. For-profit companies benefit also, with a dramatically reduced cost structure that frees them to pursue their mission instead of so many ads.
    Freedom from snooping (privacy and anonymity)
    These days, it’s not just government snooping that people think about. It’s data stolen by malware, spies at corporations (whether human or algorithmic), and even things like basic privacy of one’s own security footage. Here the picture is improving; encryption in transit, at least at a basic level, has become much more common with TLS being a standard these days. Sadly, end-to-end encryption (E2EE) is not nearly as much, perhaps because corporations have a profit motive to have access to your plaintext and metadata.
    Closely related to privacy is anonymity: that is, being able to do things in an anonymous fashion. The two are not necessarily equal: you could send an encrypted message but reveal who the correspondents are, as with email; or, you could send a plaintext message over a Tor exit node that hides who the correspondents are. It is sometimes difficult to achieve both.
    Nevertheless, numerous answers exist here that tackle one or both problems, from the Signal messenger to Tor.
    Solutions That Exist Today
    Let’s dive in to some of the things that exist today.
    One concept you’ll see in many of these is integrated encryption with public keys used for addressing. In other words, your public key is akin to an IP address (and in some cases, is literally your IP address.)
    Data link and networking technologies (some including P2P)

    Starting with the low-power and long-distance technologies, I’ve written quite a bit about LoRA, which are low-power long-distance radios. They can easily achieve several miles/km while still using much less than 1W of power. LoRA is a common building block of mesh off-the-grid messenger systems such as meshtastic, which forms an ad-hoc mesh of LoRA devices with days-long battery life and miles-long communication abilities. LoRA trades speed for bandwidth; in its longest-distance modes, it may operate at 300bps or less. That is not a typo. Some LoRAWAN devices have battery life measured in years (usually one-way sensors and such). Also, the Pine64 folks are working to integrate LoRA on nearly all their product line, which includes single-board computers, phones, and laptops.
    Similar to LoRA is XBee SX from Digi. While not quite as long-distance as LoRA, it does still do quite a bit with low power and also goes many miles. XBee modules have automatic mesh routing in firmware, and can be used in either frame mode or “serial cable emulation” mode in which they act as if they’re a serial cable. Unlike plain LoRA, XBee radios do hardware retransmit. They also run faster, at up to about 150Kbps – though that is still a lot slower than wifi.
    I’ve written about secure mesh messengers recently. One of them, Briar, particularly stands out in that it is able to form an ad-hoc mesh using phone’s Bluetooth radios. It can also route messages over the public Internet, which it does exclusively using Tor.
    I’ve also written a lot about NNCP, the sort of modernized UUCP. NNCP is completely different than the others here in that it is a store-and-forward network – sort of a modern UUCP. NNCP has easy built-in support for routing packets using USB drives, clean serial interfaces, TCP, basically anything you can pipe to, even broadcast satellite and such. And you don’t even have to pick one; you can use all of the above: Internet when it’s available, USB sticks or portable hard drives when not, etc. It uses Tor-line onion routing with E2EE. You’re not going to run TCP over NNCP, but files (including videos), backups, email, even remote execution are all possible. It is the most “Unixy” of the modern delay-tolerant networks and makes an excellent choice for a number of use cases where store-and-forward and extreme flexibility in transportation make a lot of sense.
    Moving now into the range of speeds and technologies we’re more used to, there is a lot of material out there on building mesh networks on Wifi or Wifi-adjacent technology. Amateur radio operators have been active in this area for years, and even if you aren’t a licensed ham and don’t necessarily flash amateur radio firmware onto your access points, a lot of the ideas and concepts they cover could be of interest. For instance, the Amateur Radio Emergency Data Network covers both permanent and ad-hoc meshs, and this AREDN video covers device selection for AREDN — which also happens to be devices that would be useful for quite a few other mesh or long-distance point-to-point setups.
    Once you have a physical link of some sort, cjdns and the Hyperboria network have the goals of literally replacing the Internet – but are fully functional immediately. cjdns assigns each node an IPv6 address based on its public key. The network uses DHT for routing between nodes. It can run directly atop Ethernet (and Wifi) as its own native protocol, without an IP stack underneath. It can also run as a layer atop the current Internet. And it can optionally be configured to let nodes find an exit node to reach the current public Internet, which they can do opportunistically if given permission. All traffic is E2EE. One can run an isolated network, or join the global Hyperboria network. The idea is that local meshes could be formed, and then geographically distant meshes can be linked together by simply using the current public Internet as a dumb transport. This, actually, strongly resembles the early days of Internet buildout under NSFNet. The Torento Mesh is a prominent user of cjdns, and they publish quite a bit of information online. cjdns as a standalone identity is in decline, but forms the basis of the pkt network, which is designed to foster an explosion in WISPs.
    Similar in concept to cjdns is Yggdrasil, which uses a different routing algorithm. It is now more active than cjdns and has active participants and developers.
    Althea is a startup in this space, hoping to encourage communities to build meshes whose purpose is to provide various routes to access to the traditional Internet, including digital currency micropayments. This story documents how one rural community is using it.
    Tor is a somewhat interesting case. While it doesn’t provide kernel-level routing, it does provide a SOCKS5 proxy. Traditionally, Tor is used to achieve anonymity while browsing the public Internet via an exit node. However, you can stay entirely in-network by using onion services (basically ports that are open to Tor). All Tor traffic is onion-routed so that the originating IP cannot be discovered. Data within Tor is E2EE, though if you are using an exit node to the public Internet, that of course can’t apply there.
    GNUnet is a large suite of tools for P2P communication. It includes file downloading, Tor-like IP over the network, a DNS replacement, and facilitates quite a few of the goals discussed here. (Added in a 2021-02-22 update)

    P2P Infrastructure
    While some of the technologies above, such as cjdns, explicitly facitilitate peer-to-peer communication, there are some other application-level technologies to look at.

    IPFS has been having a lot of buzz lately, since the Brave browser integrated support. IPFS headlines as “powers the distributed web”, but it is actually more than that; various other apps layer atop it. The core idea is that content you request gets reshared by your node for some period of time, somewhat akin to Bittorrent. IPFS runs atop the regular Internet and is typically accessed through an app.
    The Dat Protocol is somewhat similar in concept to IPFS, though the approach is somewhat different; it emphasizes efficient distribution of updates at the expense of requiring a git-like history.
    IPFS itself is based on libp2p, which is designed to be a generic infrastructure for adding P2P capabilities to your own code. It is probably fair to say libp2p is still quite complex compared to ordinary TCP, and the language support is in its infancy, but nevertheless it is quite an exciting development to watch.
    Of course almost all of us are familiar with Bittorrent, the software that first popularized the idea of a distributed mesh sharing knowledge about which chunks of a dataset they have in order to maximize the efficiency of distributing the whole thing. Bittorrent is still in wide use (and, despite its reputation, that wide use includes legitimate users such as archive.org and Debian).
    I recently wrote about building a delay-tolerant offline-capable mesh with Syncthing. Syncthing, on its surface, is something like an open source Dropbox. But look into a bit and you realize it’s fully P2P, serverless, can support various network topologies including intermittent connectivity between network parts, and such. My article dives into that in more detail. If your needs are mostly related to files, Syncthing can make a fine mesh infrastructure that is auto-healing and is equally at home on the public Internet, a local wifi access point with no Internet at all, a private mesh like cjdns, etc.
    Also showing some promise is Secure Scuttlebutt (SSB). Its most well-known application is a social network, but in my opinion some of the other applications atop SSB are more interesting. SSB is designed to be offline-friendly, can do things like automatically exchange data with peers on the same Wifi (eg, a coffee shop), etc., though it is an append-only log that can be unwieldy on mobile sometimes.

    Instant Messengers and Chat
    I won’t go into a lot of detail here since I recently wrote a roundup of secure mesh messengers and also a followup article about Signal and some hidden drawbacks of P2P. Please refer to those articles for some interesting things that are happening in this space.
    Matrix is a distributed IM platform similar in concept to Slack or IRC, but globally distributed in a mesh. It supports optional E2EE.
    Social Media
    I wrote recently about how to join the Fediverse, which covered joining Mastodon, a federeated, decentralized social network. Mastodon is the largest of these, with several million users, and is something of a much nicer version of Twitter.
    Mastodon is also part of what is known as the “Fediverse”, which are applications that are loosely joined together by their support of the ActivityPub protocol. Other popular Fediverse applications include Pixelfed (similar to Instagram) and Peertube for sharing video. Peertube is particularly interesting in that it supports Webtorrent for efficiently distributing popular videos. Webtorrent is akin to Bittorrent running efficiently inside your browser.
    Concluding Remarks
    Part of my goal with this is encouraging people to dream big, to ask questions like:
    What could you do if offline were easy?
    What is possible if you have freedom in the physical and data link layers? Dream big.
    We’re so used to thinking that it’s quite difficult for two devices on the Internet to talk to each other. What would be possible if this were actually quite easy?
    The assumption that costs rise dramatically as popularity increases is also baked into our thought processes. What if that weren’t the case — could you take on Youtube from your garage? Would lowering barriers to entry lower the ad economy and let nonprofits have more equal footing with large corporations?
    We have so many walled gardens, from Github to Facebook, that we almost forget it doesn’t have to be that way.
    So having asked these questions, my secondary point is to suggest that these aren’t pie-in-the-sky notions. These possibilites are with us right now.
    You’ll notice from this list that virtually every one of these technologies is ad-free at its heart (though some would be capable of serving ads). They give you back your attention. Many preserve privacy, anonymity, or both. Many dramatically improve your freedom of association and communication. Technologies like IPFS and Bittorrent ease the burden of running something popular.
    Some are quite easy to use (Mastodon or Peertube) while others are much more complex (libp2p or the lower-level mesh network systems).
    Clearly there is still room for improvement in many areas.
    But my fundamental point is this: good technology is here, right now. Technical people can vote with their feet and wallets and start using it. Early adopters will help guide the way for the next set of improvements. Join us!

    Reply

Mentions

Likes

Reposts

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.