それから、FediverseはMastodon以外の様々なタイプのサーバがあり、DMに相当するものをどう扱うかは未知数です。

Pleroma、Misskeyなどよく知られたサーバであれば期待通り扱ってくれることが期待できますが、

最悪の場合、管理者が任意に閲覧できるサーバであることも、誰でもみられる状態で受け取るサーバも考えられます。

先に悪い改造と申しましたが、見えるように改造されていた場合は、これを防げません。

従って、宛先に指定するサーバが信頼できるかどうかも考えなくてはなりません。

よく知った相手のサーバは多分大丈夫だろう、ぐらいの判断は可能かと思いますが、まぁ知らないサーバのことは判断できませんよね。

またこれは別の問題ですが、添付したデータ（画像や動画）はURLが漏洩すると誰でも参照できます。

また、オブジェクトストレージに保管していることが多いため、AWSだったりWasabiだったりに監視されることもあります。

また、添付データ（画像や動画）をモデレーション対象とするサーバもあります。

というわけで、

まあ最悪漏れてもいい内容までにしておきましょう。

DMの内容が当事者以外にみえるケースですが、

まず、そのDMの発信元か配送先であることが必要です。

DMを送信した人のサーバと、宛先に指定した人のサーバ（複数）のデータベースに内容が記録されます。

無関係のサーバからはみえません。

それから、DMの当事者の誰かがこれを通報した場合、通報の宛先となったサーバの管理者およびモデレーターがこれを確認できるようになります。

（悪い改造がされていなければ）管理者やモデレーターはMastodonの操作を通じてDMをみることはできません。

ただし、データベースに直接アクセスできる人は、DMの内容を取り出して見ることができます。

これは主に管理者が該当しますが、技術担当が別にいる場合や、ホスティングで委任している場合もありますので、ケースバイケースです。

このほか、警察や軍など司法・国家機構からデータベースを明け渡すよう求められたり、クラッキングによりデータを盗まれるケースもあります。

こうした場合に、サーバ上に鍵が存在しない方法で暗号化されていれば内容は読めないのですが、平文で保存されておりそのまま読める状態になっています。

Mastodonは基本的に所属サーバだけを信頼してもらうモデルで、クライアントは所属サーバとだけ通信して、リモートの情報もすべて所属サーバから取得する。

Mastodon本体は基本的にそういう設計で作られているけど、

たとえば管理者がGoogleのアクセス解析をつけていたり、広告を挟んだりすれば、あまり意味を成さなくなります。

ユーザー側で、リアルタイム翻訳使ってみたりね。

あと、クライアントアプリにはリモートのURI / URLが渡されているので、それを使って直接取得しにいくことができ、この場合も所属サーバに閉じ込めたモデルにはならなくなる。

クライアントアプリは、所属サーバへのAPIアクセス以外に、任意にリクエストが可能なので、追加機能を提供することができる。翻訳もそうだし、外部検索サイトに対応したり。

広告がついてたり、自サーバを経由して何かするタイプは、もうほとんど全面委任するしかないです。

鍵を預けて全部まかせるエージェントになるので、何をしているか明示していて、妥当な方法をとっている、できればソース公開のものを選ぶと良いです。