This account is not set to public on notestock.

@t_fukui 100個少ないですから、有意義に使いたいですよね。喧伝されているメリットと、実際のメリットに乖離があるような気がします。言ってはいけない系w #dtp

@t_fukui そもそも、ユーザーが気付いてないんじゃないかなw #dtp

@t_fukui おお、安くなってる！！
（でももっと安くして欲しい） #dtp

This account is not set to public on notestock.

relayの裏でwakinさんのsimple_apをずっといじってる。

なんか例外吐いてるっぽいところがあるんだけど、どうデバッグしていいかわからない。Pythonも頑張らねば……。 #dtp

This account is not set to public on notestock.

@rk_asylum かわいそうすぎる……

そもそも、旦那に浮気 🤔 #dtp

@panda_planet そのときついでにコイツをcherry-pickして…… 🍒
https://github.com/tootsuite/mastodon/commit/e55dce3176b7ac0a23a8a652c2626707a1b74dbb #dtp

やっぱり銀河丼をリレーに引き込まなあかん。もっと環境を整備しておかねば……。 #dtp

@rk_asylum 正直、ガチガチ過ぎてツライ。 #dtp

@mochi_roc たとえば、視覚デザイン研究所のVDLロゴGって書体ありますよね。

これ、本家のライセンスこんな感じです。
http://www.vdl.co.jp/license/index.html

Typekitのはこちら。
https://helpx.adobe.com/jp/typekit/using/font-licensing.html

もちろっくさんはマジで見ておいた方がいいですよ。追加料金なしで利用できる範囲が全然違います。 #dtp

Typekitの本当の凄さは、本家とはライセンス（許諾範囲）が異なることかな。

……DTP勢の詳しい人を呼んでこないと説明できないけどw #dtp

@kedama むむ、それはヤバイ……。連絡手段あったっけか。 #dtp

@centumix そういやホスティング勢は改造するワケにはいかんのか……。

必要性を訴えてマージしてもらうの、ハードル高いな……。 #relay考

@wakin quote_indicator_container.jsの10行目ですよね。

replyとかreblogとか修正入った時に一緒に直しておかないと、あとで気付くのは難しいですね……。

ウチはその変更入った時にmaster追っかけてたので、mergeする時に直しちゃったんでした。今度またヤベー変更を見つけたら報告します！ #dtp

This account is not set to public on notestock.

@centumix botバッチが設定されているアカウントのトゥートを、インスタンス側で投げないようにしました ＞ DTP-Mstdn.jp

commitおいておきます。誰でもできる簡単なお仕事です……
https://github.com/dtp-mstdn-jp/mastodon/commit/84ba276d980e28306f756dc546315c4e4d8c8550

インスタンスでルール化しているなら、Mastodon側でBotアカウントの公開トゥートを強制的にunlistedにしてもいいような気がします。 #relay考 #dtp

This account is not set to public on notestock.

This account is not set to public on notestock.

バナナTLになってるw
虚構新聞てw

@Yaaaa @sximada との掛け合いを見ていると、ここはボケなくてはいけない!! という気になるんですがw #dtp

@Cutls クライアントで実現しちゃうのが手っ取り早いので、私もクライアントに手を出したい……。

他方、WebUIや本体が標準でもっていないと、Mastodon全体の発展には繋がらないんですよねぇ。 #relay考

This account is not set to public on notestock.

Mastodonは、連合があるから、どこのインスタンスに登録しても同じだよ！

……というのは今のところ情報強者の理屈でして、

よくわかんないけど、たしかにそうだね

って状況を自然に実現する方法は、もう少し智惠を絞っておいた方が良いと思います。

リレーがうまく機能すれば、その一助になると思いますが、この観点からはどうでしょう？

#relay考

リレーされる情報を、無作為に減らして、一定量以上はリレーしないようにする、という乱暴な実装も考えられる。負荷軽減策。

1toot/秒以上は受け取らないとか、100toot/日をlimitにするとか。

pub-relayの実装も、全ての情報を確実に伝えることは意図していない（リトライしない）し、まぁ賑わえば歯抜けでもいいんじゃね🤔

#relay考

見づらいとこ書き直したくなるけど、やめておこうw #dtp

リレーによる機能の実現

・リレーに送信するが、受信しないインスタンスを認める（inboxに投げるだけでフォローしなければOK）
・特定の条件を満たす情報のみリレーする機能（タグ、キーワード、インスタンスなど）
・リレーをリレーする機能（ループしないよう、経路情報やTTLのような情報が必要？）
・経路情報やキーワードマッチ結果などの付加情報を持たせる機能（元情報をペイロードとするガワをつくる等）

リレーの倫理

・利用目的の明示（目的外利用の禁止：検索インデックス作成、トップランキング、ワーストランキング等）
・検閲・情報統制への利用を防ぐとともに、スパム・迷惑行為への対処をどう実現するか

#relay考

リレー＋インスタンス側のフィルタによる機能の実現（クライアントによっても実現できる）

リモートタイムライン（指定インスタンスのトゥートだけを選択的に表示するTL）
・リレー供給を受けていれば、自インスタンスに居ながらにして別のインスタンスのTLが再現できる

インタレストフィルタ（被ブースト・お気に入り・リプライ数によって表示可否を設定）
・リレーによって流入したトゥートを非表示にする（ユーザーが選択）
・誰もインタラクションしていないトゥートを非表示にする（ユーザーが選択）

インタレストフィルタの考察
・インスタンス内の誰かが関心を持っている外部の情報、というこれまでのインスタンス毎の連合タイムラインの意味を再確認し、その方向を強化するためのフィルタ
・当初フィルタされていたトゥートがあとから表示する条件を満たした時に、どのような挙動となるのが理想か（ひょっこりその場に現れるべきか、何らかの基準でageられるべきか）

#relay考

大規模インスタンス

・大規模なインスタンスは、既に十分なユーザーを抱えていて、基本的に自己充足している
・ユーザーのリモートフォロー・リプライ・ブースト等により、連合タイムラインに他のインスタンスのトゥートが十分に流入している
・他のインスタンスのLTLから無条件の供給を受ける必要はない
・網羅的な情報が有用なので、タグTLの供給は受けてもよい
・最小限の負荷であれば、LTLを供出してもよい

中小インスタンス

・少ないリソースで運用しなければならないため、身の丈を超えた流入は受け入れられない
・負荷軽減のため、流入量に制限を設けたい
・特定のタグの情報は欲しい
・特定のキーワードなど、内容により選別されたトゥートは欲しい

お一人様インスタンス

・あらゆる戦略が考えられるが、他のインスタンスのアカウントを必要とせず、自インスタンスに居ながらにして最大限Fediverseを活用するという目的であれば、興味のあるインスタンスの情報は受け取りたい
・情報を絞り込む戦術など、その他の事情は、中小インスタンスと共通
#relay考

ちょっと #relay考 ってタグを試してみます。

This account is not set to public on notestock.

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

@yamma_ma 同人者なので、東京流通センターが最初に思い浮かぶw

Tone Response Curve ですね。
すげーーー！！
異次元の超便利ツールになってきた！！

あとはどうやってMacでこれを使えるようにするかだな……w #dtp

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

--

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

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

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

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

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

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

https://dtp-mstdn.jp/@noellabo/100380169856378128 #dtp

@toneji Mastodonの方は、このリレーサーバと連携するための機能が追加されています。

基本的に、自分でリレーを立てる必要はありません。 #dtp

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@toneji 仕組みとしては、Ruby on Railsの話です。

ま、今晩はこのぐらいにしておきましょうかw #dtp

@toneji リレーから他のインスタンスの投稿がFTLに流れてきていれば成功です。

https://mstdn01.noellabo.jp この臨時インスタンスのFTLと同じものが来ているハズです！ #dtp

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

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

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

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

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

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

@toneji #dtp

@theoria まず、すごい勢いでリモートアカウントが増えていきますw

joinmastodonのリレーに登録した日にゃ、これまで接点がなかったアカウントがバンバン登録されています！

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

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

@toneji 最初の何行かが見えてれば。
7ac5151b7 (tag: v2.4.3) Bump version to 2.4.3
あたりまでで十分です。

まぁ、とりあえず、logは大丈夫だと思うのでほっといて、bin/tmpの処遇を決めましょう。 #dtp

@toneji 一行表示って意味なので、git log --oneline です。one #dtp

@toneji なぜそこにtmpができてるのかわかりませんが、中身を確認して削除かなぁ。 #dtp

@toneji 一番さいごのとこ、bin/tmp が増えてるけどどーすんの？って言ってきてます。 #dtp

@toneji ですです。ssh接続。 #dtp

@toneji 特に関係ないけど、不便じゃないかなと思ってw #dtp

@toneji ん？ ひょっとしてこれまでのメンテナンス、みんなwebのコンソールから操作してました？ #dtp

@toneji まず、現状確認です。
git status と、git log --oneline の出力をみましょう。 #dtp

ふぅ。おはようございます（ぉぃ #dtp