Про сервер Fediverse в альтернативних мережах
Я давно користуюсь Fediverse, але свій інстанс - підняв відносно недавно: приблизно пів року тому. При чому, його було створено у якості експерименту з працездатності екосистеми ActivityPub в рамках оверлейної мережі Yggdrasil як спроба не просто зробити веб-проксі, а організації локального сузір'я.
Так як це був перший досвід, я ще збирався організувати доступ до нього з Інтернет (повноцінну між-серверну комунікацію) але згодом усвідомив, що цей протокол на таке не розрахований і навіть якщо це технічно можливо, адміністратори інших серверів потребуватимуть додаткового шару специфікації для такої взаємодії.
Сервери
Їх вистачає: популярний Mastodon я не ставив бо не хотів морочитись з PostgreSQL та й в цілому, його розгортання виглядає для мене ледачого складно.
Snac
Мені своєчасно порадили сервер Snac:
Він є розрахованим не тільки на маленький персональний сервер без зовнішніх реєстрацій, а ще й не потребує бази даних, при тому клієнт функціонує без JS і до цього сервера є доволі якісні теми оформлення, наприклад Pika:
Написаний Snac мовою C.
Функціонування (слідування, коментарі, бусти, приватні повідомлення тощо) в локальній мережі було успішно перевірено на живих вузлах Yggdrasil в комбінаціях:
- Snac (IPv6) / Snac (IPv6)
- Snac (IPv6) / Snac (DNS)
- Snac (IPv6) / Mitra (IPv6)
- Snac (IPv6) / Mitra (DNS)
Мій інстанс для тестування:
- взаємний фоловінг по запиту
Mitra
Вже після встановлення Snac, я відкрив для себе Mitra:
Цей сервер вимагає PostgreSQL, JS для стандартного клієнта і включає в себе навороти для автоматичної реєстрації та (мабуть) менеджменту користувачів. Я планую його спробувати потім, мені подобається його простий інтерфейс, користуюсь для свого Інтернет-профілю, який спочатку створив для тестів а потім там й лишився "жити".
Окремо згадую про це програмне рішення, тому що його вдалось протестувати в між-серверній комунікації з одним з реальних користувачів мережі. Також в нього була якимось чином налаштована взаємодія з Інтернет-федерацією. Подробиці цього збочення я не знаю, але довкола нашого експерименту, розробниками рушія Mitra було проявлено цікавість і спеціально натягнуто деякі адаптації по частині IPv6, тому в контексті цей сервер вартий уваги, а кому цікаві подробиці - зконтактуйте з
@madamada@mitra.void.my
- Yggdrasil
Tootik
Окремо з цікавих платформ, я б ще відмітив сервер для протоколу Gemini - Tootik:
Його бекенд, як і передбачає ActivityPub, взаємодіє по HTTP/JSON, але на рівні користування там буде інтерфейс Gemini на 1965 порті з TLS.
Згадую про дане рішення в контексті того, що альтернативними мережами часто користуються з метою приватності, тому протокол Gemini тут може мати деяку нішу користувачів.
Ідентифікатори хостів
Власне, саме цікаве і чому взагалі я задумав написати цей матеріал.
Щоб створити свій інстанс, вам потрібно ідентифікувати свій вузол як `user@host`. Коли ви це зробите, то вже не зможете безпроблемно його змінити потім, бо інші сервери федерації втратять зв'язок з вами. Тому він повинен бути обраний один раз і обраний правильно.
DNS
ActivityPub розроблявся як протокол високого рівня для комунікації засобами класичної мережі Інтернет з DNS, у той час як мережах типу Yggdrasil прийнято користуватись IPv6 а домен - вже надавати опцією.
Локальна мережа з ідентифікацією DNS, здавалось би дозволяє легко змінювати адреси IP або навіть перескочити з мережі Yggdrasil на Mycelium, а з того - на ще якусь нову екосистему. Але за цими перескоками повинні слідувати не тільки ваші читачі, але й сервери федерації. Тому сумнівно, якщо це не якийсь спеціалізований на одну мережу домен `.ygg` в Alfis DNS, що тільки відсіче потенційну частину сегменту, яка ним не користується.
IP
Свій ID я вирішив робити на IPv6 адресі мережі Yggdrasil бо такий формат, на відміну від домена, не може бути протермінований з часом (так, я можу зникнути на рік два і неочікувано для себе повернутись до мережі через десять).
З іншого боку, перманентні IP на основі криптографії - теж не панацея: ключі можуть бути загублені, випадково опубліковані тощо, а тому можуть потенційно потребувати генерації нових.
Адреси підмереж
В мене ще лишається відкритим питання з адресами підмереж, бо ті є менш стійкими до колізій і такими, що потенційно можуть бути випиляні з майбутніх релізів роутера. Так, вони зручні, але сьогодні я б радив користуватись основними адресами для ідентифікації сервера, коли це можливо.
Гібридна маршрутизація
На початку матеріалу зауважив, що особисто для себе - відмовився від ідеї мульти-мережної комунікації для свого інстансу, спробувавши просто ініціювати локальне сузір'я, галактику, фізично ізольованої на рівні ActivityPub від інших мереж. Але зараз, спостерігаю занепад обраної мною мережі Yggdrasil, вже експериментую з Mycelium, і вже завтра - буду експериментувати з наступною. Тому трохи розкрию свої думки стосовно гібридного формату вузла.
Вже після запуску сервера в альтернативній мережі (або мережах з налаштованим проксі для між-серверного API), постане питання поширення посилань. Адже ви захочете ділитись публікаціями з друзями в Інтернет, Yggdrasil, I2P та інших екосистемах. Бажано, це має бути якесь одне канонічне посилання, яке приведе користувача до цільової сторінки в незалежності від налаштувань його маршрутизації і функціонування самої мережі на момент відвідування.
Були думки щодо організації центрального сервісу "коротких посилань" по типу колишнього bit.ly який підтримуватиме усі можливі альтернативи і для кожної з них надаватиме веб-проксі за форматом хосту...
З іншого боку, можна створити ще один "шейред роутер" як окремий протокол та програму для нього, саме з метою обслуговування гібридних сервісів без реалізації їх маршрутизації. У цьому питанні явно не вистачає сучасних рішень, адже зберігається тенденція до створення нових мереж та деградації старих, як це сталось з CJDNS і сьогодні відбувається з Yggdrasil. Технічно, діапазон IPv6 надає широке поле для експериментальних роутерів, їх кількість в умовах сучасних перешкод мережі буде тільки зростати, тому це питання є відкритим.
Висновки
Особисто для себе, вирішив не міксувати екосистеми і вести ізольовані тематичні ресурси по кожній з них, намагаючись ділитись посиланнями в рамках тої екосистеми, для якої створено інстанс. Звичайно, на практиці виходить інакше, станом на сьогодні, назвати локальний інстанс - соціальним складно, утім якщо ви цієї соціальної взаємодії не шукаєте на глобальному рівні, то чому б не спробувати.