もっと見る

Mastodonの管理画面、超格好良いダッシュボードが追加されましたね。なんでいままでなかったんだコレ……w

のえる :cava_red: DTP鯖管 さんがブースト

@toneji Mastodon以外のサーバでどんな機能追加が必要になるかまではわかりませんが、仕組みが単純なので、簡単に実装できるハズです。

--

リレーですが、フォローBotを不要にしたいという議論と、Diasporaのリレーの仕組みを参考に議論がはじまっています。

他の連合する機能を持ったシステムがこうした問題にどう取り組んでいるのか、先行する仕組みに寄せた方が良いのか、独自に発展した方がよいのか、互換性のあるものを目指すべきなのか……。

人任せにしていても、Mastodonの開発をリードするEugenさんと主要開発者、関連のIssueでの議論を中心に出来上がっていくと思いますが、我々も理想の姿について色々と考えて議論し、勝手にヘンなもの作ったり膨大なトラフィックを送り込んで怒られたりしながらw、何らかの形で参加していった方が良いのではないかと思います。

だいたい、ヘンなものができて押しつけられてから「どうしてこうなったの!?」とか思うワケですが、結局は任せきりにして意見しなかったことが原因です。どうせなら最初から参加しちゃいましょう。

自分でリレーサーバのコードを書いたみたいな実装の説明をしましたが、単に読んで説明しただけです。読み違えていたらご容赦ください。

このあたりを踏まえておくと、リレーってどうよ、という話をする際に、実装を知らずに話すより生産的な議論ができるのではないかと思います。

dtp-mstdn.jp/@noellabo/1003801

リレーサーバの実装の話。

現在のリレーサーバ実装(pub-relay)は、登録インスタンスのリスト(ドメインとinboxのアドレス)と、登録を拒否(ブロック)するドメインのリストだけをデータベースに持っています。

relay@リレーサーバ というアカウントが直接生えているので、各インスタンスはこれとやりとりしています。

登録インスタンスがrelayのinboxに投稿を投げてよこしたら、全登録インスタンスのinboxにそれを投げ直します(パススルー)。

relayへのフォローリクエストの体で、リレーに登録し、フォロー取り消しで削除。

sidekiqでProcessWorkerとDeliverWorkerが走っていて、ProcessWorkerがrelayに対するリクエストの処理、DeliverWorkerが各インスタンスへトゥートを配信する処理を行います。

sidekiqのキューはdefaultのみ、リトライは行いません。

登録インスタンス一覧と、ブロックの登録・削除を行う、シンプルなコマンドラインツールがついています。

実に美しく読みやすい。
※個人の感想です

リレー、動かしてみて良いところをみつけたり、問題点をあぶり出したりする段階なので、たくさん話題になるといいな。

箕面どんの鯖缶 @toneji さんが、v2.4.3にリレーの機能だけをcherry-pickして動かし始めました。

relay.dtp-mstdn.jp をリレーに登録し、参加いただいています。こちらは現在11のインスタンスが登録しています。

@h3zjp@m.xn--fiqwix98h.jp によると、現在下記のリレーが観測されているようです。
m.中二病.jp/@h3zjp/10037936058685

※ リレーはオプション機能で、全文検索機能のように、Mastodonに必ず必要なものではありません。また、まだ最初の実装が提供されて日の浅い、極めて実験的なものです。皆さんに積極的におすすめするものではありません。

いち早く体験し、どういうものが導入されようとしているのか、自ら確認してみたい!という人はやってみてもいいんじゃないかな、という程度です。

※ もともとがオプションということもあり、導入しても具合が悪ければすぐにリレー登録を止められるので、過度な心配は不要です。

※ cherry-pick:自分の気に入ったものだけをつまみ食いする、の意。gitで、特定の変更だけを取り入れるときに使う機能

migrateは、データベースに変更が必要な箇所をソースコードから見つけ出して、追加・変更のためのマイグレーションコード(rubyのプログラム)を生成します。

生成したmigrate用のコードは~/live/db/migrate/ に増えていきます。ここをチェックすると、データベースにいつどのような変更をしてきたのか、履歴がたどれます。

生成したコードを実行して、データベースに実際の変更を行います。

このコード生成と実行を行うのが、いつもやっている
RAILS_ENV=production bundle exec rails db:migrate
です。

(まれにmigrateに失敗して、アップデートが立ち往生することがあります。そのときに、問題を起こしているファイルを削除てやりなおしたり、コードに手を入れる場合があります)

Mastodon本体のプログラムは開発者達が修正してくれますが、自分のインスタンスの状態は自分で面倒をみなければならないので、覚えておきましょう!

@toneji

ここんとこマジメなことばかり言っていたから、少しくだらないことをいって中和せねば(いらない

@Cutls さんが違う世界線に生きているっぽくて……ゾクゾクする(ちがう

のえる :cava_red: DTP鯖管 さんがブースト

ちなみに relay.dtp-mstdn.jp の確認用臨時サーバはこちらです。
mstdn01.noellabo.jp

こちらは参加していただいているインスタンスは現在7つ(+この臨時鯖)です。

@h3zjp@m.xn--fiqwix98h.jp テスト用の臨時インスタンスおいときます。

mstdn-relay.hama3.net 観測所
mstdn02.noellabo.jp/

連合にトゥートが流れる状況を観測するためにご活用ください。このリレーにのみ参加しています。

のえる :cava_red: DTP鯖管 さんがブースト

力が欲しい………………………​ :manego:

同一サーバにインスタンス2個立てのテストをするなど。

のえる :cava_red: DTP鯖管 さんがブースト

relayはオプションですので、特に無理に導入する必要はないと思います。

連合の見えている範囲が狭いと、分散した個々のインスタンスが情報不足で孤立するので、それをカバーする仕組みかなーと思ってます。地域格差みたいな。

のえる :cava_red: DTP鯖管 さんがブースト

「何故これで動くのか」とかは(良いコードなら)大抵はコードを読めばわかるので、「何故同じように動く他の書き方をしなかったのか」を積極的に書いてほしい

のえる :cava_red: DTP鯖管 さんがブースト

ちなみに,そのシステムのコードを読んでいて学んだことは「識別子名を信じてはいけない」でした…

もっと見る

のえる :cava_red: DTP鯖管 によるおすすめ:

DTP-Mstdn.jp

DTP-Mstdn.jpは、DTP・デザイン・印刷に関わる人々のためのMastodonインスタンスです。特定分野の専門インスタンスですので、日々のつぶやき、耳寄りな情報の共有、ディスカッション、質問とその回答、役立つスクリプトなど、他では投稿しづらい内容も、思う存分トゥートしましょう!