Графики взаимоотношений мастодонтов

Новый выпуск Steampipe полностью посвящен графам отношений. В нашем сообщении в блоге показано, как эти графики обеспечивают контекстную осведомленность для специалистов по разработке и безопасности, которые теперь могут видеть все ресурсы, связанные с инстансом EC2, или сразу определять, правильно ли ограничены разрешения, связанные с ролью IAM. Как всегда, разработчики могут исследовать и изменять код, который строит эти графики, и адаптировать идиомы для своих целей в любой предметной области.

Эти графы отношений управляются запросами SQL, которые определяют узлы и ребра. Такие запросы могут использовать любой столбец любой таблицы, предоставляемой любым плагином Steampipe, для формирования узлов, а затем ребер между узлами. Если вы хотите увидеть связи между людьми и объектами, представленными различными API, теперь вы можете использовать идиомы SQL для их графического отображения. Единственным ограничением является ваше воображение.

Естественно, я представил себе график взаимоотношений мастодонтов. На данный момент я построил два графика, которые визуализируют мою домашнюю временную шкалу. Вот первый.

Здесь мы смотрим на последние 50 повышений (версия ретвита Mastodon) в моей домашней линии. Это запрос, чтобы найти их.

select
  *
from
  mastodon_toot
where
  timeline="home"
  and reblog_server is not null
  limit  50

Если мы сосредоточимся на Брайане Марике, мы увидим, что:

Брайан принадлежит к mastdn.social.
Брайан продвинул пост Тима Брея.
Тим принадлежит hachyderm.io.

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

Второй график уменьшен, чтобы показать сеть взаимосвязей повышения между серверами. Если кто-то на infosec.exchange повышает кого-то на mastodon.world, есть ребро, соединяющее два узла. Хотя на этом графике этого нигде не происходит, стрелка может указывать в обе стороны и была бы, если бы кто-то на mastodon.world также повышал кого-то на infosec.exchange.

мастодонт прокачивает сервер за сервером

Давайте построим первый график шаг за шагом.

Шаг 1. Определите выбранный сервер

Вот определение узла, представляющего выбранный сервер.

node {
  category = category.selected_server
  args = [ self.input.server.value ]
  sql = <<EOQ
    select
      server as id,
      server as title,
      jsonb_build_object(
        'server', server
      ) as properties
    from
      mastodon_boosts()
    where
      server = $1
  EOQ
}

Согласно документации, запрос узла должен как минимум выбрать столбец с псевдонимом id. Вот это server столбец в строке, возвращенной вышеуказанным запросом. Я упаковал этот запрос в функцию SQL, mastodon_boostsчтобы скрыть детали (timeline="home" reblog_server is not null limit 50) и упростить фокусировку на том, что особенного в каждом узле. В этом случае особое качество заключается в том, что столбец сервера, который дает узлу его идентификатор, соответствует выбранному серверу.

Если блок графа включает только этот узел, а выбранный сервер — mastdn.social, вот рендеринг. Здесь пока не на что смотреть!

Узел определяет набор свойств, которые могут быть любыми столбцами, возвращаемыми базовым запросом; они появляются при наведении курсора на узел. Узел также относится к категории, которая управляет значком, цветом и ссылкой узла. Вот категория для выбранного сервера.

category "selected_server" {
  color = "darkgreen"
  icon = "server"
  href  = "https://{{.properties.'server'}}"
}

Шаг 2. Определите усиленные серверы

Теперь мы добавим усиленные серверы. Этот узел использует тот же набор записей: 50 последних повышений в моей ленте. Опять находит только тех, чьи server столбец соответствует выбранному серверу. Но id теперь reblog_server который является целью, а не источником бустов с выбранного сервера.

node {
  category = category.boosted_server
  args = [ self.input.server.value ]
  sql = <<EOQ
    select
      reblog_server as id,
      reblog_server as title
    from
      mastodon_boosts()
    where
      server = $1
    EOQ
}

Вот график с обоими selected_server и boosted_server узлы. Мы использовали другую категорию, чтобы различать усиленные узлы.

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

Шаг 3. Определите людей, которые поддерживают других

Где люди? Давайте добавим их дальше, начиная с людей, которые отправляют повышения.

node {
  category = category.person
  args = [ self.input.server.value ]
  sql = <<EOQ
    select
      username as id,
      display_name as title,
	    jsonb_build_object(
        'instance_qualified_account_url', instance_qualified_account_url
      ) as properties
    from
      mastodon_boosts()
    where
     server = $1
    EOQ
  }

имя пользователя столбец дает узлу его идентификатор. Обратите внимание также на свойство instance_qualified_account_url. Это синтетический столбец, который мы добавили в плагин Mastodon в прошлый раз, чтобы гарантировать правильную работу ссылок на людей и инструменты в клиенте Mastodon. Потому что это включено в свойство здесь, и потому что category.person относится к этому свойству, ссылки, представляющие людей в графе, будут разрешены правильно.

Шаг 4. Определите людей, которых повысили

Этот узел берет свое имя из reblog_username столбец и использует синтетический столбец instance_qualified_reblog_url предоставить ссылку.

node {
  category = category.boosted_person
  args = [ self.input.server.value ]
  sql = <<EOQ
    select
      reblog_username as id,
      reblog_username as title,
      jsonb_build_object(
        'instance_qualified_reblog_url', instance_qualified_reblog_url
      ) as properties
    from
      mastodon_boosts()
    where
      server = $1
  EOQ
}

Шаг 5: Подключите бустеры на выбранном сервере к этому серверу.

До сих пор мы видели только узлы, чьи запросы минимально возвращают id свойство. Ребро соединяет узлы с помощью запроса, который минимально возвращает столбцы с псевдонимом from_id и to_id.

edge {
  sql = <<EOQ
    select
      username as from_id,
      server as to_id,
      'belongs to' as title
    from
      mastodon_boosts()
  EOQ
}

Вы также захотите указать заголовок для маркировки края. Здесь это ребро встречается дважды, обозначая «Джон Маши принадлежит к mstdn.social» и «Брайан Марик принадлежит к mstdn.social».

Шаг 6. Подключите людей на усиленных серверах к своим серверам.

Этот край работает так же, но фиксирует отношения между повышенными людьми и их серверами.

edge {
  args = [ self.input.server.value ]
  sql = <<EOQ
    select
      reblog_username as from_id,
      reblog_server as to_id,
      'belongs to' as title
    from
      mastodon_boosts()
    where
      server = $1
  EOQ
}

Шаг 7: Подключите бустеры к людям, которых они повышают

Наконец, мы добавляем преимущество, чтобы связать бустеров с людьми, которых они усиливают.

edge {
  category = category.boost
  args = [ self.input.server.value ]
  sql = <<EOQ
    select
      username as from_id,
      reblog_username as to_id,
      'boosts' as title,
      jsonb_build_object(
        'reblog_username', reblog_username,
        'reblog_server', reblog_server,
        'content', reblog ->> 'content'
      ) as properties
    from
      mastodon_boosts()
    where
      server = $1
  EOQ
}

И вот мы завершили первый график, показанный выше.

График отношений GitHub

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

А вот тот, который использует любой плагин Steampipe для отображения недавно обновленных запросов на вытягивание для выбранного репо.

Эти два представления используют общий SQL-запрос и служат дополнительным целям. Таблица удобна для сортировки по дате или автору, на графике выделены связи «один ко многим».

Снятие бремени сборки контекста

В статье «Как правильно сделать TimeDance» я оплакивал уход из жизни инструмента для планирования встреч, который отлично подходил для объединения сообщений и документов, связанных с собранием. Я назвал это «сборкой контекста» — термин, который я позаимствовал у Джека Оззи, соучредителя Groove, еще одного инструмента для совместной работы, уход которого я оплакиваю. Сборка контекста — тяжелая работа. Слишком часто бремя ложится на людей, которым нужно только использовать этот контекст и которые не хотят тратить время и усилия на его создание.

Мы видели, как SQL может унифицировать доступ к API. Теперь это также может помочь нам увидеть отношения между данными, которые мы извлекаем из этих API.

Эта серия:

Автономность, размер пакета, трение, разветвление и скорость
Mastodon, Steampipe и RSS
Просмотр федиверса
Терминал Bloomberg для Mastodon
Создайте свой собственный Mastodon UX
Списки и люди на Mastodon
Сколько людей в моей ленте Mastodon также написали сегодня в Твиттере?
URL-адреса Mastodon с указанием экземпляра
Графики взаимоотношений мастодонтов
Работа со списками мастодонтов
Изображения считаются вредными (иногда)
Картирование более широкой федеральной сети
Протоколы, API и соглашения
Новости в федерации
Сопоставление людей и тегов в Mastodon
Визуализация модерации сервера Mastodon
Сроки Mastodon для команд
Плагин Mastodon теперь доступен на Steampipe Hub.