Wenn man als Tech-Journalist den offiziellen Kanälen von Canonical folgt, erwartet man in der Regel Ankündigungen zu neuen Ubuntu-Versionen, LTS-Updates oder strategischen Shifts im Linux-Ökosystem. Doch der jüngste Versuch, einen spezifischen Post auf der Mastodon-Instanz von Canonical (ubuntu.social) zu verfolgen, endete nicht mit einem technischen Insight, sondern mit einer digitalen Mauer: „Bitte aktiviere JavaScript, um das Webinterface von Mastodon zu verwenden.“
Auf den ersten Blick wirkt diese Meldung wie ein banaler Hinweis, der jedem Internetnutzer irgendwann einmal begegnet. Für eine Organisation wie Canonical, die sich an die Spitze der Open-Source-Bewegung stellt und mit Ubuntu das wohl populärste Linux-Betriebssystem der Welt kuratiert, ist dieser kleine Satz jedoch symptomatisch für einen weitreichenden Konflikt: Die zunehmende Abhängigkeit des dezentralen Webs von zentralisierten, ressourcenintensiven Web-Technologien.
Die Ironie der JavaScript-Pflicht
Mastodon und das dahinterliegende ActivityPub-Protokoll wurden als Gegenentwurf zu den geschlossenen Silos der großen Tech-Konzerne entwickelt. Das Versprechen: Ein offenes, dezentrales und nutzerfreundliches Web, in dem man nicht von proprietären Algorithmen gesteuert wird. Doch die Realität des Web-Frontends sieht anders aus. Wer einen Mastodon-Link öffnet, lädt in der Regel eine Single Page Application (SPA), die auf React und einer Vielzahl von JavaScript-Bibliotheken basiert. Ohne aktiviertes JavaScript im Browser bleibt die Seite schlichtweg weiß.
Das ist nicht nur ein Ärgernis für Puristen. Es ist ein Architekturproblem. Das offene Web begann einst mit dem Prinzip der Progressive Enhancement: Eine Seite sollte auch ohne JavaScript grundlegend funktionieren, und dynamische Elemente sollten lediglich als Enhancement hinzukommen. Heute ist JavaScript oft die Voraussetzung, um überhaupt den Inhalt zu rendern. Canonical, als Verfechter von Open-Source-Infrastruktur, betreibt mit ubuntu.social eine Instanz, die genau diesem Paradigma folgt – und somit Nutzer aussperrt, die aus Sicherheits- oder Performancegründen auf JavaScript verzichten.
Die „Native App“ als Ausweg?
Der alternative Vorschlag der Fehlermeldung lautet: „Alternativ kannst du auch eine der nativen Apps für Mastodon verwenden.“ Das ist zwar richtig, taucht aber neue Fragen auf. Nativen Apps ist gemein, dass sie oft proprietär sind, in den App-Stores von Apple oder Google liegen und somit den Kontrollmechanismen dieser Konzerne unterliegen. Zudem verlagern sie das Problem nur: Anstatt das offene Web zugänglich zu machen, zwingt man Nutzer in eine App-Ecosystem, die dem Gedanken des dezentralen Webs eigentlich widerspricht.
Für Administratoren, Entwickler und Sysadmins – also genau die Zielgruppe, die Ubuntu nutzt und schätzt – ist der Terminal-Weg oft der bevorzugte. Wer via curl oder wget einen Metadaten-Endpunkt abfragen möchte, scheitert ebenfalls an der JavaScript-Pflicht des Web-Frontends, obwohl Mastodon im Hintergrund eine saubere REST-API bereitstellt. Der Content ist da, die Architektur des Frontends verdeckt ihn jedoch.
Das Fediverse braucht bessere Standards
Dass Canonical überhaupt eine eigene Mastodon-Instanz betreibt, ist ein lobenswerter Schritt. Es zeigt, dass das Unternehmen sich vom zentralisierten Twitter/X verabschiedet und auf föderierte Netzwerke setzt. Doch die Implementierung offenbart einen blinden Fleck. Im Fediverse wird intensiv über Barrierefreiheit, Datensparsamkeit und den Erhalt des „Small Web“ diskutiert. Eine Instanz, die ihren Content nur hinter einer JavaScript-Mauer serviert, konterkariert diese Bemühungen.
Es gibt vielversprechende Ansätze, dieses Problem zu lösen. Projekte wie Elk oder Semaphore bieten leichtgewichtigere, auf Barrierefreiheit und Performance optimierte Web-Frontends für Mastodon. Noch radikaler – und im Sinne des offenen Webs konsequenter – wäre es, wenn Instanzen wie ubuntu.social serverseitiges Rendering (SSR) oder statische HTML-Fallbacks bereitstellen würden. So könnte ein einfacher HTTP-GET-Request den Text-Beitrag als sauberes HTML ausliefern, ohne dass der Browser des Nutzers rechnen muss.
Fazit: Open Source muss das offene Web respektieren
Der Vorfall ist ein Mikrokosmos des modernen Webs. Wir haben die technischen Möglichkeiten, Inhalte dezentral, schnell und ressourcenschonend zu teilen. Das ActivityPub-Protokoll macht es möglich. Doch an der Schnittstelle zum Nutzer – dem Web-Frontend – scheitern wir an der Bequemlichkeit moderner JavaScript-Frameworks.
Canonical und das Ubuntu-Team haben eine Vorbildfunktion. Wenn sie das Fediverse als ernsthafte Alternative zu proprietären Netzwerken positionieren wollen, müssen sie sicherstellen, dass ihre Inhalte auch den Prinzipien des offenen Webs entsprechen. Ein einfacher Textpost sollte nicht einen vollwertigen JavaScript-Interpreter im Browser erfordern. Es ist an der Zeit, dass Open-Source-Projekte wieder stärker auf Progressive Enhancement setzen und das Web für alle – inklusive derer, die JavaScript deaktiviert haben – zugänglich machen.
Quelle: Canonical (Ubuntu)
