« Other digests

Redecentralize Digest — January 2020

DWeb SF meetup explored decentralised social media

The Internet Archive hosted an event with various presentations around decentralising social media. This post provides both the video recording and an excellent summary, so we will skip that here and merely quote one quip from John Ryan’s talk (which corresponds to his latest blog post):

The answer to the walled garden problem is not more walled gardens.

“What Makes Decentralisation Hard? And How Do We Overcome This?”

In this talk at linux.conf.au, Martin Krafft covers various problems that have led to the internet’s consolidation. As he says, the WWW has become the MMM: “Media, Memes & Monopolies”. He argues a major cause for this are design flaws in the protocols. In particular, because there are less IP addresses than people in the world, people are hidden behind NATs which hinder them from contacting each other, thus forcing the use of relays and middle-men, through the familiar master–slave architecture (slave, not client, as we are slaves 2.0).

Part of the talk is inspired by André Staltz’s article about how “the Web began dying in 2014”. This article, written in 2017, combines numbers and narrative to picture how the open web and the internet may end up being obsoleted by a “Trinet” consisting of GOOG-FB-AMZN.

When getting from problems to solutions, both André and Martin pursue a move from a location-centric to a content-centric and user-centric web (they are active on Secure Scuttlebutt), and they see high potential in wireless mesh networking. Martin also promotes other projects like IPFS, Beaker/Dat, Tor, Matrix, and everything on Redecentralize’s Alternative Internet list (which has recently got some small updates, but can always use more love!).

Martin then asks why not more people are using these tools (we need “peercolation”, “trialability” and other fancily named features). Going into usability and ethical design, many will recognise his illuminative example of currently pervasive bad user experience: “I want to chat with Julia, which app did she use?”; I have a hunch that solving that problem may be a helpful step for freer choice among communication solutions.

Comparing decentralised social networks

Jay Graber wrote up a great comparison between federated and peer-to-peer social networks, and the pros and cons of either approach to decentralisation. ActivityPub/Mastodon and Matrix are used as examples of federated protocols, and Secure Scuttlebutt and Aether for peer-to-peer ones.

In a follow-up post, Jay lists a few social networks that involve blockchains in various ways, again looking at the up- and downsides. She presented the content of the posts in the DWeb meetup mentioned above.

In a field with many highly complex projects, categorising and comparing various projects’ approaches is a laudable service. Jay’s comparison streak started with a comparison of two protocols, which we will go into next.

Comparing IPFS & Dat

IPFS and Dat are two active projects developing protocols and software for a more decentralised web. In contrast to the currently prevalent HTTP, the IPFS and Dat protocols do not depend on a specific server to keep hosting the data that corresponds to some URL. Instead, much like BitTorrent, they normally use a distributed hash table to discover parties that can give you the data.

Given their similarities, many people ask about their differences. Jay Graber’s comparison treats both organisational and technical differences. The clearest technical difference is that IPFS addresses a piece of data by its hash, so resolving an IPFS address will always (assuming somebody hosts it) give you exactly the same, immutable data; whereas Dat addresses the public key with which its publisher has signed the data, so the publisher can update the data while it keeps the same URL. Notably, IPFS has a subproject called IPNS, which is conceptually very similar to Dat, but less developed.

For more detail on IPFS, see its documentation. For Dat, “How Dat works” is a detailed explanation of the protocol, with helpful visual explanations drawing out all the bits and bytes — I wish all technical documentation writers would draw inspiration from this.

Why decentralise

It is interesting to read some of the responses to the talk by Signal-founder Moxie Marlinspike (mentioned in last month’s digest), in which he dismissed decentralised communication apps as misguided/infeasible. Besides rebutting a few false or bad arguments, some pieces also move towards sharper arguments about why decentralisation actually matters.

For example, in one of these responses, “On Privacy versus Freedom”, Matrix-founder Matthew Hodgson readily concedes the point that decentralised systems are indeed much harder to build than centralised ones (empirically, at least six times harder). But the point is that it is doable and worth that effort, as the resulting freedom is crucially important. And, I would add, that freedom seems required to keep pursuing all the other values in the long run.

Ditching third party cookies

While various browsers started to try blocking trackers, the Chromium team announced their plan to drop support for third-party cookies altogether within the next two years. They move slowly, as they make the point (or “laughable claim”) that abruptly blocking third party cookies could be negative for user privacy, as it will make advertisers turn to browser fingerprinting techniques which are harder to protect against.

Fingerprinting is hard to avoid; not least because a person’s IP address is revealed to every web service they contact (unless browsers adopt Tor). To respect visitors’ privacy, EDRi’s new guide for ethical website development recommends to simply not include any third party resources and services on a site. Host that image, font, or traffic counter yourself; or at least pay the hosting provider for its service with your money, not with other people’s personal data.

As with any announcement made by the browser whose creator is itself an excessively dominant, data-hungry web service provider, people seek for hidden strategies behind the product decision. An obvious question, e.g. asked by Politico, is whether their move may hinder other advertisers much worse than themselves, compel publishers to then use Google’s services instead, and thereby grow their monopoly even further.

Upcoming Events

About this digest

The Redecentralize Digest is a monthly publication about internet (re)decentralisation. It covers progress and thoughts relating technology and politics, without ties to a particular project nor to one definition of decentralisation — figuring out its meanings and relations is part of the mission.

This edition was written by Gerben. Thanks to Emery & Piers for prereading.

The digest’s format and content are not set in stone. Feedback and suggestions for next editions are welcome at hello@redecentralize.org. We don’t spy on our readers, so please do tell us what you think!