Tag: mastodon

Opublikowane w

Idź na socjal

Idź na socjal – tak właśnie można przetłumaczyć GoToSocial, czyli nazwę serwera ActivityPub napisanego w Golangu. Czyli serwera, by zaistnieć w Fediverse. Bo Mastodon może i jest popularny, ale nie jest jedyny.

GoToSocial był moim wyborem do zabawy z Fediverse już dawno temu, jednak wymagania nieco odstraszały. Głównie te związane z VPSem i jego parametrami. Co prawda niby powinno działać na mniej niż 1 GB RAM i kilkanaście GB dysku, ale jakoś nie miałem gdzie tego wcisnąć na istniejących maszynkach. Zwłaszcza, że chodzi wyłącznie o zabawę.

Jak wspominałem we wpisie o Sesji Linuksowej, wygrałem talon na VPS mikr.us. I niedawno go zrealizowałem na potrzeby innego projektu. Zasobów jest tam dużo za dużo, więc idealny moment, by pobawić się GoToSocial. Tym bardziej, że VPS na mikr.us nie pozwala na uruchomienie kontenerów LXC. W każdym razie mi się nie udało, a konsultacja na Discordzie potwierdziła, że się nie da. Za to działa docker.

Nie jestem fanem dockera. Zdarza mi się go używać, ale raczej nie jest pierwszym wyborem. Jednak i Uptime Kuma, i GoToSocial dają obrazy i sensowną – na pierwszy rzut oka – dokumentację. Postanowiłem spróbować.

Z dokumentacji GoToSocial dowiedziałem się, że potrzebuję otwartego portu 443 oraz osobnej domeny dla instancji. Ogólnie wymagania są nieco dziwne. Po pierwsze, nie można wykorzystać dowolnego portu. Na mikrusie to problem, bo o ile możemy sobie przekierować kilka portów, to są to inne porty niż 443. Po drugie, domena jest trwale przywiązana do instancji (a w zasadzie kluczy), co oznacza, że nie można zmienić oprogramowania serwera na tej samej domenie.

Wziąłem zatem darmową (sub)domenę, którą wykorzystam tylko do tego jednego celu i tylko do testu. Mikrus daje normalny dostęp po IPv6, bez konieczności przekierowywania portów, a większe serwery działają w dual stack, wiec stwierdziłem, że instancja będzie dostępna wyłącznie po IPv6.

Ostateczny setup na który się zdecydowałem to: GoToSocial w dockerze (tylko IPv4), nginx na froncie, robiący za reverse proxy, nasłuchujący na porcie 443 i adresie IPv6. TLS od Let’s Encrypt z wykorzystaniem certbota, terminowany na nginx. Dla domeny ustawiłem wyłącznie rekord AAAA. Czemu tak? Bo tak jest najwygodniej i standardowo. Mógłbym pominąć nginx, ale straciłbym wszystkie dodatkowe możliwości typu bezproblemowy rate limit. I musiałbym włączyć IPv6 w dockerze.

Uruchomienie nie było bezproblemowe. Już sama konfiguracja i start dockera sprawiły trudności. Przyczyną były oczywiście uprawnienia do katalogów. Niby jest to pokazane w logach, ale zachowanie jest nieco dziwne, zwł. w kwestii tworzenia nieistniejących katalogów. Jednak w końcu docker ruszył.

Dla odmiany z nginx poszło łatwo. Przykładowy konfig zadziałał niemal od kopa, drobnego dostosowania wymagała jedynie obsługa http2 w starszej wersji nginx. Uroki Ubuntu 24.04 LTS. Gdy już wszystkie znaki na niebie i ziemi wskazywały, że powinno działać, przyszła pora na dodanie użytkownika.

Tu nastąpiło moje lekkie zdziwienie, bo GoToSocial nie oferuje żadnego panelu, jedynie API. Użytkowników zakłada się z wiersza poleceń. Nieco dziwny wybór i raczej nie przysporzy popularności rozwiązaniu, w każdym razie nie poza grupą geeków. Kolejną konsekwencją jest konieczność połączenia się jakimś klientem, bo nie ma interfejsu WWW.

Czyli kolejny problem, bo okazało się, że nie mam dostępu do IPv6 z domu. Ani korzystając z internetu w domu od ISP, ani na telefonie, po wyłączeniu WiFi. To ostatnie mnie zdziwiło, byłem przekonany, że GSM to głównie IPv6. Na szczęście jest Pinafore, czyli klient dostępny w przeglądarce. Do tego tunel SSH do VPSa z IPv6[1], rozwiązywanie nazw DNS po socks proxy i… mogłem zobaczyć swoje konto i napisać coś.

Niektórym to może wystarczyć, jednak idea jest nieco inna. Powinna być możliwa interakcja z innymi instancjami. Wyszukałem jakieś konto w Pinafore, wybrałem follow, powtórzyłem dla kilku innych i… żadnego efektu. Informacja o oczekiwaniu na zatwierdzenie. Tylko te konta nie wymagały zatwierdzania. Sprawdziłem na swoim podstawowym koncie, na którym dla odmiany wymagam zatwierdzenia obserwacji. Ten sam efekt – pokazywało, że czeka na zgodę, ale nie dostałem zapytania o zgodę. No i nie mogłem z podstawowego konta wyszukać konta na testowej instancji. Czyli coś nie działa.

Diagnostyka tego zajęła sporo czasu, usłyszałem, że z IPv6-only bywają problemy, dostałem niepocieszające opisy problemów z GoToSocial i forwardowaniem portów przy NAT i w zasadzie już miałem stwierdzić, że gdzieś zrobiłem błąd, gdy skutecznie zaobserwowałem konto na instancji, która miała tylko adres IPv4 i korzystała z GoToSocial. Natomiast konta na serwerach Mastodon pozostawały niedostępne. Także na tych, które miały tylko IPv4.

Ostatecznie znalazłem instancję Mastodona, posiadającą zarówno adres IPv4 jak i IPv6, gdzie mogłem normalnie obserwować konta[2]. Dostrzegłem też w gąszczu logów błędy 503 przy próbach interakcji z innymi instancjami (subskrybcji). Czyli jakiś problem z kompatybilnością softów GoToSocial i Mastodon, nie u mnie z konfiguracją.

Jak już było wiadomo czego szukać, to ustaliłem, że z Mastodon v4.8.0-alpha.1 działa (dual stack), za to nie działa z v4.8.0-nightly.2026-08-27 (też dual stack) ani v4.7.0 (wyłącznie IPv4). Z kronikarskiego obowiązku, używana przeze mnie wersja to 0.22.1+git-fdff42b.

Co dalej? Pewnie nic. Może jeszcze coś mi przyjdzie do głowy, zasobów na VPS nie potrzebuję, więc zabawek nie zbieram. Przy okazji obserwacja: wymagania podawane przez dokumentację GoToSocial wyglądają na zawyżone, ale może to być kwestia obliczania pod ilość userów i interakcji zewnętrznych. Do samego postawienia opisanego setupu wystarczy spokojnie 0,5 GB RAM, na Ubuntu.

Natomiast w kwestii rozważań o selfhostingu, własnej instancji itp. – wygląda, że rozwiązanie nie robi i ciężko stwierdzić dokładnie, dlaczego. Kolejna lekcja to konieczność posiadania adresu IPv4, co skreśla mikrusa. Może być ciężko podłączyć się do instancji bez takiego adresu. Teoretycznie rozwiązaniem mógłby być Cloudflare, ale na takie eksperymenty zupełnie mi odeszła ochota, skoro nie działa zasadnicza część.

UPDATE: Trochę mi to nie dawało spokoju, więc sprawdziłem większą ilość serwerów. Nie wszystko działa, ale coś tam działa. Problem jest chyba tylko z serwerami Mastodon, ale niestety są to duże instancje, co przekreśla sens rozwiązania. Posty z nich widzę, profile widzę, ale nie mogę obserwować kont.

Nieco rozrywki/stan oprogramowania. Mój GoToSocial obecnie przedstawia się home to 0 users who have written 2 posts; peered with 29 other instances. Off by one?
Przy 11 obserwowanych.

[1] Zupełnym przypadkiem tego samego, na którym działa serwer GoToSocial, ale to bez znaczenia.
[2] Popularne Dziesiony. Szacun dla administratorów.

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

Planeta polskiego Fediwersum

Nadszedł dzień, w którym oficjalnie uruchamiam PPF czyli Polską planetę Fedi. A może Planetę polskiego Fedi? Mniejsza o nazwę. Jest to planeta gromadząca blogi osób, które – w skrócie – mają konto na Mastodonie[1] i piszą po polsku lub są Polakami.

Pomysł i wygląd oczywiście nawiązują do Planety Joggera. Planety zawsze mi się podobały, ale zamknięty charakter nie pozwalał na dodanie większej ilości blogów. Aktualnie na PPF znajduje się kilka blogów osób, które kojarzyłem z posiadania bloga i zareagowały pozytywnie na wstępną propozycję/szkic. Jeśli nadinterpretowałem lub chcecie zmienić nazwę – dajcie znać.

Więcej o Polskiej Planecie Fedi można przeczytać na stronie planety. Wygląd będzie się jeszcze nieznacznie zmieniać z czasem. Blogi można zgłaszać w sposób opisany w FAQ. Całość napędzana silnikiem nanoplanet. Czytać można na stronie, jest też RSS. Kod i konfiguracja będą niebawem publiczne, analogicznie jak przy Planecie Joggera.

Zapraszam blogerów z Mastodona do zgłaszania swoich blogów, a wszystkich do lektury.

[1] Znaczy w Fediwersum. Jak pisałem ostatnio, pomieszane są nazwy w tamtych okolicach.