のえる :cava_red: DTP鯖管
リレーのPleroma対応、現在の結論としては、PleromaにLinked data Signatures(LDS)のサポートを追加するのが最善という判断です。
--
PleromaのActivityには、LDSによる署名が含まれておらず、リレーから送信されてきたActivityが信頼出来るかどうか判断できません。
そのため、リレーから送信するところまでは動作するのですが、受け取ったサーバが拒否します。
通常の連合では、HTTP Signaturesによって、送信元、送信先、日時、送信内容（Activity）のハッシュを署名して送信し、受け取った側でそれを検証することで、改ざんされていない内容であることを確認しています。
Pleromaでは、これで必要十分であるとして、LDSのサポートを省略しています。
ところがリレーの場合、送信元が元の送信元ではなくリレーになるため、Activityの送信元と不一致で信頼できません。
#リレーの話
#ハッシュタグリレー
のえる :cava_red: DTP鯖管
Mastodonの場合、LDSが含まれるため、信頼できると確認できますが、Pleromaではこれができません。
Mastodon側で対応する方法としては、Activityに含まれる本来の送信元へ問い合わせして、裏付けをとるという方法があります。
投稿であれば、実際の投稿内容を取得して、一致しているかどうか確認すればいいわけです。動作としては、おおよそブーストの場合と同じです。（我々はフェッチしにいく、という言い方をします）
削除であれば、HTTP 404 Not Foundか、Tombstone（削除されたことを示す《墓石》）になっていることを確認すればいいわけです。
ただし、この実装は著しく非効率です。
Pleromaのリレー実装が、このようなブーストベースのものになっているということですが（詳しく見ていません）、コンセプトはともかく、実用上は現実ではないと言われています。
雪餅(2018) 連合リレーと Activity Relay
https://blog.yukimochi.jp/2018/12/fediverse-with-relay.html
#リレーの話
#ハッシュタグリレー
のえる :cava_red: DTP鯖管
信頼できる署名（LDS）があれば、どれだけ多くのリレー先に届けても、送信元の負荷は一定です。リレーに預ければ、それで終わりです。
ところが、リレー先が一斉に送信元にデータを確認しにいく実装となると、リレー先が増えれば増えるほどアクセスが集中することになり、多大なる負荷となります。（nginx等でキャッシュすることで大幅に負荷を軽減できますが、依然としてリレーより負荷が高くなります）
やはり、PleromaにLinked data Signaturesのサポートを追加するのが現実的であるように思います。
#リレーの話
#ハッシュタグリレー
senooken JP Social is a social network, courtesy of senooken. It runs on GNU social, version 2.0.2-beta0, available under the GNU Affero General Public License.
All senooken JP Social content and data are available under the Creative Commons Attribution 3.0 license.