[‡ logo square large] Redecentralize

About Blog Projects

Get Involved

« Other digests

/

About

Blog

Founder Interviews

https://github.com/redecentralize/alternative-internet

Alternative Internet

ReDigest

Events

Contact us

Join our chat

Donate to us

« Other digests

Redecentralize Digest — August 2020

Don’t shoot the messenger

The Google Play app store decided that several Fediverse apps (at least Subway Tooter, Fedilab, Husky, MastoPane) will be removed from the store because they ‘promote violence or incite hatred’; thereby blaming the app for the forums (typically Mastodon instances) people could connect to by knowingly entering such a forum’s address. Mastodon-developer Eugen/Gargron put it well:

Fediverse

at least

Mastodon

put

“A Mastodon app does not host or promote any content. The user types the
address to connect to. The responsibility of moderating resides with that
server. So unless Google is going to drop Chrome, Firefox and Opera from
its platform, this is completely out of line.”

You could just as well start blaming camera apps for the photos people make with them, or QR code scanners for the content of the codes they read, or even blame keyboards for the text typed on them.

On the other hand: with social media clients, it seems relatively easy to add a list of forums it could refuse connecting to, so for the clear-cut cases of objectionable places it understandably becomes tempting to impose the duty of blocking access to those. But going this route opens a can of worms: who determines what counts as problematic? What about all the cases that are not so clear-cut? What about chat apps that do not block known hateful groups? And, again, web browsers?

Note that this matter was also debated in the community of the F-Droid app store a year ago; although much of that debate was rather about the inverse: whether to reject apps that do block any servers. The F-Droid policy became to leave app developers free to choose whether to block specific forums; but require them not to promote a problematic forum — which I increasingly consider a wise solution.

F-Droid

a year ago

Suggesting a specific provider is a decision for which an app could be held responsible. However, it seems untenable to hold provider-neutral client apps responsible for the service providers their users intentionally connect to. Or, likewise, to hold content-neutral tools responsible for the content their users might end up consuming or producing.

Quite likely Google will revert these decisions again in a second review after sufficient outcry, perhaps with an apology (as happened with a podcast app earlier this year). But either way, incidents like this remind of the deeper problem, which is not the unjustified and unexplained decisions, nor the opaque and mediocre appeal process, but people’s dependence on this single gatekeeper platform that makes their decisions too impactful. Some lessons to draw:

happened

F-Droid

.app

DWeb meetup on community networks

In July, the DWeb meetup “Community Views Around the Globe” gave the floor to several people from around the world involved in community network projects.

Unlike the typical economic development goal of ‘connecting people to the Internet’, community networks aim for people to be connecting instead of being connected; for a community to be in control of the technology it adopts. Besides (or instead of) connecting to the outside world, focus is often on local connectivity, and on the specific ways this can create value for and with the people — for example, to provide localised information about the epidemic.

Have a look at the event’s recap for the recording and for summaries of the participants’ projects and stories.

meetup

recap

Note that DWeb meetups are often planned on short notice, so to hear of them do not rely on the events listed below, but subscribe to e.g. the DWeb mailing list.

DWeb mailing list

The Internet is for End Users

Most RFC documents from the IETF specify internet protocols and practices in technical detail. Valuable exceptions however are the more reflective RFCs, such as the just published RFC 8890 with the clear title “The Internet is for End Users”. In this RFC, the IETF’s Internet Architecture Board acknowledges the political impact of creating technical standards, and stresses the importance of prioritising end users’ interests over those of other stakeholders.

The document cites for its inspiration the “priority of constituencies” defined in the HTML design principles :

RFC

IETF

RFC 8890

HTML design principles

“In case of conflict, consider users over authors over implementors over
specifiers over theoretical purity.”

To me that reads like poetry.

About feeds

In theory, people should not need an account on some platform to follow the news, blogs or other posts. Nearly every website also provides its posts as an RSS feed, and there is a large ecosystem of apps to read them with. Nevertheless, RSS is underappreciated and people having been debating whether ‘RSS is dead’ for years now.

A big disadvantage of RSS is that it is not self-explanatory. Whereas a “follow us on Instagram/Twitter/…” kind of button leads visitors to a web page that helps (& pushes) them to get set up, a “Follow our feed” button that links to the RSS feed would likely result in people’s screen being flooded with XML code. As blogger Matt Webb realised :

debating

‘RSS is dead’

realised

“If you don’t know what RSS is, it’s really hard to start using it. This
is because, unlike a social media platform, it doesn’t have a homepage.
Nobody owns it. It’s nobody’s job to explain it.”

Hence he created aboutfeeds.com to try solve this. A simple web page that explains how feeds work, why you’d want it, and suggests a few reader apps (without being partial to any of them).

The effort is simple but laudable, and perhaps worth imitating. For various underappreciated protocols and practices, rather than inventing yet another app or protocol, it may be more helpful to create (app- & vendor-neutral!) explainer pages and instruction videos. Or to undertake an especially thankless but heroic effort: improve the relevant Wikipedia articles.

aboutfeeds.com

“How to Destroy Surveillance Capitalism”

Cory Doctorow wrote a long and long-awaited essay (see also his summary) to critique the narrative of “surveillance capitalism”, as popularised last year in Shoshana Zuboff’s book. In Cory’s view, “Zuboff puts enormous and undue weight on the persuasive power of surveillance-based influence techniques”, whereas the problem of big tech is rather rooted in their unrestrained monopoly:

essay

summary

book

“Zuboff calls surveillance capitalism a “rogue capitalism” whose
data-hoarding and machine-learning techniques rob us of our free will. But
influence campaigns that seek to displace existing, correct beliefs with
false ones have an effect that is small and temporary while monopolistic
dominance over informational systems has massive, enduring effects.
Controlling the results to the world’s search queries means controlling
access both to arguments and their rebuttals and, thus, control over much
of the world’s beliefs. If our concern is how corporations are foreclosing
on our ability to make up our own minds and determine our own futures, the
impact of dominance far exceeds the impact of manipulation and should be
central to our analysis and any remedies we seek.”

Miscellaneous

Decentralized Identity Foundation

overview of introductory resources

EFF

article

Public Spaces

reflects

posted

solutions

call for proposals

Events

All are online, unless noted otherwise.

Solid World

Open Tech Will Save Us

Our Networks

ReclaimFutures

DOTS design workshops

ActivityPub Conference

1st International Workshop on Distributed Infrastructure for Common Good

IndieWeb 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.

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!

Redecentralize Digest

tell us what you think

To receive future digests, follow our blog or subscribe to our newsletter: Subscribe to our newsletter

Support Redecentralize: Become a patron

blog

Subscribe to our newsletter

Become a patron

Proxied content from gemini://gemini.spam.works/users/dvn/test.gmi

Gemini request details:

Original URL
gemini://gemini.spam.works/users/dvn/test.gmi
Status code
Success
Meta
text/gemini
Proxied by
kineto

Be advised that no attempt was made to verify the remote SSL certificate.