@deluxe_tokyo 似たような機能ですが、

引用は、他の引用をサポートしたサーバと互換性があり、いくつかの引用を取り入れたMastodonサーバの他、すべてのMisskeyサーバで引用として期待した表示がされます。

互換性のないサーバでは、QT: [ 〜 ] という形で投稿のURLが表示されます。

参照は、いまのところFedibird系固有の機能です。投稿の詳細を開いた際に、返信のツリーに参照のツリーが合成されて表示されます。また参照のみを表示するタブもあります。

互換性のないサーバでは、[参照] というリンクを辿ることで、参照した投稿を一覧できます。

引用は、投稿の表示の中に引用した投稿を埋め込んだ形で表示します。対象にできる投稿は一つだけです。

主に、対象の投稿を見てもらうことが重要な場合に用います。

参照は、投稿の表示の中に参照した投稿を表示しません。必要な場合に、[参照]リンクや、投稿をクリックした詳細表示からみてもらう形になります。

主に、自分の言葉を主体とした投稿で、文脈を明示するために用います。

複数の投稿を対象に、一連の流れを指し示して言及することができます。

また、投稿のまとめ機能としても使えます。
#fedibird #fedibird_info

まず、Mastodonのおさらい

リプライ（返信）は、ローカルタイムラインや連合タイムラインに表示されません。

ホームタイムラインでは、リプライ対象とリプライの、両方の投稿主（ユーザー）をフォローしている場合にだけ表示されます。

片方のユーザーだけをフォローしていても、もう片方のユーザーをフォローしていない場合、無関係の他人との会話ということで隠されるようになっています。

投稿の詳細や、アカウントの『投稿と返信』まで自ら見に行けば、リプライをみることができます。

リプライされると通知されますが、これはメンション（@ のついたID）によるもので、これを削除して通知を抑制してもリプライとして機能します。

また、セルフリプライを特別扱いします。

セルフリプライは、自分自身の投稿にリプライする、連続した投稿のことです。

セルフリプライは、

・最初からメンション（@ のついたID）を含みません

・ローカルタイムラインと連合タイムラインに表示されます

・リプライの側に『スレッドを表示』というリンクが表示されます

・ホームタイムラインで隠されません（これはまあ当然だけど）

リプライ投稿は、どの投稿に対するリプライなのかという情報を持っています。このへんは基本的にメールと同じです。（InReplyTo）

Mastodonは、この情報を元にして、リプライツリー・スレッドを生成し、投稿の詳細で一覧してくれます。

対象の投稿が存在しなくなる（消されるなど）と、リプライではなくなります。

スレッドの途中の投稿が消えると、つながりがなくなってしまい、スレッドは分断します。

メンションがあるとその相手に通知されますが、メンションを消してしまえば通知しないでリプライできます。

Mastodonは、投稿についているセルフリプライを最大5つ、投稿をリモートサーバに配送する際に情報としてインラインで持たせていて、ブーストされた際などにセルフリプライがまとめて伝わるよう細工がされています。

その他のリプライの情報も取れるようになっていますが、追加のfetchが必要です。

現在の実装では、先のセルフリプライに加えて、直接の公開・未収載のリプライを最大60件取得するようになっているようです。

また、親投稿がサーバキャッシュになかった場合、親投稿をfetchします。

ローカルにある投稿にリプライがついた場合、それが署名付きの公開・未収載であれば、リプライ対象の投稿をしたユーザーのフォロワーに転送します。

一般に、リレーだけが署名付き投稿を転送すると思われていますが、このMastodon本体によるリプライの転送も頻繁に発生しています。

メンションは、相手に通知する仕組みですが、そのためには相手のサーバに投稿が届かなければいけないので、リプライを投稿したサーバから、相手のサーバに配送が行われます。

通常の投稿は、基本的にフォロワーに対して配送されますが、リプライの場合、以上のような条件により追加で投稿が配送される仕組みがあります。

Mastodonの投稿編集機能について考慮すべきことについて、過去に書いたもの、もう一度あげとくね。

投稿編集は便利ですが、欠点もあるのです。

クライアントアプリで実装する際にも、できれば、編集と、削除して下書きに戻す、の両方の機能を生かしておいて欲しいのです。

あらためて周知。 [参照]

投稿を編集する機能は、これまで不変であることを前提としてきた投稿を更新できるようにする破壊的な機能です。

Mastodon v3.5で内部的な機能の整備を行い、v4.0で実際にユーザーが編集できるように解放されました。

これは、編集に対応したサーバでないと、編集した内容やその経緯が認識されないため、v3.5時点で導入して、対応サーバを増やしておく必要があったからです。

それでも、まだまだ多数あるMastodon v3.4以前のサーバは未対応のままですし、Mastodon以外のFediverseサーバでは、まだこの機能に対応していないし、今後対応するかどうかも任意（Mastodonの独自機能を無視したっていい）なので、必ず反映されるとは限らないものであることを覚えておいてください。

そして副作用です。

内容の意味が変わらない、ちょっとした誤字の訂正やハッシュタグや補足の追加ぐらいであればいいのですが、

文意の異なる内容に変更されることもありますし、突然過激な主張や宣伝、スパムに化けることもあります。

お気に入り・ブーストされやすい内容で拡散させておき、差し替える手法です。

もちろん、Mastodon v3.5以降の編集に対応したバージョンでは様々な配慮がされており、編集履歴を確認できるし、ブーストした人に投稿が編集されたことを通知することも行われます。

悪質な編集を行うアカウントはブロックしたり通報して運営レベルで排除してもいいですし、ブーストした人も取り消すことができますが、

多くのユーザーを巻き込んで対処しなければいけないやっかいな機能でもあります。

そして、未対応のバージョンであるMastodon v3.4以前および他のFediverseサーバでは、

そういった悪質な投稿をブーストした人はそれを拡散した状態のままになります。

お気に入りしたり絵文字リアクションで好意的な反応をしたことも取り下げられません。

おっと、自分が会話に参加したリプライツリーのことも忘れてましたね。

従来のWebサイトやブログでも編集可能という意味ではまったく同一なのですが、SNSだからこそ起こる拡散や評価の問題が重いのです。

まあ道具ですので、上手に使っていけば大丈夫です。悪質な利用を封じ込め、良い面をうまく活用していきましょう（すごい便利だしね！）

なお、従来からある『削除して下書きに戻す』は、こうした問題とは無縁の機能です。

すこし時間の経ったものを削除してしまうと、ブーストしてもらったりお気に入りしてくれた人に申し訳ないと思うことはあるかと思いますが、

まあ削除せず訂正を返信でぶら下げるとか、そこは犠牲にして訂正するとか、判断すればいいわけです。

実は、今回の投稿編集機能の実装にあたって、この『削除して下書きに戻す』機能は削除されました。

これについて、絶対に残すべきである、メニューがややこしくなるなら、編集のUIを工夫してでもどちらか選べるようにすべきである、と私も反対を主張しましたし、同意見もかなりあったのではないかと思います。

リリースでは無事にメニュー内に残されることとなり、使い分けできるようになったという次第です。

どちらの機能も上手に使い分けていただければ幸いです。