Стендап Сьогодні
📢
Канал в Telegram @stendap_sogodni
🦣
@stendap_sogodni@shevtsov.me в Федиверсі
Пости з тегом #Mastodon
18.03.2025
OmniWOPE + Mastodon
Спочатку гарні новини: OmniWOPE вже опублікований! Якщо вам раптом потрібно публікувати блог у канал Telegram, то це вже можна зробити. А далі будемо працювати.
Як тільки я розвʼязав проблеми з телеграмом та перейшов на використання OmniWOPE для цього каналу, наступним чином захотів додати публікацію в Mastodon, про яку так давно думав. Власне, сама публікація — справа нескладна, бо вже є каркас, в який можна додавати більше виходів. (Чого і вам пропоную спробувати, якщо є охота.)
Але ж проблеми зʼявляються із відображенням постів. Якщо брати сам Mastodon, то там все дуже просто, бо він підтримує тільки текстовий зміст. Просто, бо багато не зробиш. Але той сервер що в мене — GoToSocial — хоч і сумісний з Mastodon, але дозволяє публікувати й у Markdown. Та якщо подивитися (зверху) на пост в самому GoToSocial, то наче все більш-менш правильно виглядає.
Проте головна відмінність федиверсу від того ж Telegram - це нескінченне різноманіття клієнтів. Та ще й серверів. Але як я розумію, задача відображення статусу перекладається саме на клієнта — сервер тільки поширює зміст.
Та якщо подивитися на популярні клієнти, то там той самий пост виглядає від недооформленого до повністю понівеченого. Тобто “просто публікувати Markdown” не вийде. Доведеться конвертувати його в такий обрізаний вигляд, який приймуть клієнти. Тобто приблизно так само, як було й з Telegram, але ще й із ретельною перевіркою у різних клієнтах.
19.03.2025
ActivityPub
Сьогодні роздивлявся більш уважно протокол ActivityPub, бо є така гадка, що публікувати пости у Mastodon це взагалі зайвий крок. Наприклад, осьо непоганий посібник, як додати ActivityPub навіть до статичного сайту. Але спочатку, що це взагалі значить?
ActivityPub пропонується як “протокол для децентралізованої соціальної мережі”. Якщо HTTP є суто “реактивним” протоколом, ActivityPub формалізує довгострокову підписку на ресурс — тобто він буде проактивно надсилати свої оновлення.
Власне, ActivityPub має більше спільного з SMTP, ніж з RSS. Хоча й побудований на HTTP, а також на JSON-LD (JSON, доповнений схемою). Але доставлення подій тут відбувається за методом Push, а не Pull. Тобто коли ресурс (“актор” на мові ActivityPub) публікує новий пост, то він розсилається всім підписникам — так само як і поштова розсилка. Різниця хіба в тому, що ActivityPub працює симетрично — в кожного актора є вхідна та вихідна скриня.
(Друге, що треба знати, це одиницею інформації в ActivityPub є подія. За природою це Event-Sourced протокол: поточний стан формується як накопичення змін-подій. Створення поста — подія, редагування та видалення — теж, як і поширення та вподобайка.)
Отже, якщо реалізувати на сайті вхідну та вихідну скриню, а також зберігати список підписників, то можна цілком стати частиною мережі ActivityPub, тобто Федиверсу. Набирати підписників, розсилати пости, отримувати коментарі — все це через дві скрині.
Втім головною перепоною для мене є неоднорідність клієнтів. Як показує вчорашній пост, тут все значно гірше, ніж у поштових клієнтах чи читачах RSS. Можна розраховувати тільки на самий базовий HTML. Або… публікувати тільки посилання на сайт. Щось таке. 🤔
20.03.2025
Федиверс та децентралізовані соціальні мережі
А давайте ще далі відсунемося та подивимось на весь обрій децентралізації. Звісно, хто був в інтернеті до середини 2000-х, знає, що колись ніякої централізації не було — головним місцем спілкування були форуми, яких було безліч. На кожному форумі користувачі були свої, тобто мої обліковки на студентському форумі, форумі улюбленої групи, та форумі по розробці ігор були ніяк не повʼязані. Та наче це було навіть фічею, а не багом, та переважна більшість учасників не оголошувала свою особу.
Втім, коли зʼявилися соціальні мережі, то всі дуже швидко втекли туди. Для мене це досі незрозуміле явище. Раптом всім стало цікаво мати свою сторінку, список своїх друзів (а за разом колег, а пізніше — ще й батьків), та все інше спілкування робити в цьому контексті. Можу тільки зробити висновок, що такий режим спілкування переміг, а значить, для змагання з олігополією сучасного інтернету всякий соціальний сервіс повинен бути частиною єдиного великого Федиверсу. Федиверс — це мережа маленьких спільнот, які вільні спілкуватися між собою.
Головним недоліком Федиверсу є його неоднорідність. Серверів та клієнтських застосунків багато, а сумісність визначена на дуже базовому рівні. Тут майже за означенням не може бути такого цілісного досвіду, як у звичайній соціальній мережі. Я впевнений, що це відштовхне всякого не досвідченого технічно користувача. Але в цьому точно є деякий шарм, бо Федиверс залишається “старим” інтернетом, інтернетом для ентузіастів.
Головною перевагою Федиверсу є воля. Тут немає “алгоритмів”. Хоча може на якомусь сервісі є, але ми самі повинні його обрати. Так само модерація є локальним явищем. “Алгоритми” та модерація корисні речі, але не тоді, коли ними керує велетенська безконтрольна корпорація. Тому, я гадаю, Федиверс, з локальними спільнотами, звичаями та законами, ближче до “мрії Інтернету”, ніж то темне місце, в якому ми зараз опинились.
Чи є майбутнє, де Федиверс стане вибором більшості інтернету? Я можу собі це уявити; адже всі ми їздимо на автомобілях різних марок по дорогах різних країн та дістаємось куди треба. Але спочатку щось повинно статись з централізованими мережами.
22.03.2025
Стендап Сьогодні — тепер і в Федиверсі
Нарешті я на це наважився та публікую цей пост на @stendap_sogodni@shevtsov.me. Перфекціонізм мене тут зупиняв вже надто довго, треба з чогось почати. Запрошую підписатися!
Також із сьогодні OmniWOPE хоч трохи виправдовує префікс “омні” та вміє публікувати в Мастодон. Нагадаю, що публікація ведеться паралельно у всі налаштовані канали.
До речі, вирішив, що федиверсізація блогу (додавання ActivityPub прямо для його сторінок) - це проєкт, хоч безумовно цікавий, але завеликий, а також надто спеціалізований. Та я опинюся з тією ж проблемою невірного відображення HTML різними клієнтами. Тому все ж вважаю доцільною ретрансляцію змісту в Федиверс через проміжний сервер.
З проблемами HTML я поки нічого не робив, оскільки… треба з чогось почати. Поки зрозумів, що процес такий: мій сервер робить з Markdown HTML, а потім цей HTML вже обрізається клієнтами. Тож мені доведеться підбирати такий Markdown, який буде перетворений у прийнятний HTML. Тобто це ще окрема непроста задача.
25.03.2025
Підтримка relref для Mastodon
Приблизно два роки в мене в ПЗ для каналу є спосіб вказати посилання так, щоб на сайті воно вело на сайт, а в каналі Telegram - на пост в каналі. Сьогодні доробив цей функціонал й для публікації в Mastodon.
До речі. Mastodon досі не вміє публікувати Markdown. Тому технічно, наразі я підтримую не Mastodon, а GoToSocial, та, здається, ще Akkoma. Але — я використовую API Mastodon, звідси й назва.
Тут цікавого те, що вихідний текст поста в мене в Markdown. Та на виході теж отримую Markdown. Тому, певно, можна було б підставити посилання магією регулярних виразів, але навіщо, коли в мене є готове рішення для синтаксичного дерева Markdown? Залишилось тільки з нього побудувати назад Markdown - для того в Goldmark є спеціальний рендерер — та справа зроблена.
Мені такий підхід згодиться й в майбутньому, бо він допоможе позбавитись від тих конструкцій, які підтримуються неповноцінно.
26.04.2025
OmniWOPE: публікація ілюстрацій в Mastodon
Хотів сьогодні насправді писати зовсім інший пост, але для нього потрібна була ілюстрація. А їх мій скрипт для публікації — себто OmniWOPE - не вмів викладати в Mastodon. Нарешті цей недолік виправлено, та зображення повернуться в мій канал.
Технічний прототип в мене вже рік був готовий. Ну тобто я міг завантажити дану світлину в Mastodon. Що, до речі, відбувається у два кроки: спочатку медіафайл окремо, потім — статус із посиланням на ID файлу.
Але я довго думав, як же ж організувати статуси. Додавати зображення прямо у головну статтю мені не подобається, бо це спонукає клієнтів показати її як “статус-зображення”. Нарешті вирішив публікувати як відповідь до головного статусу — це все ж загально прийнятний спосіб.
Ще виявилося, що треба ж оголосити тип медіа. (До речі: сьогодні дізнався, що саме “тип медіа” сучасна назва, а не “тип MIME”.) Досі для Telegram мені було потрібно тільки знати, чи є ілюстрація зображенням чи відео. Та нарешті, чомусь вбудований у Go метод multipart.Writer#CreateFormFile не дозволяє призначити тип медіа! Та найкраще рішення для того — скопіювати та виправити код методу.
На сьогодні все. Нову версію вже можна забрати з GitHub.