The main reasons why i think Mastodon is probably the worst alternative to centralized, commercial socials [with Italian version]

English version
[Italian version below]

  1. Instead of implementing the APIs defined by ActivityPub, of which only a small portion has been implemented in Mastodon to date, the Mastodon development team implemented its own APIs on top of those of ActivityPub and, taking advantage of the fact that Mastodon, before supporting ActivityPub (now the only decentralized social protocol it claims to support: little, as noted above), was by far the most widely used FOSS alternative to the large, centralized, commercial socials, it forced the development teams of the other platforms to implement the Mastodon-specific APIs, so that their own platform instances could interact with Mastodon instances; thus the Mastodon API became de facto the most widely used and most implemented interoperability standard among the Fediverse platforms, to the detriment of implementations of ActivityPub, which as a core social protocol was and would in itself be able to guarantee interoperability of the various platforms that implemented it;
  2. the Mastodon development team did everything possible, including the above, to centralize the Fediverse to its own platform and especially to the most widely used Mastodon gGmbH-owned instance, mastodon.social, which is also by far the most populated instance of all the Fediverse’s platforms, and this is bad for decentralization in itself (a network of small-to-medium instances is more resilient to any attack, and does not carry the risk that the most widely used platforms and instances will dictate interoperability rules and customs), and because the larger and more generalist an instance is, the less effective its moderation will be; it pursued and achieved this centralization by doing what is described in the first point and, even more, by putting a nice big button “Join mastodon.social” on the homepage of the project’s official website, before the “Pick another server” button, which, for its part, sends to a Mastodon instances presentation page that shows first, again, mastodon.social, and, immediately after that, the other, already more populated instances, and doing something very similar with its official mobile apps, where new users are even more induced to join mastodon.social;
  3. the Mastodon’s development team introduced “trending posts,” “trending accounts,” “trending hashtags,” and “trending news,” which are active by default and can only be turned off by those who manage the instance, thus gamifying the experience of the vast majority of users and increasing their FOMO; in other words, it has implemented features which are detrimental to equal and non-competitive interaction, investing a lot of time, energy, and money coming even or especially from the European community, instead of solving the huge problems Mastodon has been carrying for so long (see the first point, and below), and instead of implementing things which would be useful in themselves (see below, again), especially those that would be useful for decentralization, such as a simple inter-istance discovery mechanism for accounts;
  4. on Mastodon, if you read a thread whose first post comes from an instance other than your own, the thread very often has a lot of missing branches, i.e., those that develop under a post written from an account that your instance doesn’t know yet, including that very post; this is a huge bug, which greatly reduces the basic functionality of a social, and has been known since 2016, and has not yet been fixed; on other platforms supporting ActivityPub this bug is not present;
  5. on Mastodon you can’t make a public post of yours appear only on the local timeline of your instance; on other platforms you can, and it is an important feature for community-building – also, possibly, from the perspective of economic sustainability;
  6. on Mastodon those who manage an instance do not have an easy way to set the number of characters per post available to those who use it (they have to apply an hackish patch with each update); on other platforms it is possible to do this much more simply, by modifying an instance setting, and this is important because Mastodon’s default 500 characters limit is often very inadequate: as we see in so many threads, it happens very often that one has to split their posts.

Versione in italiano

I motivi principali per cui penso che Mastodon sia probabilmente l’alternativa peggiore ai social centralizzati e commerciali

  1. Invece di implementare le API definite da ActivityPub, delle quali ad oggi, in Mastodon, è stata implementata solo una piccola parte, il team di sviluppo di Mastodon ha implementato proprie API sopra quelle di ActivityPub e, sfruttando il fatto che Mastodon, prima di supportare ActivityPub (ora l’unico protocollo social decentralizzato che sostiene di supportare: poco, come già detto), era di gran lunga la più diffusa piattaforma FOSS alternativa ai grandi social commerciali e centralizzati, ha costretto i team di sviluppo delle altre piattaforme a implementare le API specifiche di Mastodon perché le istanze delle proprie piattaforme potessero interagire con le istanze Mastodon; così le API di Mastodon sono diventate di fatto lo standard di interoperabilità più diffuso e più implementato tra le piattaforme del Fediverso, a detrimento delle implementazioni di ActivityPub, che in quanto protocollo social di base era e sarebbe in grado di per sé di garantire l’interoperabilità delle diverse piattaforme che lo implementassero;
  2. il team di sviluppo di Mastodon ha fatto tutto il possibile, compreso quanto sopra, per centralizzare il Fediverso verso la propria piattaforma e soprattutto verso l’istanza di proprietà di Mastodon gGmbH più usata, mastodon.social, che è anche l’istanza di gran lunga più popolata tra tutte le piattaforme del Fediverso, il che è male per la decentralizzazione in sé (una rete di istanze medio-piccole è più resistente a qualsiasi attacco, e non si porta il rischio che le piattaforme e le istanze più usate dettino le consuetudini e le regole di interoperabilità), e perché quanto più grande e generalista è un’istanza, tanto meno sarà efficace la sua moderazione; ha perseguito e ottenuto questa centralizzazione facendo quanto descritto al primo punto e, ancor più, mettendo un bel pulsantone “Join mastodon.social” sulla homepage del sito web ufficiale del progetto, prima del pulsante “Pick another server” che, dal canto suo, manda a una pagina di presentazione delle istanze Mastodon che mostra per prima, di nuovo, mastodon.social, e subito dopo le altre istanze già più popolate, e facendo qualcosa di molto simile con le sue app mobile ufficiali, dove i nuovi utenti sono ancora più indotti a iscriversi a mastodon.social;
  3. il team di sviluppo di Mastodon ha introdotto “trending posts”, “trending accounts”, “trending hashtags”, “trending news”, attivi per default e disattivabili solo da chi gestisce l’istanza, gamificando così l’esperienza della stragrande maggioranza dell’utenza e aumentandone la FOMO; in altre parole, ha implementato funzionalità dannose per l’interazione paritaria e non competitiva, investendoci un sacco di tempo, energie, e soldi che gli arrivano anche o soprattutto dalla comunità europea, invece di risolvere i problemi enormi che si porta appresso da tanto tempo (vedi il primo punto, e sotto), e invece di implementare cose utili in sé (vedi sotto, di nuovo), in particolare quelle che sarebbero utili per la decentralizzazione, come un meccanismo di semplice discovery interistanza degli account;
  4. su Mastodon, se leggi un thread il cui primo post viene da un’istanza diversa dalla tua, il thread ha spessissimo un sacco di rami mancanti, ovvero quelli che si sviluppano sotto un post scritto da un account ancora non noto alla tua istanza, compreso quello stesso post; questo è un bug enorme, che riduce moltissimo la funzionalità di base di un social, ed è noto dal 2016, e non è ancora stato risolto; su altre piattaforme che supportano ActivityPub questo bug non c’è;
  5. su Mastodon non è possibile fare in modo che un proprio post pubblico compaia solo sulla timeline locale della propria istanza; su altre piattaforme si, ed è una funzionalità importante per fare comunità – anche, eventualmente, dal punto di vista della sostenibilità economica;
  6. su Mastodon chi gestisce un’istanza non ha un modo semplice per settare il numero di caratteri per post disponibili a chi la usa (deve applicare una patch arrangiata a ogni aggiornamento); su altre piattaforme è possibile farlo molto più semplicemente, modificando un’impostazione della propria istanza, ed è importante perché i 500 caratteri di default di Mastodon sono spessissimo insufficienti: come si vede in tanti thread, capita spessissimo di dover suddividere i propri post.

Reasons why Meta joining the Fediverse is very bad, how to mitigate the damage, and an idea to save the Fediverse as a new and safer web space

[Last edited on Tuesday, 16 January 2024]

Although i’m sure it won’t avoid most of the damage, i strongly support the Anti-Meta Fedi Pact, and urge Fediverse admins to block Meta’s Threads (currently, the threads.net domain) at their Fediverse instances’ level, because Meta, the producer of Facebook, Whatsapp, Instagram and Threads, is known to do such things as:

  1. profiling users for targeting advertisements [e.g.: 1, 2];
  2. controlling their users emotions;
  3. spreading misinformation and conspiracy theories about November 2020 presidential election in USA;
  4. censoring political organizations – mostly, and by far, of the global left [1, 2], while not censoring political organizations of the most far right (e.g.: italian neofascist organizations like Casapound, Forza Nuova, Lealtà e Azione all have many pages and profiles on Facebook);
  5. facilitating a genocide;
  6. super-exploiting moderators;
  7. censoring wildfires news stories from Canada to Canadian users;
  8. systemically censoring Palestine contents on Instagram and Facebook;
  9. and so much more;

But most Fediverse platforms’ instances, especially most or all of the most populated, are not blocking and won’t block threads.net; thus, using those instances, will be less and less different than using Meta’s products, in terms of data scraping by Meta and users’ privacy, because those instances expose their users to the risk of giving complete access to their “private” messages (messages addressed to “Mentioned people only”, on Mastodon) just by unknowingly or thoughtlessly mentioning Threads accounts in such messages, and to complete access by Meta to their “less public” posts (posts addressed to “Followers only”, on Mastodon), when Threads users will get the possibility to follow other Fediverse platforms accounts, that is soon going to be implemented by Threads developers. Meta has scraped even “less public” posts and “private” messages on its platforms in the past, and it is most probably still doing it, in spite of some court cases that accounted it guilty of doing it and “punished” it, much later than when each one of those abuses was made, with financial penalties that were ludicrous to Meta, because of its huge financial wealth.

To mitigate these risks, users of Fediverse platforms instances that have not blocked the threads.net domain at instance level can still block it by themselves and for themselves only (on Mastodon’s official web frontend, this can be done by clicking on the three dots icon in the lower right corner of any post and choosing Block domain from the popup menu); or they can set their accounts to prompt for their confirmation whenever another account tries to follow theirs (on Mastodon’s official web frontend, this can be done by going to Preferences > Public profile > Privacy and reach tab, and unchecking the Automatically accept new followers checkbox), and then paying attention to not mention any Threads account in their non-public posts (“Followers only” and “Mentioned people only” posts, on Mastodon).

Still, to ensure that the Fediverse won’t become a big barrel from which Meta, and probably other big and medium commercial players in the future, will scrape not only data from public posts, but also from “less public” and “private” posts, the most safe way would be to write a new social networking protocol specification, that could be named FreeSocialProtocol, and to put it under a license or a patent that (1) would prohibit any use of the protocol itself in products that are not open source, and (2) would prohibit its use in products that also use other protocols that are under no licenses, or that are under licenses not prohibiting their use in non-open source products (point 2 would make it a viral license/patent, like the GPL, but only on the open source condition; and necessarily so, because otherwise, this license/patent very purpose would be defeated).

I have no illusion that a new protocol with such a license or patent would be used by many from the start, and maybe it would take long for it to gain traction, or maybe it would never exit the “niche” status, but it would be good all the same even in these cases, and i think there is the possibility that it would gain a lot of traction, soon or later. But, again, i think it would be just and good if it existed even if it was never to exit the “niche” status.

Note 1: i’m trying to verify whether it is possible to create such a license, or such a patent, and to apply it to the specification of a social networking protocol: on Friday, 22 December 2023, i wrote an e-mail to the FSF (using the licensing@fsf.org e-mail address) asking just this; and on Saturday, 6 January 2024, i’ve written to the European section of the FSF too, at its licence-questions@fsfe.org e-mail address, without receiving any answer from both as of today, Tuesday, 16 January 2024.

Note 2: on this topic, you may want to read these ongoing discussions i’m having: the first one with a Fediverse protocols and platform (Streams) developer, the second one with an Akkoma developer (Akkoma is another Fediverse platform, a fork of Pleroma). I think they’re both at least very useful, clarifying and instructive.

E2ee and the web

English version

I wonder how including end-to-end encryption in a webapp, like corporations such as whatsapp, telegram, protonmail, tutanota and probably many others already do, could not be a bad idea even for less commercial projects like Mastodon, etc., basically for a very simple reason: every time a user’s browser connects to an url, it downloads from the server code (html, javascript, ecc.) that, despite showing a potentially identical interface to the user, can be different and do different things than the code the browser downloaded from the same url the previous time, so there’s no way for third parties to check that code and verify it doesn’t do malicious things, and even without big technical skills a malicious admin of a web server claiming to host a webapp implementing end-to-end encryption can alter it, even just for a short amount of time, so that the server, to make an example, will send to the browser of a single targeted user – let’s call him Pippo -, even just once, code that will make it do things which Pippo doesn’t want it to do, such as sending his private key, on first submission of a new post/message, to a mailbox owned by the admin, which would allow the admin, soon after that, to revert the webapp to its official version, having by then obtained the possibility to decrypt and thus read, since that very moment, all the posts or messages which Pippo will continue to consider accessible only to his recipients, as well as the possibility to impersonate him, without risking any longer Pippo noticing it before he possibly finds himself in big troubles, and maybe even later.

A false sense of security is worse than no security at all, thus i think it would be better to not implement end-to-end encryption in webapps, warning their users that anything they send will be potentially readable by the admins, and reserving end-to-end encryption to “classical” apps which are distributed by safer means like f-droid.

Versione in italiano

Mi chiedo in che modo implementare la crittografia end-to-end in una webapp, come già fanno aziendone quali whatsapp, telegram, protonmail, tutanota e chissà quante altre più piccole, potrebbe non essere una cattiva idea anche per progetti meno commerciali come Mastodon, ecc., fondamentalmente per un motivo molto semplice: ogni volta che il browser di un utente accede a una url, scarica dal server del codice (html, javascript, ecc.) che, pur mostrando all’utente un’interfaccia potenzialmente identica, può essere diverso e fare cose diverse rispetto al codice che il browser ha scaricato dalla stessa url la volta precedente, quindi non c’è modo per terze parti di controllare quel codice e verificare che non faccia cose cattive, e anche senza grandi conoscenze e capacità tecniche un admino malevolo di un server web che dichiari di ospitare una webapp che implementa crittografia end-to-end può alterarla, anche solo per un breve lasso di tempo, in modo che il server, per fare un esempio, mandi al browser di un singolo utente preso di mira – chiamiamolo Pippo -, anche una volta sola, del codice che gli farà fare cose che Pippo non vorrebbe facesse, come mandare la sua chiave privata a una mailbox dell’admino al primo invio, da parte di Pippo, di un nuovo post/messaggio, ciò che permetterebbe all’admino di ripristinare, subito dopo, la webapp ufficiale, avendo nel frattempo ottenuto la possibilità di decrittare e quindi leggere, da quel momento in poi, tutti i post o i messaggi che Pippo continuerà a presumere accessibili soltanto ai suoi destinatari, come pure quella di impersonarlo, senza più nemmeno il remotissimo rischio che Pippo se ne accorga prima di trovarsi magari in guai seri, e forse anche dopo.

Un falso senso di sicurezza è peggio di nessuna sicurezza, meglio quindi una webapp che non implementa crittografia end-to-end ma avverte gli utenti che qualsiasi cosa inviino tramite la stessa può essere letta dagli admin, riservando la crittografia end-to-end alle app “classiche” distribuite tramite sistemi più sicuri tipo f-droid.

Services offering end-to-end encryption through web sites can’t be trusted

A false sense of security is worse than no security at all

Whatsapp, Telegram, Element/Matrix, Protonmail, Tutanota are just the most known and widely used services, among many, offering end-to-end encryption not only through their apps, but also through their web sites.

– Can users of these web sites be confident that the people behind these web sites’ servers can’t read their “end-to-end encrypted” contents?

No, they can’t.

Continua a leggere Services offering end-to-end encryption through web sites can’t be trusted

NetworkManager: come cambiare i DNS

Usare, per la propria connessione, DNS pubblici alternativi invece di quelli preimpostati dal proprio provider, magari per aggirare la censura di qualche sito (cosa che è possibile fare anche, e forse più semplicemente, usando Tor Browser), è facile con NetworkManager, il “gestore di rete” di gran lunga più usato su Linux.

Per prima cosa si tratta di cliccare con il tasto destro del mouse sull’iconcina di rete che sta nella “system tray” del desktop e, dal menu che compare, cliccare col tasto sinistro su “Modifica connessioni…”.

NetworkManager - Cambiare i DNS - 1

Dalla finestra “Connessioni di rete” che compare bisogna selezionare la connessione che si sta utilizzando, nel mio caso “Ethernet”, e poi cliccare sull’iconcina con l’ingranaggio.

NetworkManager - Cambiare i DNS - 2

Dalla nuova finestra che compare bisogna selezionare la scheda “Impostazioni IPv4”.

Se il “Metodo” è impostato su “Automatico (DHCP)”, bisogna cambiarlo in “Automatico (DHCP) solo indirizzi”. Se invece, come nel mio caso, è impostato su “Manuale”, va già bene così. Nella casella di testo “Server DNS” bisogna specificare i DNS che si vuole usare (se sono più di uno basta separarli con uno spazio, o con virgola e poi spazio), poi cliccare sul pulsante “Salva”.

NetworkManager - Cambiare i DNS - 3

Ora si può chiudere anche la finestra “Connessioni di rete”.

Poi, perché il cambiamento di DNS sia effettivo, bisogna (almeno sul mio sistema), disattivare la connessione in uso cliccando col tasto sinistro sull’iconcina di rete e poi su “Disconnetti”…

NetworkManager - Cambiare i DNS - 4

…per poi riattivarla cliccando di nuovo col tasto sinistro sull’iconcina di rete e poi sul nome della connessione.

NetworkManager - Cambiare i DNS - 5

Ecco fatto.