のえる DTP鯖管 @noellabo@dtp-mstdn.jp

@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

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

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

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

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

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

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

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

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

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

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

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

#relay考

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

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

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

#relay考

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

リレーによる機能の実現

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

リレーの倫理

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

#relay考

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

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

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

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

#relay考

大規模インスタンス

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

中小インスタンス

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

お一人様インスタンス

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

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

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