@how What’s the 500 error? Is it coming from the ActivityPub plugin (I assume it is, but I’m not seeing it on other sites)?
I just got back from holiday. I have access to the logs here now, and will be taking a closer look at this specific error (i.e. the outbox issue you’re seeing on this site but not on demo.pavilion.tech) next week (assuming you’re still seeing).
2 Likes
I guess I’ll put this here as there’s doesn’t seems to be a bugtracker.
04:10:35.847 [error] Could not decode user at fetch https://socialhub.activitypub.rocks/ap/actor/bcde488169a4ac803695493219aece2a, {:content_type, "application/json; charset=utf-8"}
application/json isn’t a valid Content-Type for ActivityPub data and gets rejected by Pleroma (to avoid trivial content injection via attachments, other implementations also should reject btw), it needs to be either application/activity+json or application/ld+json; profile="https://www.w3.org/ns/activitystreams".
3 Likes
Thanks for the report, I’ll take a closer look soon. I will respond here, however, in general, please report any issues on the plugin’s topic on meta.discourse.org. As imperfect as it is, that’s the best way to report issues with Discourse plugins.
1 Like
@lanodan Thanks for raising this and thanks for your patience. This will be addressed when this PR is merged.
1 Like
I just found this in my inbox:
{
"@context": "https://www.w3.org/ns/activitystreams",
"actor": {
"@context": "https://www.w3.org/ns/activitystreams",
"followers": "https://socialhub.activitypub.rocks/ap/actor/bcde488169a4ac803695493219aece2a/followers",
"icon": {
"mediaType": "image/png",
"type": "Image",
"url": "https://socialhub.activitypub.rocks/uploads/default/original/1X/8faac84234dc73d074dadaa2bcf24dc746b8647f.png"
},
"id": "https://socialhub.activitypub.rocks/ap/actor/bcde488169a4ac803695493219aece2a",
"inbox": "https://socialhub.activitypub.rocks/ap/actor/bcde488169a4ac803695493219aece2a/inbox",
"name": "Fediverse Enhancement Proposals",
"outbox": "https://socialhub.activitypub.rocks/ap/actor/bcde488169a4ac803695493219aece2a/outbox",
"preferredUsername": "feps",
"publicKey": {
"id": "https://socialhub.activitypub.rocks/ap/actor/bcde488169a4ac803695493219aece2a#main-key",
"owner": "https://socialhub.activitypub.rocks/ap/actor/bcde488169a4ac803695493219aece2a",
"publicKeyPem": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwNTaKKVfQhJhlLIDDjW2\nQgDp3sIQPUa7aUB2UY5Z5esiNNew6wR0oBN7QpEHdM3nbnJ8hV2qzOY5dZaegaeb\nM4aUBZfuWsfUzfSJRt9FTpf2MGami5lGZs0MMww6les0Meq8bNNdeIZujJ9nItcu\nXqpaU36DH8FMUbCRdELR3TxdXgbOm6TE9A7B+om05YPE5eRbMK6k1nXWfVDgTzMg\nx5jLHRhE/KOJkSPT6rWAt0SqaqMbOHuS2osGhxNTdLeuqY1nFptvqGcceDv2LhzR\n4kHrrI6rYPgTQa5dd1JbOgQpIE0UxncnppaXofJFodj2Z7YO+2RGMPqaua4L2SIV\npwIDAQAB\n-----END PUBLIC KEY-----\n"
},
"type": "Group",
"updated": "2023-06-01T13:19:32Z",
"url": "https://socialhub.activitypub.rocks/c/standards/fep/54"
},
"audience": "https://socialhub.activitypub.rocks/ap/actor/bcde488169a4ac803695493219aece2a",
"cc": [
"https://www.w3.org/ns/activitystreams#Public"
],
"id": "https://socialhub.activitypub.rocks/ap/activity/6de1505cda7a63e4aff6ec46031314a7",
"object": {
"@context": "https://www.w3.org/ns/activitystreams",
"attributedTo": "https://socialhub.activitypub.rocks/ap/actor/bcde488169a4ac803695493219aece2a",
"audience": "https://socialhub.activitypub.rocks/ap/actor/bcde488169a4ac803695493219aece2a",
"content": "Hello!\nThis is a discussion thread for the proposed <a href=\"https://codeberg.org/fediverse/fep/src/branch/main/fep/7502/fep-7502.md\">FEP-7502: Limiting visibility to authenticated actors</a>.\nPlease use this thread to discuss the proposed FEP and any potential problems\nor improvements that can be addressed.\nSummary\nSome servers require authentication for all requests made via ActivityPub, even for GET requests on public objects addressed to as:Public. This violates the requirement that anything…<br><br><a href=\"https://socialhub.activitypub.rocks/t/fep-7502-limiting-visibility-to-authenticated-actors/3784/1\">↪ SocialHub</a>",
"id": "https://socialhub.activitypub.rocks/ap/object/79ae9114aabe5fd8a26eedb927edc291",
"name": "FEP-7502: Limiting visibility to authenticated actors",
"published": "2023-12-24T19:15:19Z",
"type": "Note",
"updated": "2023-12-24T19:15:19Z",
"url": "https://socialhub.activitypub.rocks/t/fep-7502-limiting-visibility-to-authenticated-actors/3784/1"
},
"published": "2023-12-24T19:15:15Z",
"to": "https://socialhub.activitypub.rocks/ap/actor/bcde488169a4ac803695493219aece2a",
"type": "Create",
"updated": "2023-12-24T19:15:15Z"
}
The activity has to and cc fields (and addressed to https://www.w3.org/ns/activitystreams#Public), but the embedded Note object doesn’t have them. This could be the reason why some servers reject this activity.
Here’s what ActivityPub spec says on that matter:
A mismatch between addressing of the Create activity and its
objectis likely to lead to confusion. As such, a server SHOULD copy any recipients of the Create activity to itsobjectupon initial distribution, and likewise with copying recipients from theobjectto the wrapping Create activity.
4 Likes
Thanks for this, and sorry for my slow response, I’ve been on holiday.
I’ve made a PR to copy create activity addressing to the object. This was actually something we had in a previous version, but lost when I updated the modelling.
Also, this is a good opportunity to ask something I’ve been wondering. The text you extracted above is from the “Client to Server Interactions” section of the spec. Aren’t we technically dealing with a Server to Server interaction here? I understand the utility of copying the addressing across, so my question is more of an interpretative one of the spec, rather than this specific point of implementation.
2 Likes
Since activities are supposed to be generated by clients, “SHOULD copy any recipients” in the C2S part of the spec likely translates into “SHOULD have the same recipients” in the S2S part of the spec. There could be other interpretations.
2 Likes
Got another Create activity from SocialHub in my inbox today. Everything seems to be fine, except the actor’s outbox, which still responds with 500 Internal Server Error to a GET request.
1 Like
That changed the structure of Create activity, but when object is not embedded in activity, it still doesn’t have to field. Example:
https://socialhub.activitypub.rocks/ap/object/cba5172786abcd3cf81544c375a18fc9
Thanks, I’m back working on this plugin again after a little break. I’ll take another look soon.
1 Like
Just circling back on this, this was intentional. Note “initial” in the spec you highlighted
I’m now wondering what the utility of addressing of an object after its initial distribution is? In what scenario would you be retrieving the object directly and not already know the addressing? I’m probably missing something.
One common scenario is “boosting” where you send an Announce activity referencing the object. Recipients then fetch the object from the origin.
1 Like
Ah I see. Just thinking in the abstract, wouldn’t you still already need to know the addressing of the object prior to allowing an announce in the first place? I’m just trying to think of a real situation in which you’d initiate an announce activity without already knowing the object addressing. Anyway, I trust you, and I don’t see any harm in this. I’ll copy the addressing to that scenario as well soon.
Recipients of Announce may also want to know object’s addressing. For example micro-blogging applications use information from to and cc fields to distinguish ‘public’, ‘followers-only’ and ‘direct’ posts.
2 Likes
The PR addressing this is merged. Let me know if you have any other issues.
4 Likes