Własna instancja Mastodona dla nietechnicznych

Popularność sieci społecznościowej Mastodon stale rośnie, a kolejni ludzie uciekają z tonącego Twittera właśnie do zdecentralizowanego Fediverse’u. o ile czytasz ten wpis, a jeszcze nie do końca rozumiesz ideę Fediverse czy choćby Mastodona to odsyłam do mojego wpisu na ten temat. Muszę przyznać, iż bardzo, ale to bardzo, wsiąknąłem w Fedi, więc w pewnym momencie postanowiłem, iż uruchomię swoją własną instancję. Oczywiście nie mówimy tutaj o czymś dużym, bo nie mógłbym sobie czasowo pozwolić na zapewnienie konserwacji serwera i chociażby moderacji treści na odpowiednim poziomie. Od początku myślałem o przestrzeni jedynie dla siebie, taka Single User Instance. Tak się składa, iż jakiś tydzień temu uruchomiłem taką instancję, zrobiłem to najniższym możliwym nakładem pracy przy zachowaniu przy tym najniższego możliwego kosztu. W tym wpisie podzielę się jak to dokładnie wyglądało w moim przypadku.

https://mastodon.tomaszdunia.pl

Dostępne sposoby

Jest wiele sposobów na uruchomienie swojej instancji. Można to zrobić na serwerze postawionym u siebie w domu (np. Raspberry Pi, Terminal czy też po prostu stary komputer) lub na wynajmowanym VPSie. Można przejść przez całą instalację krok po kroku tak jak to jest w dokumentacji lub też skorzystać z gotowego środowiska do uruchamiania takich rzeczy jakim jest np. Yunohost, który jest znacznie przyjaźniejszy, szczególnie dla niezbyt technicznych osób. Ciekawą opcją jest także skorzystanie z oferty DigitalOcean, a konkretnie czegoś co się nazywa 1-Click App Marketplace, który jest swego rodzaju sklepem z aplikacjami, które uruchamia się w chmurze przysłowiowym jednym kliknięciem, a nazywane są one Droplets (z ang. kroplami). Dla Mastodona istnieje właśnie taki Droplet. Jest to bardzo fajna opcja, bo z jednej strony łatwo się ją uruchamia, a z drugiej po wszystkim otrzymujemy pełen dostęp do serwera i działającego na nim oprogramowania, co pozwala nam na pełną konfigurację naszej instancji, oczywiście o ile mamy umiejętności i wiedzę jak to zrobić. Haczyk jest taki, iż to rozwiązanie kosztuje niemało, bo koszt uruchomienia najtańszej instancji to $12 miesięcznie (1vCPU, 2GB RAM, 50GB przestrzeni dyskowej i limit 2 TB transferu miesięcznego).

Jednakże istnieje jeszcze jeden sposób, który nazwałbym dedykowanym dla osób nietechnicznych, lub po prostu nie mających ochoty poświęcać kilku wieczorów na walkę z ciągle niedziałającą konfiguracją, czytanie dokumentacji czy też szukanie rozwiązania problemu na StackOverflow i wkurzania się, iż tak naprawdę był banalny do rozwiązania. Tym sposobem jest skorzystanie z tzw. Managed Hosting’u (z ang. hosting zarządzany). Polega to na tym, iż płacimy komuś za uruchomienie dla nas instancji, wykonanie podstawowej konfiguracji i późniejsze pilnowanie jej prawidłowego działania. Plusem tego rozwiązanie jest to, iż zostaniemy poprowadzeni za rączkę, a więc nie jest od nas wymagana praktycznie żadna wiedza techniczna. Do tego nie wychodzi to bardzo drogo, bo na moim przykładzie mogę powiedzieć, iż kosztuje to 5 euro miesięcznie (w przeliczeniu na złotówki to niecałe 25 zł). Minus to brak dostępu do maszyny, na której stoi instancja, a także brak dostępu do jej kodu. Odbiera to możliwość bardziej zaawansowanej konfiguracji i personalizacji.

Przebieg tworzenia mojej instancji

Na samym wstępie chciałbym rozwiać wszelkie wątpliwości, które mogą się pojawić, i zadeklarować, iż żaden z linków zawartych w tym wpisie nie jest afiliacyjny, nie czerpię żadnych korzyści finansowych z polecenia tego, a nie innego sposobu.

Jako managed hosting dla mojej instancji wybrałem ossrox.org, który po krótkim badaniu rynku okazał się dostawcą z najlepszym stosunkiem ceny do jakości, a może raczej oferowanych parametrów. Dodatkowo wygląda na to, iż jest to dość mała firemka prowadzona przez dwóch Niemców, więc stwierdziłem, iż jest szansa iż będą bardziej elastyczni od większych dostawców. Z perspektywy czasu już mogę powiedzieć, iż w sporej części miałem rację, bo w Ossrox dało się ustawić parę rzeczy, które są niekonfigurowalne np. w masto.host. Wybrałem najniższy pakiet Familie, który kosztuje 5 euro za miesiąc. Przy wybieraniu hostingu zarządzanego najważniejsze na co trzeba zwracać uwagę to ilość oferowanej przestrzeni dyskowej. W pakiecie Familie w Ossrox mam 30GB, to w mojej ocenie OK, ale pełnią szczęścia byłoby mieć ok. 100GB lub chociaż choćby 50GB. Oczywiście to wszystko zależy od tego jak korzysta się z Mastodona, a konkretnie od tego ile osób się obserwuje i ile danych te osoby generują (głównie mowa tutaj o filmach i zdjęciach, które najbardziej zapychają dysk instancji). Patrząc na własnym przykładzie – mam ok. 300 obserwowanych, którzy przy 3 dniowej retencji danych (o tym szczegółowo jeszcze później) generują ok. 6 GB danych. A więc można przyjąć, iż jedna osoba przez jeden dzień generuje ok. (6000 / 3 / 300 =) 6.6MB danych. Zatem 30GB pamięci powinno mi, przy zachowaniu tych ustawień, wystarczyć na wariant, w którym obserwuję 1500 osób (5 razy więcej niż tego potrzebuję). W razie jakby to było mało to można jeszcze retencję danych ograniczyć z 3 do 2 dni i wtedy maksymalna możliwa liczba obserwowanych mogłaby w teorii sięgnąć 2250 kont.

Przed rozpoczęciem procesu zakupu usługi w Ossrox proponuję nabyć domenę, która zostanie podpięta pod naszą instancję. Ja w tym celu stworzyłem subdomenę dla mojego adresu bazowego – mastodon.tomaszdunia.pl. Nie ma znaczenie jaką domenę będziecie mieli, grunt to mieć możliwość zmiany jej konkretnych rekordów DNS – A (dla IPv4) oraz AAAA (dla IPv6) lub CNAME. Chodzi o to, żeby wskazać w ustawieniach domeny adres serwera, do którego ma ona kierować. W takim przypadku domena może być zarejestrowana u dostawcy numer 1, a serwer być wykupionym u dostawcy numer 2 i poza odpowiednim przekierowaniem nie muszą oni mieć ze sobą nic wspólnego.

Strona Ossrox jest niestety w całości po niemiecku. Wymieniłem choćby kilka maili w tej sprawie z właścicielami oferując im, iż pomogę w tłumaczeniu. Są oni jednak mocno zapracowani, a do tego chcą rozpocząć cały proces od przetłumaczenia polityki prywatności (w sumie rozsądne podejście), a z tym raczej nie byłbym w stanie im pomóc. Tak czy owak, każdy translator daje sobie świetnie radę z tłumaczeniem niemieckiego na angielski i to w locie. Ważne jest, iż późniejsza komunikacja w sprawie wsparcia, czy konfiguracji posprzedażowej, może odbywać się już normalnie po angielsku.

Proces zakupu to zaledwie parę kliknięć i konieczność podpięcia karty kredytowej (lub debetowej). Należy pamiętać, iż będziemy płacić walutą zagraniczną, więc nasz bank musi nam pozwalać na takie działania. Ja skorzystałem z Revoluta. Istotne jest to, iż najkrótszy okres na jaki można dokonać zakupu to kwartał, a więc płacimy z góry za minimum 3 miesiące. Aby przyspieszyć proces dobrze jest już w uwagach do zamówienia zawrzeć podstawowe informacje takie jak:

1. Domena do jakiej chcielibyśmy podpiąć instancję – w moim przypadku była to domena mastodon.tomaszdunia.pl
2. Zależało mi na tym, aby moim handle (z ang. uchwyt) było @[email protected], a nie @[email protected], czyli aby w handle użyta była domena główna, a nie subdomena. Da się to zrealizować poprzez ustawienie dwóch parametrów:
   • LOCAL_DOMAIN=tomaszdunia.pl
   • WEB_DOMAIN=mastodon.tomaszdunia.pl
3. Chęć, aby został włączony Single User Mode, który sprawia, iż po wejściu na stronę główną instancji mastodon.tomaszdunia.pl zamiast lokalnej osi czasu (co nie ma sensu dla instancji jednoosobowej) zostanie wyświetlony profil administratora.
4. Ja dodatkowo chciałem też, aby Ossrox zmieniło mi domyślny limit 500 znaków w jednym toocie (rate_limit) na najwyższy jaki mogą ustawić. Nie ma sensu wprowadzać sobie tego typu limitów dla jednoosobowej instancji. Jednak w odpowiedzi na ticket dostałem informację, iż taka zmiana wiąże się z koniecznością modyfikacji kodu i będzie dla nich problematyczna, bo inni użytkownicy wykazują małe zainteresowanie tego typu zmianą i dla mnie specjalnie musieliby robić fork kodu z tą zmianą. Jednak za dodatkową opłatą 5 euro miesięcznie zgodziliby się na zrobienie tego i zmianę na 2000 lub 5000 znaków. Nie zdecydowałem się na taki deal, bo nie jest to dla mnie aż tak istotna funkcja, żeby płacić za nią drugie tyle co płacę za serwer. Jednak informuję, iż istnieje taka opcja jakby ktoś był zainteresowany.
5. Do tego zapytałem czy jest możliwosć, aby znieśli mi limit znaków w bio w profilu oraz zwiększyli liczbę linków jakie mogę podpiąć do profilu. Jednakże na obie te prośby dostałem informację, iż nie mogą tego zrealizować, bo jest to zbyt duża ingerencja w kod Mastodona. Cóż, trudno… Wiem, iż da się to zrobić, ale i tak jak na managed hosting udało mi się dogadać sporo konfiguracji, niemożliwych u innych dostawców (nawet droższych).

Korzystając z moich doświadczeń proponuję w uwagach do zamówienia zawrzeć jedynie tematy z punktów 1-3 oraz ewentualnie o ile chcecie się decydować na dodatkowy koszt za zwiększenie limitu znaków to napisać do nich również w sprawie punktu 4.

Po prawidłowej płatności pozostaje czekać na odpowiedź od Ossrox z instrukcjami dotyczącymi konfiguracji. Ja do zrobienia miałem w zasadzie tylko dwie rzeczy:

1. Ustawić odpowiednio rekordy DNS dla mojej domeny. Tutaj mogłem zrobić to dwojako (obstawiam, iż wartości dla Was będą takie same, ale na pewno poczekajcie na potwierdzenie):
   • A = 49.12.191.254 / AAAA = 2a01:4f8:c012:5147::1
   • CNAME = cname.ossrox.org
2. Skonfigurować przekierowanie 301 z domeny tomaszdunia.pl na subdomenę mastodon.tomaszdunia.pl. Realizuje się to poprzez edycję (lub utworzenie o ile nie istnieje) pliku .htaccess w domenie głównej. Należy na jego początku dopisać taką linijkę:
   • Redirect 301 /.well-known/webfinger https://mastodon.tomaszdunia.pl/.well-known/webfinger

Po wykonaniu niezbędnych działań trzeba niestety czekać aż zmiany w DNSach się rozpropagują, co może potrwać choćby 24 godziny. Jednak tu już rolą Ossrox jest pilnować kiedy możliwe będzie dokończenie konfiguracji instancji. Po zakończonym procesie konfiguracji otrzymamy maila z loginem i hasłem do użytkownika będącego administratorem instancji.

Panel administratora instancji

Przejdźmy sobie jeszcze przez wszystkie zakładki ustawień dostępnych dla administratora.

• Dashboard – panel z podsumowaniem i statystykami. Jest on prawdopodobnie istotny dla administratorów instancji, które posiadają więcej niż jednego użytkownika. W naszym przypadku jedyna istotna informacja jaka jest tam zawarta znajduje się na samym dole i jest to sekcja SPACE USAGE, która podaje ile aktualnie przestrzeni dyskowej wykorzystuje nasza instancja. Parametr, którym wcześniej operowałem nazywa się Media storage i jest to ilość miejsca jaką zajmują dane multimedialne (głównie – filmy, zdjęcia, awatary) nasze oraz pobrane z instancji osób, które obserwujemy. Ten parametr warto monitorować i na jego podstawie ustawiać odpowiednią wartość retencji danych, o której będzie za chwilę, bo znajduje się w jednej z zakładek poniżej.
• Server Settings – najważniejsza zakładka, w której ustawiamy praktycznie wszystko co istotne.
  • Branding – Zakładka, w której możemy ustawić podstawowe informacje o instancji, które wyświetlane są na stronie głównej, która w przypadku włączonego Single User Mode w teorii nie istnieje, bo z automatu przekierowuje do naszego profilu. Niemniej jednak dobrze jest wypełnić te dane.
  • About – Zakładka z bardziej szczegółowymi informacjami jak rozszerzony opis czy polityka prywatności. Tutaj już naprawdę nie ma sensu tego wypełniać dla jednoosobowej instancji.
  • Registrations – Zakładka, w której należy wyłączyć możliwość rejestracji (oczywiście o ile chce się mieć jednoosobową instancję). Realizuje się to poprzez wybranie opcji Nobody can sign up w menu rozwijanym Who can sign-up. Jako Custom message wpisałem This is a private server. Sign-ups are not available. If you want to join Mastodon use this https://joinmastodon.org.
  • Discovery – Zakładka dotycząca polecania treści na zasadzie Odkryj. Na Mastodon ma to niewielkie znaczenie, gdyż decentralizacja robi swoje i nie ma jednej listy z trendami, a i przy jednoosobowej instancji ma to jeszcze mniej sensu. Niemniej jednak według mnie dobrze jest zaznaczyć następujące opcje: Enable trends, Allow trends without prior review, Allow unauthenticated access to public timelines, Publish aggregate statistics about user activity in the API, Publish list of discovered servers in the API, Enable profile directory. Resztę można śmiało oznaczyć lub zostawić puste.
  • Content retention – To chyba najważniejsza zakładka dla wszystkich administratora instancji, choć określa się w niej jedynie trzy parametry. Retencja oznacza zachowywanie danych. Określenie czasu retencji danych oznacza w praktyce określenie ile dni dane mają być przechowywane na serwerze i następnie z niego usuwane. Zacznijmy od tego jak to działa w Fediverse. Otóż instancje się ze sobą federują to znaczy wymieniają dane. Ja zaczynając obserwowanie kogoś mówię mojemu serwerowi, iż od tej pory chcę, aby pobierane na dysk serwera były wszelkie dane generowane przez tego użytkownika. W ten sposób jak obserwowany przeze mnie użytkownik opublikuje toota ze zdjęciem to jego serwer rozgłosi to i roześle do wszystkich zainteresowanych (w tym mojej instancji) tą treść. Następnie ja łącząc się ze swoim serwerem mogę te dane wyświetlić w swoim kliencie (np. Ivory). To ile te dane będą przechowywane na moim serwerze określają właśnie dwa pierwsze parametry w tej zakładce. Media cache retention period określa jak długo mają być przechowywane dane multimedialne (filmy, zdjęcia itp.) z innych instancji. Ja mam tutaj ustawione 7 dni i jest to dla mnie w zupełności wystarczający okres. Ba, choćby testowałem ustawienie tego na 3 dni i też okazało się wystarczające. Istotne jest, iż choćby o ile usuniemy te dane po np. 3 dniach i później będziemy chcieli do nich wrócić to zostaną ode pobrane jeszcze raz. Różnica jest tylko taka, iż może to nie być natychmiastowe i na ich wyświetlenie trzeba będzie chwilę zaczekać. Natomiast parametr Content cache retention period określa jak długo mają być przechowywane posty z innych instancji. Same posty (tooty) nie zajmują wiele miejsca, więc na ten moment to pole zostawiłem puste, co oznacza, iż nie mają być nigdy usuwane. Zobaczę co z tym zrobić po dłuższym czasie. Ostatni parametr to User archive retention period i w przypadku jednosobowej instancji nie jest zbytnio istotny, bo jego ustawienie określa ilość dni po jakich będą usuwane archiwa wygenerowane na prośbę użytkowników. Archiwa to taka kopia zapasowa naszych danych jak lista obserwowanych, lista zablokowanych lub wyciszonych, zakładki itp.
  • Appearance – Zakładka dotycząca aspektów wizualnych, tj. dająca możliwość zmiany domyślnej szaty graficznej (kolorystyki) oraz modyfikację wyglądu strony instancji poprzez wprowadzenie swojego kodu CSS.
• Server rules – W tej zakładce definiuje się zasady panujące na instancji. Jest to swego rodzaju regulamin, który ma być przestrzegany przez użytkowników. W przypadku jednoosobowej instancji raczej nie ma to znaczenia, więc na swojej instancji dodałem jedynie jedną zasadę This is a private instance, so I don’t need to write rules only for me .
• Roles – Zakładka do zarządzania rolami użytkowników. Można w niej mianować moderatorów i nadawać im uprawnienia. Kompletnie nieistotna przy jednoosobowej instancji.
• Announcements – Komunikaty do użytkowników np. o jakimś wydarzeniu. Nieistotne.
• Custom emojis – Na Mastodonie mamy możliwość definiowania swoich niestandardowych emoji. Jest to dość fajna funkcja. Po pewnym czasie, gdy nasz serwer sfederuje się z innymi, lista w tej zakładce zacznie się znacząco powiększać. Z poziomu tej zakładki można decydować, które niestandardowe emoji chcemy widzieć (allow), a których nie. Do tego o ile któreś z tych emoji przypadną nam do gustu i sami będziemy chcieli z nich korzystać to można je zaznaczyć i użyć funkcji Copy, co spowoduje, iż dane emoji zostaną zaimportowane do naszej instancji i możliwe do użytku w naszych tootach czy też bio profilu.
• Webhooks – Szczerze powiedziawszy jeszcze się tym nie bawiłem, ale zakładam, iż to coś w rodzaju automatyzacji. Definiuje się serwer, na który mają być wysyłane komunikaty na temat jakichś zdarzeń występujących na naszej instancji. Prawdopodobnie można też w odpowiedzi na te komunikaty odesłać informację jaka ma być na nie reakcja.
• Relays – czyli w wolnym tłumaczeniu przekaźniki. To jest trochę temat rzeka. W telegraficznym skrócie przekaźniki to takie serwery pośredniczące, które zbierają subskrybujące je instancje w grupy i umożliwiają im wymianę danych. Członkostwo w takim grupie oznacza, iż na naszej globalnej osi czasu będziemy widzieli tooty z innych instancji należących do grupy danego przekaźnika. Działa to również w drugą stronę, bo nasze tooty będą też wysyłane i wyświetlane na globalnych osiach czasu innych instancji. Jest to pewnego rodzaju sposób na znalezienie nowych osób do obserwowania, a także pokazanie się światu. Relays są odpowiedzą na zjawisko odizolowania małych instancji od reszty Fediverse’u. Czy działa to dobrze? W mojej ocenie średnio, bo ciężko o tak naprawdę dobre przekaźniki, w których nie ma podpiętych po prostu słabych lub dziwnych instancji, z którymi normalnie raczej nie chcielibyśmy się federować. Trzeba też przyznać, iż korzystanie z większego przekaźnika kosztuje bardzo dużo przestrzeni dyskowej. Ja aktualnie eksperymentuję będąc podłączonym pod dwa przekaźniki: 101010.pl i infosec.exchange. Zobaczymy co z tego wyjdzie. Aby dodać przekaźnik należy po naciśnięciu przycisku ADD NEW RELAY podać adres przekaźnika zakończony frazą /inbox (np. https://relay.infosec.exchange/inbox). Następnie trzeba czekać na zaakceptowanie naszej prośby o dodanie. Bycie subskrybentem dużego przekaźnika oznacza konieczność intensywniejszego zarządzania przestrzenią dyskową naszego serwera, dlatego ja na czas wyżej wspomnianych testów zmieniłem parametr Media cache retention period na 1 dzień.

To w zasadzie wszystko do czego otrzymujemy dostęp jako administrator. Pozostałe ustawienia są takie same jak dla zwykłego użytkownika i tożsame z tym do czego jesteśmy przyzwyczajeni będąc na innych instancjach.

Podsumowanie

Starałem się wszystkie powyższe zagadnienia opisać jak najbardziej zwięźle i prosto. Jak widać stworzenie swojej własnej instancji to nic trudnego i na pewno nie wymaga posiadania ekstremalnej wiedzy technicznej. Nie jest to niestety bardzo tani czy choćby darmowy interes, jednak nie można też powiedzieć, iż 5 euro miesięcznie to kosmiczne pieniądze. Posiadanie własnej instancji na pewno nie będzie atrakcyjne dla wszystkich, ale skoro czytasz ten wpis to zakładam, iż dla Ciebie, drogi Czytelniku, jest czymś interesującym i wartym rozważenia. Mam nadzieję, iż mój wpis pomoże Ci w procesie decyzyjnym.

W przyszłości planuję przykucować i uruchomić własną instancję całkowicie od zera, bez użycia managed hostingu, który całą część techniczną wykonał za mnie. Jeszcze nie wiem czy zrobię to na domowym serwerze (Raspberry Pi lub może terminalu ze środowiskiem Proxmox, o którym będą następne, planowane wpisy), w chmurze Oracle Free Tier, czy może na Mikrusie. Jednak na ten moment uważam, iż moja bazowa instancja pozostanie na dłużej na hostingu zarządzanym Ossrox, bo jest po prostu pewnym rozwiązaniem, a ewentualny self-hosting pozostawię sobie jako eksperyment, ciekawostkę, rozszerzenie umiejętności i zabawę.