BlueSky vs Fediwersum: Analiza techniczna decentralizacji w kontekście migracji Wyborczej
Maciej Lesiak
- 7 minut czytania - 1400 słówSpis treści
Inauguruję serię analizującą platformy społecznościowe z perspektywy technicznej, gdzie będę dzielił się szczegółowymi spostrzeżeniami technicznymi dotyczącymi zdecentralizowanych sieci społecznościowych.
Dzisiaj zaczynamy od BlueSky (bsky) to zdecentralizowana platforma społecznościowa, bardzo podobna do Twittera. Jest oparta na protokole AT. Pozwala na większą kontrolę nad danymi użytkownika i moderacją treści.
Tekst podzieliłem na trzy części. W pierwszej omawiam dzisiejszą migrację redakcji Wyborczej na BSKY. W drugiej zastanowimy się, że skoro idziemy w bardziej etyczne i zdecentralizowane, to dlaczego komercyjne a nie Mastodon? Natomiast w trzeciej części wyjaśnię wam o co chodzi z tą rzekomą decentralizacją.
Część 1: Argumenty za opuszczeniem X na przykładzie Gazety Wyborczej
Dzisiaj (28 listopada 2024) Gazeta Wyborcza ogłosiła decyzję o zawieszeniu swojej aktywności na platformie X (dawniej Twitter) i przeniesieniu się na Bluesky. Przyjrzyjmy się szczegółowo przedstawionym argumentom.
Problemy z dezinformacją na X i autentycznością kont
Platforma X w ostatnim czasie, po przejęciu przez Elona Muska, znacząco zmieniła swoje podejście do moderacji treści. Algorytmy platformy aktywnie promują treści kontrowersyjne i emocjonalne, co prowadzi do zwiększonej widoczności kont fejkowych prowadzonych przez trolle internetowe. System weryfikacji użytkowników, po wprowadzeniu płatnej subskrypcji Twitter Blue (obecnie X Premium), przestał spełniać swoją pierwotną funkcję odróżniania autentycznych kont od fałszywych. Co więcej, platforma stała się podatna na zorganizowane kampanie dezinformacyjne, w tym te sponsorowane przez podmioty zagraniczne (Chiny, Rosja). W moim przypadku X to zasób nieskończonej ilości teorii spiskowych podbijanych między innymi przez Muska.
Ograniczenia zasięgów dla wydawców
Obecny model biznesowy X, tak jak większości social mediów, opiera się na zatrzymywaniu użytkowników wewnątrz platformy. W praktyce oznacza to, że posty zawierające linki do zewnętrznych stron internetowych otrzymują znacznie mniejszy zasięg organiczny, żeby po prostu nie odsyłać ich na zewnątrz. Dla mediów, których celem jest kierowanie czytelników do pełnych artykułów na własnych stronach, stanowi to poważne ograniczenie skuteczności komunikacji i promowania własnej platformy. Narracje są przenoszone w większości na serwisy społecznościowe, co prowadzi do postępującej centralizacji i uzależnienia od platform. Dodatkowo, platformy coraz częściej faworyzują treści tworzone przez influencerów i sztuczną inteligencję, spychając profesjonalne dziennikarstwo na dalszy plan.
Zalety Bluesky przedstawiane przez redakcję
Redakcja GW twierdzi, że BSKY oferuje bardziej przejrzysty system wyświetlania treści. Użytkownicy mogą zobaczyć posty w kolejności chronologicznej, bez ingerencji algorytmów promujących określone treści. Platforma nie karze także udostępniania linków zewnętrznych, co jest kluczowe dla wydawców. Dodatkowo, interfejs BSKY jest bardzo podobny do klasycznego Twittera, co ułatwia migrację użytkowników. Najważniejszą różnicą jest jednak moderacja i system rekomendacji feedów, czyli prawdziwie społecznościowy algorytm.
Część 2: Dlaczego nie Mastodon?
Naturalnym pytaniem w kontekście poszukiwania zdecentralizowanej alternatywy jest: dlaczego redakcja nie wybrała federacyjnej sieci Mastodon? To platforma mikroblogowa oferująca prawdziwą decentralizację poprzez protokół ActivityPub, jednak Wyborcza zdecydowała się na inne rozwiązanie. Przeanalizujmy potencjalne czynniki, które mogły wpłynąć na tę decyzję.
Bariery techniczne
Federacyjna natura Mastodona wymaga od użytkowników zrozumienia koncepcji instancji i podejmowania decyzji o wyborze serwera. Dla przeciętnego czytelnika gazety może to stanowić znaczącą barierę wejścia. System federacji, choć technicznie przez sympatyków uznawany jest za doskonały, to w rzeczywistości jest trudniejszy w komunikacji marketingowej i może odstraszać mniej technicznych użytkowników.
Aspekty biznesowe
Mastodon charakteryzuje się znacznym rozproszeniem użytkowników pomiędzy różnymi instancjami. Praktycznie utrudnia to budowanie spójnej społeczności wokół treści wydawcy. Dodatkowo, mniejsza obecność kluczowych źródeł informacji, takich jak politycy czy instytucje publiczne, ogranicza możliwości szybkiego reagowania na bieżące wydarzenia.
Ograniczenia weryfikacji tożsamości (jeden z ważniejszych aspektów)
Warto zwrócić uwagę na to, że istotną wadą architektury Mastodona jest brak zaufanego systemu weryfikacji tożsamości. W systemie zdecentralizowanym i opartym na ActivityPub, każda instancja samodzielnie zarządza tożsamością swoich użytkowników, co utrudnia jednoznaczną weryfikację autentyczności kont na poziomie całej sieci. W dobie dezinformacji i manipulacji dla mediów i osób publicznych stanowi to znaczące wyzwanie, a ten argument był podstawowym dla wyjścia przez redakcję Wyborczej z X’a - nie istnieje w Mastodonie mechanizm pozwalający na jednoznaczne potwierdzenie, że dane konto rzeczywiście należy do danej organizacji czy osoby publicznej.
Ta decentralizacja weryfikacji, może być problematyczna w kontekście profesjonalnego wykorzystania platformy. Szczegóły dotyczące rel-me jako formy weryfikacji czy GPG omówię w SWOT Mastodona. Te sieć nie zapewnia scentralizowanego rejestru tożsamości i może być łatwo podważona przez utworzenie podobnie wyglądającego konta na innej instancji. Dla organizacji medialnych i osób publicznych takie podejście nie zapewnia wystarczającego poziomu wiarygodności i rozpoznawalności w skali całej sieci.
Bardziej szczegółową analizę przedstawię w osobnej publikacji SWOT mastodona. Gdzie podam przykłady.
Część 3: Techniczna architektura modelu federacyjnego BlueSky
Implementacja protokołu AT w BlueSky tworzy model federacyjny, który zachowuje znaczące punkty centralnej kontroli. Aby zrozumieć, dlaczego system ten nie jest prawdziwie zdecentralizowany, musimy przeanalizować jego podstawową architekturę (mam nadzieję, że dobrze to rozumiem).
Podstawowe komponenty architektury
Ta architektura ujawnia trzy krytyczne punkty centralizacji w implementacji BlueSky:
System Tożsamości (Identity System) pełni rolę centralnego autorytetu dla całej autentykacji i weryfikacji użytkowników. Nawet samodzielnie hostowane Serwery Danych Osobistych (PDS) muszą weryfikować swoją tożsamość przez usługę DID BlueSky, co tworzy fundamentalną zależność od infrastruktury BlueSky.
Usługa Przekaźnikowa (Relay Service) działa jako obowiązkowy pośrednik dla całego ruchu federacyjnego. W przeciwieństwie do prawdziwie zdecentralizowanych systemów, gdzie serwery mogą komunikować się bezpośrednio, każda interakcja między serwerami PDS musi przechodzić przez centralny przekaźnik BlueSky. Tworzy to jeden punkt kontroli dla całej komunikacji sieciowej.
Usługa AppView centralizuje dystrybucję i filtrowanie treści. Mimo że użytkownicy mogą implementować własne kanały, podstawowy przepływ danych pozostaje zależny od infrastruktury BlueSky w zakresie dystrybucji i dostępu.
BlueSky ogranicza potencjał decentralizacji protokołu AT
Taki sposób okrojenia możliwości protokołu AT i scentralizowania sprawia, że chociaż organizacje mogą hostować własne instancje PDS, prawdziwa niezależność od infrastruktury BlueSky pozostaje niemożliwa. Każdy komponent w sieci – czy to oficjalny PDS BlueSky, własna instancja, czy implementacja firm trzecich – musi utrzymywać stałą synchronizację z tymi centralnymi usługami, aby uczestniczyć w sieci.
Moja analiza pokazuje, że architektura BlueSky reprezentuje system federacyjny z centralnymi punktami kontroli, a nie prawdziwie zdecentralizowaną sieć. Choć oferuje większą elastyczność niż tradycyjne platformy scentralizowane, zachowuje znaczącą kontrolę poprzez swoją niezbędną infrastrukturę. Prowadzenie własnego PDS zapewnia pewną kontrolę nad fizycznym przechowywaniem i eksportem danych, ale nie dorównuje prawdziwej niezależności oferowanej przez autentycznie zdecentralizowane protokoły jak ActivityPub, NOSTR czy Matrix. System wykazuje jednak dojrzałość techniczną poprzez zaawansowane funkcje, takie jak skuteczna moderacja, społecznościowe tworzenie algorytmicznych kanałów informacji oraz bezproblemowa migracja kont między instancjami PDS. Te cechy uczyniły platformę szczególnie atrakcyjną dla zespołów redakcyjnych i polityków w Polsce.
W przeciwieństwie do prawdziwie zdecentralizowanych platform, takich jak Mastodon, Matrix czy NOSTR, system BlueSky wymaga stałej synchronizacji z centralnym rejestrem. Ten fundamentalny wymóg oznacza, że prowadzenie niezależnej instancji jest niemożliwe bez zgody i współpracy głównego operatora systemu. Przy wszystkich operacjach podlegających weryfikacji przez jeden podmiot, deklaracje platformy o decentralizacji pozostają dyskusyjne.
System Weryfikacji Tożsamości
BlueSky wprowadza istotną innowację w postaci systemu DID (Decentralized Identifiers), który umożliwia wiarygodną weryfikację tożsamości w skali całej sieci. System obsługuje dwie metody weryfikacji: did:plc (wewnętrzny system BlueSky) oraz did:web, pozwalający na wykorzystanie własnych domen internetowych. Ta druga opcja jest szczególnie istotna dla wydawców i osób publicznych - organizacje medialne mogą używać własnych domen (np. @redaktor.gazeta.pl) jako potwierdzonego identyfikatora.
Weryfikacja oparta na domenach zapewnia moim zdaniem wysoki poziom wiarygodności, ponieważ wymaga kontroli nad domeną, co jest szczególnie cenne dla dziennikarzy i polityków potrzebujących potwierdzenia autentyczności swoich kont. Umożliwia także cofnięcie weryfikacji. System oferuje elastyczność w weryfikacji tożsamości, nie zmienia to scentralizowanej natury platformy - wszystkie operacje sieciowe nadal wymagają pośrednictwa centralnej infrastruktury BlueSky.
Wnioski: implikacje dla wydawców
Wydawcy decydujący się na korzystanie z Bluesky muszą być świadomi, że delegują swoją cyfrową tożsamość i reputację do centralnego systemu zarządzanego przez jedną firmę. Oznacza to uzależnienie od decyzji biznesowych i technicznych podejmowanych przez operatora platformy.
Istnieje również ryzyko długoterminowe związane z potencjalnymi zmianami w polityce platformy. Historia X/Twitter pokazuje, jak znaczące zmiany właścicielskie mogą wpłynąć na funkcjonowanie mediów na platformie społecznościowej.
W kolejnych artykułach z cyklu poświęconego platformom społecznościowym przedstawię szczegółową analizę SWOT aplikacji Mastodon i ActivityPub oraz kompleksowe omówienie protokołu NOSTR. Szczególnie interesująca będzie analiza tego drugiego rozwiązania, które prezentuje odmienne podejście do decentralizacji sieci społecznościowych, oparte na kryptografii i architekturze rozproszonej.