[bug] instance actor object (/internal/fetch) does not have a valid following/follower collection #855
Labels
No labels
approved, awaiting change
bug
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs docs
needs tests
not a bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: AkkomaGang/akkoma#855
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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...
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/816Logs
Severity
I cannot use it as easily as I'd like
Have you searched for this issue?
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
Yeah, if the collection is advertised it should also behave like an AP object; thanks for the report.
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
*(nointernal.
-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
@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.