Dass Bluesky eine bessere Usability bietet, kann ich nicht ganz nachvollziehen.
Die Usability für DMs, den Einsatz von Hashtags oder Umfragen mit auswählbaren Optionen dort ist nicht besser. Das liegt daran, dass Bluesky diese Features schlicht nicht hat (es ist Beta-Software).
Kleiner Nachschlag zum Thema Usability: Damit man bei Bluesky die eigene Domain als Handle (das mit dem @) benutzen kann, muss man nur im DNS einen speziellen TXT Record mit dem eigenen Decentralized Identifier (DID) eintragen. https://blueskyweb.xyz/blog/4-28-2023-domain-handle-tutorial
Vielleicht fehlt mir hier die objektive Sicht, aber mir persönlich kommt das nicht weniger „nerdig“ oder besser aus UX-Sicht vor als die Auswahl einer Instanz.
@johl Der Vergleich hinkt aber gewaltig. Bei Mastodon muss man eine Instanz wählen.* Bei Bluesky ist das, was du beschreibst, dagegen optional.
*Vorher heißt es: Ach, spielt keine Rolle, nimm einfach irgendeine, kannst du eh ändern. Und hinterher wird man dann für seine Wahl die ganze Zeit angemeckert...
@johl Naja. Ich kenne kein soziales Netzwerk, das diese Funktion überhaupt bietet. Daraus Bluesky jetzt einen Strick zu drehen, ist schon etwas... konstriert. Es gibt sicher Gründe, warum Bluesky problematisch ist, aber das ist es nicht.
Abgesehen davon: Wie würdest du es denn machen, wenn nicht über DNS?
@lavievagabonde @sebwilken Ich musste das nicht.
Auch die Dokumentation bei Mastodon erwähnt das nicht: https://joinmastodon.org/verification
Es gibt auf Github den Vorschlag, so eine Art der Verifikation in Zukunft zusätzlich einzuführen, bisher wurde der Vorschlag weder angenommen noch wurde Code dafür geschrieben: https://github.com/mastodon/mastodon/issues/20030
Sicher, dass du Mastodon meinst?
Bluesky ist auch dezentral und open source entwickelt. Mit dem zentralen Telefonbuch (closed source) bestimmt aber Dorsey (ehemaliger Twitter CEO) wer rein darf und noch sind keine Instanzen zugelassen.
Und es ist kein Blockchain Gewächs (nur die Chefin), sondern hat seine Krippe bei Twitter stehen gehabt. Dorsey hat es ausgefirmt bevor Musk ins Spiel kam.
1/
@johl Die Serversoftware ist frei verfügbar und kann als Insellösung eigenständig betrieben oder in der Bluesky DEV Umgebung gestartet werden. Der verwaltet die Benutzer lokal (wie die Apps im Fediverse), meldet sie aber den zentralen Yellow Pages und das ist closed source. Ein Netzwerk ist ohne die nicht machbar.
Und später kann Dorsey natürlich jede Instanz auch per Mausklick aus dem Netz entfernen. Er bestimmt wer föderieren darf und Andere stellen die Server.
Das ATProtokoll ist die Quelle. Hier ist ein guter Startpunkt:
https://atproto.com/guides/overview#account-portability
Wenn Du Dir die Funktion eines PDS (das ist der eigentliche Server, die Instanz) und dort die Behandlung der DID (die global eindeutige und unveränderlichen ID hinter dem Nutzerprofil) ansiehst, wird das deutlich.
ATProtokoll: https://github.com/bluesky-social/atproto
Personal Data Server (PDS): https://github.com/bluesky-social/pds
Kannst du das detailierter erklären? Ein PDS ist gegenüber einem Anderen gleichwertig. Wie soll das funktionieren, dass ein PDS von einem anderen daran gehindert wird mit wiederum anderen zu föderieren. Klar, es gibt hier die Gefahr eine Fragmentierung. Die gibt es bei Mastodon aber doch auch.
Kann er nicht. Bis zum PDS (einschließlich) ist das beinahe 1:1 vom ActivityPub abgekupfert. Der Unterschied liegt in der DID, die global eindeutig ist, also über alle Instanzen hinweg (wie eine GUUID). Im ActivityPub wird die NutzerID erst durch Angabe der Instanz eindeutig.
Dadurch kann man im BlueSky Netz die Instanz wechseln, die Adresse aber behalten und das machen die über einen zentralen Dienst den ich Yellow Pages nenne (Telefonbuch).
/1
Daher ist es notwendig, dass dieser zentrale Dienst eine Instanz als gültig zertifizieren muss, damit die ihre DIDs veröffentlichen und dann föderieren kann.
Nein. Aus dem Nutzernamen geht nicht hervor auf welcher Instanz er zu finden ist. Der sendende PDS befragt die Zentrale und bekommt die DID zu dem Namen und erst daraus bekommt er die Instanz.
Der Nutzername ändert sich auch nach einem Umzug auf eine andere Instanz nicht. Ein PDS muss die DID also immer in der Zentrale aktualisieren um die Zielinstanz herauszufinden.
Anyway, dieses zentrale Directory ist nicht in Ordnung.
Hier mal ein Beispiel für ein wirklich dezentrales (verteiltes) DID: https://lsd.gnunet.org/lsd0005/
Das "Trust Model" des PLC ist lustig!
https://github.com/did-method-plc/did-method-plc#plc-server-trust-model
Da habe ich nicht hereingeschaut. Ich gehe davon aus, dass es sich um die Schnittstellenbeschreibung (API) für Javascript etc. handelt.
Ja, das beschreibt aber lediglich die Schnittstelle um DIDs zu erzeugen und auszutauschen. Der PLC Directory Service ist das Telefonbuch von dem ich sprach.
Die hält Bluesky PBLLC unter Verschluss. Natürlich könnte man die aus ATProto und PDS ableiten, aber das bringt einen nicht ins Netz - würde nur die Möglichkeit eröffnen ein eigenes aufzusetzen.
Ich sehe das ActivityPub für die Gemeinschaft da doch sehr im Vorteil.
Mache ich ja auch. Ich wollte auch eine Instanz aufsetzen, aber nach Lektüre der Spezifikation hatte ich dann die Motivation verloren.
Die Feeds (eigene Algorithmen) finde ich auch spannend, das ist aber ein Datenschutz-Albtraum. Alles auf Bluesky ist öffentlich. Wenn Du also einen Feed erstellst, kann den jeder nutzen - und den hostest Du selbst auf Deinem Webserver. Die Daten werden also ausgeleitet.
Tatsächlich war die erste Idee das ActivityPub in Twitter zu implementieren. Dorsey behauptete aber der Umzug zwischen Instanzen würde Nutzer ihre Daten verlieren lassen und eine neue Adresse wäre unsexy.
Ich denke er wollte die Kontrolle behalten, aber der Erfolg scheint ihm Recht zu geben. Mal schauen wie lange das anhält. Der Client ist auch nach 2 Jahren nicht einmal lokalisiert.
PBLLC ist eine Personengesellschaft und gemeinsam mit Jeremie Miller (Erfinder von XMPP) bestimmt er wer CEO ist, oder bleiben darf. Mehr Chef geht wohl kaum.