Email or username:

Password:

Forgot your password?
iliazeus

Расскажу вам про еще одну свою полу-доделанную штуку: fediread.link

Это читалка для (public и unlisted) тредов Федиверса, для которой я пытаюсь делать такой UI, чтобы длинные треды было удобно читать.

Кроме того, она не требует логиниться в какой-либо инстанс, потому что использует ActivityPub и публичные API серверов. Поэтому, например, можно делиться ссылками на тред:

fediread.link/#p=https://lor.s

Главное: указывать URL нужно именно с того инстанса, которому принадлежит пост. Для мастодона это можно сделать опцией "скопировать URL поста" в трехточечном меню.

Из больших недоделок: не поддерживается Френдика и многие мелкие/самописные сервера. Да и вообще, пока я это писал, к своему сожалению понял, что — как _клиентский_ протокол — серверы довольно плохо поддерживают ActivityPub. В треде ниже я буду ругаться на конкретные вещи, с которыми я столкнулся.

@rf

10 comments
iliazeus

Самая частая из проблем, на самом деле, даже не специфична для ActivityPub — криво настроенные Access-Control (CORS) заголовки.

Некоторые инстансы совсем не ставят заголовок http.dev/access-control-allow- на свой публичный API. Это автоматически значит, что к этому API невозможно получить доступ из браузера, если там origin (домен + порт) отличается от origin самого API.

Некоторые инстансы пытаются это исправить, но делают это криво. У них в ответе приходит разрешающий все `Access-Control-Allow-Origin: *` ... но _два_ раза. По спеке, этот заголовок должен быть не более чем один, поэтому (по крайней мере в Firefox) такая API все равно недоступна.

Эта проблема — почти единственная причина, почему у fediread.link вообще есть какой-либо бэкенд. Это должно было быть полностью браузерное приложение!

Самая частая из проблем, на самом деле, даже не специфична для ActivityPub — криво настроенные Access-Control (CORS) заголовки.

Некоторые инстансы совсем не ставят заголовок http.dev/access-control-allow- на свой публичный API. Это автоматически значит, что к этому API невозможно получить доступ из браузера, если там origin (домен + порт) отличается от origin самого API.

iliazeus

Вторая крупная проблема — непоследовательность в том, какие API инстансы считают публичными, а какие нет.

Например, у Мастодона есть "защищенный" режим, когда любой ActivityPub-запрос требует подписи приватным ключом аккаунта. Фактически, это значит, что запросить что-либо по протоколу AP может только другой инстанс, по команде какого-либо пользователя этого инстанса.

И все бы ничего, но при этом у таких Мастодонов остается открытой собственное мастодоновское API! Через которое можно без какой-либо авторизации получить любые public и unlisted посты!

Из-за этого и подобных ограничений я не мог просто использовать "голый" ActivityPub, как хотел изначально — мне пришлось писать адаптеры и фолбеки на API Mastodon и Misskey. И, вероятно, придется делать так еще и для других серверов.

Вторая крупная проблема — непоследовательность в том, какие API инстансы считают публичными, а какие нет.

Например, у Мастодона есть "защищенный" режим, когда любой ActivityPub-запрос требует подписи приватным ключом аккаунта. Фактически, это значит, что запросить что-либо по протоколу AP может только другой инстанс, по команде какого-либо пользователя этого инстанса.

iliazeus

Еще одна особенность, которая меня раздражала — почти никакие инстансы, кроме Mastodon, не отдают в ActivityPub-объектах коллекцию replies.

Для коммуникаций сервер-сервер это, в каком-то смысле, даже можно понять — другой инстанс все равно получает большинство ответов через федерацию, и может связать их по полю inReplyTo. Но для коммуникаций сервер-клиент это отвратительно — мне приходится делать фоллбеки на API конкрентных реализаций, через которые все реплаи обычно доступны.

iliazeus

С необходимостью ходить в API конкретных реализаций связана еще одна проблема: ID сущностей в этих API и в ActivityPub зачастую совершенно разные!

Из-за этого мне приходится костылями вытаскивать "внутренние" id, и не для всех серверов я умею это делать. Для некоторых, например, мне приходится делать запрос на URI из ActivityPub-объекта и потом смотреть, на какой URL меня редиректнет — в этом URL будет тот самый внутренний ID.

А вот что делать для Френдики, я так и не придумал. Буду рад, если кто подскажет, кстати.

С необходимостью ходить в API конкретных реализаций связана еще одна проблема: ID сущностей в этих API и в ActivityPub зачастую совершенно разные!

Из-за этого мне приходится костылями вытаскивать "внутренние" id, и не для всех серверов я умею это делать. Для некоторых, например, мне приходится делать запрос на URI из ActivityPub-объекта и потом смотреть, на какой URL меня редиректнет — в этом URL будет тот самый внутренний ID.

iliazeus

Вот, кстати, исходники для веб-интерфейса:

github.com/iliazeus/fedireader

И для самой клиентской библиотеки, которая используется и на беке, и на клиенте:

github.com/iliazeus/fedijs

Предупреждаю: js-говнокод, который вырос очень _органически_, и требует рефакторинга.

top.ofthe.top

> > Некоторые инстансы совсем не ставят заголовок https://http.dev/access-control-allow-origin на свой публичный API. Это автоматически значит, что к этому API невозможно получить доступ из браузера

Ну вообще activitypub и задумывался для межсерверного взаимодействия, а не для клиент-серверного. А ставить ли хедер access-control-origin зависит от того, хочет ли админ сервера чтобы запросы могли слать посторонние. По дефолту ведь и сам мастодон его не ставит, а мог бы, возможно не хотят лишних запросов.

iliazeus

@top

> activitypub и задумывался для межсерверного взаимодействия, а не для клиент-серверного

Есть пруфы? Сам стандарт вот описывает и сервер-сервер, и клиент-сервер. Причем клиент-сервер даже упомянут первым.

iliazeus

@top

> А ставить ли хедер access-control-origin зависит от того, хочет ли админ сервера чтобы запросы могли слать посторонние.

Запросы _уже шлют_ посторонние, просто это не браузеры, а другие серверы. К примеру, перкзапросить activity по ее id по HTTPS - один из стандартных способов подтвердить ее достоверность, если она не была подписана. А если была - то запросить профиль ее автора, чтобы получить его публичный ключ и валидировать эту подпись.

А говорить "это API публично, но только если ты шлёшь запросы не из браузера" очень нелогично и непоследовательно, как по мне.

@top

> А ставить ли хедер access-control-origin зависит от того, хочет ли админ сервера чтобы запросы могли слать посторонние.

Запросы _уже шлют_ посторонние, просто это не браузеры, а другие серверы. К примеру, перкзапросить activity по ее id по HTTPS - один из стандартных способов подтвердить ее достоверность, если она не была подписана. А если была - то запросить профиль ее автора, чтобы получить его публичный ключ и валидировать эту подпись.

top.ofthe.top

В явном виде в спеках этого не попадалось, но по-моему, это вытекает из того что по дефолту браузеры не могут получать джейсоны со сторонних доменов и по дефолту на AP инстансах этот хедер не включён. Почему большинство AP движков по дефолту не включают хз, возможно, как я уже предположил выше, чтобы минимизироать трафик: запрашивая инфу через свой инстанс, инфа сперва ищется в кеше твоего инстанса, а уже потом запрашивается со стороннего.

Go Up