« Other digests

Redecentralize Digest — July 2020

Having started in July 2019, this monthly digest has been going for a full year now. Thanks for all the positive and constructive feedback so far! We hope to continue to be a helpful source of information and opinion for our readers, while looking for ways to improve it further and add value in other ways.

One improvement already: we are abandoning Mailchimp to distribute our emails from our own server instead, using the Mailtrain software. We hope that everything will work out well, apologies for any glitches that may occur!

NODE zine volume 2

After the first edition a year ago, NODE published a second zine: 180 beautiful, black-and-white pages full of open hardware and decentralised software projects. It is a joy to flip through, reminds a little of the classic Dream Machines, and may likewise attract new audiences to these (often unappealingly presented) topics.

This is fine 🔥

Cade Diehm wrote a critical essay to warn about the unpreparedness of well-intended, decentralised technologies in the face of incumbent power and political crises. As a comparison to learn from, he renarrates the rise, conflicts and corporate exploitation of peer-to-peer file sharing in the 2000’s. A few excerpts:

“The resilience of centralised networks and the political organisation of their owners remains significantly underestimated by protocol activists.”

“The moment demands not another protocol, not another manifesto, not another social network, but a savvy understanding of the political dynamics of protocols and the nakedness of today’s networks.”

“We need to lay aside our delusions that decentralisation grants us immunity – any ground ceded to the commons will be met with amplified resistance from those who already own these spaces.”

Even if at times it may sound alarmist, this (self-)critical, big-picture type of analysis deserves being taken seriously.

Platform interoperability regulation

Early July, Redecentralize joined several EU-based software startups and civil society organisations to send an open letter to the European Commission, urging them to impose interoperability requirements on large platforms as part of the upcoming Digital Services Act.

Also this month, the UK Consumer and Markets Authority published a remarkably resolute report about the dire state of the market in online platforms and advertising. In over 400 pages (plus 27 appendices) of thorough analysis, it recommends the creation of a digital markets unit (DMU) to regulate this sector, suggests breaking up both Google and Facebook, and makes the case for mandated interoperability in social media (even drawing up a user interface for a multi-platform social media app, cutely named “Huddlr”).

Just a week later, the French digital council CNNum published a report specifically on interoperability. And finally, the GAFA’s executives got questioned by the US Congress about their monopolistic behaviour. Perhaps this all will finally lead to something…

Sketching out such regulation

EFF wrote a great explanation of what interoperability regulation could look like. Following the 2019 US ACCESS Act proposal, it lists three complementary demands for interoperability: data portability (to switch between providers), back-end interoperability (i.e. supporting federation), and delegability (i.e. letting any software/service interact with a platform on your behalf, instead of using the platform’s own apps). Moreover, it promotes a two-sided approach: it aims to both ‘build a floor’ on interoperability by requiring monopolist platforms to enable interacting with it, and to ‘heighten the ceiling’ of interoperability by not letting platforms curb third parties’ unilateral attempts at interoperating with (e.g. through creative (ab)use of copyright or cybersecurity laws).

Riot→Element, and naming things

The popular Matrix client Riot (or actually its successor RiotX) has been renamed to Element because of a trademark issue, and because the word’s apparent association with violence (“rather than the more constructive forms of chaos we had in mind”). The company developing it, New Vector, and its Modular hosting service, are likewise renamed to Element and Element Matrix Services, because emphasising their distinct roles in the ecosystem became less relevant than avoiding confusion.

This last point makes me think of the more general question of how to name open ecosystem components in a time when monolithic platforms are the norm. Most people expect that app X connects to other people with app X, via the ‘cloud’ of company X which also developed the app (and all that using some proprietary, nameless protocol).

When creating a modular system where people can mix and match various apps and service providers, how to best name and present these? I have friends who’d say “let’s chat on Riot”, which makes sense since that’s the name of the app they open; but to me it sounds similar to “sending an Outlook message”. But if I suggest “chatting over Matrix”, they look at me like if I’d suggest to send something “over SMTP”. May such language (and conceptual) mismatches be impeding wider adoption?

Schrems wins again

In case you missed it: the EU Court of Justice concluded that the US is still not sufficiently respecting data protection rights of EU citizens. Like with “Safe Harbour” before it, the court invalidated the EU’s “Privacy Shield” decision (that permitted companies to transfer personal data to the US), while also clarifying duties of companies and data protection authorities when international transfers are based on other legal grounds. See also e.g. EDRi’s summary.

For ‘pro-industry’ voices complaining about the outcome, Max Schrems clarified eloquently:

“This judgment is not the cause of a limit to data transfers, but the consequence of US surveillance laws. You can’t blame the Court for saying the unavoidable - when shit hits the fan, you can’t blame the fan.”

Miscellaneous

Events

All are online.

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, with thanks to all who contributed.

The digest’s format and content are not set in stone. Feedback, corrections 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!