نمودارهای رابطه ماستودون

Steampipe و SQL به ما این امکان را می دهند که روابط بین داده هایی را که از API استخراج می کنیم، ببینیم. در اینجا نحوه ترسیم ارتباط بین توترها و بوسترها در Mastodon آورده شده است.

نسخه جدید Steampipe همه چیز در مورد نمودارهای رابطه است. پست وبلاگ ما نشان می دهد که چگونه این نمودارها آگاهی زمینه ای را برای توسعه دهندگان و متخصصان امنیتی که می توانند اکنون تمام منابع مربوط به یک نمونه EC2 را مشاهده کنید، یا در یک نگاه مشخص کنید که آیا مجوزهای مربوط به یک نقش IAM به درستی دامنه دارند یا خیر. مثل همیشه، توسعه‌دهندگان می‌توانند کدی را که این نمودارها را می‌سازد، کاوش کرده و دوباره ترکیب کنند، و اصطلاحات را برای اهداف خود در هر دامنه داده ای تطبیق دهند.

این نمودارهای رابطه توسط پرس و جوهای SQL هدایت می شوند که گره ها و یال ها را تعریف می کنند. چنین پرسش‌هایی می‌توانند از هر ستونی از هر جدولی که توسط هر افزونه Steampipe ارائه شده است برای تشکیل گره‌ها و سپس لبه‌های بین گره‌ها استفاده کنند. . اگر می‌خواهید اتصالات بین افراد و اشیاء نشان‌داده‌شده توسط APIهای متنوع را ببینید، اکنون می‌توانید از اصطلاحات SQL برای ترسیم آنها استفاده کنید. تنها محدودیت تخیل شماست.

به طور طبیعی من تصور کردم که روابط ماستودون را ترسیم کنم. تاکنون دو نمودار ساخته ام که جدول زمانی خانه من را تجسم می کند. این اولین مورد است.

در اینجا ما به ۵۰ تقویت اخیر (نسخه ریتوییت Mastodon) در صفحه اصلی من نگاه می کنیم. این پرس و جو برای یافتن آنها است.

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

اگر روی برایان ماریک تمرکز کنیم، می‌توانیم ببینیم:

• برایان متعلق به mastdn.social است.
• برایان یک پست توسط تیم بری را تقویت کرد.
• Tim متعلق به hachyderm.io است.

بنابراین این نمودار افرادی را در یک سرور انتخابی نشان می دهد که افراد را در سرورهای دیگر تقویت می کنند. در این مورد mastdn.social سرور انتخابی است، اما می‌توانیم نمودار را روی هر سرور دیگری که تقویت‌کننده ارسال می‌کند، دوباره متمرکز کنیم.

نمودار دوم کوچک‌نمایی می‌شود تا شبکه تقویت روابط بین سرورها را نشان دهد. اگر کسی در infosec.exchange کسی را در mastodon.world تقویت کند، یک لبه وجود دارد که این دو گره را به هم متصل می کند. اگرچه در هیچ کجای این نمودار اتفاق نمی‌افتد، فلش می‌تواند به هر دو طرف اشاره کند و اگر کسی در mastodon.world هم کسی را در infosec.exchange تقویت کند.

اجازه دهید اولین نمودار را مرحله به مرحله بسازیم.

مرحله ۱: سرور انتخابی را شناسایی کنید

در اینجا تعریف گره ای است که سرور انتخاب شده را نشان می دهد.

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. در اینجا ستون سرور در یک ردیف است که توسط پرس و جوی بالا برگردانده شده است. من آن درخواست را در یک تابع SQL، mastodon_boosts، بسته‌بندی کرده‌ام تا جزئیات را پنهان کنم (timeline = 'home' reblog_server حد تهی ۵۰ نیست) و تمرکز روی آن را آسان‌تر کنم. هر گره چه ویژگی خاصی دارد در این مورد کیفیت ویژه این است که ستون سروری که به گره هویت می دهد با سرور انتخاب شده مطابقت داشته باشد.

اگر بلوک گراف فقط شامل این گره باشد، و mastdn.social سرور انتخاب شده، اینجا رندر است. هنوز چیز زیادی برای دیدن اینجا نیست!

گره مجموعه‌ای از ویژگی‌ها را تعریف می‌کند که می‌تواند هر یک از ستون‌های بازگردانده شده توسط پرس و جو زیربنایی باشد. این ها زمانی ظاهر می شوند که گره را نگه دارید. گره همچنین به دسته ای اشاره دارد که بر نماد، رنگ و پیوند گره حاکم است. در اینجا دسته بندی برای سرور انتخاب شده است.

category "selected_server" {
  color = "darkgreen"
  icon = "server"
  href  = "https://{{.properties.'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 است. ما از دسته دیگری برای متمایز کردن گره های تقویت شده استفاده کرده ایم.

فقط یک سرور انتخاب شده وجود دارد، اما می‌تواند به بیش از یک سرور تقویت‌شده، بوست ارسال کند. رندر پیش‌فرض آنها را در یک گره جمع می‌کند اما می‌توانید برای باز کردن و دیدن همه آنها کلیک کنید.

مرحله ۳: افرادی را که دیگران را تقویت می کنند شناسایی کنید

مردم کجا هستند؟ بیایید آنها را در مرحله بعد اضافه کنیم، از افرادی که در حال ارسال افزایش هستند شروع کنیم.

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 به آن ویژگی اشاره دارد، پیوندهایی که افراد در نمودار را نشان می دهند به درستی حل می شوند.

مرحله ۴: افرادی که تقویت شده اند را شناسایی کنید

این گره شناسایی خود را از ستون 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
}

مرحله ۵: تقویت کننده های سرور انتخابی را به آن سرور متصل کنید

تا کنون ما فقط گره هایی را دیده ایم که پرس و جوهای آنها به حداقل ویژگی 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 است” رخ می دهد.

مرحله ۶: افراد روی سرورهای تقویت شده را به سرورهایشان متصل کنید

این لبه به همان روش کار می‌کند، اما رابطه بین افراد تقویت‌شده و سرورهایشان را نشان می‌دهد.

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
}

مرحله ۷: تقویت کننده ها را به افرادی که تقویت می کنند وصل کنید

در نهایت یک لبه برای اتصال بوسترها به افرادی که آنها را تقویت می کنند اضافه می کنیم.

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 مشترک دارند و اهداف تکمیلی را انجام می دهند. جدول برای مرتب‌سازی بر اساس تاریخ یا نویسنده مفید است، نمودار روابط یک به چند را برجسته می‌کند.

برداشتن بار مونتاژ زمینه

در What TimeDance درست شد من برای گذشتن ابزاری برای برنامه‌ریزی جلسات که در گردآوری پیام‌ها و اسناد مربوط به یک جلسه عالی بود، عزادار شدم. من این را «مجموعه زمینه‌ای» نامیدم – اصطلاحی که از جک اوزی، یکی از بنیان‌گذاران Groove، ابزار همکاری دیگری که برای مرگش سوگواری می‌کنم، گرفته بودم. مونتاژ زمینه کار سختی است. اغلب این بار بر دوش افرادی است که فقط باید از آن زمینه استفاده کنند و ترجیح می دهند برای ایجاد آن زمان و تلاش صرف نکنند.

ما دیدیم که چگونه SQL می‌تواند دسترسی به APIها را یکسان کند. اکنون همچنین می‌تواند به ما کمک کند تا روابط بین داده‌هایی را که از آن API استخراج می‌کنیم، ببینیم.

این مجموعه:

1. خودمختاری، اندازه بسته، اصطکاک، هواکش و سرعت
2. Mastodon، Steampipe و RSS
3. مرور fediverse
4. یک پایانه بلومبرگ برای Mastodon
5. Mastodon UX خود را ایجاد کنید
6. لیست ها و افراد موجود در Mastodon
7. چند نفر در فید Mastodon من نیز امروز توییت کردند؟
8. نشانی‌های اینترنتی Mastodon واجد شرایط نمونه
9. نمودارهای رابطه ماستودون
10. کار با لیست های Mastodon
11. تصاویری که مضر تلقی می شوند (گاهی اوقات)
12. نقشه برداری فدیورس وسیع تر
13. پروتکل‌ها، APIها و قراردادها
14. اخبار در fediverse
15. نقشه برداری از افراد و برچسب ها در Mastodon
16. تجسم نظارت سرور Mastodon
17. جدول زمانی Mastodon برای تیم ها
18. افزونه Mastodon اکنون در Steampipe Hub در دسترس است