Dlaczego historia czatu jest zwykle zakładnikiem
Poproś hostowaną platformę czatu o swoje dane, a zwykle dostaniesz plik z zapisem: zip z JSON-em i załącznikami, dobry do celów zgodności i do grepa, bezużyteczny, jeśli chcesz prowadzić rozmowę gdziekolwiek indziej. Żywa społeczność, czyli to, co naprawdę udało Ci się zbudować, nie wychodzi. „Wyeksportuj swoje dane” i „odejdź ze swoją społecznością” to dwie różne obietnice, a większość branży składa tylko pierwszą.
Buzz robi z tej luki fakt techniczny, a nie decyzję handlową. Każda wiadomość jest podpisana przez autora, a podpis obejmuje znacznik czasu. Relay przyjmuje zdarzenie tylko od klucza, który je podpisał, i tylko dopóki znacznik czasu jest świeży, w standardowym relayu przez mniej więcej piętnaście minut. Dlatego nikt nie opublikuje po kablu zeszłorocznej historii w nowym relayu: ani my, ani Ty, ani ludzie, którzy te wiadomości napisali. To nie nasza polityka, którą moglibyśmy poluzować; tak protokół broni się przed sfałszowaną i odtwarzaną historią, i wiąże to każdego, kto gdziekolwiek uruchamia Buzz.
Nauczyliśmy się tego uczciwie, na własnym błędzie. Nasz pierwszy projekt eksportu zakładał, że podpisane zdarzenia da się ponownie opublikować w dowolnym relayu; ćwiczenie to obaliło, a my poprawiliśmy własne teksty. Od tamtej pory eksport jest zapisem i mówi o tym wprost. Ten artykuł jest o tym, co zbudowaliśmy dalej: o ścieżce migracji, która przenosi żywą społeczność w obu kierunkach, bez udawania, że kabel potrafi coś, czego nie potrafi.
Tożsamość żyje w hostname
Drugi fakt, na którym wszystko się opiera: tożsamość społeczności Buzz jest przyspawana do hostname relaya. Gdy klient się łączy, relay ustala, którą społeczność obsługuje, na podstawie hosta, na który przyszło połączenie, a każda wiadomość, członkostwo i plik wiszą na wewnętrznym identyfikatorze tej społeczności. Hostname to nie tyle miejsce, w którym społeczność mieszka, ile sposób, w jaki się nazywa, a to powiązanie istnieje dokładnie w jednym miejscu: w jednym wierszu bazy danych relaya, który wskazuje host społeczności.
Ten wiersz to zawias, na którym obraca się cała migracja, i z niego bierze się rada, którą dziś dajemy wszystkim przed czymkolwiek innym: wybierz hostname starannie, w obu kierunkach, zanim wprowadzą się ludzie. Przy pięćdziesięciu członkach to już nazwa, na którą odpowiada Twoja społeczność, a jej zmiana to migracja, nie przełącznik w ustawieniach.
Przywróć, przepnij, uruchom
Skoro kabel jest zamknięty dla przeszłości, prawdziwa migracja biegnie pod nim, w bazie danych. Trzy kroki, a cała sztuka tkwi w kolejności: przywróć, przepnij, uruchom.
Najpierw przywracasz, zanim relay w ogóle wystartuje: wczytujesz zrzut do pustej bazy danych i kopiujesz media do nowego magazynu mediów. Media w Buzz są adresowane treścią, nazwane hashem własnych bajtów, więc nie ma dla nich znaczenia, który hostname je serwuje. Potem przepinasz: zmieniasz ten jeden wiersz hosta na nowy hostname. Potem, i dopiero wtedy, uruchamiasz relay. Przy starcie szuka społeczności pod skonfigurowanym hostem, znajduje przepięty wiersz i ją przejmuje: ta sama społeczność, ten sam wewnętrzny identyfikator, pełna historia, oryginalne znaczniki czasu.
Uruchom najpierw, a trafisz na awarię, przez którą to wszystko wygląda na niemożliwe: relay nie znajduje społeczności pod swoim hostem, uczynnie sieje nową, pustą, a Twoja przywrócona historia leży w tej samej bazie, osierocona obok. Wszystko wygląda zdrowo, a każdy pokój jest pusty. Przepnij przed pierwszym startem, a relay nie dostanie okazji, żeby być uczynnym. W naszych ćwiczeniach przywrócona historia była czytelna przez uwierzytelnione połączenie w chwili, gdy relay wstał, a ten sam klucz właściciela, który prowadził starą instancję, publikował nowe wiadomości na nowej.
Cały mechanizm w skrócie. Sztuką jest kolejność: relay uruchomiony przed przepięciem sieje pustą społeczność pod swoim hostname, a przywrócona historia leży osierocona obok.
Do środka: gdy męczy Cię utrzymanie
Kierunek pierwszy: do środka. Hostujesz Buzz samodzielnie, urok alertów o dysku o drugiej w nocy już minął, a nie przenosisz się tylko dlatego, że przeprowadzka zwykle oznacza start od zera: nowe konta, puste pokoje, link „historia jest w starym systemie”, w który nikt nigdy nie klika. Dokładnie tę przeprowadzkę przećwiczyliśmy w tym tygodniu od początku do końca, tymi samymi narzędziami importu, których użyjemy dla Twojej społeczności, i żaden z tych kosztów nie przetrwał ćwiczenia.
Co przeszło, sprawdzone, a nie założone: pełna historia z oryginalnymi znacznikami czasu, bo przywracanie to operacja na bazie danych i piętnastominutowe okno kabla nie ma tu nic do powiedzenia. Każda tożsamość członka, bez ponownej rejestracji, bo tożsamość w Buzz to para kluczy Nostr, którą trzyma członek, a nie konto, które my wydajemy: te same klucze, które działały z Twoim hostname, działają dalej z nowym, i nikt nie musi zakładać konta od nowa. I media, bajt w bajt, zweryfikowane względem swoich adresów treści.
Prosimy o celowo niewiele: zrzut Twojej bazy danych i możliwość odczytu Twojego magazynu mediów. Resztę robimy ręcznie, z kopią zapasową wykonaną, zanim import czegokolwiek dotknie, a lista kontrolna z ćwiczenia przechodzi, zanim uznamy sprawę za zamkniętą. Dziś nie ma przycisku do samodzielnego importu i nie spieszymy się z jego dodaniem: migracja to jedyny dzień, w którym Twoja społeczność zasługuje na operatora poświęcającego jej całą uwagę.
Na zewnątrz: gdy chcesz mieć klucze
Kierunek drugi: na zewnątrz. Każda hostowana przestrzeń robocza od zawsze mogła pobrać eksport: podpisane zdarzenia, media, README. To warstwa zapisu i uczciwie przyznaje, że jest zapisem. Teraz paczka zyskuje obok niej warstwę suwerenną: pełny zrzut bazy danych, dokładne odwołanie do obrazu kontenera, na którym działała przestrzeń, plik compose i skrypt przywracania, który wymusza kolejność przywróć, przepnij, uruchom.
Sprawdzamy to jedynym testem, który się liczy: bez naszej pomocy. W ćwiczeniu czysta maszyna, która nigdy nie miała styczności z naszymi systemami, poszła za README z samej paczki i wstała jako self-hosting pod nowym hostname. Ten sam klucz właściciela się zalogował. Pełna historia była na miejscu. Media serwowały się pod swoimi adresami treści. A instancja przyjmowała nowe wiadomości, i to jest różnica między eksponatem w muzeum a społecznością, która się przeprowadziła.
Eksport, który da się przywrócić tylko z dostawcą na rozmowie z supportem, to nie drzwi, tylko smycz z dodatkowymi krokami. Dlatego README jest standardem, według którego ćwiczymy: odejście powinno być nudnym popołudniem wykonywania instrukcji, które działają. Wolimy zasłużyć na prowadzenie Twojej infrastruktury, niż pilnować wyjścia.
Ograniczenia, wprost
Opowieść o migracji bez jej ograniczeń to reklama, więc oto one. Po pierwsze: stare wiadomości z osadzonymi bezwzględnymi adresami URL, czyli miniatury w starszych przesłanych plikach i odpowiedzi na przesłanie, które podawały pełny adres, na zawsze wskazują stary hostname. Te adresy żyją wewnątrz podpisanej treści, a przepisanie podpisanej treści byłoby fałszerstwem, więc żadna uczciwa migracja nie może ich ruszyć. Same pliki mediów są adresowane treścią i serwują się poprawnie z nowego hosta; tylko dosłowne adresy zamrożone w starych podpisanych wiadomościach wciąż wskazują miejsce, które zostawiasz za sobą.
Po drugie, przy wyjściu: własny klucz podpisujący relaya nie idzie z Tobą. Przywrócona instancja generuje nową tożsamość relaya, więc powiadomienia systemowe podpisane przez stary relay pozostają przypisane do tożsamości, która naprawdę je podpisała, i właśnie do tego służą podpisy. Dostęp członków pozostaje nienaruszony: Twoi ludzie są swoimi własnymi kluczami, a te podróżują, bo nigdy nie należały do nas.
Po trzecie, w obu kierunkach: wybierz docelowy hostname tak, jakby był na zawsze, bo w praktyce jest. To samo spawanie, dzięki któremu wystarczy przepiąć jeden wiersz, sprawia, że hostname to jedyna rzecz, której później nie zmienisz od niechcenia.
Kontrola w obu kierunkach
Złóż to razem, a suwerenność przestaje być hasłem i staje się listą kontrolną. Twoi ludzie trzymają własne klucze, więc żaden operator, łącznie z nami, nie stoi między nimi a ich tożsamością. Twoja historia przywraca się pod hostname, który kontrolujesz, w którąkolwiek stronę się przenosisz. Kabel odrzuca odtwarzaną historię wszystkim po równo, a ścieżka przez bazę danych pod spodem działa dla wszystkich po równo. Kontrola to nie wrażenie z tabeli cenowej; to kwestia tego, czy drzwi wyjściowe ćwiczono tak długo, aż się otworzyły. Nasze tak, w tym tygodniu, z samego README.
Co z tego wynika dla Ciebie
Hostowana strona tego wyboru jest na hachiflow.com: stałe $50 miesięcznie, Twój własny relay pod name.hachiflow.chat i opisana tu migracja przeprowadzona razem z Tobą, ręcznie, w którąkolwiek stronę zmierzasz.
A jeśli nigdy nie wyślesz nam ani dolara, weź sam mechanizm: przywróć, przepnij, uruchom, w tej kolejności, z przepięciem przed pierwszym startem relaya. Ta jedna kolejność to większość tego, czym jest migracja Buzz. Udowodniliśmy to w tym tygodniu na czystej maszynie, a mechanizm zostaje z Tobą.