ActivityPubの投稿を削除するには2つ必要で。

・自分んち、ローカルは

→データベースから該当の投稿を削除する。

・他所んち、リモートには

→「Delete」のActivityをリクエストする。

今回のネタはこの2つ。

1)なんでautoincrementを設定してなかったんだ!？

2)Mastodon系とMisskey系で削除したNoteのIDの扱いが違っていた？

この投稿のうち、真ん中の2つ「6453」と「6454」は一度削除後に再投稿したもの

・一度データベースから削除

・DeleteのActivityをリモートにリクエスト

・削除されていることを確認して

・削除後に新たに別の内容を投稿したもの

ローカルから消すために、データベースからの削除はスグできる。

リモートには、対象の投稿はもう「墓石」です、というのを「Delete」のActivityに入れてリクエストする。

{
  "id":"https://tokoroten.doncha.net/t2aki/items/03881-20250208"，
  "url":"https://tokoroten.doncha.net/t2aki/items/03881-20250208"，
  "type":"Tombstone"
}

「投稿を削除する::On Golden Pond」

https://www.doncha.net/activitypub/activitypub007.html

お相手は削除のリクエストが飛んできたのを見て、対象のNoteは墓の下になったということで、タイムラインからも削除する。

そのIDはもう使えない。

削除後に新しく別のものを投稿すると

データベース的には、primarykeyにautoincrementを設定してないもんだから、IDの最大値を使う。

つまり、一度使用した・削除されたIDをまた使うことがある(IDの使い回しなどあってはいけない自業自得案件)

削除したIDを使い回して新たに投稿

mastodon.social

misskey.io

そもそも、IDの使い回しなどあってはいけない、というのが大前提なので、わたしのポカなんだけど。

mastodonは削除IDの復活はない、misskeyは削除IDを墓の下から復活する。

同じIDの使い回しというと「Update」(投稿の編集更新)があるけど、これもサーバーによって対応がビミョーに違ってた、かなあ。

IDの使い回しなどあってはなりません(教訓

SQLiteはAlterなんちゃらでautoincrementを後付けできない。

改めてテーブルを作って、そこに既存データをコピーすることになる…ので、いろいろ危険だなあ。これは「運用でカバー」という腐った対応にしておこう。そのためのメモだ。

[12/10 20:30:37] 追記

言い訳をしておくと。

mastodonの仕様は把握していた。miskkeyが意外だった。

autoincrementをつけるかどうかは、データベースを作る時にちょっと迷った。

投稿作成フローで、うちはまず「下書き」状態でデータベースに登録。この時点でIDがふられる。下書きを確認した後、問題がなさそうだったらリモートに配送する。

ということは、実際に配送に至らなかった投稿でもIDを消費してしまう。これを嫌ってautoincrementを見送ったという経緯。配送IDとか別建てにしておけば良かったんだろうけど…手抜きしちゃったなあ。