The Real Grunfink (nprofile…73zh) Hello, Grünfink, I've been facing an issue where friends from different instances (Pleroma mostly?) appear to unfollow me, but they confirm that they really didn't. I suspect commit e9f391e "Added a special check for Undo + Follow.", in which activitypub.c is modified as follows:
if (strcmp(type, "Undo") == 0) { /** **/
+ if (xs_type(object) != XSTYPE_DICT)
+ utype = "Follow";
+
It seems that it treats all messages of type 'Undo', where 'object' is not a dict, to be a utype 'Follow' by default. But that does not seem to be necessarily correct; there are messages that are not like that. This notification JSON for example shows a message that was likely overridden to be utype 'Follow', but originally wasn't. I confirmed with friendo that they didn't unfollow me. My account is not even in the 'to' field, which is a thing I noticed with all such mistaken unfollows (I have some 5 or 6 so far, in a few days):
https://dreamscape.link/vault/public/debug/snac2/1741791872.179863.json
Compare with this object, which is a real Pleroma unfollow I intentionally made:
https://dreamscape.link/vault/public/debug/snac2/1741805474.188476.json
Any thoughts or ideas? I'm familiar with C, but not enough with ActivityPub to know what is happening in this case. A quick solution that comes to mind, based on the handful of objects I've seen so far, is to check whether we're in the 'to' field before overriding the utype, but I have no idea why this whole utype override exists in the first place.
Red Rozenglass /
npub1aj…94pgc
2025-03-12 19:22:29
Author Public Key
npub1aj05n6h74ys35hfujyddczfcmr4drhs79xtrfdxw8sutdq2gnw9q994pgcPublished at
2025-03-12 19:22:29Event JSON
{
"id": "d7a74ac54aaa849bab22975b4545e52158ead7053105c94dc2d97e27adb40eee",
"pubkey": "ec9f49eafea9211a5d3c911adc0938d8ead1de1e299634b4ce3c38b681489b8a",
"created_at": 1741807349,
"kind": 1,
"tags": [
[
"p",
"0fbceb8e38272c4e7d199540626739d2246c9b9b957f0b97b5799e0aa28bf2a0",
"wss://relay.mostr.pub"
],
[
"proxy",
"https://fedi.dreamscape.link/rozenglass/p/1741807349.380868",
"activitypub"
]
],
"content": "nostr:nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpqp77whr3cyukyulgej4qxyeee6gjxexumj4lsh9a40x0q4g5t72sq7p73zh Hello, Grünfink, I've been facing an issue where friends from different instances (Pleroma mostly?) appear to unfollow me, but they confirm that they really didn't. I suspect commit e9f391e \"Added a special check for Undo + Follow.\", in which activitypub.c is modified as follows:\n\n if (strcmp(type, \"Undo\") == 0) { /** **/\n+ if (xs_type(object) != XSTYPE_DICT)\n+ utype = \"Follow\";\n+\nIt seems that it treats all messages of type 'Undo', where 'object' is not a dict, to be a utype 'Follow' by default. But that does not seem to be necessarily correct; there are messages that are not like that. This notification JSON for example shows a message that was likely overridden to be utype 'Follow', but originally wasn't. I confirmed with friendo that they didn't unfollow me. My account is not even in the 'to' field, which is a thing I noticed with all such mistaken unfollows (I have some 5 or 6 so far, in a few days):\n\nhttps://dreamscape.link/vault/public/debug/snac2/1741791872.179863.json\n\nCompare with this object, which is a real Pleroma unfollow I intentionally made:\n\nhttps://dreamscape.link/vault/public/debug/snac2/1741805474.188476.json\n\nAny thoughts or ideas? I'm familiar with C, but not enough with ActivityPub to know what is happening in this case. A quick solution that comes to mind, based on the handful of objects I've seen so far, is to check whether we're in the 'to' field before overriding the utype, but I have no idea why this whole utype override exists in the first place.\n",
"sig": "824664949e4daf772894e27ad4146e00a4bcd064f746aeefda9c5c68fdc1e764f4196e087150f2a3de7bc7c9e9ba3b3e9c56f3f9f921d2b6040ac58f5c706a06"
}