#Mastodon

Спочатку гарні новини: OmniWOPE вже опублікований! Якщо вам раптом потрібно публікувати блог у канал Telegram, то це вже можна зробити. А далі будемо працювати.

Як тільки я розвʼязав проблеми з телеграмом та перейшов на використання OmniWOPE для цього каналу, наступним чином захотів додати публікацію в Mastodon, про яку так давно думав. Власне, сама публікація — справа нескладна, бо вже є каркас, в який можна додавати більше виходів. (Чого і вам пропоную спробувати, якщо є охота.)

Але ж проблеми зʼявляються із відображенням постів. Якщо брати сам Mastodon, то там все дуже просто, бо він підтримує тільки текстовий зміст. Просто, бо багато не зробиш. Але той сервер що в мене — GoToSocial — хоч і сумісний з Mastodon, але дозволяє публікувати й у Markdown. Та якщо подивитися (зверху) на пост в самому GoToSocial, то наче все більш-менш правильно виглядає.

Проте головна відмінність федиверсу від того ж Telegram - це нескінченне різноманіття клієнтів. Та ще й серверів. Але як я розумію, задача відображення статусу перекладається саме на клієнта — сервер тільки поширює зміст.

Та якщо подивитися на популярні клієнти, то там той самий пост виглядає від недооформленого до повністю понівеченого. Тобто “просто публікувати Markdown” не вийде. Доведеться конвертувати його в такий обрізаний вигляд, який приймуть клієнти. Тобто приблизно так само, як було й з Telegram, але ще й із ретельною перевіркою у різних клієнтах.

Сьогодні роздивлявся більш уважно протокол ActivityPub, бо є така гадка, що публікувати пости у Mastodon це взагалі зайвий крок. Наприклад, осьо непоганий посібник, як додати ActivityPub навіть до статичного сайту. Але спочатку, що це взагалі значить?

ActivityPub пропонується як “протокол для децентралізованої соціальної мережі”. Якщо HTTP є суто “реактивним” протоколом, ActivityPub формалізує довгострокову підписку на ресурс — тобто він буде проактивно надсилати свої оновлення.

Власне, ActivityPub має більше спільного з SMTP, ніж з RSS. Хоча й побудований на HTTP, а також на JSON-LD (JSON, доповнений схемою). Але доставлення подій тут відбувається за методом Push, а не Pull. Тобто коли ресурс (“актор” на мові ActivityPub) публікує новий пост, то він розсилається всім підписникам — так само як і поштова розсилка. Різниця хіба в тому, що ActivityPub працює симетрично — в кожного актора є вхідна та вихідна скриня.

(Друге, що треба знати, це одиницею інформації в ActivityPub є подія. За природою це Event-Sourced протокол: поточний стан формується як накопичення змін-подій. Створення поста — подія, редагування та видалення — теж, як і поширення та вподобайка.)

Отже, якщо реалізувати на сайті вхідну та вихідну скриню, а також зберігати список підписників, то можна цілком стати частиною мережі ActivityPub, тобто Федиверсу. Набирати підписників, розсилати пости, отримувати коментарі — все це через дві скрині.

Втім головною перепоною для мене є неоднорідність клієнтів. Як показує вчорашній пост, тут все значно гірше, ніж у поштових клієнтах чи читачах RSS. Можна розраховувати тільки на самий базовий HTML. Або… публікувати тільки посилання на сайт. Щось таке. 🤔

А давайте ще далі відсунемося та подивимось на весь обрій децентралізації. Звісно, хто був в інтернеті до середини 2000-х, знає, що колись ніякої централізації не було — головним місцем спілкування були форуми, яких було безліч. На кожному форумі користувачі були свої, тобто мої обліковки на студентському форумі, форумі улюбленої групи, та форумі по розробці ігор були ніяк не повʼязані. Та наче це було навіть фічею, а не багом, та переважна більшість учасників не оголошувала свою особу.

Втім, коли зʼявилися соціальні мережі, то всі дуже швидко втекли туди. Для мене це досі незрозуміле явище. Раптом всім стало цікаво мати свою сторінку, список своїх друзів (а за разом колег, а пізніше — ще й батьків), та все інше спілкування робити в цьому контексті. Можу тільки зробити висновок, що такий режим спілкування переміг, а значить, для змагання з олігополією сучасного інтернету всякий соціальний сервіс повинен бути частиною єдиного великого Федиверсу. Федиверс — це мережа маленьких спільнот, які вільні спілкуватися між собою.

Головним недоліком Федиверсу є його неоднорідність. Серверів та клієнтських застосунків багато, а сумісність визначена на дуже базовому рівні. Тут майже за означенням не може бути такого цілісного досвіду, як у звичайній соціальній мережі. Я впевнений, що це відштовхне всякого не досвідченого технічно користувача. Але в цьому точно є деякий шарм, бо Федиверс залишається “старим” інтернетом, інтернетом для ентузіастів.

Головною перевагою Федиверсу є воля. Тут немає “алгоритмів”. Хоча може на якомусь сервісі є, але ми самі повинні його обрати. Так само модерація є локальним явищем. “Алгоритми” та модерація корисні речі, але не тоді, коли ними керує велетенська безконтрольна корпорація. Тому, я гадаю, Федиверс, з локальними спільнотами, звичаями та законами, ближче до “мрії Інтернету”, ніж то темне місце, в якому ми зараз опинились.

Чи є майбутнє, де Федиверс стане вибором більшості інтернету? Я можу собі це уявити; адже всі ми їздимо на автомобілях різних марок по дорогах різних країн та дістаємось куди треба. Але спочатку щось повинно статись з централізованими мережами.

Нарешті я на це наважився та публікую цей пост на @stendap_sogodni@shevtsov.me. Перфекціонізм мене тут зупиняв вже надто довго, треба з чогось почати. Запрошую підписатися!

Також із сьогодні OmniWOPE хоч трохи виправдовує префікс “омні” та вміє публікувати в Мастодон. Нагадаю, що публікація ведеться паралельно у всі налаштовані канали.

До речі, вирішив, що федиверсізація блогу (додавання ActivityPub прямо для його сторінок) - це проєкт, хоч безумовно цікавий, але завеликий, а також надто спеціалізований. Та я опинюся з тією ж проблемою невірного відображення HTML різними клієнтами. Тому все ж вважаю доцільною ретрансляцію змісту в Федиверс через проміжний сервер.

З проблемами HTML я поки нічого не робив, оскільки… треба з чогось почати. Поки зрозумів, що процес такий: мій сервер робить з Markdown HTML, а потім цей HTML вже обрізається клієнтами. Тож мені доведеться підбирати такий Markdown, який буде перетворений у прийнятний HTML. Тобто це ще окрема непроста задача.

Приблизно два роки в мене в ПЗ для каналу є спосіб вказати посилання так, щоб на сайті воно вело на сайт, а в каналі Telegram - на пост в каналі. Сьогодні доробив цей функціонал й для публікації в Mastodon.

До речі. Mastodon досі не вміє публікувати Markdown. Тому технічно, наразі я підтримую не Mastodon, а GoToSocial, та, здається, ще Akkoma. Але — я використовую API Mastodon, звідси й назва.

Тут цікавого те, що вихідний текст поста в мене в Markdown. Та на виході теж отримую Markdown. Тому, певно, можна було б підставити посилання магією регулярних виразів, але навіщо, коли в мене є готове рішення для синтаксичного дерева Markdown? Залишилось тільки з нього побудувати назад Markdown - для того в Goldmark є спеціальний рендерер — та справа зроблена.

Мені такий підхід згодиться й в майбутньому, бо він допоможе позбавитись від тих конструкцій, які підтримуються неповноцінно.

Хотів сьогодні насправді писати зовсім інший пост, але для нього потрібна була ілюстрація. А їх мій скрипт для публікації — себто OmniWOPE - не вмів викладати в Mastodon. Нарешті цей недолік виправлено, та зображення повернуться в мій канал.

Технічний прототип в мене вже рік був готовий. Ну тобто я міг завантажити дану світлину в Mastodon. Що, до речі, відбувається у два кроки: спочатку медіафайл окремо, потім — статус із посиланням на ID файлу.

Але я довго думав, як же ж організувати статуси. Додавати зображення прямо у головну статтю мені не подобається, бо це спонукає клієнтів показати її як “статус-зображення”. Нарешті вирішив публікувати як відповідь до головного статусу — це все ж загально прийнятний спосіб.

Ще виявилося, що треба ж оголосити тип медіа. (До речі: сьогодні дізнався, що саме “тип медіа” сучасна назва, а не “тип MIME”.) Досі для Telegram мені було потрібно тільки знати, чи є ілюстрація зображенням чи відео. Та нарешті, чомусь вбудований у Go метод multipart.Writer#CreateFormFile не дозволяє призначити тип медіа! Та найкраще рішення для того — скопіювати та виправити код методу.

На сьогодні все. Нову версію вже можна забрати з GitHub.

Сьогодні у Федиверсі виникла дискусія — що таке Pleroma та чим вона відрізняється від Mastodon. Оце захотілося ширше про все це розповісти, бо я для себе копався, коли робив адаптер для Mastodon до OmniWOPE.

Федиверс — це децентралізована соціальна мережа. Соціальна — значить, в ній є облікові записи. На них можна підписуватися, стежити за ними, надсилати ним повідомлення. Децентралізована — значить, містить не один сервер, а всі сервери в інтернеті, що підтримують протокол ActivityPub (та інші.) З різним керуванням, різним ПЗ, різним всім.

Якщо це звучить надто абстрактно, то так воно і є. Бо хоча ActivityPub чітко задає логістику повідомлень, але їхній зміст залишає відносно вільним, щоб охопити будь-який зміст. Тому Федиверс містить не тільки умовний Твітер, але й базу туристичних маршрутів Wanderer, відеохостинг PeerTube, аудіохостинг Funkwhale, також інтеграції від WordPress або Discourse та, звісно, Mastodon.

(Та все це не конкретні сервіси, а програмне забезпечення, яке можна розгорнути для себе. Або доєднатись до одного з безлічі серверів, що вже існують.)

Але окрім серверів, є ще клієнти — хай то буде вебзастосунок чи повноцінний, але клієнт буде привʼязаний до якогось конкретного сервера, бо клієнти не використовують ActivityPub для спілкування з сервером. Та тут, я гадаю, набуває вагомості Mastodon.

Сам собою Mastodon - дуже успішний клон Твітеру для Федиверсу. Але ще важливо, що API для клієнтів Mastodon став де-факто стандартом, тому такі сервери, як Pleroma чи GoToSocial, його реалізують. А клієнти, як Mona, Tusky, чи Ivory, таким чином підтримують не тільки Mastodon, але й ці сервери теж. (Не завжди ідеально.)

От, виходить, коли кажуть Федиверс — то йдеться про загальну світову децентралізовану мережу. А коли Мастодон — то про її потужний твітеро-форматний сегмент, який має спільні клієнти та загальні домовленості про зміст повідомлень. Але не тільки сам Мастодон, присутня певна генералізація. 🦣