@silverpill Voted for the first option (the double-at form appears as an example in the `acct:` URI scheme RFC, so it seems to be the easiest sigil to persuade other impls to accept), but I’d vote for `repo@organization.server` if DDNS is applicable.
fedibird.comからmstdn.jpに投稿やお気に入りなどが届かない件、調査してみたところ、mstdn.jpがFedibirdからのActivityをCloudflareで弾いていることがわかりました。
先日mstdn.jpがダウンしていて、復帰した際に、先方でセキュリティ制限を厳しく設定した可能性が高いです。
mstdn.jpの管理者に調整してもらうしかなさそうですね。
※ mstdn.jpは昔からさまざまな標的にされることが多く、CloudflareなどのWAFの設定が厳しい傾向にあります。
mstdn.jpからFedibirdが見られない件、mstdn.jpの管理者に対応していただき、さきほど回復しました。
ホワイトリスト対応のようです。
古いアクティビティ（投稿とかお気に入りとかフォローリクエスト）は届かないので、必要に応じて再送信したりしてください。
ActivityPubのエラー回復がガバガバなのがどうにもなあ。アクティビティの受け取り側がしくじるとフォローリクエストは永遠に宙ぶらりんになるし、DMも暗黙のうちに虚無に吸い込まれるという
そりゃ`outbox`をプルすれば遡れはするけどさ（ただし`Like`等も含めて配送したアクティビティの全てをきちんと`outbox`に露出している実装はそう多くはない）、そもそも取りこぼしがあったことを検出できなければ改めて取得する動機もないわけで
あとは多数のアクターをホストしているサーバの場合は1件ずつプルするのもかなりの手間になるだろう。それに対してAT Protocolの場合はそもそもサーバ全体を一括でクロールする前提の作りだから比較的問題にならないだろうけど、それを真似すれば良いかというと……どうなんすかね？
FEP-8fcfの`Collection-Synchronization`で何らかの欠損の存在までは検出できなくもないけど（同FEPの`followers`コレクション以外への適用については未定義であることは無視するものとして）、MSTと比べると具体的にどこが欠けているかの情報が読み取れないのがなあ（読み取れたとしてASのコレクションはカーソルで範囲指定して取得する仕組みもないけど）
