افزونه Mastodon اکنون در Steampipe Hub در دسترس است

fediverse فرصتی برای راه اندازی مجدد وب اجتماعی و به دست آوردن کنترل رژیم های اطلاعاتی ما ارائه می دهد. Steampipe و پلاگین Mastodon آن می توانند به شما در کشف آن کمک کنند.

وقتی توییتر در نوامبر گذشته دست به دست شد، من به Mastodon تغییر مکان دادم. از زمانی که از شبکه های اجتماعی شادتر و پربارتر لذت بردم. برای افزایش شادی و بهره وری خود، شروع به کار بر روی یک افزونه Mastodon برای Steampipe کردم. هدف اولیه من مطالعه گسترده نوشتار فدیورس بود. کدام افراد و کدام سرورها کانکتورهای قدرتمندی هستند؟ سیاست های اعتدال چگونه کار می کنند؟ پیوستن به یک سرور کوچک در مقابل سرور بزرگ چگونه است؟

اینها سؤالات مهمی هستند و می توانید از افزونه برای شروع به پاسخ دادن به آنها استفاده کنید. اما به زودی متوجه شدم که به عنوان یک تازه وارد در صحنه ای که شش سال است در حال تکامل است و از چنین تحلیلی استقبال نکرده ام، باید با جستجوی راه هایی برای تقویت تجربه خواندن ماستودون شروع کنم. بنابراین من شروع به ساخت مجموعه ای از داشبورد کردم که مشتری سهام 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 کلیک می کنم تا تصاویر را تقویت کنم، پاسخ بدهم یا مشاهده کنم. این تجربه با نشانی‌های اینترنتی واجد شرایط برای نمونه که نشانی‌های اینترنتی خارجی را به نشانی‌هایی که روی سرور خانگی شما کار می‌کنند ترجمه می‌کنند، بهبود می‌یابد.

افراد و لیست ها را مدیریت کنید

امکان اختصاص دادن افراد به فهرست‌ها و خواندن به روش فهرست‌محور، یک ابزار مفید توییتر است که من هرگز زیاد از آن استفاده نکردم، زیرا به راحتی اجازه می‌دادم الگوریتم‌ها بر رژیم غذایی من نظارت داشته باشند. از آنجایی که Mastodon اینطور کار نمی کند، لیست ها به روش اصلی من برای خواندن جریان fediverse تبدیل شده اند. از بیش از ۸۰۰ نفری که تاکنون دنبال کرده ام، بیش از نیمی از آنها را به لیست هایی با عناوینی مانند *اقلیم* و *انرژی* و *نرم افزار* اختصاص داده ام. برای کمک به من در انجام این کار، چندین داشبورد گزارش می‌دهند که چند نفر از افرادی که دنبال می‌کنم به فهرست‌ها اختصاص داده شده‌اند (یا نه).

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

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
    ۴۰
)
select
  distinct on (person, day) -- only one per person per day
  day,
  person,
  toot,
  url
from
  data
order by
  day desc,
  person;

در داشبورد خط زمانی خانه، گنجاندن یا پنهان کردن تقویت‌ها را اختیاری کرده‌ام، که می‌تواند اکثر موارد باشد. در داشبورد فهرست‌خوانی، من ترجیح داده‌ام همیشه آنها را حذف کنم، اما اصطلاح SQL برای انجام این کار – انتخاب متمایز در (شخص، روز) – ساده است، درک آن آسان است و به راحتی قابل تغییر است. .

روابط را تجسم کنید

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

در هر سه مورد، قالب اطلاعاتی را منتقل می‌کند که مستقیماً از نماهای جدولی در دسترس نیست. دسته‌ای از افراد جالب ظاهر می‌شوند، مانند افرادی که برچسب‌ها را به اشتراک می‌گذارند. و هنگامی که من نموداری از سرورهایی که سرورهای دیگر را مسدود می کنند را ترسیم کردم، دسته غیرمنتظره ای را کشف کردم: برخی از سرورهایی که دیگران را مسدود می کنند، خودشان نیز مسدود هستند، مانند infosec.exchange در این مثال.

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

از فیدهای RSS

استفاده کنید

وقتی .rss را به URL یک حساب Mastodon یا برچسب اضافه می کنید، یک فید RSS مانند https://mastodon.social/@judell.rss یا https: //mastodon.social/tags/steampipe.rss. این فیدها نوعی API کمکی را ارائه می‌کنند که شامل داده‌هایی است که در غیر این صورت از API اصلی در دسترس نیستند: برچسب‌های مرتبط، که در فیدها به عنوان عناصر رده RSS ظاهر می‌شوند. Steampipe واقعاً در اینجا به لطف افزونه RSS می درخشد که امکان اتصال با Mastodon API اولیه را فراهم می کند. این پرس و جو موارد موجود در فید حساب را با برچسب هایی که در هر مورد ظاهر می شود، افزایش می دهد.

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 را هدایت می کند.

در آن مثال، ظاهر کردن ارتباط بین یک کاربر، @themarkup، و یک جفت تگ، scotus و section230 مفید بود. به دو صورت اول، به من کمک کرد که فوراً موردی را که بیشتر می‌خواستم بخوانم، که در اعماق نتایج جستجو مدفون بود، پیدا کنم. دوم، به من کمک کرد منبعی را کشف کنم که برای راهنمایی در مورد موضوعات مشابه به آن باز خواهم گشت. البته من آن منبع را به فهرست قانون خود اضافه کردم!

الگوریتم را در اختیار دارید

همه کسانی که به Mastodon می‌آیند از نداشتن الگوریتم خصمانه برای کنترل آنچه در جدول زمانی خود می‌بینند قدردانی می‌کنند. اگرچه بسیاری از ما به خودی خود با تأثیر الگوریتمی مخالف نیستیم. ما فقط ماهیت خصمانه آن را دوست نداریم. چگونه می‌توانیم الگوریتم‌هایی بسازیم که با ما کار می‌کنند، نه علیه ما؟ ما قبلاً یک مثال را دیده‌ایم: داشبورد لیست‌خوان فقط یک مورد را در هر لیست به ازای هر نفر در روز نمایش می‌دهد. این سیاستی است که من توانستم آن را با Steampipe تعریف کنم و به راحتی اجرا کنم. و در واقع بعد از مدتی استفاده آن را تنظیم کردم. خط‌مشی اصلی ساعتی بود، و این خیلی پرحرف بود، بنابراین با ایجاد یک تغییر بی‌اهمیت در پرس و جوی SQL، به روزانه تغییر کردم.

در News in the fediverse مثال دیگری را نشان دادم. سرور Mastodon press.coop فیدها را از منابع خبری اصلی جمع آوری می کند. از داشتن آن فیدها خوشحال بودم، اما نمی‌خواستم آن اخبار را با جدول زمانی خانه‌ام ترکیب کنم. در عوض، می‌خواستم آنها را به فهرست News اختصاص دهم و فقط زمانی که با طرز فکر خبرخوانی از آن لیست بازدید می‌کنم، آنها را بخوانم. fediverse فرصتی برای راه اندازی مجدد وب اجتماعی و به دست آوردن کنترل رژیم های اطلاعاتی ما ارائه می دهد. از آنجایی که رژیم‌های غذایی ما همگی متفاوت است، برای هر کسی باید این امکان و حتی آسان باشد که قوانینی مانند *اخبار فقط در فهرست‌ها، نه جدول‌های زمانی* را روشن کند. Steampipe می تواند آن را چنین کند.

Steamppipe به عنوان جزء

وقتی از افراد در Mastodon در مورد این نوع ویژگی‌ها می‌پرسید، پاسخ اغلب این است: «آیا مشتری X را امتحان کرده‌اید؟ این ویژگی Y را ارائه می دهد. اما این راه حل مقیاس نمی شود. برای اجرای هر یک از این سیاست‌ها، هر مشتری به تلاش‌های مضاعف نیاز دارد. در همین حال، مردم نمی خواهند فقط برای ویژگی Y (که ممکن است به از دست دادن ویژگی Z منجر شود) به مشتری X سوئیچ کنند. آیا می‌توان خط‌مشی‌ها را کپسوله کرد و در اختیار هر مشتری Mastodon قرار داد؟ جالب است که در مورد Steampipe به عنوان یک کامپوننت فکر کنید که آن کپسوله سازی را ارائه می دهد. خط زمانی ساخته شده توسط پرس و جوهای SQL، و توسط سیاست های تعریف شده توسط SQL اداره می شود، منبعی است که برای هر برنامه ای که می تواند به Postgres متصل شود، به صورت محلی یا Steampipe Cloud در دسترس است.

اگر در مورد ترکیب Steampipe + Mastodon کنجکاو هستید، افزونه، نمونه سوالات را امتحان کنید، سپس mod را شبیه سازی کنید و داشبوردها را بررسی کنید. . آیا آنها به طور مفیدی خواننده Mastodon شما را تقویت می کنند؟ چه چیزی آنها را بهبود می بخشد؟ آیا می توانید از این مواد برای اختراع تجربه سفارشی Mastodon خود استفاده کنید؟ به انجمن Slack ما بپیوندید و به ما اطلاع دهید که چگونه پیش می‌رود!

این مجموعه:

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 در دسترس است

• API
• SQL
• توسعه وب< /a>
• توسعه نرم افزار< /a>
• Analytics
• رایانش ابری< /a>