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

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.

@t3sserakt @johl

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

@christian @johl

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.

@t3sserakt @johl

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

@t3sserakt @johl

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.

@christian @johl

Das hier? https://web.plc.directory/

Dann verstehe ich, warum du das kritisierst.