« Other digests

Redecentralize Digest — July 2019

Hello friends,

We’ve been quietly working on revitalising Redecentralize with a few initiatives, and one of them is upgrading this newsletter to become a monthly digest! Event updates, publications, reviews and summaries of all things decentralised. This is the very first edition, so we will be playing with the format as we go along :-)

Have a read, share with friends and please send us any thoughts or feedback <3

As ever, we are working towards practising what we preach, by phasing out our reliance on the monolithic services of Google and GitHub. And we want to get off Mailchimp; if anyone has a recommendation for an ethical, reliable, convenient mailing list provider, we’d love to hear from you!

Please enjoy,

Ira and Gerben (a new contributor, hi!)
xx

Updates and reviews

DWeb Camp happened

After its DWeb Summits in 2016 and 2018, this year Internet Archive organised a DWeb Camp in the Californian countryside. Must have been fun; it is being remembered as a little bit Burning Man, a little bit Chaos Communication Camp.

Some of the lightning talks were recorded: Friday, Saturday. I’ll mention two, both from the latter:

IPFS Camp happened

Much more about IPFS and related topics went on in Barcelona. Some talk recordings have been published, others should follow soon™.

Cloudflare offers Ethereum gateway

Cloudflare’s introduction post also serves as a primer on Ethereum in general (like with IPFS last year).

Such a gateway to bridge the old and new worlds (while most software does not yet speak the protocols) seems a logical path to mainstream adoption. However, a company like Cloudflare could end up creating a central chokepoint. They see the irony too:

“”But Jonathan,” I hear you say, “by providing a gateway aren’t you just making Cloudflare a centralizing institution?” That’s a fair question. Thankfully, Cloudflare won’t be alone in offering these gateways.”

Also without monopolisation, if gateways would become the norm, interest in client-side support for peer-to-peer networking might diminish. But perhaps that risk is low, and as long as there are several bridge providers that talk the same standard protocols and can be swapped out any time, I suppose Cloudflare’s involvement is welcome progress for these protocols.

“Interoperability: Fix the Internet, Not the Tech Companies.”

In this EFF blog post, Cory Doctorow distinguishes three types of interoperability (indifferent, cooperative, adversarial). He then suggests legally requiring interoperability as a structural solution to today’s harmfully dominant platforms, instead of merely fighting symptoms.

“Today, much of the emphasis is on making Big Tech better by charging the companies to filter and monitor their users.” … “Instead of enshrining Google, Facebook, Amazon, Apple, and Microsoft as the Internet’s permanent overlords and then striving to make them as benign as possible, we can fix the Internet by making Big Tech less central to its future.”

We could not agree more.

In a preceding post, he goes deeper into his newly introduced term “adversarial interoperability”.

“This kind of adversarial interoperability goes beyond the sort of thing envisioned by “data portability,” which usually refers to tools that allow users to make a one-off export of all their data, which they can take with them to rival services. Data portability is important, but it is no substitute for the ability to have ongoing access to a service that you’re in the process of migrating away from.”

These are great articles. Perhaps one point deserves more emphasis: that ‘adversarial interoperability’ was so much easier with file formats and hardware connectors than it is with ‘live’ services. Microsoft cannot control what you do with your MS Word file, but it could limit access to your ‘own’ Office365 documents, revoke a competitor’s API keys, limit its API’s usefulness, etcetera.

Choice between competing & compatible service providers would be a huge step forward, but why is everybody creating their software as a service in the first place?

Designing ‘local-first’ software

This article, published in April by research lab Ink and Switch, explains why and how ‘local-first’ (≈ ‘offline-first’) software can benefit users in several ways, while retaining pleasant features of service-based software.

TL;DR

The article compares how various application architectures influence the user experience, with regard to each of these 7 aspects:

  1. Fast (no spinners)
  2. Multi-device syncing
  3. Works offline
  4. Seemless collaboration (hard: working offline + collaboration = need to deal with conflicts)
  5. Longevity of both your data and app (not losing either when the app is discontinued)
  6. Privacy & security (nor the app developers, nor any third party can see your data)
  7. Retaining control (nor can they lock you out of your own work)

These are hard to meet simultaneously. For example, thin-client web apps (‘software as a service’) allow for easy collaboration and multi-device usage, but fall short on every other aspect.

It concludes with thoughts about how to meet the whole list of ideals; great potential is seen in data synchronisation protocols like Dat in combination with Conflict-free Replicated Data Types (CRDTs), with which the lab created several experiments.

Notes

“How to run a small social network site for your friends”

Darius Kazemi’s Run your own social is a guide to running your own Mastodon instance for a small community, regarding it as the digital equivalent of hosting a party. It covers many practical and social aspects such as: cap your instance at ~50 people, allow for local-only (i.e. not federated) posting, welcome and onboard new members individually, and deter unwelcome people with a strict Code of Conduct.

Always interesting is to read an author’s suggestions for future work. A few quotes from those:

“The existence of a server and an administrator implies some local form of centralization. … People need to be able to jump ship and migrate their accounts, seamlessly and wholly, to other servers.” 🔗

This aspect is important, especially when each instance is such a tight community, because the fediverse is currently not as decentralised as it may appear. Yes, unlike with mainstream social media, there is choice between instances to join; but after that, your account is strongly tied to the chosen instance, and under control of its admins and policies (no less than those of Facebook or Twitter). If your account is suspended by the admin, you do not only lose membership of that instance’s community, but also lose your posts and your access to personal contacts, followers and followees on other instances.

Migrating accounts has been discussed in the scene for a while. Ideally, your identity and data should never have been so tightly bound to the instance(s) (orthogonality!). This is difficult to achieve, but solutions using portable (cryptographic key-based) identities and content-addressed data are being explored.

An alternative (but not easier) direction to decoupling identity from community would be to have everybody run their own instance, and support a form of cross-instance community memberships. Although without this ‘self-sovereign’ angle, Darius actually suggests forming multi-instance ‘neighborhoods’:

“I would like to see groups of servers that band together through a kind of mutual approval system.” 🔗

Another suggestion:

“Server forking should be easy” 🔗

Besides/instead of easier forking, I could imagine server customisation through plugins, so that people can easily pick and reuse various modifications from other communities (± the fediverse’s WordPress).

And:

“I’d like to advance the notion that software does not have to scale, and in fact software can be better if it is not built to scale.” 🔗

Banning Gab from the fediverse

The Verge covered the recent upheaval in the fediverse after a notorious ‘free speech’ social network Gab switched to use the Mastodon software. Becoming a Mastodon instance (and instantly the largest instance in the fediverse) would allow its content to spread across the network to other instances. In theory, that is, because many (most?) other instances have blocked interaction with Gab’s instance completely.

Besides servers refusing to federate with Gab, some Mastodon client app developers decided to hard-code an exception so their software would not let people log in to Gab even if the user explicitly tried to (e.g. rickrolling them instead).

The F-Droid (free software app repository) team summarised the conflicting opinions:

Under pressure to both reject apps imposing restrictions and reject apps not imposing restrictions, F-Droid decided to reject neither (but it will reject any apps that actively promote Gab).

Nolan Lawson wrote a piece last year titled ‘Mastodon and the challenges of abuse in a federated system’. It looks like the recent events take the challenges to another level, and there is much to be learnt about decentralised politics, censorship/bigotry conflicts, ‘higher order’ blocking policies, and the need for moderation in debates about moderation.

Coming up

Redecentralize gathering idea!

We want to host a gathering in London on the 24th and/or 25th of October, right before MozFest. We’re interested in a community unconference style event about interoperability, adoption, lessons from the past, and future challenges to tackle.

It would be great to bring together people working on decentralised tech, but also advocates, journalists, investors, open culture types and policy peeps — similar to the 2015 Redecentralize Conference. We’re looking for people to join the organising team and for funders — please get in touch ASAPs if this is you, and we can start planning!

About this digest

The Redecentralize Digest is (or plans to be!) 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. Thanks to Yannic for prereading.

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