Плагин Mastodon теперь доступен на Steampipe Hub.

Когда в ноябре прошлого года Twitter сменил владельца, я переключился на Mastodon; с тех пор я наслаждаюсь более счастливым и продуктивным общением в социальных сетях. Чтобы увеличить свое счастье и продуктивность, я начал работать над плагином Mastodon для Steampipe. Моя первоначальная цель состояла в том, чтобы изучить Федиверс в целом. Какие люди и какие серверы являются мощными соединителями? Как работают политики модерации? Каково это присоединиться к маленькому серверу по сравнению с большим?

Это важные вопросы, и вы можете использовать плагин, чтобы начать отвечать на них. Но вскоре я понял, что как новичок в сфере, которая развивалась в течение шести лет и не приветствовал такой анализ, я должен начать с поиска способов улучшить опыт чтения Mastodon. Поэтому я начал создавать набор панелей управления, которые дополняют стандартный клиент Mastodon или (мой любимый) elk.zone. И я рассказал об этом проекте в серии постов.

На прошлой неделе мы выпустили плагин для Steampipe Hub. Если вы установили Steampipe, теперь вы можете получить плагин, используя steampipe plugin install mastodon. На следующих этапах этого проекта будет рассмотрено использование плагина и панелей мониторинга в Steampipe Cloud, а также ускорение работы панелей с помощью постоянных таблиц Postgres и снимков состояния Steampipe Cloud. Между тем, вот резюме того, что я узнал до сих пор.

Увидеть больше, меньше отвлекаясь

Хотя информационные панели используют диаграммы и графики взаимосвязей, в основном они представляют собой таблицы результатов запросов. Поскольку информационные панели Steampipe (пока) не отображают HTML, эти представления отображают только обычный текст — без изображений и без стилизованного текста. Я принял это ограничение и считаю его ценным в двух отношениях. Во-первых, я могу просматривать гораздо больше сообщений, чем это возможно в обычных клиентах, и более эффективно выбирать, с чем взаимодействовать. Когда я описал этот эффект другу, он сказал: «Это терминал Блумберга для Mastodon!» Как помнят те из нас, кто оседлал первую волну блогосферы, читатели RSS были откровением по той же причине.

Во-вторых, я считаю, что отсутствие изображений и стилизованного текста действует успокаивающе. Чтобы поддерживать здоровую информационную диету, вам нужно разумно выбирать источники, но независимо от того, куда вы идете, сайты используют множество привлекающих внимание устройств. Я нахожу снижение уровня шума полезным по той же причине, по которой я часто переключаю свой телефон в монохромный режим. Внимание — наш самый дефицитный ресурс; чем меньше отвлекающих факторов, тем лучше.

Конечно, есть компромисс; иногда изображение — это весь смысл поста. Так что, хотя я часто читаю Mastodon с помощью этих дашбордов Steampipe, я также использую Elk напрямую. Панели инструментов Steampipe работают вместе с обычными клиентами Mastodon и действительно зависят от них: я переключаюсь с панелей на Elk, чтобы увеличить, ответить или просмотреть изображения. Этот опыт усиливается URL-адресами с указанием экземпляра, которые переводят иностранные URL-адреса в те, которые работают на вашем домашнем сервере.

Управление людьми и списками

Возможность назначать людей в списки и читать по спискам — удобная возможность Twitter, которой я никогда особо не пользовался, потому что алгоритмы легко управляли моей информационной диетой. Поскольку Mastodon так не работает, списки стали основным способом чтения Fediverse. Из более чем 800 человек, за которыми я следил до сих пор, я назначил более половины списков с такими названиями, как *Климат* и *Энергия* и *Программное обеспечение*. Чтобы помочь мне в этом, несколько информационных панелей сообщают, сколько людей, за которыми я следую, включены в списки (или нет).

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

with list_account as (
  select
    a.id,
    l.title as list
  from
    mastodon_my_list l
    join mastodon_list_account a on l.id = a.list_id
),
list_account_follows as (
  select
    list
  from
    mastodon_my_following
    left join list_account using (id)
)
select 'follows listed' as label, count(*) from list_account_follows where list is not null
union
select 'follows unlisted' as label, count(*) from list_account_follows where list is null

Когда вы читаете, ориентируясь на список, а также когда вы читаете по хэштегам, всегда найдутся люди, чья болтливость отвлекает. Чтобы контролировать это, я внедрил следующее правило: показывать не более одного оригинального файла на человека в списке в день. Не пропущу ли я некоторые вещи таким образом? Конечно! Но если вы сказали что-то, что находит отклик у других людей, я, скорее всего, услышу об этом от кого-то еще. Это компромисс, который хорошо работает для меня до сих пор.

Вот SQL-реализация правила.

with data as (
  select
    list_id,
    to_char(created_at, 'YYYY-MM-DD') as day,
    case
      when display_name="" then username
      else display_name
    end as person,
    instance_qualified_url as url,
    substring(content from 1 for 200) as toot
  from
    mastodon_toot_list
  where
    list_id = '42994'
    and reblog is null -- only original posts
    and in_reply_to_account_id is null -- only original posts
  limit
    40
)
select
  distinct on (person, day) -- only one per person per day
  day,
  person,
  toot,
  url
from
  data
order by
  day desc,
  person;

На домашней панели временной шкалы я сделал необязательным включать или скрывать повышения, которые могут быть большинством элементов. На панели чтения списка я решил всегда исключать их, но идиома SQL для этого —select distinct on (person, day)— прост, легок для понимания и легко изменяется.

Визуализируйте отношения

На данный момент я нашел три способа, с помощью которых графы отношений могут сделать Mastodon более разборчивым. Во-первых, на графиках отношений Mastodon я показал, как использовать узлы и ребра, определенные в SQL, для демонстрации взаимосвязей между людьми и серверами. В другой статье я использовал те же инструменты для сопоставления отношений между людьми и тегами. И совсем недавно я использовал их для изучения межсерверной модерации.

Во всех трех случаях формат передает информацию, недоступную напрямую из табличных представлений. Выскакивают группы интересных людей, как и люди, которые делятся тегами. И когда я нарисовал серверы, которые блокируют другие серверы, я обнаружил неожиданную категорию: некоторые серверы, которые блокируют другие, сами также заблокированы, например информационная биржа в этом примере.

IDG

Комбинация Steampipe с доступом к API, ориентированным на SQL, и панелями мониторинга в виде кода — это уникальный продуктивный способ построения графиков взаимосвязей, которые могут открыть доступ к информации в любой области. Как мы видели на примере Kubernetes, они могут помочь сделать облачную инфраструктуру более понятной. Графики Mastodon показывают, что то же самое может произойти и в сфере социальных сетей.

Используйте RSS-каналы

Когда вы добавляете .rss на URL-адрес учетной записи Mastodon или тег, вы создаете RSS-канал, например https://mastodon.social/@judell.rss или https://mastodon.social/tags/steampipe.rss. Эти каналы предоставляют своего рода вспомогательный API, который включает данные, недоступные в основном API: связанные теги, которые отображаются в каналах как RSS. category элементы. Steampipe здесь действительно великолепен благодаря плагину RSS, который позволяет подключаться к основному API Mastodon. Этот запрос дополняет элементы в ленте аккаунта тегами, которые появляются в каждом элементе.

with data as (
  select
    name,
    url || '.rss' as feed_link
  from
    mastodon_search_hashtag
  where
    query = $1,
    and name = query
  limit 
)
select
  to_char(r.published, 'YYYY-MM-DD') as published,
  d.name as tag,
  (
    select string_agg(trim(JsonString::text, '"'), ', ')
    from jsonb_array_elements(r.categories) JsonString
  ) as categories,
  r.guid as link,
  ( select content as toot from mastodon_search_toot where query = r.guid ) as content
from
  data d
join
  rss_item r
on
  r.feed_link = d.feed_link
order by
  r.published desc
limit 10

Аналогичный запрос управляет графом, который обсуждался в разделе «Отображение людей и тегов на Mastodon».

IDG

В этом примере, выявляя связь между пользователем, @themarkupи пару тегов, scotus и section230, был полезен в двух отношениях. Во-первых, это помогло мне мгновенно найти статью, которую я больше всего хотел прочитать, которая была скрыта глубоко в результатах поиска. Во-вторых, это помогло мне найти источник, к которому я вернусь за советом по схожим темам. Конечно, я добавил этот источник в свой Law список!

Владейте алгоритмом

Каждый, кто приходит на Mastodon, ценит отсутствие враждебного алгоритма, контролирующего то, что они видят на своей временной шкале. Однако большинство из нас не против алгоритмического влияния как такового; нам просто не нравится враждебный характер этого. Как мы можем построить алгоритмы, которые работают с нами, а не против нас? Мы уже видели один пример: панель чтения списка отображает только один элемент в списке на человека в день. Это политика, которую я смог определить и легко реализовать с помощью Steampipe. И на самом деле я отрегулировал его после того, как использовал его некоторое время. Первоначальная политика была ежечасной, и это было слишком болтливо, поэтому я переключился на ежедневную, внеся тривиальное изменение в SQL-запрос.

В News in the fediverse я показал еще один пример. Сервер мастодонт press.coop объединяет каналы из основных источников новостей. Я был счастлив получить эти каналы, но я не хотел, чтобы эти новости смешивались с моей домашней хроникой. Скорее, я хотел назначить их News список и читать их только тогда, когда я посещаю этот список в мышлении чтения новостей. Fediverse предлагает возможность перезагрузить социальную сеть и получить контроль над нашими информационными диетами. Поскольку у всех разные диеты, должно быть возможно — и даже легко — для любого включить правило, такое как *новости только в списках, а не в хрониках*. Steampipe может сделать это так.

Паровая труба как компонент

Когда вы спрашиваете людей на Mastodon о таких функциях, ответ часто бывает таким: «Вы пробовали клиент X? Он предлагает функцию Y». Но это решение не масштабируется. Для реализации каждой такой политики потребовалось бы огромное дублирование усилий каждого клиента; Между тем, люди не хотят переключаться на клиент X только из-за функции Y (что может привести к потере функции Z). Можно ли инкапсулировать политики и сделать их доступными для любого клиента Mastodon? Интересно думать о Steampipe как о компоненте, обеспечивающем такую ​​инкапсуляцию. Временная шкала, созданная с помощью SQL-запросов и управляемая политиками, определенными SQL, — это ресурс, доступный любому приложению, которое может подключаться к Postgres локально или в облаке Steampipe.

Если вам интересно узнать о комбинации Steampipe + Mastodon, установите плагин, попробуйте примеры запросов, затем клонируйте мод и проверьте панели инструментов. Полезно ли они дополняют ваш считыватель Mastodon? Что бы их улучшить? Можете ли вы использовать эти ингредиенты, чтобы придумать свой собственный опыт Mastodon? Присоединяйтесь к нашему сообществу Slack и дайте нам знать, как идут дела!

Эта серия:

1. Автономность, размер пакета, трение, разветвление и скорость
2. Mastodon, Steampipe и RSS
3. Просмотр федиверса
4. Терминал Bloomberg для Mastodon
5. Создайте свой собственный Mastodon UX
6. Списки и люди на Mastodon
7. Сколько людей в моей ленте Mastodon также написали сегодня в Твиттере?
8. URL-адреса Mastodon с указанием экземпляра
9. Графики взаимоотношений мастодонтов
10. Работа со списками мастодонтов
11. Изображения считаются вредными (иногда)
12. Картирование более широкой федеральной сети
13. Протоколы, API и соглашения
14. Новости в федерации
15. Сопоставление людей и тегов в Mastodon
16. Визуализация модерации сервера Mastodon
17. Сроки Mastodon для команд
18. Плагин Mastodon теперь доступен на Steampipe Hub.