kmyblueでうっかり作ってしまった微妙な機能たち

2024年12月15日 21:55

あすかです。
去年のアドベントカレンダーで場外乱闘をしてしまいカレンダーよりも盛り上がってしまったあすかです。あのときは各所にご迷惑おかけしました。

こちら、Fediverse Advent Calendar 2024の１６日目の記事です。

今回は自分が開発保守しているMastodonフォークの１つ、kmyblueについてちょっとした余談を入れてみます。kmyblueは誰でも自分のサーバー建てられるよう整備してありまして、すでに２０くらいのサーバーが建っています。使ってくれてる人ありがとうございます。

ソフトってこう、適当に作っていると、後から考えれば何のためにあるのかよくわからない機能ができてしまったりしますよね。よく考えずに作っちゃうというか。そういうのって保守が面倒になりますけど、需要がゼロになるわけではないので、一度作ったら消すのが大変難しいやつになります。
簡単に消しちゃうとソフトウェアに対する信頼も一緒に消えちゃうので、どれだけさりげなく消せるかが重要になったりします。

kmyblueももれなくそれで、一回作ったけどやっぱりこの機能いらないんじゃない＆影が薄すぎる＆直すのが難しいバグや問題がある、でも一回作った以上簡単には消せないし‥‥っていう微妙な機能がいくつかあります。
それぞれの機能の紹介と微妙な理由、微妙なのに消せない理由などなどを簡単に書いてみます。あすかのいつもの長ったらしくて中身のない記事を読めるような酔狂な方を対象に、その人がなんかソフト作るときに参考にしてもらえればなーと思ってます。

あ、これらの機能をこれから消しますよって予告では決してないです。互換性確保のためにできるだけ残すつもりではいます。以下に挙げる機能の中には、普通に役立っているもの、有用性の高いものもあります。

本記事で挙げた機能の概要

この記事とても長いので、読みたいところだけ読んでもらいたいです。最初にそれぞれの機能について結論を一文で書きますと、

ログインユーザー限定投稿：いらないけど他のSNSにもある機能なので消しづらい
NGルール：使い方を説明したくないから誰も使えない
ひかえめな引用：システム的に引用の代替になっているので消せない
購読許可：削除済、解決
フレンドサーバー：最初からいらないと思って作ったので消したくない
Markdown：過去の投稿の表示が崩れるので消せない
拡張ドメインブロック：いつか消そうと思っている

ログインユーザー限定投稿

これ、一番多くのユーザーの目に留まるのにいらないと思ってる機能ナンバーワンです。

概要

サーバーkmyblueまたはkmyblueフォークに登録した人が公開範囲を選ぶとき、この選択肢が出ます。

kmyblueのログインユーザー限定投稿、これはじめから連合する前提で設計した機能ですけども、有用性に疑問があります。

そもそもkmyblueのログインユーザー限定投稿は2023年5月下旬、サーバーkmyblueが立ち上がってから３ヶ月目、まだフォークとして整備されていなかった頃に実装したものです（Misskeyよりずっと前ですね）。

つまり当時は同人テーマサーバー以外の意識はありませんでしたから、機能を使う対象はクリエイターを想定してました。
投稿をGoogleや攻撃者の用意したクローラに検出されたくない、AI学習に使われたくないという目的で作りました。このへんはMisskeyと同じですね。

でもこれね、実装した時点で問題が３つありました。

問題点１：拡散の難しさ

問題の１つは、拡散の難しさです。
連合させるためには、この機能に対応していないサーバーでもログインユーザー限定投稿に要求された最低限の要件を満たさなければいけません。だってこれ、ロボット対策とはいえ、見られる人を限定する機能ですよ。言い換えればプライバシーです。じゃあこの公開範囲のない他の実装に対応するためにどうするかというと、フォロワー限定になります。

kmyblueフォークの中ではログインユーザーであれば誰でも見れますが、他のサーバーではフォロワーしか見れなくなります。
kmyblueフォークの中では、ログインユーザー限定投稿は誰でもブーストできます。フォローとか関係ありません。ローカルタイムラインにも流れます。他のkmyblueフォークから来たログインユーザー限定投稿も同様にブーストできます。
それが、Misskeyを含む他の実装ではフォロワー限定として扱われますから、当然ブーストできません。しかも、kmyblueユーザーがログインユーザー限定投稿をブーストしても、他のサーバーから見れば「他人のフォロワー限定投稿をブーストした」という扱いになって、それを他のサーバーが受け入れてタイムラインに流すかどうかは各実装の判断になります。（余談ですがMisskeyは、kmyblueで特定条件下に限り発される「フォロワー限定投稿の引用」は認識できません。投稿を受け取った時にエラーになります）

クリエイターにとって自分の作品が拡散されるのは大事です。売上とか知名度とかおはぎとかに繋がりますから。でもこれをMisskeyがやるならまたしも、人口の少ないkmyblueフォークの中でしか拡散が有効でないのなら、やっぱり厳しい。画像にウォーターマーク入れるほうが百倍ましってなるんですよね。

問題点２：ログインユーザー限定は公開範囲ではない？

ログインユーザー限定という概念、kmyblueでは公開範囲の一つとして実装してしまいましたけど、やっぱりこれ公開範囲とは分けるべきだと思ってます。

kmyblueのログインユーザー限定投稿は、kmyblueフォークでは公開投稿と似た扱いになります。もちろんローカルタイムラインに流れます。でも非収載投稿をログインユーザー限定にしたいってなった場合、対応する機能がないです。
新たに非収載向けの公開範囲を作るのもなんか違うと思います。それだとこう、同じ公開範囲を複数作るのと変わらない。そうじゃなくて、投稿時のオプションに変更するのが最もいいと思ってます。

これ実装直後から思ってることですが、実は直前に実装したMarkdownとあいまって投稿フォームにボタンを追加する余裕がなくて、オプションとして実装するなら、ボタンを押したらポップアップが出てその中で設定する形が理想だと思ってます。

ただ、現在kmyblueが追従している本家MastodonはJavaScriptからTypeScriptへの入れ替え途中でして、このログインユーザー限定投稿そのものの有用性もほとんど感じられないってのもあって、今すぐUIいじるのは抵抗感あるなーと思っててずっと放置していたりします。

あと、この仕様のせいで、Misskeyが最近実装した同様の機能にも対応できていません。
現在kmyblueはログインユーザー限定の設定を公開範囲にそのままくっつけているため、指定が投稿単位、かつ過去の投稿に遡及適用されません。Misskeyはアカウント単位で、遡及適用されます。
よって現仕様ではMisskeyの希望する動作をkmyblue内で再現することはできません。対応するとしても、kmyblueのほうのこれが改善されたあとになると思います。

Misskeyのログインユーザー限定をkmyblueで対応できない理由はこれを含め他にもいくつかありまして、以下のIssueにも書いてます（文章わかりにくいかもしれない）。

問題点３：クローラがActivityPubのタイムラインから直接投稿を収集するのは防げない

そもそも、どういうクローラを想定しているかですね。Googleだけなのか、他にもあるのか。kmyblueでは、攻撃者が自作したクローラを想定に入れてます。

ちゃぶ台ひっくり返すようですけど、クローラがActivityPubのどっかのサーバーに登録して、そこからkmyblueのユーザーをフォローして、そこから流れてきた画像をAPIで収集するのは防げないです。
これはkmyblueだけでなくFediverseやってる限り脆弱なところでして、Misskeyのローカル限定＋ログイン限定の組み合わせというのが今ある対策の中では最も有効だと思います。

ただしローカル限定もね、巨大なサーバーでそれやったら意味ないです。API使ってそのサーバーの連合タイムライン巡回すればいいんですから。特にmisskey.ioとかいうところは絵がいっぱい流れてくるうえに多数のリモートアカウントと繋がってますから、そこ巡回すれば効率いいんです。

後の章にも書きますけど、攻撃するときってね、攻撃した時のメリットが攻撃の手間を上回らなくちゃいけないんです。MisskeyはAPIも提供してるから、敷居が低い。攻撃しやすい。APIがあってもなくても攻撃はできるんですけど、とっつきやすさとしては重要です。素人でもできるかどうかです。みなさんもF5アタックくらいはしたことあるでしょ。~~あすかは某CGIゲームでやりました。~~misskey.ioはまだDanporuと比べるとかなり小さいサイトなんで、メリットが上回っているかは攻撃者次第になりますけど、反AI過激派なら気にしたほうがいいと思います。

個人的には、MisskeyやMastodonのような分散型SNSではなく他のとこのほうがよっぽと安全かなと。Fediverseに拘る必要性は薄いし、むしろ非推奨かと。
このあたりについては同じカレンダーの５日目で別の方が記事書いていただいてますので、参考になるかと思います。

ちなみにローカル限定は存在自体、巨大なサーバーができちゃうのが前提の設計、新しいサーバーの参入を阻害する諸刃の剣だとも思ってまして、Misskeyは著作権だなんだで需要は根強いかもしれませんが、少なくともうちではやりたくないです。

現状

というわけでkmyblueでは今すぐこの機能にテコ入れできることはないと思ってまして。問題点２の修正はいつかやるかもしれませんけど。

この機能を消すのは技術的には簡単だと思ってて、消すとしたら従来のログインユーザー限定投稿はフォロワー限定に変換する感じですね。
でも今すぐそれをやらないのはなぜかというと、前提として、これは消すのは簡単ですけど作るのが難しいんです。ログインユーザーでしか見れないように変更しなければいけない画面がたくさんありますので、ヌケモレがないように点検しないと。コードを書くのも大変ですが、動作確認にも時間がかかると思います。なので、少しでも需要がありそうなら、消すに消せない感じ。

そのうえで、Blueskyもこれに似た機能を作っているんですよ。この機能を実際に使ってるBlueskyユーザーも多数おられるのかなと。英語圏のkmyblueユーザーからも（この機能に気付かずに）要望もらったことがありまして、この様子見てるに、AIイラスト以外にも用途あるんじゃないかと思ってます。それが何なのかはわからないですが。今は消さずにもうちょっと様子を見たいです。

一度作ったものは最後まで責任とらなあかんので考えるなら作る前だなーと、考えてから作るべきであってよく考えてないもんは入れるべきではないと。kmyblueでそういう話をするときに最初に挙げられるのがこのログインユーザー限定投稿になると思います。

NGルール

え、この機能めちゃくちゃ使えるじゃん、便利じゃん、ないと困るって言う人いると思います。あすかもその１人です。これ、めちゃくちゃ役に立ちます。この機能がないサーバーの管理は死んでも嫌です。Pleromaならできるかもしれない。
ただ最大の問題は、その「具体的にどこがどう役に立つのか」という情報をあまり外に出しづらいことです。

概要

この機能は2024年2月の例のスパム騒動を受けまして、2024年2月下旬に作りました。もちろんスパム対策を意図したものです。これが効果てきめんで、2024年3月以降は追加の対策を行わなくてもうちのサーバーがスパムで困ることはありませんでした。
10月ころにまた同様の騒動がありましたけど、そのときもうちはこの設定を2月からずっと有効にしてたので、むしろスパム騒動があったということに気づくまで時間がかかるレベルでした。

もうNGルール機能のない他のソフトウェアで運営するのが怖くなっちゃったくらいで、以前はMisskey管理興味あったんですけど今はもうやりたくないですよ。それくらい、もう自分にとってはなくてはならない機能になってしまったわけですけど、やっぱりフォークとして運用する以上、あすか以外の人もkmyblueを管理することになるわけですから、どうしても問題は出てきます。

問題点１：できることが多すぎる、設定画面が複雑すぎる

NGルール、設定できることはたくさんあります。いっぱいあります。ありすぎて難しいです。どの項目を設定すべきか分かりませんから。

いろんなことができるってことは、設定する人の個性も出てきちゃうってことです。
今のスパムはこんな感じだけど、将来攻撃者がここをちょっといじるかもしれないからちょっと範囲広めにするか、いやいや誤検出は嫌だから狭くするか、これ設定する人の判断です。個性です。おはぎです。性格が出ます。そうならないようにするのは無理です。責任持てません。
これはつまりどういうことかというと、みんな一緒にこう設定しましょうね、この設定が最強だよという、攻略的なことがやりづらい。中央から推奨設定を出すよりも、みんなが自分で考えて設定したほうがいいと思います。でもそれはあくまで理想です。

実際は、設定項目多すぎて、初めて見る人は面食らっちゃう。しかも正規表現の知識も必要になります。サーバーの管理者みんな詳しいわけではありませんから、そういう人たちのことも考えて機能を設計しなければいけない。それができてないと思います。
ですから、こちらから設定例を出してみなさんに設定してもらうのがどうしても一番ということになっちゃう。そうなるとみなさん、こちらと同じリスクを背負うことになる。それぞれのサーバー固有の事情にあった設定ができない。自由度高いのはいいけど、高すぎるのも考えものってやつです。

まず設定画面に大量の項目が出るとそれだけで圧迫になっちゃうので、そこからまずは改善しなければいけないと思うんですけど、そうなるとJavaScriptをめちゃくちゃ使う感じになると思います。単純に実装が大掛かりになるので後回しにしちゃえ‥‥になってます。

じゃあ設定方法を説明する記事とかたくさん書けばいいじゃん、になると思いますけど、そこでもう１つの問題点が絡んできます。

問題点２：相手に対策される

みなさん知ってると思いますが、スパムはいたちごっこです。基本は、対症療法以外は存在しないと思ってください。最近はAIもありますけど。
スパム対策にはもう１つ性質があります。「正常な投稿の誤検出をいかに最小限にするか」「スパムの検出をいかに最大限にするか」この２つを両立しなければいけません。これがとても難しい。Twitterの過剰な規制もそんな感じだと思いますよ。100%は絶対に不可能だと思ってください。

何が言いたいかというと、こっちがスパム対策でこういう機能を作りましたよと宣伝します。スパムはそれを乗り越えて、攻撃方法を変えてやってくるわけです。
こっちが対策を複雑にすればするほど、あっちももっと複雑なことをやってきます。そういう意味で、万能なスパム対策など存在しないし、今ある対策もいずれ必ず陳腐化します。ってのがあすかの考えです。

そういうわけで、なんかすごい対策機能作ったとしても、それを宣伝した時点で機能そのものが無意味になります。

問題点３：パターン化されていない攻撃に脆弱

このNGルール、自由度はたいへん高い、高すぎて困ってると問題点１で述べました。ただ、自由度が高いからといって、NGワードの最大の弱点が解消されたわけではありません。

さすがにね、こういうスパムが出る頃にはFediverseはとっくに焦土になっていると思いますので言わせてもらいますけどね、パターン化されていないスパム。そういうのが各所から出てきた場合、（サーバー管理者に十分な知識や知恵やおはぎがあるという前提で）NGルールでもある程度は頑張れるかもしれませんが、誤検出、ドメインブロック・ホワイトリストとの併用は不可避になるでしょう。
（具体的にどういうスパムなのかは、さすがに爆弾すぎるのでここでは割愛します）

同じ人の発出するスパムは、どんなに頑張っても必ず共通点は出ます。それを探して防ぐというのが基本的なスパム対策になりますけど、あちらがその共通点を徹底的に排した場合、やっぱりきつい。NGルールも所詮はパターン防御でしかないです。NGルールは、NGワードにちょっと毛が生えただけの機能であって、根本はNGワードと何も変わらないということは頭に入れなければいけません。
Twitterの各種規制に不満持ってる人いるでしょ、あれはそういうのと戦った結果じゃないかとあすかは思ってます。

とはいえ、このようなスパムが本当に出る頃にはkmyblueのNGルールがどうとの以前に、Pleromaを除くFediverse全体が大きな混乱に陥っていると思いますね。いやAIに強い人たちがなんとかしそうな気はしますけど。期待してます。

現状

使い方を紹介したり、NGルールでできることを具体的に説明したりしたらNGルール機能そのものが無意味になりかねないので、NGルールについての詳細な説明は公開したくないというのが本音です。

管理者に個人的に連絡してきたら設定方法のアドバイス位はするかもしれませんが、それ以上のことは周りの状況を見て慎重に判断、という形になるかと思います。

当面は、NGワード機能やホワイトリスト機能など、既存の機能を代わりに検討してもらえればと。

それに、NGルール自体にもまだまだ足りない機能は大量にあると思います。ただそれをするにはUIやデータ構造を大きく変えなければいけなくて、設定画面に関しては作り直しに近い感じになるかもしれません。大変な時間はかかりますけども、スパムのレベルが上がったらやるかもしれません。おはぎ作ってー

私見

あとこれ記事から外れてて完全に私見になりますけど、現在すでにドメインブロックでスパム対策は難しい段階に入ってると思うんですよね、そういうときに連合を重視しているサーバーであれば連合してるサーバーに対して縦断的な対策ができる機能（NGワードとか）が重要になると思うんですけど、それすら限界来るんで、ホワイトリストが最も安易ではありますが手軽で人気のある解決策になると思います。kmyblueもそれを見込んで作ってるところはあります。
ただ、ホワイトリストは最終的な解決策にはならないと思います。そうするとスパムは、mastodon.socialなど正常なサーバーに大量にアカウントを作ろうとしますから。今そうなってないのは、スパムを作るコストが、スパムによって得られる利益に見合ってないからであって偶然の幸運にすぎないと思うんですよ。そういうの度外視して攻撃する人がいて今年のはそれだと思いますけど（正直２月のやり方はいつか来ると思ってたけど、商業や詐欺ではなく荒らしが先に来るのは予想外でした。あれで対策されちゃったので利益重視系はさらにハードル上がりそう）、これからFediverseが成長していく限り、永い戦いになるということは頭に入れたほうがいいと思います。

Misskeyはそもそも連合を重視しないというのが設計思想になってるので、こういうのが来たらあちこちが連合切るんで、すぐに連合全体が混乱しやすくなる、脆弱になるんじゃないかとは思いますけども。実際に２月がそうなってて、連合に失望する人何人か見かけましたけど、今後来るスパムはその比ではないものもあるはずなので、ちょっとそれが心配ですね。
あすかは管理するサーバーを１つだけにしたりいろいろ対策機能追加したりすることでその日のために備えていますが、みなさんもそろそろなんか考えたほうがいいと思います。

とはいっても、いつどんな形で来るかもわからない、見えないものは対策しづらいんですよね。特に、今年２月のあれの特異な点は、Fediverse人口が少なくうまみも少ないから攻撃を控えてる商業・詐欺スパムの頭を超えてやっちゃったところです。時代を先取りしたんです。ですから次にあれを超えるスパムは数年後かそれよりも遅くなるかもしれない。もしくはその時が来るまでにFediverseが衰退して無くなるか。この２つですね。
ついさっき対策しろって言ったばかりなんですけどね、あすかの考えすぎかもしれませんし、ほんまに対策するかは皆さん次第でいいかも。でもFediverseの発展は必ずこういうのと抱合せなので、その意識は広まってもいいと思います。

あと対策って、自分が攻撃者になったつもりでどこを突くか、攻撃する人の気持ちで考えるものです。そんな要領で今あすかが考えてる攻撃方法はいくつかありますけども、今年２月のは前座にすぎないというかまだかわいいものだと考えてます。だってあの人たち、攻撃にお金使ってないですよね。

余談ですが、本家MastodonがAntispamというクラス作りました。１１月２８日時点でこのコードは全く動作しませんが、今後の本家のスパム対策にも注目ですね。コード読んでいる限り、NGワード機能を本家でサポートしようとしているようにも見えます。全く分かりませんけどね。

参考

NGルール、およびスパムについては複数の記事を書いていますので、あわせて参照してください。

ひかえめな引用

kmyblueには引用機能があります。２種類です。引用機能が２種類あるということは、２種類の引用機能があるということでして、「引用」のほかに「ひかえめな引用」というのがあります。

概要

これ簡単に言えば、Fedibirdに「参照」機能ありますよね、それと同じです。

kmyblueにも以前、Fedibirdの同名機能に対応した「参照」という機能がありました。それの名前が「ひかえめな引用」に変わっただけです。Fedibirdの参照とちゃんと連合します。
名前を変えた直接の理由としては、サーバーkmyblueに登録した英語圏のユーザーが「Reference?」と書いてたことでした。機能の名前が「参照」となっていても、見る人はばっと見て何のことなのか分からないかなーと。初見にあまり優しくない名前だと思ったんですよね。

「引用」との違いについて、引用された投稿がタイムラインに流れるか、というのがあります。例えば普通に引用すると、引用された投稿はこうやってタイムラインに流れます。（ただしkmyblueのデフォルト設定では、公開タイムラインに引用は表示されません。この設定はユーザー各自で変更することができます）

対してひかえめな引用では、引用された投稿はタイムラインには流れません。投稿を開くと、返信欄にその投稿が出てきます。

通常の引用と同様、ひかえめな引用を行うことで相手に通知が届きます。タイムライン上の表示以外は、全部引用と同じです。

ただ現状、ひかえめな引用を意識的にやってる人もいるんですけど、あすか自身はそんなに使い所がないかなーと見てます。そりゃあれですよ、引用のほうが見る人にとって使い勝手がいい、自分の投稿をより多くの人に見せられるので。
そもそも見た目が似ているからって公式に引用と同じカテゴリに入れちゃった時点でよくなかったのかなーとか考えてます。

問題点１：Fedibirdと機能の意味が変わっている

まずね、ひかえめな引用って、引用と機能や見た目は似てるんですけど、Activity的に見たら全く別の機能です。なので、これをやってもFedibird、kmyblue以外の実装には届きません。Misskeyもダメです。通知行きません。

ただでさえ実態がそうなっているうえに、kmyblueとFedibirdの間では実装に差異があります。

差異１：リンクが自動で参照にならない
投稿の中に、別の投稿へのリンクを単純に貼るとします。（※参照機能は使いません）
Fedibirdの場合、投稿内にリンクを貼っただけでも参照になります。これはリモートからFedibirdへ来た投稿でも同様で、リモートでFedibirdの投稿へのURLを貼っただけで参照になってFのユーザーへ通知行きます。
kmyblueではそうなりません。リンクの先頭に「BT」とつけて「BT https://～」としないと、参照になりません。
こういう仕様にしたのは、やっぱ参照って通知いくんで気付かない間に相手に通知行かせるのがちょっとプライバシーの関係で心配だったのと、後述する参照の上限がFより厳しかったからってのがあります。

差異２：１つの投稿に含められる参照は５つまで
Fedibirdでは１つの投稿に設定できる参照は１００個までとなっており、事実上無制限です。それに対してkmyblueでは５つまでです。
このように極端に制限を厳しくした理由は、荒らし・スパム対策です。なんかこう、リンク貼っただけで相手に通知いっちゃいますから、それを無差別にやられないようにという趣旨です。
いうてこの攻撃が有効なのはFedibirdとkmyblueのアカウントだけですから、現実的に考えて攻撃するメリットはほとんどないと思いますが、こういう小さいことにもいちいち気を配ってますからうちの対策は厳しいですよと、他に穴がないか調べる前にあきらめてくださいと、そういうのも対策としては大切なんじゃないかと思います。
ただ結果的に、Fではたまに１０以上の投稿を参照する人がいるんですが、そういうのがkmyblueでは正常に認識されません。５つで止まります。

あと、投稿を分析して参照投稿がローカルになければリモートへ取得しに行く処理があるんですが、あれを投稿取得処理と別スレッドにしているのも荒らし・スパム対策の一環です。結果的に参照が参照と認識されない場合があって不安定になってしまっちゃってまして、すでに一度リファクタリングしてますが完全には直らず、今後の課題の一つかなと思ってます。

Fedibirdと違ってこういう差異を入れましたけども、結果としてkmyblueの「ひかえめな引用」は目立たなくなってしまったかなと。
Fedibirdの「参照」機能の意義としてはここで本人が触れておりますけども、

現在、Misskeyで引用機能がどういうふうに使われているかというと、返信代わりなんですよね。引用とは本来、他の投稿を載せたうえで自分の考えを述べる行為。返信のためには設計されてないはずなんです。Misskeyで返信として利用されることが慣習化したことを問題視していたと思います。
それとあれですね、自分の投稿は何を見て書いたか。引用は本来の意味を考えると、文章全体の１割とか２割とかに補足的に入れるコンテンツであって、あくまで主体は投稿者の文章なんです。JASRACの言ってる引用は、ネットの感覚とだいぶ乖離してると思うんですが、あれが本来の引用だと思いますし学術論文でもそうですよね。
でも厳密な運用にも限界があって、例えば、TLにおはぎのさんま漬けの画像が流れてきまして、それを引用して「これ食べたーい」って投稿する時に、それ引用になりますかと。厳密な意味での引用にはならないです。でもブーストだと対象と自分の感想がばらばらになりますし、読者に見やすくといえば引用しかないですよね。
そういう「引用機能の濫用」に対して「参照」を作ったという理解をしています。

対してkmyblueが「（旧）参照」を導入した理由は、特にそんな深い意味はなかったです。時系列から申しますと、実はkmyblueが実装したのって、「（旧）参照」が先なんです。「引用」機能はその時、存在すらしていませんでした。5.x LTS使ったことある人はわかると思いますが、あれ引用無いです。もちろんMisskeyの引用は、kmyblueでは参照に変換されますがちゃんと認識されます。
引用を差し置いて先に参照を作った理由は、Mastodon本家の思想からきてまして、当時（本家は今はv4.4.0で引用作るって言ってるんであくまで当時）、引用って炎上や晒し上げのもとになるから作る予定はない、というメッセージがあったんですね。あと当時はたまたま参照機能を作る直前に検索許可機能（Searchability）を実装してて、その時にいろいろ、こう、いろいろあって本家Mastodonの思想を尊重して開発したいと思ってたタイミングでした。（察して）

それで、他サーバーの引用投稿を見やすくしたいというニーズに対して作ったのが参照機能で、引用ではなく参照を実装した理由として「他人を勝手に晒し上げないため」というのを伝えていました。しかも引用機能について実装の予定はないと当時は言っていたと思います。この時点でFedibirdの「参照」と、そもそもの目的が違います。
そのあとkmyblueは結局正式に引用機能を実装しますが、その時も以下のオプションを追加しました。

これは、他のサーバーの投稿って自分のサーバーとルールが違うので、自分とこにはないような過激な投稿が引用を介してローカルタイムラインに流れる可能性がありますんで、それを抑制しますよと（Misskeyでは日常茶飯事かもしれませんけど、そもそもMastodonではブーストすらLTLに流れないです。LTLに他サーバーの投稿が載る引用はMastodonにとって異質ではないかと）。
アカウント新規作成直後のデフォルト設定では、真ん中の設定のチェックが外れておりまして、自分でチェックしない限りローカルタイムライン（＝自分がフォローしていないアカウントの投稿も流れる場所）の引用は表示されないようにしてます。

引用って相手だけでなく周りの人も不快にさせる可能性があるからと。そういう面で、Activityこそ一緒であるものの、Fedibirdとは趣が全く違います。機能の差異もそこからきています。

問題点２：引用機能との差別化ができていない

前項でkmyblueとFedibirdの「参照」「ひかえめな引用」の違いやkmyblueにおける歴史的経緯やおはぎについて述べましたけども、この差異がkmyblueの「ひかえめな引用」に与えた影響は大きくて、
kmyblueにおいて「引用」と「ひかえめな引用」を使い分ける基準は、「晒し上げにならないか」「周りを不快にさせないか」ただそれだけになってしまったんですね。Fedibirdのような、引用の本来の意味についての考慮がないです。

あすかは個人的に、引用機能に対応していない本家Mastodonの投稿は「ひかえめな引用」、kmyblueやMisskeyなど引用機能に対応している投稿は「引用」を使うことで区別してますが、それも本家Mastodonが引用実装しちゃったら意味なくなるわけで、

そもそも「引用」「参照」って、単数・複数の違いこそあれと、機能としてはそこまで差は大きくないです。どれも他の投稿を関連付けるという点でちょっと分かりづらくなってます。それをFedibirdは意味論的に区別して、kmyblueは配慮の有無で区別したんですけども、配慮ってのはネットユーザーにとってはやらなくてもいいのと一緒ですね。それでkmyblueでは、Fedibirdと互換性を保つ以外に存在感がほとんどなくなったんじゃないかと思います。

現状

というわけでkmyblueの「ひかえめな引用」は存在意義がないんですけども、それでも技術的な理由で必要な機能であり、削除すべきではないと思っています。

理由として、Fedibirdの「参照」と互換させるってのもありますけど、もう１つあります。kmyblueでは引用できない投稿というのが存在しまして、それを参照として結びつけるためです。

引用できない投稿って具体的になにかといいますと、今挙げられるのは２つ。

まずこれは他の実装にも関係することですけど、「非公開投稿を引用した場合」の取り扱いですね。例えば現在、Misskeyでは非公開投稿を引用することはできませんし、リモートからそういう投稿が来ても認識しません。Fedibirdやkmyblueでもできません。でも未知の実装でそういうのが許可されていたら困ると。基本的には未知の投稿に対する対処です。
kmyblueでは非公開投稿を参照することはできますので（ただし閲覧権限が最優先です）、引用がダメでも参照ならOKと柔軟に運用できます。
あと、１つの投稿に複数の引用をつけられるようにしましたとかの実装が出た場合も（FEP-e232の仕様だとできそう）kmyblueはもちろん対応に時間はかかりますけども、それまでは参照機能で我慢してね、ができるわけです。もちろんそんな実装出てくるとは思いませんけど、これを理由に機能作るのと、すでに作っちゃった機能に後から理由をつけるのとでは違いますよね、はい、後者です。

もう１つ、kmyblueにはこういう設定項目があります。

これ、他のサーバーにはない設定ですけども、連合の関係でほぼ意味のない設定項目のひとつですね。これONにしてもkmyblueから引用できなくなるだけで、Misskeyからは引用できますし、通知も来ます（Misskeyがやっていたログインユーザー限定投稿と同じ理屈です）。ただ、連合先と違って自分のサーバーには仲間や趣味の近い人たちがいることが多いというのがkmyblueの開発方針や想定でありまして、せめてその人たちのタイムラインには炎上しても恥を晒さないようにと。
それを考えて消さずに残していますけども、この場合、その人の投稿を引用しようとしたら参照に変換されます。投稿同士がリンクされることに変わりはないことは注意が必要です。
ただしこの設定は、本家Mastodonが引用機能を実装する時の具体的な実装次第では削除する可能性もあります。

あ、そうそう、もう１つ理由がありました。kmyblueでの「引用」「ひかえめな引用」はFと違って、投稿本文内に直接書き込む方式です。

ちなみにこのような仕様にした理由は、これが一番実装が楽だったから。当時（2023年春～初夏）はとにかく機能を作りまくっていた時期で、他にもアンテナ設定画面など雑な実装も多かった（７月漏洩事件を機に頑張って改善した）。でも自分は今でも、引用未対応の実装に配慮したこの仕様が気に入ってます。見栄えが悪いと言われれば悪いかもしれない

「QT」が引用、「BT」がひかえめな引用です。
この仕様に関しては賛否両論あるかもしれませんけど、とりあえず、この仕様だと１つの投稿に引用（QT）を複数含めることもできてしまうわけです（他サーバーに送るActivityではちゃんと１つになってるので安心して）。
そんなときに２つ目以降のQTをどうするかというと、「ひかえめな引用」になります。通常の引用より少し見にくくなりますけど、やっぱり投稿者が引用しようと思ったものが見られるのはメリットとして大きいと思います。

これらの事情があってkmyblueでは「ひかえめな引用」は技術的に必要ということで、今後も残していく予定です。あと、現状kmyblueでは、全く別の機能として扱われるFedibirdと違って、内部的に「引用」は「ひかえめな引用」の下位集合として結びつけてまして、それも残す理由です。

購読許可

ここから先の４つは、ほんまもんの黒歴史になります。深淵です。触れてはいけないやつですのでよろしくお願いします。
さっきの「ひかえめな引用」の項目で引用許可という設定を出しましたけども、あれは少しでも意味があるからいいんです。ではこっちはどうなのかと。

結論からいうと、この機能はすでに一部を除き廃止済です。この記事に掲載の７つのうち、解決に持ち込めた唯一の例です。まだコードは残っているのでメンテナンスの必要はありますけども。

概要

サーバーkmyblueは2023年2月11日に立ち上げましたけども、当時からFedibirdの購読機能は気になってました。特にアカウント購読ですね、あれ、仮に自分が炎上した時、自分が他のサーバーからこうやって監視されるわけですよ。ブラウザのブックマークならいいんですけど、FedibirdやMisskeyで公式に実装されている機能を用いて見られるのもちょっと心地が悪いなと。誰に見られているのがわからないと。はじめに抱いた印象はこれでした。

もう１つの理由として、どこのサーバーも固有の事情があると思うんですけど、うちのサーバーでは女性作家さんが多いんです。ということはカップリングがある。地雷っていうのがある。そこはね、ちょっとデリケートな言い方になるんですけど、男よりも敏感ですね、あんま見せてはいけないっていう意味合いが強いです。
そういったところが逆カプの人に捕捉されたりすると、Twitterのトレンドに載らないレベルの小さい炎上が至るところで起きるわけですね。男の間では笑い話になることもあるんですけどね。
BL専用のサーバーやSNSもあるくらいですし、わざわざ連合切ってる（Fedibirdとか特定のサーバーとしか繋がれない）サーバーもある。そんな状況下で、自分の意図しない相手のキーワード購読に自分の投稿を追加しない機能って需要があると思ったんです。

そんなこんなで作ったのがこの設定です。

この設定は、アンテナ機能に影響します。例えばAが「フォロワーにのみ許可」していた場合、AのフォロワーのアンテナにAの投稿が流れます。フォロワーでない人のアンテナには流れませんが、誰かがブーストするとホームに流れたりします。

この設定は連合しますので、kmyblueフォークではこの設定が解釈されてアンテナタイムラインへの追加が適切に制限されます（現在は設定項目を廃止していますが、引き続きリモートアカウントの設定は動作します）。

問題点１：対応サーバーの数が非常に少ない場合、メリットがほぼない

先程挙げた「引用許可」あれも対応するサーバーが大変少ないんですけども、ローカルのユーザーに見せないという一応の目的があるのでいいんです。あれは一回炎上してしまった後の対応を想定に入れてますので。
で、この「購読許可」は何かと言うと、大まかには自分が炎上しにくくするための機能ですね。一回炎上したらもう意味ないじゃないですか。

で、この「購読許可」機能に対応しているサーバーはというと、kmyblueフォークを使っているところだけです。２０いくかどうか。全体で見るとかなり少ないです。

この時点で、炎上を防止するという本来の役目は果たせません。機能そのものの意味がほとんどないです。

問題点２：今後対応実装が増える見込みがない

みなさん、無料サービスが有料化するときに、それまで使えていた機能が使えなくなるのは困るって思いますよね。サーバーも同じで、これまで当たり前のように使われていた機能が有料になるのは時として議論を巻き起こすものです。にじみすとかがその一例になってますね。肯定的な声のほうが多くても、開発者はサイレントマジョリティの存在を認識してやってくのが大事だと思います。

今回の機能に関しても考え方は同じで、他の実装にとってこの購読許可に対応するということは、今まであることをできないようにする、わざと不便にするということになります。それでもFedibirdさんはやってくれましたけど。悪いことをしたかなと思ってます。

で、Misskeyのほうは、この購読許可以前に、Mastodonのindexableにも対応してないんですよ。（今はなき）Firefishさんがイケメンなのですっかり忘れてますけども、Misskeyってそういうことには根本から興味がないという。要はFさんが神というだけで、この設定に対応した実装が今後増える見込みはなく、問題点１の解消も見込めないと考えました。

削除した理由

必要性がない、それだけですぐ削除するのも安直でして、これまでこの機能を使っていた人にまず説明する必要があります。この機能はもう意味がないので消しますと。それをお知らせアカウントでやってアンケートもとりました。反対意見がほぼなかったので削除しました。

この削除、他の６つの機能と比べると早い対応になりましたけども、理由として、

・利用者に勘違いさせないようにするため：こういう設定はありがたい人もいるだけに、「無意味です」とはっきり言っても特に新規さんには伝わらない可能性もありまして、そもそも設定項目自体を無くせばそういう勘違いもなくせると思いました。ActivityPubの連合って、Twitterばかりやってきた人にとっては複雑ですからね。
他にも同様の問題を抱えた機能はありますけど、この購読許可の削除を急いだのは、特にプライバシーに関わる箇所だったからです。

フレンドサーバー

kmyblueにおけるローカルの扱い

フレンドサーバーについて説明する前に、まずkmyblueの独自機能である「ローカル公開」「ローカルとフォロワー」について説明しなければいけません。

kmyblueでは開発の重要なコンセプトとして、小規模なコミュニティが使うことを想定しています。そういうコミュニティって動もすれば先鋭化しがちで、他から見ても理解されにくいというか、うわこいつらこわかかわらんどこってなっちゃうわけで。
それを、完全には無理ですけどゆるやかに隠して外側から見えにくくしようっていう意図で作ったのが「ローカル公開」と「ローカルとフォロワー」です。
ローカルユーザーからは探しやすく、リモートユーザーからは探しづらい、というところは共通しています。
（※ただし内輪ノリを本気で隠したい人には向いてません。そういう人は本家Mastodonにもある連合制限モードを使ってください）

「ローカル公開」は公開範囲の１つです。一部の人は「ローカル限定」と書いてしまってますけど、あれとは全く違います。名前が似てるだけの別物です。
ローカル公開は、投稿者のサーバーのローカルタイムラインに流れます。ですが他のサーバーでは非収載として扱われます。

「ローカルとフォロワー」は検索許可（Searchability）の１つです。これが設定された投稿は、kmyblueにおいては、そのサーバーにいる全てのアカウント、リモートサーバーの場合はフォロワーのみが検索できます。

Mastodonでは公開投稿と非収載投稿についてはっきりした区別がありまして、まずindexable対応サーバー（主にMastodon）では非収載投稿は検索にかかりません。
kmyblueにおいては事情はもっと複雑で、検索許可（Searchability）との併用で、検索許可が「誰でも」「ローカルとフォロワー」のいずれかでないと検索にかかりません。アンテナに至っては、先述の２条件に加えてアンテナの絞り込み条件「キーワード」「タグ」に引っかからないと流れません（検索ではできるのにアンテナではできないのは不便すぎるという経緯で追加したため、例えばアカウント購読で非収載投稿を流すのは検索機能の範囲を超えてしまうので）

多分ここらへん複雑すぎて日常的にkmyblueを使ってないと理解以前に理解のための土台ができないくらいの話なんじゃないかと思いますが、今回はもうみなさん分かってるものとして話を進めます。
とにかくMastodonにおいて非収載投稿は、単に公開タイムラインに流れない以外にも制約がたくさんありますよということ。Misskeyでは公開タイムラインに流れない以外は大抵一緒なんですから、Mastodonとは根本的に文化が違うと思います。

この検索許可の設定はFedibirdから輸入したものですが、当のFでは以下の３つの設定しかありません。

余談：kmyblueにおける「自分のみ」検索許可はFどころか本家Mastodonの挙動よりも厳しく、連合先のMastodonで普通に検索できたりします。「購読許可」と同じ理由でこの記事の項目の１つに数えてもいいくらいなのですが、あれには「他に全く検索できない投稿の存在する実装があり、そのプライバシーを尊重する」とかとか様々な使い道があるので必要です

それで、「ローカル公開」と「ローカルとフォロワー」をどうやって実装しているかというと、REST APIでは「ローカル公開」という情報を出しておいて、他のサーバーに送るActivityでは「非収載」として出します。つまり他のサーバーは、kmyblueを含め、投稿がまごうことなき非収載として扱います。普通の非収載投稿と区別できないというか、区別できないようにkmyblueがデータを出しますので区別することができないんです。

ローカル公開の問題点

この機能を実装した理由繰り返しますけども、kmyblueの設計思想も大きく関わってます。kmyblueって同人サーバーから始まってるんです。「尖った趣味を持った小さい集団が気兼ねなく活動できるように」という、小規模コミュニティ向けであるという方針を、フォーク整備する前から現在までずっと貫いています。そのために、内輪ノリを外に出さない、外から見えにくい実装というのを目指しました。

このローカル公開にはいろいろ問題がありまして、今もっとも大きいのが、Misskeyでは非収載投稿を自由に検索できちゃうという話。これに関してはこういう設定項目を追加することで一応は対応。

次が、公開投稿じゃないとBlueSkyやThreadsやおはぎに載せられないという話。これはもうあちらのSNSでは公開範囲という概念ありませんから、全部が公開投稿として扱われますから、SNSをまたぐ以前に、むしろあちらがプライバシーを守るための最低限のことをやってくれていると思って諦めていただく。

それからもう１つ、「非収載」という公開範囲は、公開タイムラインに載らないだけで、やろうと思えば拡散されちゃいます。多くの人の目に触れてしまいます。「ローカル公開」も他のサーバーでは非収載になりますけども、この問題を継承していることに変わりありません。
うちのサーバーではぽんぽんローカル公開使う人も多いんですけども、リーチする機会が少ないってだけで一度火が着いたら拡散されるってのを承知したリテラシーが必要になります。

ということで対応はしましたけども、もう１つ大きな問題が残っていました。

同じ趣味嗜好を持つサーバーが複数できた時の対応です。

そんなことある？と思う人いるかもしれませんが、よくあります。めちゃくちゃあります。例えばおはぎの上側を愛でるサーバーとおはぎの下側を愛でるサーバーは同じですよ。ひっくり返せば同じですから（おはぎ上側過激派に叱られそうな発言ではありますが）。実際は細かい違いはありますけど、もう同じで構わないんじゃないのってところがたくさん。

kmyblueの「ローカル公開」って、内輪でしか正しく通じないセンシティブな話題を外から見えにくくする機能ですけども、自分と同じ趣味嗜好を持ったサーバーになら見つかってもいい。でも「公開」投稿にすると意図しないサーバーに見つかってしまう。この場合の適切な対応がなかったんです。

さっきも言った通りkmyblueって小規模コミュニティを重視していることの他に、ローカル限定を実装することによる一極集中を避けている面もありまして、ローカル公開がリーチされにくくなることも一極集中にゆるやかに関与していくんじゃないかと。

フレンドサーバー機能はまさしく、そのために作った機能です。自分が指名した特定のサーバーにのみ、ローカル公開投稿をローカル公開として認識してもらいます。フレンドとなったサーバーは、その投稿を自由に検索・購読できます。なんなら誰でも検索可能な投稿（公開範囲「公開」「ローカル公開」また一部の「非収載」）を全部流すっていう、リレーサーバーの劣化版のような設定もできます。

では、そんなフレンドサーバーがどうして微妙な機能になっているか。ここまで読んだみなさんなら予想できると思います。

問題点１：他にフレンドサーバーに対応している実装がない

もしkmyblue以外の実装がフレンドサーバー機能に対応するとしたら、その前にまず「ローカル公開」機能を作らなければいけません。リレーサーバーの劣化版のような機能はあくまでおまけですね、ローカル公開がないなら本物のリレーサーバー使ってもらったほうが早いですし。

で、他の実装が「ローカル公開」に対応するか以前に、他の技術者（特に外国人）がkmyblueを紹介する時に「ローカル限定」と混合している書き込みを多く見かけるので、需要がない以前の問題として機能自体が意味不明にうつっているんじゃないかなと思います。

そんな現状ですから、kmyblue以外で「ローカル公開」を実装しているものはひとつも確認できていません。よってフレンドサーバー機能が他の実装でも作られる可能性はゼロです。

一応フレンドサーバーによって複数のサーバーを繋げる方法って、リレーサーバーの応用でして、特にkmyblueやMastodonやおはぎじゃなくても実装自体はできます。ここ見て頑張ってください。Activityに「フレンドサーバー」という言葉を使ってないですしActivity自体はリレーサーバーに送るやつと全く一緒なので、もしかしたら他のソフトウェアの全く別の機能が引っかかる可能性はあります。

問題点２：利点が検索と購読だけ

フレンドサーバーになったところで、タイムラインが劇的に変わるわけではありません。連合タイムラインの量はちょっと増えるかもしれませんけど、登録者１０００人超えたサーバーの連合タイムラインなんておはぎですから。おはぎになりますから。
というわけで、利用者が恩恵を受けられるのは検索と購読だけです。基本的に、検索と購読って連合タイムラインに目をつぶれば目に見えませんから。自分で実際に検索・設定しないと効果が実感できない。そういうのが地味なんじゃないかと思ってます。
それでも、例えば大きいサーバーが分裂した時に分裂先の小さいサーバーにとってはとても助かるかもしれませんけど（ちなみにこれはフレンドサーバーのユースケースの１つです）。

もちろん、フレンドサーバーの投稿だけが流れるフレンドタイムラインというのを考えたことはあります。でも、大きく２つの問題があって作らないことにしました。

・フレンドサーバー同士でモデレーションの基準が違う場合の扱いでトラブルになりそう

・フレンドタイムライン作るなら当然、特定のサーバーをフレンドタイムラインに入れない設定というのも作ることになるけども、そうすると空リプが通じない、自分には見えているものが相手には見えない、何のためのフレンドなのか、ということになる（サーバー同士の関係が無駄に複雑になる）

もしフレンドタイムラインを作っていれば、ローカル公開ではなくこっち目的での機能利用もありだと思ったんですが、あれはリレーサーバーと比べるとどうしてもおまけです。やっぱりリレーサーバー使ってもらうほうが圧倒的に効率がいいです。

現状

ちょっと何言ってんのこいつになるかもしれませんけど、このフレンドサーバーという機能、需要が全く無いことを最初から分かったうえで作ってました。
作った意図としては、言い訳です。はい。言い訳のためだけに作りました。将来ローカル公開についてここを突っ込まれた時に説明するためだけに作りました。ローカル公開で連合がゆるやかに不便になる件はこれで勘弁してくださいと。うちは連合を重視してると言ってますけどこれをこうしてるから矛盾してませんよと。ポーズです。今になったから言えますけど、言い訳以外の理由はないです。
それでもフレンドサーバーは、kmyblueフォークがこれから発展していった時にいつか誰かが興味を持つんじゃないかと思ってます。なので今でもたまにフレンドサーバーの動作確認をしています。最近ではバージョン15 LTSをリリースする直前に軽く確認したり。

もちろん誰にも使われずkmyblueとともに消えていく可能性のほうが圧倒的に高い機能だとは思ってますけど。

というわけで今後この機能を削除する予定はないですが、本家がもしプログラミング言語をRubyからCOBOLに変更するとかそういうレベルの改変を加えた時にこっそり削除する可能性はあります。

フレンドサーバーについて実装当時の記事はここにあります。

Markdown

はい、このMarkdownもわりと使用頻度の高い機能です。
実は本家Mastodonでは、Markdown投稿ができないんです。リモートのサーバーで太字とか斜体とかおはぎとかあればきちんとそれを反映しますけど、自分のサーバーから投稿することはできません。
MarkdownがあるからFではなくkmyblueを選びましたって人も過去にいました。なんならkmyblueの公式アカウントでも毎回のようにばんばん使っています。
この記事でいうとNGルールと同じチームですね。有用なのになぜか微妙になってる。

問題点１：「_」という文字の使用頻度が高すぎる

その最大の難点が、「_」という文字です。これ、Markdownでは「_」で囲った部分に下線を引きます。お知らせアカウントでも毎回使ってます。ちなみにMisskeyはこの文字に対応してないですが、その選択は正しいと思います。

なぜなら「_」は普通にアカウントのIDに使われます。プログラミングでもスネークケースで頻用します。Mastodon自体のコードでもスネークケースが多いのでけっこう使います。ハッシュタグでも使います。それらが全部下線として認識されてしまいます。おいたわしや。

例えば以下の投稿が

@ohagi_ga_aruku もぅﾏﾁﾞ無理。initial_stateのプロパティがundefinedだって。せっかくaccount.featured_tagsを設定したのにｩﾁのことゎもぅどぉでもぃぃんだって。どぉせｩﾁゎ遊ばれてたってｺﾄ。今手首切った。

実際はこう表示されてしまいます。（Noteでは下線はないので取り消し線で代用）

@ohagigaaruku もぅﾏﾁﾞ無理。initial~~stateのプロパティがundefinedだって。せっかくaccount.featured~~tagsを設定したのにｩﾁのことゎもぅどぉでもぃぃんだって。どぉせｩﾁゎ遊ばれてたってｺﾄ。今手首切った。

下線になるだけでなく「_」も消えてしまいますね。これではちょっと意味が分かりませんし、人によっては誤読してしまいます。
今どきアカウントIDに「_」を使ってる人はたくさんいますから、これを避けろっていうのは無理に等しい。kmyblueが最初にMarkdownを実装する時に避けるべきルールであったと思います。

一応エスケープは可能です。Markdownの実装にRedcarpetというライブラリを使ってますから、それが対応してる「\」を使って「\_」とすることで、下線として使わず文字として表示することは可能です。
でも、運の悪いことに、投稿本文内に記載されたメンションを抽出する処理が、投稿本文のMarkdownをHTMLに変換する処理よりも先なんです。つまり、エスケープをすると見た目上は正しく見えても、きちんとアカウント名として認識されなくなります。
エスケープしてもしなくてもダメってｺﾄ。

問題点２：引用「>」の対応がトリッキー

kmyblueで投稿本文をどうやってHTMLに変換しているかというと、

という順番になってますけども、ここで最初にMarkdown処理しちゃうと、MarkdownによってできたHTMLがサニタイズされるためこちゃこちゃした表示になります。太字になったりしないです。
なので、サニタイズしたあとの本文に対してMarkdown処理してるわけです。

ここまではいいですね。
Markdownで、引用をあらわす記号があって、この記号が行頭にあったら引用として見れるようにしなさいってのがありまして

> ここが
> 引用に
> なります

これが、4.4.0 alpha.1のMastodonでは

というふうに表示されます。（v4.3.xでは別の表示になると思う）

で、「>」ってHTMLタグをあらわす文字です。当然、サニタイズ対象です。サニタイズしちゃうと「>」になってしまって、それはもうMarkdownの引用として使えません。つまりこのままではkmyblueのMarkdownで引用ができないことになります。

でも引用はやりたいです。著作権の範囲を示すものですから、できればやりたいです。困りましたねってなったときに2023年5月のあすかが出した解決策がこれで

「>」について、行頭にあるものに限って「>」に戻しちゃえ、と。
もちろんサニタイズしたものを一部とはいえ元に戻すわけで、例えば以下の攻撃ができるかもしれないんです。（これもHTMLの記法として成立しますし、HTML内の改行がブラウザでスペースとして表示される問題の対策として実際にやってるサイトもあるらしいです）

<img src="evil.png"
>投稿本文

もちろんこれに関しては当時何度も動作確認したうえで、Markdown処理をすれば引用に変換されちゃうので無害だし、「<」をサニタイズしない以上問題はないという結論にはなってます。
ただこれもやっぱり、現状で問題はないとはいえ、今後本家Mastodonがなんか仕様変更した時にインシデントになりかねない不安はありますし、出力されるHTMLもこう見栄えが悪いと思ってます。

そういうわけで、こちらで散々確認はしてますけども、引用の実装これでいいのかっていう不安が１年越した今でもまだあります。

現状

現在、投稿のMarkdownのON・OFFを切り替えられるようになっています（デフォルトではOFF）。編集でも切り替え可能です。以前は切り替え不可で全部強制的にMarkdown有効でしたから、それだけでも大きな改善になってるかと思います。

「_」ルールの削除は簡単ですが、現在予定は決めていません。というのも、お知らせアカウントでめちゃくちゃ使ってしまってますから。

kmyblueでMarkdownをどのタイミングで適用しているかというと、投稿したときではないです。投稿をREST APIを通してWebに表示する時、投稿テキストをもとにHTMLを生成するんですが、その時にMarkdownの処理をやります。このタイミングでMarkdown処理をやるとどうなるか。Markdownのルールを変更したときに、過去投稿にも遡及して適用されます。

つまり、過去の投稿が全部崩れて見えちゃうってｺﾄ。現在下線を積極的に使ってるのってお知らせアカウントくらいなんですが、消すタイミングをちょっと迷っているところです。

ちなみにリモートサーバーから来た投稿はHTMLをそのままキャッシュとして保持してますので、その投稿がキャッシュされている限り他のサーバーから見たときの表示は変わりません。

ただ、「_」についてはいずれ削除すべきものかなーと思ってます。

「>」についてはできれば消したくないとは思ってますけども、使用頻度も少ないようですし気が向いたらやるかもしれないです。

拡張ドメインブロック

これは機能削除には至らなかったものの改善した機能です。改善できたのは、あすか以外にこの機能を使っている人がいないと見込まれたことがとても大きいです。

概要

そもそも拡張ドメインブロックとは何かということですけど、kmyblueではドメインブロックの項目を拡張しています。以下の設定がドメインごとにできます。
本家では「メディアファイルを拒否する」「通報を拒否する」のみでしたから、それがかなり細かく設定できるようになってます。

これを実装した動機として、とあるサーバーから迷惑行為がここまで来た時、本家Mastodonでとれる対策としては「制限」しかありませんでした。でも制限すると公開投稿が連合タイムラインに流れなくなる、非収載扱いになるので検索もできなくなる、アカウントのプロフィールを開いた時に「表示しますか？」と出てくる、フォローが強制的にフォローリクエストになるなど、いっぺんに制限されるものがちょっと多すぎます。
なので、もうちょっと軽く制限できないものかと。

一見、制限機能の拡張に見えちゃうのですが、要は、とあるサーバーとの連合をできる限り切らなくてもいいように、邪魔な部分を取り除いて連合だけは続けられるように、というのを目標として作った機能です。
本家の「メディアファイルを拒否する」も大体同じようなものですね。

問題点１：ドメイン単位での指定である／項目数が多い

この拡張ドメインブロックの項目をエクスポート・インポートできるようになったのは今年に入ってからでして、それでずいぶんまじになったのですが、それでもこの問題は一番大きいかなと思っています。

ドメインブロックの項目がドメイン単位で指定できることのどこが問題かといいますと、対象となるドメインがたくさんあったときにいちいち設定できるのかと。事情が変わった時にそれぞれのサーバーの設定をきっちり正確に変更できるかと。細かいチューイングって事実上無理だと思ったんです。

複数のドメインをグループ化してまとめて設定できるようにしたいとも思ってますがまだ実現できておらず。UIを作るのがちょっと大変そうな気がしますが、頑張れば作れそうではあります。（Issue）←今見たら👍️が２つついてた

問題点２：後発の機能（NGワード、NGルール）で代替可能

この拡張ドメインブロックって機能としてはけっこう初期のもので、最初のアプローチがフォークとして整備するよりも前の２０２３年４月２８日。サーバーを立ち上げたのが２０２３年２月１１日ですから、その２ヶ月後です。

ただ、ドメインブロックはサーバー１つに対して指定するものですけども、「分散型スパム（サーバーを縦断するスパム）」を想定した対策（例：NGワード、NGルール）を始めたのってそれよりも後なんです。そこでできることも、拡張ドメインブロックとかぶってるところが多い。
で、今のkmyblueって、「１つのサーバーに対する制限」と「連合全体に対する制限」両方が設定できるわけですけど、どっちが便利かって言ったら、スパムに関しては圧倒的に後者ですね。攻撃者は常に同じサーバーから来るわけではないし、むしろそれは攻撃者にとっては避けるべき事柄です。

そんなわけで、分散型スパムに対して拡張ドメインブロックは意味がないと思います。
実装当初はスパムもmastodon.socialにばかり集まっていたので、mastodon.socialだけを制限していれば十分だったのですが、昨今の事情を考えるとそうではないと。

改善と現状

この機能、以前はもっと設定項目があったのですが、不要なものは減らしています。

このIssueの中で「リプライを拒否する」を残すとありますが、これものちに削除しています（Issue）。

ただ、スパムに関して拡張ドメインブロックがほぼ無意味という考えはありますし、NGワード・NGルールとの重複という観点で考えれば、もうちょっと消しても良さそうな項目はいくつかあります。
これについてはおいおい（忘れてなければ）対応したいなーと思ってます。

まとめ

去年２０２３年の春頃に、Misskeyのチャット機能（だっけ？）を削除するって話で物議になったこと覚えてますか。７月２日よりも前だったんで知らない人も多いと思います。チャット機能は人気の高い機能だったんですけど、あれダイレクトメッセージ機能とかぶるからって、そのまま消されちゃいました。

その様子見てて、一度作った機能を削除するのは難しいと、どこかに需要が残ってるかもしれないと。機能の削除に慎重になったのはこれが一番の原因です。

ここに挙げた機能の中には、技術的に必要、kmyblueのシステムに深く関わっているという理由で残しているものもいくつかあります。ひかえめな引用がそれですね。
でも基本的な考え方として、一度作ったものをむやみに消しちゃうと、他の機能もこれいつまで使えるのかわからないってことになっちゃう。それがどんなに人気のある機能だとしても例外なくそういう目で見られることもあります。ですから、機能を削除するかどうか以前に、機能を作る前にしっかり考えましょうと。それがうちの方針です。

思い返してみれば今回挙げた７つの機能のうち、NGルールとフレンドサーバーを除く５つが全部、kmyblueをフォークとして整備する前の初期に作った機能ですね。kmyblueを整備する時に取捨選択はしたつもりでしたが捨てきれてなかったという感じ。
あとの２つは「有能だけど使い方を説明したくない」「最初からいらないと分かっていて作ったから消したくない」という固有の事情を抱えていますのでもっと面倒ですけど。

こうして考えると、機能を作る前にその機能が本当に必要なのか考える技術が少しずつ育っているというか、開発初期のいろいろ試してみてる時期の機能をそのまま残したから失敗も残ってるというか。
いずれにせよ過去の遺物はどこかで思い切って整理する必要はあると思います。

みなさんもMastodonやMisskeyをフォークしたり、新たに独自の実装を作る際には、機能の取捨選択をする技術を身に着けてほしいかなーと思います。ついでに消したいものを思い切って消せるメンタルも、時には必要だと思います。おはぎ。