もっと見る

いろいろあって、あらためてEugenさんが書いたリッチテキスト対応のコード(まだ制作中)ですが、

* 従来は、HTML要素としては下記の4つのタグのみ受け入れていた
p br span a

* あらたに、7つのタグを受け入れる
em i strong b code del s

* その上で、Mastodonから強調とコードの投稿を許可する

というような内容になっています。

`*強調1*` *強調1*
`**強調2**` **強調2**
`` `コード` `` `コード`

(将来のMastodon、Pleromaでしか見えません。添付画像参照)

コードは、アカウントやハッシュタグの記述をリンクに変換せずに記述できます(発信元での変換の抑制なので、従来バージョン向けにも有用です)

実例:
`@relayctl@dtp-mstdn.jp join` を投稿すると、リレーに個人参加できます。

`@relayctl@dtp-mstdn.jp subscribe ` を投稿すると、``タグ付き投稿を購読できます。(あらかじめ`@relay@dtp-mstdn.jp`をフォローしておく必要があります)


Mastodonのリレーについていえば、オプショナルな存在で、

あなたはリレーに参加してもいいし、参加しなくてもいい。

というシロモノです。

また、最初から入力候補に入っているオフィシャルのrelay.joinmastodon.orgは動いてないという有様です。

有力なリレーとしては、Pleromaのrelay(Generic LitePub relay)を使ったリレーが
relay.mastodon.host/
で運用されていて、MastodonやPleromaが相互接続しています。私のFediBot鯖(Botや開発用のMastodonサーバ)も参加しています。

いま見ると226のサーバが接続していますね。流量は雪餅リレーの方がずっと多いです。

本来は、リレーが単一障害点にならないよう、複数のリレーに参加して、どこか落ちてもそんなに影響ないよね、という状態にしようという話でした。

現状、ジェネリックリレーですら数が少なすぎて全然だし、ハッシュタグリレーは単独運用だし、便利だけどそれぞれが落ちたりやめたらそれまでだよね、という状況です。

雪餅リレーはgo製で十分な剛性が……

もとい。リレーはサーバ強化すれば捌ききれると思うけど、受け取る方が死ぬだろうね。

Mastodon本体の方が、処理内容も多いし、RoRで処理速度も遅い。

もCrystal製なので処理は速い方。

今は、tootctl statuses removeで、誰も絡んでない古い投稿は削除できる。実はそれほどデータベースサイズが深刻に肥大するわけでもない。

とはいえ、ギリギリで動かしているところは無理だし、メンテしないで放置すれば死ぬ。

まぁ、リレー入るような人が放置するとは思えない……思いたくないところだけど。

ランランリレーも出来上がりつつあるし、ほんと楽しくなってきたなぁ。

オッ、雪餅リレーにも、アクティブなactorが生えてきたぞ。

公益性のある情報とか、宣伝とか、できるだけ多くの人に届けたい投稿をブロードキャストするなら、やはりハッシュタグ付けてリレーってのが有効なので、ちゃんとインフラを整備して、皆に使ってもらえるようにせねば。

リレーは、Fediverseのサブプレイヤーなのです。

Mastodonにとっては、オプショナルな機能です。

しかし、リレーを通じて利用者に主流のものとは異なるあり方を提案することができ、規格やメインプレイヤーに影響を与えることもできるので、たいへんやりがいがあります。

■ 使い方

まず、 @relay@hashtag-relay.dtp-mstdn.jp を直接フォローしておいてください。

@relayctl@hashtag-relay.dtp-mstdn.jp にメンションを送ることでコマンドを実行します。皆に見えてしまうので、DMがお薦めです。

subscribe Gargron@mastodon.social

のように、アカウントは先頭の@を除いたドメイン込みの表記、ハッシュタグはそのまま、追加したい分だけ記載します。

unsubscribe Gargron@mastodon.social

解除したいアカウント、タグを指定します。全部消しちゃう時は、 :all というオプションをつけてください。 :all-tag でタグだけ、 :all-account でアカウントだけ全消です。

status

現在のリレーの登録状況を確認します。

set :lang:ja

言語を指定します。:lang:en で英語、:lang:ja で日本語、という簡易の対応です。Mastodonの投稿言語の設定も反映されます。

hello

こんにちは!


スレッドを表示

に、ハッシュタグとアカウントの購読機能を追加しました。

先に投入した、個人参加の機能は、リレーへの送信のみでしたが、こちらは受信のみの機能です。

組み合わせることで、特定タグの送受信が可能になります。

また、直接フォローせずに、特定のアカウントの公開投稿をホームタイムラインで購読できる機能でもあります。

Public Followとか、Weak Followとか、何か名称が必要になりそうな概念です。

現在、Mastodonでの動作は確認されていますが、Pleromaについてはまだカバーできていません。Misskey他、テストできていないシステムで実行すると異常が発生するかもしれませんので、あらかじめご了承ください。


Qrunchにもう一個書いた。

Mastodon本家のpub-relay動かそうとしてハマっている人多いので、そういう人にこれ見せてあげて。

Crystalでbio_newが無いとかエラーでる場合の対処(openssl_ext)
noellabo.qrunch.io/logs/KgdoPu

Pleromaを(手動で)ハッシュタグリレーに参加させた状態です。リレーから受信できています。

送信も個人参加で実現できています。サーバ単位での参加は、Pleroma側の実装を確認中です。

まだ細かな部分では問題含みなので、解決に取り組んでいます。

とりあえず、技術的には可能、ということをお伝えしておきます。

リレー制限を10分にしたよ。ぽむたんを再召還して能力が封じられたか確認しようず。 @nippon

一応、Pleromaからの投稿がMastodonにも届くようになったけど、これ削除が転送できないのでは……。

現在、Mastodonのリレーでは、PleromaのActivity(投稿、フォロー、お気に入りなどの情報)を受け付けません。

これは、PleromaがActivityに署名を付与していないため、正当な送り主が送ってきた、改ざんされていないActivityであることを、簡単に確かめられないからです。

Fediverseのサーバ同士が直接やりとりする場合は、HTTPリクエストに署名を行う仕組みを使って、Activityへの署名を省略することができます。

PleromaはHTTPに署名すれば、Activityに署名しなくてもいいんじゃね?と判断しているわけです。

リレーは代理で送信する仕組みであるため、HTTPへの署名では正当性が確かめられない(むしろ、他人が送っていることを証明している)ため、Activityへの署名が頼りです。

なお、Pleromaのリレーでは、代理で送信せずに、このActivityを受け取って!という通知(Announce)だけを行って、受信するサーバに直接取りに行かせることで解決しています。

Pleroma、リレーの受信は問題なさげ。

relayctlが送信するActivityの何かが原因でタイムラインの読み込みにエラーが発生する症状がでているので、原因解明までPleromaあての送信は失敗するようにしておくことにする。

Mastodon FE(PleromaのMastodonの見た目のフロントエンド)では問題が起きないので、Pleroma FEを調べる。

スレッドを表示

まぁ、非互換性といっても、一つ一つは些細なモノです。

ただし、どんなに些細な違いでも、エコシステムに致命的な影響を与えることがあります。

APIの破壊的変更を伴って、辛うじて生き延びていた古いバージョンのサーバやクライアントが死滅するかもしれません。まぁ、隕石が衝突したみたいな話ですね。

リレーの話で言うと、PleromaのinboxにPOSTする(Activityを送信する)際に、Content-Type : application/activity+json をちゃんと送信する、というのがありました。

pub-relay、何も送らないんですが、そうするとPleromaがHTTP 500エラーを吐きますw

Mastodonは動いちゃう。

いま、MisskeyからのPublicKeyがデコード出来ないってエラーでハマっています。解決方法は確認中です。まぁ、そういう話です。

なんか難しい話してる、としか思えないかと思いますが、恐らくActivityPubを扱っている人ならだいたい同じトコで悩むことが多いと思うんですよね……。

スレッドを表示

ハッシュタグリレーは、Mastodon本家のリレー(pub-relay / Crystal言語で書かれた配送にsidekiqを用いるバージョン / 作成者はChris Hobbs)から派生して書かれているのですが、

この本家リレー、ActivityPubベースでやりとりするようになっていて、一応はFediverseに向けた汎用目的になっていますが、実際はMastodonの実績はなく、そのままで機能するようにはなっていません。細かなところで非互換があって、実装間の差異を埋めていくには、ActivityPubの実務に詳しくなっていくしかなさそうです。

現在、少しずつActivityPub対応のコードを書く人が増えてきているように観測していますが、情報交換を行ったり、その記録を残したり、非互換の解消を働きかけたり、一緒にやれることについては協力できるといいなと思ったりします。

ちょっと簡単に言い直しますw

現状、Pleromaのハッシュタグリレー対応には、ちょっとPleromaの改造が必要になりそうです。
dtp-mstdn.jp/@noellabo/1014958

信頼できる署名(LDS)があれば、どれだけ多くのリレー先に届けても、送信元の負荷は一定です。リレーに預ければ、それで終わりです。

ところが、リレー先が一斉に送信元にデータを確認しにいく実装となると、リレー先が増えれば増えるほどアクセスが集中することになり、多大なる負荷となります。(nginx等でキャッシュすることで大幅に負荷を軽減できますが、依然としてリレーより負荷が高くなります)

やはり、PleromaにLinked data Signaturesのサポートを追加するのが現実的であるように思います。

スレッドを表示

Mastodonの場合、LDSが含まれるため、信頼できると確認できますが、Pleromaではこれができません。

Mastodon側で対応する方法としては、Activityに含まれる本来の送信元へ問い合わせして、裏付けをとるという方法があります。

投稿であれば、実際の投稿内容を取得して、一致しているかどうか確認すればいいわけです。動作としては、おおよそブーストの場合と同じです。(我々はフェッチしにいく、という言い方をします)

削除であれば、HTTP 404 Not Foundか、Tombstone(削除されたことを示す《墓石》)になっていることを確認すればいいわけです。

ただし、この実装は著しく非効率です。

Pleromaのリレー実装が、このようなブーストベースのものになっているということですが(詳しく見ていません)、コンセプトはともかく、実用上は現実ではないと言われています。

雪餅(2018) 連合リレーと Activity Relay
blog.yukimochi.jp/2018/12/fedi

スレッドを表示
もっと見る

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

DTP-Mstdn.jp

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