Redecentralize Digest — August 2019

Hi all,

Thank you for all the lovely messages, comments and suggestions last month! We’re still experimenting and still looking for a new maillist provider, so please do write to us with any feedback or thoughts.

Right now, we are working hard on organising a venue and sponsors for a get-together in London in October, right before MozFest. Please shout if you’d like to get involved in organising or sponsoring. We’re keen to have a diverse community event covering topics sometimes left out at tech conferences. More on this soon :)

And here’s the digest for August, enjoy!

— Ira and Gerben

Updates and reviews

CCCamp happened

The four-yearly Choas Communication Camp took place, at a bikable(ish) distance from Berlin. Camping, lake swims, blockchain jokes, many lights and a fair amount of partying later… some of us are still recovering.

Lots of the talks are online. A few picks:

Although interesting, talks felt like a pretty minor part of the camp, perhaps mainly functioning as a break between swimming, volunteering, coding in hammocks, and participating in the many self-organised sessions; such as the Decentrathon, which had 8 teams work on decentralisation projects in the weekend.

One year of Data Transfer Project

The Data Transfer Project exists roughly a year now. It is a laudable initiative by some of the tech giants (Google, Microsoft, and now also Apple) to create a system that lets users move their data between various cloud services. An example in the whitepaper is moving your pictures from Google Photos to Microsoft OneDrive.

In its first year, some code has been contributed and some discussions took place, but overall it looks like a rather half-hearted approach for such an ambitious project. The project website is still a single page, and while its updates section mentions exciting-sounding new integrations (e.g. with Solid and Mastodon), these look like one-off experiments labelled ‘proof of concept’ or ‘alpha’.

In the European Union, a “right to data portability” is defined in the GDPR, article 20. So far, the Data Transfer Project looks like a way for the giants to show that they are ‘working on it’. Waiting for the incumbents to lead the way on increasing interoperability may not be the most promising approach.

In any case, even if this project would get the commitment it needs, it is important to keep in mind that data portability is only half a solution for many services: as long as social features only work between users of the same provider, the network effect keeps people locked into the platform where their friends are, even if they could take their data elsewhere. On top of that, services tend to come with their own ecosystem, and many apps only work with some specific provider(s). These giants have a long way to go.

Governmental institutions self-hosting their clouds

Nextcloud reports growing adoption by EU governments, as the use of (US-based) cloud services becomes suspicious and sometimes illegal because of data protection issues; see e.g. the recent ban on Microsoft Office 365 in schools in Hesse, and its denunciation inside the Dutch government after discovering it siphons loads of data, including even email subject lines, to Microsoft.

While instititions often focus on negotiating their contracts with their service provider, luckily some are trying to find alternatives instead. Keeping your data and software on-premise is the obvious thing to do.

EU’s internet plans

The upcoming European Commission will most likely work on a rehaul of the laws around online services. From President-elect Ursula von der Leyen’s agenda:

“A new Digital Services Act will upgrade our liability and safety rules for digital platforms, services and products, and complete our Digital Single Market.”

Besides the revision of platform liability rules (now covered by the eCommerce Directive from 2000), the envisioned Directive or Regulation (just ‘Act’ for now) may incorporate many more changes, for better or worse.

For the purpose of decentralisation, a great (but unlikely) possible change could be a legal requirement for every service to support interoperability, instead of locking its users into its silo. A leaked exploratory note suggests regulation for interoperability as an option:

“Service interoperabillty. Where equivalent services exist, the framework should take account of the emerging application of existing data portability rules and explore further options for facilitating data transfers and improve service interoperability – where such interoperability makes sense, is technically feasible, and can increase consumer choice without hindering the ability of (in particular, Smaller) companies to grow. Such initiatives could be accompanied by appropriate standardisation initiatives, and co-regulatory approaches.”

Despite this delightful suggestion, it seems more likely that politicians will consider the centralised status quo as a given, will desire more control over platforms’ behaviour, and then regulate them in burdensome ways that make it harder for small service providers to exist. On the other hand, might hampering digital services perhaps help create a larger market of products that let people serve themselves instead?

See further analyses by e.g. Netzpolitik and Andrej Savin.

Cory continues

Following up on his previous posts about adversarial interoperability (see our notes), Cory Doctorow’s subsequent article “Interoperability and Privacy: Squaring the Circle” is not as spot-on as his previous essays, but also it’s touching harder topics. Two discussed points:

Object capabilities for “managing spam and hate-speech on the fediverse”

Episode 25 of the LibreLounge podcast discusses object capabilities (short ‘ocaps’); a usually rather technical concept, but explained here using simple real-world scenarios: the running example is exchanging business cards at a conference. Instead of giving everybody the same address (or number), an alternative would be to instead write on each card a different address, but which all forward to you. This way, if somebody ends up bothering you (or the address gets published, scraped and spammed), you could just revoke that single address. Each address is a revokable capability to message you, rather than a constant identifier.

Starting from this concept, several extensions and variations are discussed. Perhaps my favourite idea is the analogy with postage stamps; but in this case the stamp/payment is automatically returned when the message is accepted, so normal messaging is gratis, while spamming costs money. Why don’t we have this already?

By the way, the podcast’s subsequent episode announces Datashards, a new addressing scheme for decentralised & encrypted storage systems. Unlike some of its alternatives (the episode compares IPFS, Tahoe-LAFS and Freenet), Datashards remains unopinionated about the methods or protocols used for obtaining the data; it only addresses addressing, which may be a healthy separation of concerns.

Unionising against Youtube

Some ‘YouTube creators’ are getting help from the German Metalworkers’ Union (as tubes can be metal, I guess?). In the Fairtube campaign, they demand YouTube be more transparent about its moderation decisions, and to allow appealing against them. Given YouTube’s dominance, the name being almost synonymous with ‘video on the internet’, these demands seem more than reasonable. But really, the only real solution is for ‘YouTube creators’ to just become ‘video bloggers’, and be able move their videos to other publishers than YouTube without losing their audience.

Upcoming

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 and edited by Gerben and Irina.

The digest’s format and content are not set in stone. Feedback and suggestions for next editions are welcome at hello@redecentralize.org.

Subscribe to receive future digests by email