𝙲𝚑𝚛𝚒𝚜𝚝𝚒𝚊𝚗 𝚂𝚌𝚑𝚖𝚒𝚍𝚝

@t3sserakt @johl Da habe ich nicht hereingeschaut. Ich gehe davon aus, dass es sich um die Schnittstellenbeschreibung (API) für Javascript etc. handelt.

@t3sserakt @johl Ja, das beschreibt aber lediglich die Schnittstelle um DIDs zu erzeugen und auszutauschen. Der PLC Directory Service ist das Telefonbuch von dem ich sprach.

@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.

@t3sserakt @johl 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.

@t3sserakt @johl 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.

@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 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.

@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

@lavievagabonde @johl 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.

@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.

@johl 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.

@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/

@eskensaskia@mastodon.social Wenn Sie das Social im Netzwerk leben, wird es hier funktionieren. Angenehmer ist es allemal.