[bug] instance actor object (/internal/fetch) does not have a valid following/follower collection #855

Open
opened 2024-11-21 19:16:22 +00:00 by puppygirlhornypost · 4 comments

Your setup

Docker

Extra details

Debian with docker compose.

Version

3.13.2

PostgreSQL version

don't know

What were you trying to do?

I run a sharkey instance, current version 2024.9.3. What my instance was trying to do is update an instance actor from an akkoma instance running 3.13.2. What happened was some very interesting errors.

What did you expect to happen?

I expected that when my instance fetched https://labyrinth.zone/internal/fetch (to update the actor) that I would see...

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://labyrinth.zone/schemas/litepub-0.1.jsonld",
    {
      "@language": "und"
    }
  ],
  "endpoints": {
    "oauthAuthorizationEndpoint": "https://labyrinth.zone/oauth/authorize",
    "oauthRegistrationEndpoint": "https://labyrinth.zone/api/v1/apps",
    "oauthTokenEndpoint": "https://labyrinth.zone/oauth/token",
    "sharedInbox": "https://labyrinth.zone/inbox"
  },
  "id": "https://labyrinth.zone/internal/fetch",
  "inbox": "https://labyrinth.zone/internal/fetch/inbox",
  "invisible": true,
  "manuallyApprovesFollowers": false,
  "name": "Pleroma",
  "outbox": "https://labyrinth.zone/internal/fetch/outbox",
  "preferredUsername": "internal.fetch",
  "publicKey": {
    "id": "https://labyrinth.zone/internal/fetch#main-key",
    "owner": "https://labyrinth.zone/internal/fetch",
    "publicKeyPem": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAl61oi4/PA3A11g1tmPWa\nQ+dP6pb5TzjZPulBgwLDCn4zzUmkUj7TCtEyZfQ86XTccRHI/bFmQIfmu2oXETn2\nzt/npjdXQNhXpb9URU8vB58UeykaE+1SsV3i2uSTNyATfFX9VXnxiYHym5buDfh8\nQvlpNle9nHUAQ7Js+2B3yzy+Unh1Ff09bvU/1i+9N0/jz2/4PS37pR+TEN7nVjSL\n/A3L9Qx2uAkODWvK8HMwBiUy4nVN4shxRrdx8ZX+YClJRUDZBcgxA6k6WaXVsMXt\nrgDQwCKiF9q5BWxgarpz3NPDOwkJVPzOc+7hGACCK223hp2XetO8NXpufpLZfiT+\n+QIDAQAB\n-----END PUBLIC KEY-----\n\n"
  },
  "summary": "An internal service actor for this Pleroma instance.  No user-serviceable parts inside.",
  "type": "Application",
  "url": "https://labyrinth.zone/internal/fetch"
}

Because when my instance fetches https://labyrinth.zone/internal/fetch/following it throws an error. I expected either akkoma does not have the following/follower collection on the instance actor (valid by spec) or that since it had a following/follower collection linked with a url that would resolve to a valid AP following/follower collection. What I found was not exactly what I had hoped.

What actually happened?

So, for reasons unknown to me akkoma seems to be giving a url for the following and follower collections. This is great, but when you actually fetch from them curl -X GET -H 'Accept: application/activity+json' https://labyrinth.zone/internal/fetch/following you do not get a following collection, or a follower collection. Instead, you get a blank html page. I go more in depth on the sharkey side (the instance software I used that found this bug) here: https://activitypub.software/TransFem-org/Sharkey/-/issues/816

Logs

I have no relevant akkoma logs to provide unfortunately.

Severity

I cannot use it as easily as I'd like

Have you searched for this issue?

  • I have double-checked and have not found this issue mentioned anywhere.
### Your setup Docker ### Extra details Debian with docker compose. ### Version 3.13.2 ### PostgreSQL version don't know ### What were you trying to do? I run a sharkey instance, current version 2024.9.3. What my instance was trying to do is update an instance actor from an akkoma instance running 3.13.2. What happened was some very interesting errors. ### What did you expect to happen? I expected that when my instance fetched https://labyrinth.zone/internal/fetch (to update the actor) that I would see... ``` { "@context": [ "https://www.w3.org/ns/activitystreams", "https://labyrinth.zone/schemas/litepub-0.1.jsonld", { "@language": "und" } ], "endpoints": { "oauthAuthorizationEndpoint": "https://labyrinth.zone/oauth/authorize", "oauthRegistrationEndpoint": "https://labyrinth.zone/api/v1/apps", "oauthTokenEndpoint": "https://labyrinth.zone/oauth/token", "sharedInbox": "https://labyrinth.zone/inbox" }, "id": "https://labyrinth.zone/internal/fetch", "inbox": "https://labyrinth.zone/internal/fetch/inbox", "invisible": true, "manuallyApprovesFollowers": false, "name": "Pleroma", "outbox": "https://labyrinth.zone/internal/fetch/outbox", "preferredUsername": "internal.fetch", "publicKey": { "id": "https://labyrinth.zone/internal/fetch#main-key", "owner": "https://labyrinth.zone/internal/fetch", "publicKeyPem": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAl61oi4/PA3A11g1tmPWa\nQ+dP6pb5TzjZPulBgwLDCn4zzUmkUj7TCtEyZfQ86XTccRHI/bFmQIfmu2oXETn2\nzt/npjdXQNhXpb9URU8vB58UeykaE+1SsV3i2uSTNyATfFX9VXnxiYHym5buDfh8\nQvlpNle9nHUAQ7Js+2B3yzy+Unh1Ff09bvU/1i+9N0/jz2/4PS37pR+TEN7nVjSL\n/A3L9Qx2uAkODWvK8HMwBiUy4nVN4shxRrdx8ZX+YClJRUDZBcgxA6k6WaXVsMXt\nrgDQwCKiF9q5BWxgarpz3NPDOwkJVPzOc+7hGACCK223hp2XetO8NXpufpLZfiT+\n+QIDAQAB\n-----END PUBLIC KEY-----\n\n" }, "summary": "An internal service actor for this Pleroma instance. No user-serviceable parts inside.", "type": "Application", "url": "https://labyrinth.zone/internal/fetch" } ``` Because when my instance fetches `https://labyrinth.zone/internal/fetch/following` it throws an error. I expected either akkoma does not have the following/follower collection on the instance actor (valid by spec) or that since it had a following/follower collection linked with a url that would resolve to a valid AP following/follower collection. What I found was not exactly what I had hoped. ### What actually happened? So, for reasons unknown to me akkoma seems to be giving a url for the following and follower collections. This is great, but when you actually fetch from them `curl -X GET -H 'Accept: application/activity+json' https://labyrinth.zone/internal/fetch/following` you do not get a following collection, or a follower collection. Instead, you get a blank html page. I go more in depth on the sharkey side (the instance software I used that found this bug) here: https://activitypub.software/TransFem-org/Sharkey/-/issues/816 ### Logs ```shell I have no relevant akkoma logs to provide unfortunately. ``` ### Severity I cannot use it as easily as I'd like ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.
puppygirlhornypost added the
bug
label 2024-11-21 19:16:22 +00:00

An update... https://activitypub.software/TransFem-org/Sharkey/-/issues/816#note_8556 Misskey/Sharkey handles this (we have follower visibility) by returning an empty body. I still cannot attest to whether dropping the "following" and "follower" attributes would impact federation, I do know the safest bet is probably to follow what misskey does considering mastodon and other instance software doesn't seem to have a problem with that. It seems like misskey is just upset because with the current situation on akkoma we get an text/html body when we expect application/activity+json

An update... https://activitypub.software/TransFem-org/Sharkey/-/issues/816#note_8556 Misskey/Sharkey handles this (we have follower visibility) by returning an empty body. I still cannot attest to whether dropping the "following" and "follower" attributes would impact federation, I do know the *safest* bet is probably to follow what misskey does considering mastodon and other instance software doesn't seem to have a problem with that. It seems like misskey is just upset because with the current situation on akkoma we get an text/html body when we expect application/activity+json
Member

Yeah, if the collection is advertised it should also behave like an AP object; thanks for the report.

I still cannot attest to whether dropping the "following" and "follower" attributes would impact federation […]

Checking Mastodon’s internal actor, it doesn’t advertise any follow* collections so I think it’s generally safe though I imagine it’s possible some implementations consider this a hint the actor cannot be followed. We also have a built-in relay actor which by necessity needs follows to work, but it’s a separate relay *(no internal.-prefix!) actor and we do serve proper collections here.

Just dropping the follow* collections from the internal fetch actor is probably easiest

Mastodon’s internal actor
{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://w3id.org/security/v1",
    {
      "manuallyApprovesFollowers": "as:manuallyApprovesFollowers",
      "toot": "http://joinmastodon.org/ns#",
      "featured": {
        "@id": "toot:featured",
        "@type": "@id"
      },
      "featuredTags": {
        "@id": "toot:featuredTags",
        "@type": "@id"
      },
      "alsoKnownAs": {
        "@id": "as:alsoKnownAs",
        "@type": "@id"
      },
      "movedTo": {
        "@id": "as:movedTo",
        "@type": "@id"
      },
      "schema": "http://schema.org#",
      "PropertyValue": "schema:PropertyValue",
      "value": "schema:value",
      "discoverable": "toot:discoverable",
      "suspended": "toot:suspended",
      "memorial": "toot:memorial",
      "indexable": "toot:indexable",
      "attributionDomains": {
        "@id": "toot:attributionDomains",
        "@type": "@id"
      }
    }
  ],
  "id": "https://mastodon.social/actor",
  "type": "Application",
  "inbox": "https://mastodon.social/actor/inbox",
  "outbox": "https://mastodon.social/actor/outbox",
  "preferredUsername": "mastodon.social",
  "url": "https://mastodon.social/about/more?instance_actor=true",
  "manuallyApprovesFollowers": true,
  "publicKey": {
    "id": "https://mastodon.social/actor#main-key",
    "owner": "https://mastodon.social/actor",
    "publicKeyPem": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxgaTsw2L7KAJVEi2yu/M\nxOTleg9h3GBgi13YhyqaCw20wgSXhvd5C5Q8tMTlv5otUrYOB4CtwpkbD9gcSk3Y\n4wQAGPjmkyp9XvzckRX1FJBm7Z9owNtvcu87OaIO3JZOXH0AB3BO+j5qvDJr9KlT\neY8pbxNRAwegoFomFHWtTNQzrennkmWMbAya4IYwDUsTDHfYRR4MiWfKxhNI2HA8\nrYPRSKfKBHZBGvX+nWzLvL0Km8mCHTGGiKiHB+x6GpFkve49uB3QYRtuYeNqgyNI\n4Mn2/+JB9vJVw1HBiTVV4Gy2lc4NeY4GnrEEMQgeRj6YPm9u42auxApBl31TIs6J\nxQIDAQAB\n-----END PUBLIC KEY-----\n"
  },
  "endpoints": {
    "sharedInbox": "https://mastodon.social/inbox"
  }
}
Yeah, if the collection is advertised it should also behave like an AP object; thanks for the report. > I still cannot attest to whether dropping the "following" and "follower" attributes would impact federation […] Checking Mastodon’s internal actor, it doesn’t advertise any follow\* collections so I think it’s generally safe though I imagine it’s possible some implementations consider this a hint the actor cannot be followed. We also have a built-in relay actor which by necessity needs follows to work, but it’s a separate `relay` *(no `internal.`-prefix!) actor and we _do_ serve proper collections here. Just dropping the follow\* collections from the internal fetch actor is probably easiest <details> <summary>Mastodon’s internal actor</summary> ```json { "@context": [ "https://www.w3.org/ns/activitystreams", "https://w3id.org/security/v1", { "manuallyApprovesFollowers": "as:manuallyApprovesFollowers", "toot": "http://joinmastodon.org/ns#", "featured": { "@id": "toot:featured", "@type": "@id" }, "featuredTags": { "@id": "toot:featuredTags", "@type": "@id" }, "alsoKnownAs": { "@id": "as:alsoKnownAs", "@type": "@id" }, "movedTo": { "@id": "as:movedTo", "@type": "@id" }, "schema": "http://schema.org#", "PropertyValue": "schema:PropertyValue", "value": "schema:value", "discoverable": "toot:discoverable", "suspended": "toot:suspended", "memorial": "toot:memorial", "indexable": "toot:indexable", "attributionDomains": { "@id": "toot:attributionDomains", "@type": "@id" } } ], "id": "https://mastodon.social/actor", "type": "Application", "inbox": "https://mastodon.social/actor/inbox", "outbox": "https://mastodon.social/actor/outbox", "preferredUsername": "mastodon.social", "url": "https://mastodon.social/about/more?instance_actor=true", "manuallyApprovesFollowers": true, "publicKey": { "id": "https://mastodon.social/actor#main-key", "owner": "https://mastodon.social/actor", "publicKeyPem": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxgaTsw2L7KAJVEi2yu/M\nxOTleg9h3GBgi13YhyqaCw20wgSXhvd5C5Q8tMTlv5otUrYOB4CtwpkbD9gcSk3Y\n4wQAGPjmkyp9XvzckRX1FJBm7Z9owNtvcu87OaIO3JZOXH0AB3BO+j5qvDJr9KlT\neY8pbxNRAwegoFomFHWtTNQzrennkmWMbAya4IYwDUsTDHfYRR4MiWfKxhNI2HA8\nrYPRSKfKBHZBGvX+nWzLvL0Km8mCHTGGiKiHB+x6GpFkve49uB3QYRtuYeNqgyNI\n4Mn2/+JB9vJVw1HBiTVV4Gy2lc4NeY4GnrEEMQgeRj6YPm9u42auxApBl31TIs6J\nxQIDAQAB\n-----END PUBLIC KEY-----\n" }, "endpoints": { "sharedInbox": "https://mastodon.social/inbox" } } ``` </details>

@Oneric By the way, I found an example in the wild of an implementation that does not implement follower/following collections. Do a curl -X GET -H 'Accept: application/activity+json' https://bsky.brid.gy/r/https://bsky.app/profile/puppygirlhornypost.bsky.zoner.work. Bridgyfed does not incorporate a following/follower collection and most instance software that is able to federate with it allows for you to follow it normally.

@Oneric By the way, I found an example in the wild of an implementation that does not implement follower/following collections. Do a `curl -X GET -H 'Accept: application/activity+json' https://bsky.brid.gy/r/https://bsky.app/profile/puppygirlhornypost.bsky.zoner.work`. Bridgyfed does *not* incorporate a following/follower collection and most instance software that is able to federate with it allows for you to follow it normally.

I say this as a final word for this. I don't think it particularly matters for your implementation I just wanted to make you aware of this fact before I left.

I say this as a final word for this. I don't think it particularly matters for your implementation I just wanted to make you aware of this fact before I left.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: AkkomaGang/akkoma#855
No description provided.