Undo activities may not be handled

[Johann150]

💡 Summary

Some Undo activities are not handled correctly. The problem is that the remote server sends the object as only its id instead of the full object. Because it was undone, the remote server will return a 404 error code when Misskey tries to fetch the object with HTTP.

example Activity

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://pleroma.example/schemas/litepub-0.1.jsonld",
    {
      "@language": "und"
    }
  ],
  "type": "Undo",
  "id": "https://pleroma.example/activities/320d5a6f-2a0b-4d3f-b59b-77fbe66c9796",
  "actor": "https://pleroma.example/users/example",
  "to": [ "https://pleroma.example/users/example/followers" ],
  "cc": [ "https://www.w3.org/ns/activitystreams#Public" ],
  "object": "https://pleroma.example/activities/a684eca1-3c1d-4ec9-b259-323c2b1312e5"
}

🥰 Expected Behavior

The id is known to Misskey so it can undo the activity.

🤬 Actual Behavior

The id is not saved (e.g. reactions) or it is known but is not looked up from the database even if external resolution fails (e.g. renotes).

📝 Steps to Reproduce

1. React to a note on Misskey from Pleroma
2. Remove reaction
3. Reaction is still visible on Misskey

📌 Environment

Misskey version: 12.110.1

related: #8688

[Johann150]

A solution would require saving the id of a reaction. Probably something like

ALTER TABLE "note_reaction" ADD COLUMN "uri" TEXT;

The column has similar meaning to note.uri which already saves the ids of renotes.

[Johann150]

Perhaps a more general approach is also a good idea, a table that holds all known external ActivityPub ids, the object type and internal database id. That would be helpful for cases where you do not know the type of object you are looking for and only know the id. I think this would be necessary in this case because there are more types of Activities that Misskey can in principle undo:

misskey/packages/backend/src/remote/activitypub/kernel/undo/index.ts

Lines 29 to 33 in 79de4d7

	if (isFollow(object)) return await unfollow(actor, object);
	if (isBlock(object)) return await unblock(actor, object);
	if (isLike(object)) return await undoLike(actor, object);
	if (isAnnounce(object)) return await undoAnnounce(actor, object);
	if (isAccept(object)) return await undoAccept(actor, object);

So maybe something like this:

CREATE TYPE ap_ids_kind AS ENUM (
    'Note', 'Person', 'Like', 'Follow', 'Block', 'Accept' -- etc.
);

CREATE TABLE ap_ids (
    uri TEXT PRIMARY KEY,
    kind ap_ids_kind not null,
    id varchar(32) not null
);

In turn we might be able to remove the uri columns from other tables if that is desired. But I think since that would require more joins it is maybe not a good idea.