FoundKeyGang/FoundKey

Fork 22

Remove Follower button does not use the correct object ID #263

New issue

Closed

opened 2022-12-01 18:18:34 +00:00 by floatingghost · 5 comments

floatingghost commented

2022-12-01 18:18:34 +00:00

from some debugging

when a user clicks on the "remove follower" button, the following object is sent:

VERB 1	[deliver]	delivering {
  "type": "Reject",
  "actor": "https://misskey.local.live/users/988yivyylo",
  "object": {
    "id": "https://misskey.local.live/follows/988xdwum2h/988yivyylo",
    "type": "Follow",
    "actor": "https://akkoma.local.live/users/user",
    "object": "https://misskey.local.live/users/988yivyylo"
  },
  "id": "https://misskey.local.live/d026b9f1-033a-427e-9830-06021d60f804"
}

note that the object.id here is a misskey ID, it is trying to Reject an object ID that would be generated if a misskey user followed someone from their instance

in contrast, an Accept activity will be sent as follows:

VERB 1	[deliver]	delivering {
  "type": "Accept",
  "actor": "https://misskey.local.live/users/988yivyylo",
  "object": {
    "id": "https://akkoma.local.live/activities/50519bbc-1f32-4347-b2b2-d222b1187a2a",
    "type": "Follow",
    "actor": "https://akkoma.local.live/users/user",
    "object": "https://misskey.local.live/users/988yivyylo"
  },
  "id": "https://misskey.local.live/2a329614-050e-4afe-9162-9758e34b7c72"
}

note here that object.id is a remote ID

these Reject and Accept activities are nominally on on the same activity, but the Reject erroneously references a locally-generated object ID, which causes remote instances to reject the activity as that object ID does not exist.

so i believe that the functionality of Remove Follower does not federate at all.

this was inherited from upstream i believe

from some debugging when a user clicks on the "remove follower" button, the following object is sent: ``` VERB 1 [deliver] delivering { "type": "Reject", "actor": "https://misskey.local.live/users/988yivyylo", "object": { "id": "https://misskey.local.live/follows/988xdwum2h/988yivyylo", "type": "Follow", "actor": "https://akkoma.local.live/users/user", "object": "https://misskey.local.live/users/988yivyylo" }, "id": "https://misskey.local.live/d026b9f1-033a-427e-9830-06021d60f804" } ``` note that the `object.id` here is a misskey ID, it is trying to `Reject` an object ID that _would_ be generated if a misskey user followed someone from their instance in contrast, an `Accept` activity will be sent as follows: ``` VERB 1 [deliver] delivering { "type": "Accept", "actor": "https://misskey.local.live/users/988yivyylo", "object": { "id": "https://akkoma.local.live/activities/50519bbc-1f32-4347-b2b2-d222b1187a2a", "type": "Follow", "actor": "https://akkoma.local.live/users/user", "object": "https://misskey.local.live/users/988yivyylo" }, "id": "https://misskey.local.live/2a329614-050e-4afe-9162-9758e34b7c72" } ``` note here that `object.id` is a *remote* ID these `Reject` and `Accept` activities are nominally on on the same activity, but the `Reject` erroneously references a locally-generated object ID, which causes remote instances to reject the activity as that object ID does not exist. so i believe that the functionality of `Remove Follower` does not federate at all. this was inherited from upstream i believe

a commented

2022-12-01 19:05:02 +00:00

worth noting that you could probably remove the id for the inlined object entirely and it would still be valid. if provided, it should be the original remote ID

associated misskey issue: https://github.com/misskey-dev/misskey/issues/9250

worth noting that you could probably remove the `id` for the inlined `object` entirely and it would still be valid. *if* provided, it should be the original remote ID associated misskey issue: https://github.com/misskey-dev/misskey/issues/9250

Johann150 commented

2022-12-01 19:23:01 +00:00

Owner

Seeing that we don't (yet?) keep track of the remote id we probably have to remove it.

Seeing that we don't (yet?) keep track of the remote `id` we probably have to remove it.

Johann150 self-assigned this 2022-12-01 19:52:06 +00:00

Johann150 commented

2022-12-01 20:02:08 +00:00

Owner

It's kind of a thin line when to put an id, when to generate a fallback id and when to not put an id.

see also https://github.com/misskey-dev/misskey/issues/8655 It's kind of a thin line when to put an id, when to generate a fallback id and when to not put an id.

Johann150 commented

2022-12-01 20:32:18 +00:00

Owner

So my solution is to generate an id only if the following user is local. Otherwise, if we know the id (because it was stored from the follow request) use that. Otherwise, no id for you.

Since to my knowledge a user on another instance cannot request to be followed, and instead can only request to follow someone. Is that correct? (That would mean all Followings with a local follower would have a local id too.)

So my solution is to generate an `id` only if the following user is local. Otherwise, if we know the `id` (because it was stored from the follow *request*) use that. Otherwise, no `id` for you. Since to my knowledge a user on another instance cannot request to be *followed*, and instead can only request to *follow* someone. Is that correct? (That would mean all `Followings` with a local follower would have a local id too.)

👍 1

a commented

2022-12-01 20:38:25 +00:00

a user on another instance cannot request to be followed, and instead can only request to follow someone. Is that correct?

that seems correct, yes. Follow is an explicit action by one actor toward another. if you were to model a "request to be followed", you would probably use Offer Follow (but this seems spammy and would need a valid use-case before being implemented imo)

> a user on another instance cannot request to be followed, and instead can only request to follow someone. Is that correct? that seems correct, yes. Follow is an explicit action by one actor toward another. if you were to model a "request to be followed", you would probably use Offer Follow (but this seems spammy and would need a valid use-case before being implemented imo)

👍 1

Johann150 referenced this issue from a commit

2022-12-01 20:49:50 +00:00

server: fix rendering of Follow activity when removing follow

Johann150 closed this issue

2022-12-01 20:49:50 +00:00