Tag: sieć

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

LinkedOut

Konto na portalu LinkedIn założyłem dawno temu. Miało być trochę takim CV online, trochę miejscem gdzie można „pokazać się” i dać się znaleźć pracodawcom. Szybko okazało się, że nie do końca to działa i głównie zbieram ludzi, z którymi zetknąłem się zawodowo. I znajomych, których znam niekoniecznie zawodowo, ale też uczelnie itp. Wszytko niby zgodnie z założeniem, bo edukacja, umiejętności, doświadczenie zawodowe, ba, nawet to CV online/historia zatrudnienia coś tam pokazuje. Czy też może raczej pokazywałoby, gdybym tylko przyłożył się do uzupełniania.

Ciekawe oferty pracy? No powiedzmy, że coś tam było, ale takich naprawdę ciekawych i dopasowanych – mało. Szczególnie przez pryzmat lat. Faza, gdy zdecydowałem się przejść do rozmowy rekrutacyjnej – może kilka razy w historii. No ale też nie miałem parcia na to. Więc powiedzmy, że w kwestii zawodowej LinkedIn jako tako daje radę. W kwestii socjalnej (choć nie taka wg mnie jest rola) było dość przewidywalnie i nudno. Chwalenie się osiągnięciami, zmianą pracy, szkoleniami, rocznicami. Not great, not terrible.

I jakiś czas temu to wszystko zaczęło się zmieniać. Niekoniecznie na lepsze. Zaczęło pojawiać się więcej treści zbliżonych do Facebooka. Nie czysto zawodowych, niekoniecznie prawdziwych, obliczonych na zaangażowanie. To, co kiedyś było na FB na grupach tematycznych, albo po prostu na FB, zaczęło się pojawiać na LinkedIn. Narzekania na usługi firm, promowanie własnych usług przy pomocy wymyślonych historii i czego nauczyło mnie to o prowadzeniu biznesu. Rzyg.

Tyle jeśli chodzi o użytkowników i ich podejście, ale sam portal nie pozostaje w tyle. Pojawiły się jakieś mało sensowne gry w które rzekomo grają znajomi z firmy (przy czym każdy pyta, kto gra, bo on nie). Obliczone oczywiście na wywołanie zaangażowania i otwarcie aplikacji. Która, po otwarciu, już coś podsunie. Czy to więcej powiadomień o postach znajomych, czy po prostu treściach, które są trending.

Wiele sensownych organizacji z mojej bańki (niekoniecznie firm, choć firmy także) używa teraz combo w postaci Discord plus LinkedIn jako podstawowego sposobu informowania o organizowanych wydarzeniach. Nie jest to dla mnie niezrozumiały wybór, bo edukacyjnie/zawodowo czy nawet hobbystycznie ma sens. Ma też sens ze względu na nakład pracy z utrzymaniem – LinkedIn czy Discord oznaczają niewielki narzut. Zarówno po stronie zamieszczających, jak i odbiorców. Choć nie wiem, na ile pewne jest informowanie poprzez LinkedIn – algorytm może ukryć, a wiara, że ludzie korzystają może być zbyt optymistyczna. Istnieje co prawda ryzyko konieczności płatności lub odcięcia kanału, ale… mało prawdopodobne (odcięcie) i zapewne akceptowalne (płatności). No i teoretycznie wygodne dla użytkowników, bo zwykle mają już te platformy. Dla pozostałych jest – czy raczej: bywa – RSS lub lista mailowa.

Złapałem się na tym, że większość nieinteresujących powiadomień na telefonie pochodzi z serwisu LinkedIn[1]. Szczególnie irytujące były te o grach. Myślałem o wyłączeniu powiadomień zupełnie, jednak skoro portal stał się jednocześnie trochę feedem o eventach, to nie chciałem tego tracić. Pewnie FOMO, bo tak naprawdę o eventach i tak dowiaduję się z innych źródeł. Postanowiłem sprawdzić, czy mogę wyłączyć tylko powiadomienia push z LinkedIn dotyczące gier. Okazało się, że tak. Przy okazji zobaczyłem, że ustawienia dotyczące powiadomień w aplikacji są bardzo rozbudowane i granularne.

Wyłączyłem te o grach i… nie pomogło. Tzn. pomogło częściowo. Te o grach przestały przychodzić, ale nadal za większość powiadomień odpowiada LinkedIn. Zacząłem grzebać w ustawieniach i wyłączać kolejne rzeczy. Na pierwszy ogień poszły powiadomienia push. I znowu – niezbyt to pomogło. Mimo wyłączenia powiadomień push w większości kategorii, nadal przychodzą. Kolejnym krokiem jest wyłączenie powiadomień pochodzących z aplikacji. Stopniowo to robię – staram się, by każde nietrafione powiadomienie skutkowało wyłączeniem kolejnego w ustawieniach. Nie wykluczam, że wkrótce wyłączę powiadomienia z LinkedIn na telefonie zupełnie, czyli 2026 może być u mnie rokiem bez LinkedIn (na telefonie).

Tymczasem wpadłem na pomysł, jaki system powiadomień byłby rozsądny. Po prostu każda aplikacja powinna mieć obowiązek udostępniania maksymalnej liczby powiadomień w ciągu dnia/tygodnia. Oczywiście powiadomienia transakcyjne, potwierdzanie logowania i alerty bezpieczeństwa wyłączone z limitu. I wtedy określalibyśmy, że drogi serwisie, możesz mi wysłać w ciągu tygodnia 5 powiadomień, kombinuj, by były jak najbardziej wartościowe. Co by to dało? Totalną zmianę pozycji. Serwis musiałby dobierać interesujące treści, agregować treści. Użytkownik nie mógłby być bombardowany nadmierną ilością powiadomień.

Można to zaimplementować oczywiście inaczej, na poziomie systemu. Tyle, że wtedy jest ryzyko pominięcia powiadomień transakcyjnych itp. Jednak nie każda appka takie posiada, więc coś takiego też bym chętnie zobaczył. Pewne możliwości ustawień powiadomień już istnieją w systemie Android. Zacznę od uruchomienia historii powiadomień… (Settings -> Notifications -> Notification history).

UPDATE: Dobrzy ludzie podpowiedzieli, że nie trzeba włączać historii powiadomień. Wystarczy wejść w Settings -> Apps i dla każdej aplikacji można sprawdzić, ile powiadomień wysłała. Twarde dane potwierdzają, że appka LinkedIn jest u mnie w ścisłej czołówce. I to w porównaniu z appkami, których aktywnie używam i chcę z nich powiadomienia. W dodatku po częściowym wyłączeniu powiadomień…

[1] Swoją drogą, jeśli appka LinkedIn jest u mnie najbardziej agresywną, to czuję, że i tak mam mało powiadomień. Ale tak, nie mam np. FB na telefonie.

Opublikowane w

Mastodon backup

Kolejna w stosunkowo krótkim czasie, ale dość długa awaria jednego z liczniejszych serwerów Mastodon w Polsce, pol.social, dała okazję do bliższego przyjrzenia się możliwościom backupu. Okazało się, że ludzie się przenoszą na inne serwery i… nie jest to takie proste, szczególnie, gdy dotychczasowy serwer nie działa.

W normalnych warunkach migracja na Mastodonie polega na wskazaniu nowego miejsca, gdzie ma znaleźć się konto. Przenoszeni są m.in. obserwowani, obserwujący, ale treści (tooty, czyli dopowiednik postów) zostają na starym serwerze. Nie ma możliwości przeniesienia treści na nowy serwer, przynajmniej oficjalnej. Zresztą byłoby to trudne, bo wszystkie istniejące odnośniki do niej, wątki, i tak przestaną działać. Kwestia niezbyt szczęśliwego projektu protokołu.

Istnieje nieoficjalne rozwiązanie slurp, które zostało zaprojektowane do działania z GoToSocial. Jeden serwerów ActivityPub, raczej pomyślany o małych, samodzielnie utrzymywanych instancjach. Polega na umieszczeniu starych tootów na serwerze z oryginalnymi datami. Wątki i odnośniki nadal przestają działać, jeśli serwer na którym były umieszczane zostanie wyłączony. Jednak można mieć przynajmniej swoje wpisy w formie „ciągłej”, razem z nowymi, które będą już pełnoprawne. Nie jest to rozwiązanie idealne, ale lepsze, niż nic.

Mastodon pozwala na wykonanie pełnej kopii, eksportu danych, raz na siedem dni:

You can request an archive of your posts and uploaded media. The exported data will be in the ActivityPub format, readable by any compliant software. You can request an archive every 7 days.

Niezależnie od tego, można – czy może bardziej: trzeba – pobierać formacie CSV dodatkowe ustawienia swojego profilu, np. obserwowanych, banowanych, bookmarki czy blokowane domeny. Trzeba, bo tych danych nie ma w tworzonym archiwum. A szkoda.

Zrobiłem prosty skrypt, który – nie wymagając logowania w przypadku publicznej widoczności – wyświetla obserwowanych. Wg mnie to najważniejsza, najtrudniej odtwarzalna informacja, poza samą treścią. Można go użyć np. w trakcie robienia backupu danych, jako jednego z elementów wykonywanych przez skrypty do backupu.

Włączyłem tworzenie archiwum i… po 20 minutach nadal wyświetlał informację, że tworzy archiwum. Przynajmniej tak pokazywała strona, bo po odświeżeniu strony jednak pojawił się gotowy do pobrania plik. Zapewne był już wcześniej, tylko błąd w Mastodon powoduje, że nie ma informacji o zakończeniu tworzenia.

Sam plik zawiera kilka plików JSON oraz drzewo katalogów z grafikami. W samych grafikach trudno się zorientować – tytuły plików i struktura katalogów nie są w formacie czytelnym dla człowieka.

Fun fact: archiwum pobrałem głównie po to, żeby łatwo móc przeszukiwać treść swoich postów. Wyszukiwarka na Mastodonie jest i niby działa, ale jednak wygodniej mi korzystać z grep w wierszu poleceń.