Keine Angst, es geht nicht um Avatare ohne Beine!

Threads has entered the fediverse!!!

TL;DR: Ich freue mich, dass Meta diesen Schritt geht und ich zukünftig vielleicht all meine Freunde im Fediverse Social Web treffen kann, ohne dafür einen Threads, Facebook oder Instagram Account zu benötigen, ich respektiere aber auch jeden, der anderer Meinung ist und das Netzwerk (aus guten und nachvollziehbaren Gründen) blockiert.

Meta experimentiert ja schon eine ganze Weile mit ActivityPub, aber jetzt können wirklich alle, die:

das Teilen im Fediverse auf Threads aktivieren!

If they do, they’ll be able to publish posts on Threads that will be viewable on other ActivityPub-compliant servers. Threads users will also be able to see aggregated like counts on their posts from other fediverse servers directly from the Threads app. If people on other fediverse servers follow federated Threads profiles they’ll be able to see, reply to, and repost Threads posts (if their server allows it).

Das ist sicherlich noch alles sehr limitiert und klingt auch immer noch experimentell, aber es ist raus aus der „beta“ Phase und ein erstes Zeichen, dass Meta es mit ActivityPub doch ernst meinen könnte.

Ich bin wirklich kein großer Fan von Meta/Facebook und habe den „Verein“ in der Vergangenheit heftig kritisiert, aber ich glaube diese Entwicklung ist wichtig und ich freue mich dass Meta sie (bisher noch) weiter verfolgt!

Die Entwicklung ist wichtig, da ohne Meta das Fediverse einfach nur das Fediverse bleibt und wir uns die Diskussion, ob „Social Web“ nicht passender wäre, sparen können. Ohne Facebook (et al.) ist das Fediverse nur eine Nische, zwar eine offene und dezentrale Nische, aber eben nur eine Nische.

Ich weine immer noch den Anfängen der Web 2.0 Zeit nach, in der Blogs und soziale Netzwerke sich ergänzt und nicht untereinander konkurriert haben. Das bezieht sich aber nicht ausschließlich auf Walled Gardens wie Facebook und Twitter, auch Netzwerke wie Diaspora, die im Grunde zwar dezentral aufgebaut sind, aber nie den Anspruch erhoben auch mit anderen Netzwerken zu „föderieren“, waren bzw. sind das Problem.

Was ich vor 12 Jahren über Diaspora geschrieben habe, passt (glaube ich) immer noch sehr gut:

Wenn die großen Netzwerke wie Facebook, Twitter und Google+ sich nicht auf ein einheitliches Protokoll einigen, wird es wohl nichts mit der „dezentralen“ Idee! Ich möchte mich in Zukunft für eine Community entscheiden die meinen Interessen und Wertvorstellungen entspricht und nicht von der Mehrheit meiner Freunde abhängig sein. Wenn alle meine Freunde aber bei Facebook sind, bleib ich auch auf einem offenen und dezentralen Diaspora alleine!

Dezentrale „Walled Gardens“

Beide Seiten müssen kooperieren, deshalb finde ich es wichtig, dass sich das Fediverse auch für Threads öffnet!

Da aber genau diese Haltung die Fediverse-Community spaltet, möchte ich das nicht so stehen lassen.

Evan Prodromou, benennt die zwei entstandenen Lager in einem Blog-Post „Big Fedi versus Small Fedi“ und ich würde mich (aus den oben genannten Gründen und auch wenn ich den Namen unpassend finde) eher dem „Big Fedi“ Lager zuordnen, schon alleine wegen dem ersten Punkt:

The fediverse should be big. Real big. Like, everyone on the planet should have an account on the fediverse. It will make the internet better and the world better.

Das heißt aber weder, dass ich allen Punkten von „Big Fedi“ zustimme, noch dass ich alle Argumente aus dem „Small Fedi“ Abschnitt ablehne… im Gegenteil!

Gleich den ersten Punkt der „Small Fedi“ Liste, sehe ich als essentiell wichtig für das weitere Bestehen und die Zukunft des Fediverse und bin der Meinung, dass er beiden Lagern zugeordnet werden sollte muss:

The fediverse should be safe. Safe from harassment, safe from privacy violations.

Für viele ist Threads per se eine Verletzung dieser Aussage und die fedipact Seite empfiehlt, das Meta-Netzwerk aus genau diesen Gründen zu blocken:

tl;dr

  1. they won’t moderate effectively, there is precedent with facebook being a toxic cesspit of hate
  2. they have a long track record of pure evil and we have no reason to give them the benefit of the doubt
  3. to protect the existing communities of marginalized people on the fediverse, many of whom rely on it to survive
https://fedipact.online/why

Das sind alles valide Argumente, die Schlussfolgerung ist in meinen Augen aber die Falsche. Mit Spam und Abuse hat das Fediverse auch jetzt schon und gänzlich ohne das zutun von Threads zu kämpfen. Wie toxisch das Fediverse sein kann, zeigt der Fall von „Content Nation“ vom März diesen Jahres mehr als deutlich.

Aside from simply blocking the domain and moving on, community members decided to have a little bit of extra fun, attempting to “make the crawler crash“, send angry emails to the service operator, and more. After some study of how the site worked, one person had the malicious idea to send a remote post containing child pornography to the site, before getting someone else to report Content Nation for Child Sexual Abuse Material.

Content Nation Backlash Highlights Mastodon’s Toxicity

Threads zu blocken, ist nicht die alleinige Lösung für das stetig wachsende „Trust & Safety“ Problem. Neben simplen Block-Listen, brauchen wir zukünftig bessere Strategien um diesem Problemen Herr zu werden. Wir brauchen mehr Initiativen wie IFTAS und Services, die sich ähnlich wie mit E-Mail- oder Kommentar-Spam, zukünftig auch mit Social Media „Spam“ befassen.

Andernfalls betreiben wir einfach nur „Security by obscurity„.


Aber eine Sache noch zum Schluss: In dem Abschnitt in dem Meta ActivityPub und das Fediverse erklärt, wird ausgerechnet WordPress als das einzige Beispiel neben Mastodon erwähnt.

The protocol plays a key role in allowing Threads to be interoperable with other servers that also use it. Eventually, people on Threads will be able to interact with people on platforms like Mastodon and WordPress without having to sign up for accounts on those apps.

What is ActivityPub?

… 😍

Ich hab WhatsApp gelöscht!

Facebook ist mir ja schon länger ein Dorn im Auge und vor ein paar Wochen hat Tantek Çelik im IndieWeb Chat folgendes vorgeschlagen:

Just suggested „Blocktober“ for October as a CTA for The Social Dilemma, as in, make your October the month you Blocktober social media

Perfekte Gelegenheit!

Ich hab schon vor knapp zwei Jahren meinen Facebook und Instagram Account gelöscht aber WhatsApp ist mir bisher wirklich schwer gefallen.

Die Entwicklung (Rechtsruck, Alternative Fakten, Verschwörungstheorien) der letzten Jahre hat das geändert. Facebook ist sicherlich nicht die Ursache dieser Entwicklung, aber ist ein wesentlicher Verstärker!

Mit seinen Algorithmen und Echo-Chambers, mit seinen Regeln und seinem eigenem kleinen Ökosystem sorgt Facebook für eine Radikalisierung seiner Nutzer, es diskriminiert, es experimentiert mit der Psyche, es duldet Aufrufe zum Mord, es verkauft Drogen, es manipuliert und es überwacht.

Warum fällt es uns trotz dieser Überschriften so schwer Facebook, Instagram oder WhatsApp zu löschen?

Tim Kendall, der ehemalige „Director of Monetization“ von Facebook schreibt folgendes über seinen ehemaligen Arbeitgeber:

We took a page from Big Tobacco’s playbook, working to make our offering addictive at the outset. The social media services that I and others have built over the past 15 years have served to tear people apart with alarming speed and intensity. At the very least, we have eroded our collective understanding — at worst, I fear we are pushing ourselves to the brink of a civil war.

businessinsider.com

Facebook macht süchtig! Pubertierende definieren sich über ihre Instagram Profile, ihre großen Geschwister haben nahezu ihr ganzes Leben auf Facebook veröffentlicht und ihre Eltern planen die Elternabende über WhatsApp. Egal welches Alter, ohne Facebook & Co. erfährt man Ausgrenzung.

Da ich so langsam in die letzte Kategorie rutsche, war es für mich besonders schwer WhatsApp zu ersetzen. Einzelne Kontakte waren einfach zu überzeugen auf eine andere App zu wechseln, aber für viele WhatsApp Gruppen habe ich bisher keine Alternative. Ein Freund meinte, dass ich mit meiner Aktion andere indirekt zwingen würde, mich auf alternativen Wegen zu kontaktieren… Perfekt! Vielleicht schaffe ich es ja sogar, dass sie das Medium komplett wechseln!

Mit WhatsApp lösche ich auf alle Fälle meine letzte Facebook App! …auch wenn das Facebook nur wenig interessieren wird!

Noch ein Grund mehr!

In den letzten 4…5 Jahren hab ich immer wieder mit dem Gedanken gespielt meinen facebook Account zu löschen. Mein Account hatte wirklich wenig persönliches und ich habe ihn fast ausschließlich dazu benutzt, meine Blogposts zu teilen. Der einzig plausible Grund der mich noch daran gehindert hat ihn zu löschen, ist mein Beruf. Mittlerweile bin ich aber der Überzeugung, dass dafür auch ein … nennen wir es mal „Test-Account“ … ausreicht.

Glücklicherweise gehöre ich zu einer Generation die auch ganz gut ohne facebook auskommt, weshalb ich das „Privileg“ habe, meinen Account zu löschen.

Also dann: Ciao facebook!

Wer mich erreichen, mir folgen, mit mir diskutieren, oder einfach nur „hallo“ sagen will, ist (bzw. „war schon immer“) hier auf notiz.blog am besten aufgehoben. Mein Blog hat RSS, ATOM, JSON, Microformats(2), Schema.org und ActivityStream Feeds, er unterstützt Kommentare, Salmons, Webmentions und Pingbacks, ihr könnt mir auf Mastodon, Friendi.ca, GNU.social, STATUS.net, Diaspora (WIP) ((@)pfefferle@notiz.blog), Micro.blog (über irgend einen der oben erwähnten Feeds) oder über Telegram folgen (@notizblog).

Außerdem bin ich weiterhin über Twitter, GitHub und diverse Slack Channels (IndieWeb, WordPress, …) zu erreichen.

Als nächstes würde ich übrigens auch gerne auf Whatsapp verzichten… Also bitte nur noch Telegram verwenden!

Facebook kauft WhatsApp und ich hab nur wenig Möglichkeiten meine Konsequenzen daraus zu ziehen. Leider sind alle aktuell populären "Chat" Systeme direkt an die App gekoppelt und ich "muss" zwangsläufig die App benutzen die mein Freundeskreis bevorzugt.

WhatsApp benutzt intern das XMPP-Protokoll und arbeitet dadurch ja theoretisch dezentral und auch Telegram hat beispielsweise eine Art offenes Protokoll gebaut… Das Problem: Woher wissen auf welchem Server der Andere angemeldet ist.

Seit WhatsApp die Identifizierung über die Telefonnummer (statt einer z.B. E-Mail Adresse) eingeführt hat, sind viele anderen diesem Beispiel gefolgt und es gibt nichts Verwerfliches daran. Jeder der eine solche App nutzt hat zwangsläufig ein Telefon, was bedeutet dass er auch eine Telefonnummer hat und die Wahrscheinlichkeit dass in seinem (Telefon-)Adressbuch mehr Telefonnummern als E-Mail Adressen stehen ist auch sehr hoch. Prinzipiell also eine gute Idee! Leider kann man aber anhand einer Telefonnummer nicht auf einen Server (mal abgesehen vom Telekommunikations-unternehmen) schließen und das bedeutet, dass das Verfahren leider auch nur zentral funktionieren kann. Nutze ich WhatsApp, kann man mich nur über die WhatsApp-Server erreichen, für Telegram läuft die Kommunikation nur über die Telegram-Server usw.

Um mit XMPP oder anderen Protokollen wirklich dezentral arbeiten zu können, müsste man über die Telefonnummer erfahren können welchen Chat-Server der Andere benutzt. Vielleicht über so eine Art Tel to Id – Service oder über andere Protokolle wie z.B. SMS. Damit könnte sich jeder selbst den Client seines Vertrauens aussuchen und alles wäre gut 😉

Diaspora Logo

Diaspora* wurde kaum für „tot“ erklärt und schon steht das nächste Projekt in den Startlöchern! Tent.io soll ein protocol for distributed social networking and personal data storage werden. Alles neu, alles anders, alles besser als OStatus, DiSo oder Diaspora*. Aber mal ganz ehrlich… was haben die Diasporas & Co. bisher geschaffen? Ziel war es Facebooks „Walled Gardens“ aufzubrechen und was kam wirklich dabei rum? Eine ganze Reihe an dezentralen „Walled Gardens“. Na danke!

Seit Chris Messinas DiSO-Projekt schwärme ich ein wenig für das Thema „Dezentrale Netze“ und wie man die Idee am besten technisch umsetzen könnte. Trotz der „Schwärmerei“ ist mir aber durchaus bewusst dass das Thema noch nicht wirklich populär ist und kein wirkliches User-Bedürfnis deckt. Das hängt aber unter anderem damit zusammen, dass bisherige Bemühungen (und Diaspora ist ein Vorzeigebeispiel hierfür) rein technischer Natur sind! Aber:

  • „Open“ und „Dezentral“ sind keine Argumente um sich bei einer neuen Plattform anzumelden (zumindest nicht für die breite Masse).
  • Es ist idiotisch wenn jede Community ihr eigenes „Dezentralisierungsprotokoll“ entwickelt… das führt nämlich dazu, dass Diaspora und StatusNET zwar beide dezentral sind, aber nur die eigenen Netzwerke unterstützen.
  • Jedes neue Protokoll (mal abgesehen von OStatus) erfindet das Rad neu anstatt auf bisherigen Formaten aufzubauen. Warum muss alles JSON sein? RSS und Atom kann jedes Blog und mit ein bisschen „Zauberei“ reicht das vielleicht schon aus.
  • „Open Source“ und die Möglichkeiten das Projekt selber zu hosten überzeugt nur Geeks!

Wenn die großen Netzwerke wie Facebook, Twitter und Google+ sich nicht auf ein einheitliches Protokoll einigen, wird es wohl nichts mit der „dezentralen“ Idee! Ich möchte mich in Zukunft für eine Community entscheiden die meinen Interessen und Wertvorstellungen entspricht und nicht von der Mehrheit meiner Freunde abhängig sein. Wenn alle meine Freunde aber bei Facebook sind, bleib ich auch auf einem offenen und dezentralen Diaspora alleine!

Wir brauchen eine Art XMPP oder POP3/SMTP für soziale Interaktionen, unabhängig von einer spezifischen Plattform und trotzdem von allen unterstützt! Und dann haben auch kleine und unabhängige Projekte wie Diaspora und StatusNET wieder eine echte Chance! Die Zeit die bisher in Spezifikationen aller Art fließt sollte dazu genutzt werden, zuerst einmal Facebook und Google von dem Problem zu überzeugen und sie mit ins Boot zu holen.

…das ist übrigens das Thema meiner Kolumne im nächsten Screengui-Magazin. Also kaufen!

Anfang der Woche hat Martin Weigert schon über Twitters Pläne, die eigenen Tweets mit noch mehr Medieninhalten zu erweitern, geschrieben:

Immer mehr Partnerseiten können zusätzliche multimediale Inhalte im Kontext von Tweets darstellen. Ganz eindeutig ist bisher nicht, wohin diese Reise für Twitter geht.

Aber ich habe mir nichts weiter dabei gedacht… Immerhin macht das Twitter ja schon seit einer ganzen Weile und ich meine mich zu erinnern, irgendwo gelesen zu haben, dass sie dazu oEmbed einsetzen… Also alles in bester „OpenWeb“-Ordnung 🙂

Aber, Geek der ich bin, hab ich mir gestern zufällig einen Quelltext angeschaut in dem ich auf folgendes entdeckt habe:

<meta name="twitter:card" content="summary">
<meta name="twitter:url" content="...">
<meta name="twitter:title" content="...">Code-Sprache: HTML, XML (xml)

…und nach kurzem googlen bin ich auf die Twitter Cards gestoßen, Twitters eigenes, kleines Open Graph Protocol. Mit den Twitter Cards bekommen Seitenbetreiber ein Set an Meta-Tags an die Hand, und Twitter kann diese Informationen nutzen um die tweets mit den oben erwähnten Mediendaten anzureichern.

Example Twitter Card

…und ich wollte mich gerade darüber aufregen, warum Twitter dazu eine eigene Meta-Sprache erfindet, da bin ich in der Doku ironischerweise auf folgendes gestoßen:

You’ll notice that Twitter card tags look similar to OpenGraph tags, and that’s because they are based on the same conventions as the Open Graph protocol. If you’re already using OpenGraph to describe data on your page, it’s easy to generate a Twitter card without duplicating your tags and data. When the Twitter card processor looks for tags on your page, it first checks for the Twitter property, and if not present, falls back to the supported Open Graph property. This allows for both to be defined on the page independently, and minimizes the amount of duplicate markup required to describe your content and experience.

„Ok“, dachte ich… vielleicht reichen die Open Graph Properties ja nicht aus um alle Informationen, die Twitter braucht, abzubilden. Also hab ich mir mal die Mühe gemacht sie zu vergleichen:

Twitter CardsOpen Graph Protocol
twitter:cardog:type
twitter:siteog:site_name
twitter:urlog:url
twitter:descriptionog:description
twitter:titleog:title
twitter:imageog:image
twitter:image:widthog:image:width
twitter:image:heightog:image:height
twitter:player oder twitter:player:streamog:video oder og:audio
twitter:player:widthog:video:width
twitter:player:heightog:video:height

Es lässt sich also prinzipiell alles mit dem Open Graph Protocol abbilden, es fehlen lediglich die Felder twitter:site:id und twitter:creator:id. Aber wegen diesen zwei Feldern muss man doch nicht das ganze Format „kopieren“. Es reicht doch ein kleiner Absatz, wie man den Open Graph mit den proprietären Werten erweitert… So wie das auch Facebook praktiziert:

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:og="http://ogp.me/ns#"
      xmlns:fb="https://www.facebook.com/2008/fbml">
      xmlns:twitter="https://dev.twitter.com/docs/cards">
  <head>
    <title>The Rock (1996)</title>
    <meta property="og:title" content="The Rock"/>
    <meta property="fb:admins" content="USER_ID"/>
    <meta property="twitter:site:id" content="@USER_ID"/>
    ...
  </head>
  ...
</html>
Code-Sprache: HTML, XML (xml)

Hoffentlich überlegt sich das Twitter noch einmal… Wenn nicht, wird dank dieser (und folgender) Redundanzen der <head /> einer Webseite in ein paar Jahren mehr Informationen beinhalten wie der <body />.

…welch ein Over-<head> 🙂

Neben all den negativen Meldungen endlich mal wieder ein Highlight für OpenID: Seit dieser Woche ist PayPal offizieller OpenID-Provider mit allen Schikanen (OpenID 2.0, OpenID Simple Registration, OpenID attribute exchange, OpenID user interface, PAPE specification).

Die Meldung ist nicht nur erfreulich, sondern vielleicht auch die Rettung des etwas angeschlagenen offenen Standards. Trotz des eher hinkenden Vergleichs, wurde OpenID immer mit dem Erfolg von Facebook Connect gemessen. Die OIDF hat es durchweg versäumt den Standard als reines „Werkzeug“ sehen und die Produkte basierend auf OpenID zu promoten. Wie ich schon im Webstandards-Magazin (Ausgabe 9: Pfefferles OpenWeb) schrieb:

Facebook Connect ist nicht wegen seinem proprietären System so erfolgreich und der Misserfolg von MySpaceID hat nichts mit den benutzten offenen Standards zu tun. Promote the utility not the technologie. To reach the majority of users who aren’t familiar with OpenID as a technology, promote the ability to log in using an existing account, not „OpenID“ itself. Ich würde sagen das Problem liegt nicht am Protokoll sondern an den fehlenden sinnvollen Anwendungsfällen. OpenID funktioniert überall da, wo der User einen Nutzen hat ohne zu wissen was unter der Oberfläche passiert, beispielsweise „Sign in with Google“ oder „Sign in with Yahoo!“. Wo bleiben also die Killerapplikationen wie z.B. Paypals angekündigtes Express Checkout auf Basis von OpenID?

Reines Single-Sign-On ist ein Geek-Thema und scheint wohl kein generelles Bedürfnis zu befriedigen. Ein „Mit einem Klick-Bezahlen“ ist dagegen eine enorme Chance für Einkäufer und kleine Verkäufer. Wo man bisher, oft durch die langwierige Anmeldung und das hinterlegen der Kontodaten, trotz günstigerer Angebote doch wieder bei Amazon bestellt hat, bietet PayPal in Zukunft vielleicht die Lösung: Schnelles, unkompliziertes und sicheres Einkaufen mit einem „Klick“.

Hoch lebe OpenID 🙂