Ich finde weder eine Ankündigung noch eine Diskussion über das Thema Blockieren von Threads in dieser Community. Gab es die gar nicht?
Update: Es wurde wohl bereits kurz in einem anderen thread diskutiert.
Blocked Instances (on feddit.de)
| Name | Software | Version |
|---|---|---|
| … | … | … |
| threads.net | ||
| … | … | … |
Das Thema wird unter Fediverse Entwicklern, Admins und Usern durchaus kontrovers diskutiert, insbesondere ob Fediblock as a Frist Strike oder Watching Like a Hawk, with our Fingers Over the Block Button besser ist.
Hier eine nicht-repräsentative Auswahl an Lesestoff. Ich persönlich tendiere mehr zum Abwarten und genau Hinschauen als zum Sofort Blocken. Die feddit.de Admins haben sich offenbar (ziemlich lautlos) für Sofort Blocken entschieden:
- https://blog.joinmastodon.org/2023/07/what-to-know-about-threads/
- https://hub.fosstodon.org/facebook-fosstodon-fedi
- https://www.timothychambers.net/2023/07/03/instagram-threads-and.html
- https://venera.social/profile/activitypubtestsuite/conversations
- https://ploum.net/2023-06-23-how-to-kill-decentralised-networks.html
Es geht hier dabei nicht um die Frage, ob man die Praktiken von Großkonzernen wie Meta gut bzw. akzeptabel findet. Darüber gibt es hier sicherlich einen so breiten Konsens, dass eine Diskussion ziemlich überflüssig ist.
Es geht darum, ob ein Föderieren mit Threads so steuerbar ist, dass für die FOSS-Community keine Nachteile entstehen sondern eher Vorteile, also z. B. die Frage, ob es gut ist, wenn jemand Mastodon nutzen kann, um mit Freunden, Firmen oder Promis in Kontakt zu bleiben, die (leider) noch nicht in’s Fediverse gewechselt sind, also auch um die Frage, ob das Fediverse bereit ist, einen sanften Übergang für verlorene Schafe anzubieten.
Update/Fazit:
- Nur sehr wenige Kommentare haben sich tatsächlich mit der Fragestellung auseinandergesetzt.
- Ich hatte gehofft, dass über notwendige (technische) Bedingungen für ein Föderieren mit Threads diskutiert wird, also z. B.
- ActivityPub TestSuite
- notwendige Moderator-/Admin-Werkzeuge, z. B. Instanz-Block auf Community-Ebene
- notwendige Benutzer-Werkzeuge, z. B. persönlicher Instanz-Block
- Bandbreitenbegrenzungen für Datenverkehr zu/von großen Instanzen
- Ein image proxy feature wie es derzeit hier diskutiert wird: https://github.com/LemmyNet/lemmy/pull/3550
- Derzeit ist das Blocken von
threads.netnur symbolisch und nicht technisch relevant, da Threads noch nicht ActivityPub unterstützt und lemmy nicht die (zunächst/hauptsächlich) betroffene Fediverse App wäre sondern Mastodon. - Eine Stellungnahme von den Admins dazu, ob der Block permanent ist oder unter welchen Bedingungen er aufgehoben werden könnte, wäre schön.
Sorry, aber als ehemaliger Adium-Entwickler (XMPP-Client für macOS) finde ich dein Post ziemlich frech.
Ja, XMPP verwendet Extensions, so what? OpenGL verwendet auch Extensions für Basisfunktionalität, d.h. aber nicht, dass es nur ein Spielzeug war, das nur zum Spaß verwendet wurde.
Es gibt einige Clients, die zahlreiche Extensions richtig implementieren und auch miteinander funktionieren. Da wurde viel getestet und kommuniziert zwischen den Teams.
Ich mein, nix persönliches aber XMPP hat ewig gebraucht um keines der Features die man von einem modernen Chatclient erwartet stabil hinzubekommen.
Das Basisprotokoll ist etwa auf dem Featurelevel von IRC, also Textchats, allerdings mit Presence (was aber eher ein Nischenfeature ist) und die Erweiterungen leider so inkonsistent implementiert worden (wenn überhaupt) das man sich wenn man nicht alle zwingt den selben Server UND Client zu verwenden man leider nie sicher sein konnte was gerade funktioniert, es war einfach unbenutzbar wenn man nicht gerade selbst Tech-Geek ist.
Selbst wenn: Mit der schönen Föderation ist es dann endgültig vorbei, man weiß ja nicht was der andere überhaupt sieht und wie.
Dazu sind halt so viele Erweiterungen nötig um XMPP irgendwie so zurecht zu biegen das es von mehreren Endgeräten, mit E2EE anständig funktioniert, da macht eben auf Dauer keiner mit.
In meinen Augen wäre es notwendig gewesen 1. einen neuen XMPP Standard herauszubringen der wenigstens beinhaltet was heutzutage von einer Chatplattform erwartet wird (aka alles was WhatsApp kann) und 2. ein Gremium das in der Lage ist den Standard verbindlich anzupassen, dazu muss es natürlich auch in der Lage sein eine Referenzimplementierung anzubieten.
Matrix ist im Grunde genau das und hat damit bisher ganz gute Erfolge. Klar hat dieses System seine ganz eigenen Probleme aber XMPP hat halt nie außerhalb eines winzigen Subsets der Geekszene funktioniert.
Das war nicht meine Erfahrung. Interop war eigentlich immer problemlos möglich, und das Protokoll hat den Clients und Servern erlaubt, unbekannte Erweiterungen einfach zu ignorieren.
Es war ein Riesenproblem, dass XMPP keine E2E-Verschlüsselung erlaubt hat und es nicht mal eine brauchbare Extension dafür gab (nur PGP, welches unbrauchbar ist für Normalsterbliche), und ich glaube das war dann auch der Genickschuss im Endeffekt.
Du musst das im Kontext der Zeit sehen. Damals in den anfänglichen 2000ern ist man noch “online” gegangen, wo so ein Status durchaus wichtig war. Es gab keine portablen Internetgeräte, die man immer mit sich herumgetragen hat, und die eine push notification bekommen haben, wenn eine Nachricht reingekommen ist. Wenn jemand offline war, konnte man keine Antwort innerhalb der nächsten paar Stunden erwarten.