Tag: Facebook

Opublikowane w

Sfederowany problem

Mamy trzy główne topologie czy też modele działania usług w sieci: scentralizowany, sfederowany[1] i rozproszony. Każdy z nich ma swoje wady, zalety i… problemy. W tym wpisie będzie o tym, czemu federacja nie zawsze jest dobrym pomysłem, jaki problem wprowadził z powodu wyboru sfederowanego modelu Mastodon. I co można z tym zrobić.

Wstęp

Na początek dla przypomnienia – albo dla kontekstu – Mastodon to serwer social media, w założeniu mający być – mniej więcej – alternatywą dla Twittera. Działaja w oparciu o protokół ActivityPub. Zamiast jednego, centralnego serwera, działającego pod jedną domeną[2] istnieje wiele serwerów. Każdy z nich ma swoją odrębną domenę, swojego administratora, swoją moderację i swoich użytkowników. A pod spodem – swoją własną bazę danych. Jednak przy tych wszystkich odrębnościach, w przeciwieństwie do sieci scentralizwoanych, serwery wymieniają się między sobą danymi, jeśli zachodzi taka potrzeba. Czyli na Bluesky nie polubimy tweeta, natomiast w przypadku wpisu na Mastodonie (toot) nie ma przeszkód by użytkownik jednego serwera polubił wpis z innego[3].

Typowo za przykład sieci zdecentralizowanej podawane są serwery popularnej usługi, jaką jest poczta elektroniczna (email). Niezależnie, czy „skrzynkę”[4] mamy na Gmail, Outlook, Onecie, Protonie czy własnym serwerze, możemy wysłać mail i za – pośrednictwem protokołu SMTP – dotrze on na serwer odbiorcy.

Osobiście uważam, że lepszym, bliższym przykładem usługi sfederowanej, do której można porównać Mastodona, są grupy dyskusyjne, działające w oparciu o protokół NNTP. Niestety, usługa nie jest już powszechnie używana czy znana, więc jako przykład przybliżający ideę słabo się nadaje. Jednak wydaje mi się lepsza, bo zachodziła interakcja między wieloma użytkownikami, którzy mogli swobodnie wchodzić w interakcję z treściami zamieszczonymi przez innych użytkowników. Nie było określonego przez nadawcę odbiorcy.

Technicznie działało to tak, że administrator uruchamiał serwer NNTP, ustalał z jakimi serwerami wymienia się treściami, jakie grupy, czyli treści będzie utrzymywał na swoim serwerze. I jacy użytkownicy mogą z jego serwera korzystać, czyli pobierać i zamieszczać treści. Z punktu widzenia użytkownika wyglądało to tak, że łączy się do jednego serwera, odbiera wiadomości z wybranych grup dyskusyjnych napisane przez różnych użytkowników. A jeśli coś napisze, to trafia to na wszystkie serwery, na których obsługiwana jest dana grupa.

Problem

Tyle tytułem wstępu, pora przejść do problemu. Serwer Mastodona może postawić każdy. Obecnie działa blisko 10 tys. serwerów Mastodon[5]. Gdy któryś z użytkowników zamieści toot z linkiem do strony WWW, to wszystkie serwery, na których na których znajdują się jego followers (obserwujący), generują podgląd strony. W tym celu każdy z serwerów wysyła żądanie do docelowego serwera WWW w celu pobrania strony? Gdzie problem? Ano w tym, że w przypadku kont z większą liczbą obserwujących, tych serwerów potrafi być wiele. I wysyłają te żądania w zbliżonym czasie. Z punktu widzenia ofiary, czyli serwera WWW do którego link zamieszczono to coś w rodzaju DDoS.

Temat nie jest nowy, był dokładnie opisany w 2022, z wykresami, schematem działania i ilością żądań. Gorąco polecam lekturę, szczególnie jeśli w moim opisie jest coś niejasnego. Jest tam też trochę o zasadności nazywania tego działania DDoSem. Oryginalne zgłoszenie na GitHub jest jeszcze starsze i pochodzi z roku 2017. Sam schemat „ataku” w pewnym sensie przypomina botnet, przy czym kontrolującym byłaby tu dowolna osoba zamieszczająca link w treści toota, a boty wykonują tylko jedno żądanie.

Tyle, że to wystarcza do zakłócenia działania zewnętrznych usług. O tym, że problem nie jest jedynie teoretyczny, świadczą niedawne przykłady z kraju:

Czy linki dodawane na fedi obciążają serwery www? Obciążają, bo po dodaniu linku, każdy sfederowany serwer zaciąga sobie jego podgląd.
[…]
Spotkałem się już z głosami, że to coraz poważniejszy problem, porównywalny z małym atakiem DDOS. Nie wiem na ile wpływa to na obciążenie mojej strony, ale na pewno jest zauważalne. Dlatego będę pamiętał, aby dodawać link nieco wcześniej lub później niż w innych mediach.
Źródło: https://101010.pl/@rdrozd/113668863306405283

To jest problem, który mnie dotknął (blog na WP z wtyczką ActivityPub), po przeprowadzce na mniejszy serwer.
Mimo tego, że śledzących na fedi mam raptem niecałe cztery dychy, to pierwsza publikacja nowego wpisu zamuliła mi stronę na jakieś pół godziny, może dłużej, a logi były pełne błędów 500 i 503 (w tysiącach).
Dzięki pomocy @m0bi ustaliłem co bardziej obciążające wtyczki, wywaliłem je i trochę innych, zostawiając pewnie z połowę. Do tego czyszczenie instalacji i takie tam, a i tak pomogło dopiero zwiększenie limitów serwera. Dzięki temu przydycha po publikacji „tylko” na 5-10 minut :/
Myślałem o rezygnacji z wtyczki AP, ale widzę, że musiałbym też odpuścić wrzucanie odnośników do wpisów na fedi.

To właściwie uniemożliwia funkcjonowanie w fediświecie malutkim amatorskim blogom bez wsparcia dużych platform.
Źródło: https://pol.social/@LukaszHorodecki/113685265406284436

Jeśli chodzi o mnie i ten blog, to z zupełnie innej okazji mam nieco stuningowaną konfigurację, relatywnie mało obserwujących, a serwer uruchomiony na dedykowanym VPSie. Więc jedyne co zauważam – poza wpisami w logach – to kilkusekundowa mniejsza responsywność serwera[6].

Dlaczego problem dotyczy Mastodona, a nie innych wspomnianych wcześniej sfederowanych usług? Powody są dwa. Po pierwsze, poczta elektroniczne czy grupy dyskusyjne działają wyłącznie same ze sobą, nie wchodząc w automatyczne, masowe interakcje z zewnętrznymi usługami. Po drugie, zjawisko popularny serwis linkuje do mniejszego i ten nie daje rady obsłużyć ruchu jest znane od dawna pod nazwą Slashdot effect. Tyle, że w tamtym przypadku ruch inicjowany był przez ludzi, a nie automatycznie. Czyli problem wynika z architektury rozwiązania i implementacji.

Rozwiązanie

Możliwych rozwiązań jest kilka. Pierwsze, najprostsze, to usunięcie interakcji z zewnętrznymi usługami w ogólności, a funkcjonalności generowania podglądu w szczególności. Tyle, że to obecnie trochę standard w social media i Mastodon wyglądałby ubogo.

Kolejne rozwiązanie to wprowadzenie jakiegoś rozwiązania typu cache, działającego w obrębie całej sieci. Czy to w stylu: serwer, którego użytkownik zamieszcza link, jego serwer generuje podgląd i rozsyła go razem z tootem. Czy też w postaci zewnętrznego, wspólnego dla wielu instancji Mastodon, serwisu służącego do generowania podglądu. Wreszcie można wyznaczyć główne serwery, które będą generować podgląd, a pozostałe będą polegać na ich danych. Tyle, że wszystkie te rozwiązania – może pierwsze najmniej – podważają niezależność działania poszczególnych serwerów.

Innym rozwiązaniem jest zmniejszenie ilości serwerów, czyli większa koncentracja użytkowników. Jednak nie zanosi się na to i trudno w praktyce na to liczyć.

Konsekwencje

Z jednej strony trudno posądzać autorów rozwiązania o celowe stworzenie takiej architektury, by powodowała problemy zewnętrznych serwisów, Z drugiej strony jeśli coś wygląda jak kaczka, chodzi jak kaczka i kwacze jak kaczka... Problem jest znany twórcom Mastodona od blisko dekady i… jest uparcie ignorowany.

Piszę o tym, bo co jakiś czas wraca temat wykorzystywania scentralizowanych platform social media (Facebook, X/Twitter) przez instytucje publicznie. I pojawia się pomysł/propozycja wykorzystania Mastodona jako alternatywy. Według mnie, przy obecnym stanie rzeczy, jest to pomysł niepoważny. Trudno oczekiwać, by instytucje państwowe czy samorządowe wykorzystywały narzędzia, o których wiadomo, że mogą być szkodliwe dla innych usług w sieci.

Mnie osobiście ten stan rzeczy zniechęca do korzystania z platformy. Nie czuję się komfortowo z tym, że mój błahy wpis może powodować problem u jakiejś strony trzeciej. Może nie na tyle, by przestać zupełnie z niej korzystać, ale na tyle, by ograniczyć aktywność. Staram się linkować tylko do swoich stron i nie podbijać (boost) wpisów z linkami.

UPDATE. Jeszcze – zanim nastąpi rotacja logów – ilość żądań GET do wpisu. Pierwsze odwołanie 16:44:36, następnie, per minuta:
16:44 – 67
16:45 – 201
16:46 – 3
16:47 – 42
16:48 – 22
16:49 – 5
Praktycznie wszystkie pochodzą od botów (zawierają słowo Bot).
Łączna ilość GET w dniu 06.03.2026 – 516, z czego 431 zawierało słowo Bot.

[1] Znany też jako zdecentralizowany.
[2] Uproszczenie, w praktyce scentralizowane serwisy mają wiele serwerów, ale dla łączącego z zewnątrz użytkownika jest to niezauważalne.
[3] Uproszczenie, serwery muszą dopuszczać federację między sobą, użytkownicy nie mogą się blokować. Jednak stan domyślny i wyjściowy jest taki, że mogą.
[4] Czyli adres email.
[5] Źródło, Marzec 2026, tylko serwery działające w oparciu o oprogramowanie Mastodon. W praktyce jest więcej kompatybilnego oprogramowania o podobnym schemacie działania.
[6] Dla pamięci: load average 9,95, 3,51, 1,25 w po kilkudziesięciu sekundach od zamieszczenia tego wpisu. Możliwe, że zasługa popularnych tagów, nie ilości obserwujących. Typowo jest load average: 0,17, 0,36, 0,18.

Opublikowane w

Facebookowe blokady

Niedawno Facebook najpierw zablokował wpis CERT Polska dotyczący scamu za pośrednictwem reklam na Facebooku. Potem usuwał posty, które odwoływały się do zablokowanego wpisu. A także blokowano profile, które zamieszczały te posty np. zablokowany został profil Sekuraka.

Bez dwóch zdań wtopa, w dodatku komunikat przy blokadzie strony Sekuraka jest zupełnie od czapy (jakie podszycie się?) i nie tak powinno to wszystko zadziałać, ale… spróbuję pobawić się w adwokata diabła i poszukać jasnych stron. Dla jasności: raczej nie korzystam z FB, od lat.

  • Facebook zna problem oszustw i ma jakieś narzędzie do wykrywania podejrzanych treści. Raczej nie działa ono w reklamach (hrhrhr), przynajmniej nie skutecznie, ale coś jest. Nieoczywiste w porównaniu z innymi platformami.
  • Blokady są automatyczne i szybkie. Zaleta, bo ogranicza zasięgi faktycznych postów z naruszeniami. W przypadku jakiegokolwiek ręcznego blokowania czas byłby wielokrotnie dłuższy.
  • Można odwołać się od decyzji i wygląda, że jest to rozpatrywane szybko i sensownie.
  • Działanie jest konsekwentne, tj. zablokowana została nie tylko pierwotna treść zidentyfikowana jako szkodliwa, ale i późniejsze odniesienia do niej.

Automatyczna klasyfikacja treści nie jest trywialna, szczególnie, jeśli opisują one zabronione rzeczy, w dodatku z przykładami. Zresztą wiadomo, że błędne klasyfikacje, w obie strony, zawsze będą się zdarzały. Nasunął mi się się pomysł whitelistowania profili, bo oczywiste jest, że profile związane z IT security będą pisały o nadużyciach w tym zakresie ale… takie wyjątki musiałyby istnieć dla każdej branży. No i whitelista profili jest niebezpieczna, bo w przypadku włamania i przejęcia dostępu do profilu pozwoliłaby bezkarnie zamieszczać/podbijać szkodliwe treści.

Ciekawe czy Facebook w jakikolwiek sposób odniesie się do tej sytuacji, wprowadzi korekty w mechanizmie blokad? Jeszcze gdyby w reklamach zaczęli walczyć ze scamem choć w połowie skutecznie jak z opisami zagrożeń…

I oczywiście jest to kolejne przypomnienie o zagrożeniach płynących z życia na platformie, nad którą nie ma się kontroli i na której obecność nie zależy od widzimisię jej administratora czy moderatora. Warto zapewnić własny, możliwie niezależny kanał dotarcia do użytkowników (lista mailowa, RSS) i go propagować. Żeby jeszcze tylko ludzie chcieli z niego korzystać…

Opublikowane w

Mastodon

Szczeżuja namawiał, namawiał i w końcu namówił. Znaczy nie namawiał wprost, ale pisał o zaletach fediwersum i jakoś tak mnie zachęcił do założenia konta Mastodon[1]. Nie żeby trzeba było mnie specjalnie namawiać, bo od zawsze miałem słabość do alternatywnych rozwiązań i DIY. Nawet od dłuższego czasu produkcyjnie jest w użyciu Diaspora*.

Geneza

Czemu w ogóle wziąłem się za Mastodona, skoro jest Diaspora*, której używam od kilku lat? To, że Diaspora to niby bardziej Twitter, a Mastodon to niby bardziej Facebook nie miało znaczenia. Zresztą piszę „niby bardziej”, bo odnoszę dokładnie odwrotne wrażenie. Możliwe, że kwestia mojej instancji Mastodona, która limituje ilość znaków we wpisie do 500. Nie żeby mnie to jakoś bolało, ale Diaspora* chyba nie limituje. Przynajmniej nie zauważyłem. No ale może znowu może to być kwestia konkretnej instancji.

Poza tym, że lubię testować nowe rzeczy, poszło o ideę fediwersum i chęć sprawdzenia jak to działa w praktyce. Diaspora* niby umożliwia wymianę z innymi instancjami, ale robi to swoim własnym protokołem. Niespecjalnie przez coś innego używanym, jak zeznaje anglojęzyczna Wikipedia. Były plany implementacji Activity Pub, ale zostały porzucone. Brak wsparcia standardu Activity Pub źle wróży na przyszłość. No i nie ma tak ciekawych implementacji jak Pleroma, czyli własny serwer, który można uruchomić na Raspberry Pi.

Mastodon - propozycja logo
Propozycja logo fediwersum. Tęczowy pentagram. Szatan gender. Gównoburza za 3…2…1…
Źródło: https://en.wikipedia.org/wiki/Fediverse#/media/File:Fediverse_logo_proposal.svg

Pozytywy

Jednak miało być o Mastodonie. Na początek dobre wiadomości. Coś jest i nawet działa. Nie jest to wielkie zaskoczenie, bo Diaspora* działała lata temu. Rejstracja konta na wybranej instancji trwała moment. W przeglądarce WWW jest OK i używalnie. Na mobilki są aplikacje. Jako klienta na Androida wybrałem Tusky, czyli jeden z popularniejszych klientów. Daje radę. I chyba nawet wygodniej mi się przegląda, czyli czyta, niż przez WWW.

Kolejny pozytywny aspekt – jest jakieś życie. Są ludzie, nawet dość regularnie piszą. I pisząc ludzi mam na myśli ludzi, nie konta, na których zapięty jest jakiś bot czyli automatyczny feed.

Są integracje. Na przykład WordPress ma wtyczki, które pozwalają zamieszczać informacje o nowych wpisach na Mastodon[3]. W przypadku Twittera korzystam do tego z 3rd party serwisu, a na niszowego Blablera sam dopisałem stosowny skrypt.

Sama platforma też generalnie działa i nie zauważyłem problemów z korzystaniem. Poza paroma zgrzytami, o których niżej.

Mastodon – negatywy

Niestety, porównując z Twitterem widać braki w funkcjonalnościach. Można followować[2] ludzi ale… już nie hashtagi. Follow użytkownika z innej instancji nie jest intuicyjny. Przynajmniej przez przeglądarkę. Ewentualnie są bugi. Objawia się to tym, że po wejściu na profil ofiary zawsze aktywny jest przycisk follow. Nawet, jeśli już obserwujemy osobę.

Wiele instancji daje się we znaki także gdy chcemy poznać obserwujących dane konto. Nie jest to proste ani dostępne w zasięgu jednego kliknięcia. Tusky w ogóle pokazuje chyba tylko followersów z naszej instancji i nie ma możliwości podejrzenia pozostałych. Przynajmniej ja nie znalazłem, a patrzyłem w ustawieniach, czy nie mam czegoś wyłączonego. Z kolei Mastodon przez WWW wyświetla komunikat:

Followers from other servers are not displayed.
Browse more on the original profile

Czyli da się, choć wymaga dodatkowego kliknięcia. Porównując z rozwiązaniami scentralizowanymi – średnie.

Edycja posta w Diasporze jest wygodniejsza. Po przyzwyczajeniu i zapamiętaniu podstaw składni, Markdown jednak robi robotę, szczególnie na mobilkach, gdzie nie mamy wygodnego dostępu do klawisza ctrl. Mastodon tego nie ma – po prostu wpisuje się tekst. W 99% niekrytyczne.

Kolejna sprawa jest poważniejsza. Rozproszenie powoduje, że w przypadku zamieszczenia linka na przez popularne konto, następuje wiele pobrań przez wszystkie serwery obserwujących daną osobę, w celu wygenerowania podglądu. Taki DDoS przez pobieranie podglądu strony. Efekt można zobaczyć w wątku, z którego dowiedziałem się o sprawie. Było zgłoszone jako issue na GitHubie, ale nie zostało rozwiązane. I nie wiem czy zostanie, bo na szali jest wolność i autonomia działania instancji.

Największa wada w stosunku do „dużych” platform: mało ludzi, mało treści. O ile na Twitterze bez problemu jestem w stanie znaleźć kolejne kilka kont, których mógłbym chcieć followować, to na Mastodonie jest to wyzwanie. Może kwestia ilości kont, może kwestia architektury, a może jestem po prostu za krótko na tej platformie i z czasem się to zmieni? W każdym razie zauważam to i nie cieszy mnie.

Mastodon czyli wolność

No i na koniec coś co pewnie nie dotyczy całego Mastodona, ale akurat serwera, na którym mam konto i wydaje mi się śmiesznym ograniczeniem, jeśli chodzi o wolną platformę. Zasady serwera mówią, że nie wolno używać nienadzorowanych botów kopiujących z jednego miejsca na Mastodon i że nie wolno crosspostować z Twittera. Kierunkowo, bo w drugą stronę można. Zresztą jest to później wprost napisane:

Cross-posting from Mastodon to other platforms is fully permitted. Cross-posting into Mastodon from another platform is not permitted.

Nie przeszkadza mi to. Gdyby było inaczej mógłbym przecież założyć konto na swoim serwerze, albo postawić własny, nieprawdaż? Natomiast kojarzy się mocno z odpowiedzią Kalego na pytanie co to jest dobry uczynek? I rodzi pytania o kwestie wolności, możliwość działania na większą skalę i ogólnie przyszłość. Raczej przyszłość odległą, więc odpowiedzi nie wydają mi się w tej chwili zbyt istotne.

Podsumowanie

Mastodon przy odrobinie samozaparcia nadaje się do użytku. Koncepcja jest ciekawa, choć ma przed sobą kilka wyzwań. Zdecydowanie wymaga wygładzenia, jeśli chce móc konkurować z „dużymi” na masową skalę. Gdybym miał bawić się w przepowiadanie przyszłości, to jest spora szansa, że Mastodon wchłonie Diasporę. I bardzo mała, że w przeciągu najbliższych kilku lat stanie się zauważalną alternatywą dla Facebooka czy Twittera. Nawet, jeśli moda przetrwa.

Niemniej, u mnie zostanie. Prawdopodobnie właśnie pomału kanibalizując Diasporę.

[1] Jak wynika z wpisu, z kolei Szczeżuję do założenia Mastodona zainspirowałem ja, przy pomocy Diaspory. Rekurencja…
[2] Przydałby się polski odpowiednik angielskiego follow. Niby jest śledzić, ale – podobnie jak obserwować – to pasywna obserwacja, z boku, bez aspektu podążania czyjąś ścieżką, popierania.
[3] Jak widać na przykładzie tego wpisu, wtyczka nie zadziałała. Przyczyna nieznana i nawet nie wiem jak to debugować.
UPDATE Po bliższym przyjrzeniu się opcjom, okazało się, że nie zaznaczyłem opcji „toot on mastodon” przy publikacji wpisu. O tyle bez sensu, że w opcjach wtyczki mam wybrane „autopost new posts”.