The thing is: It does not show up, although I am getting a postive HTTP response (202 Accepted) and I am trying to figure out why. Perhaps someone here can give me a hint what is going on.
Have you tried putting the to field onto the Create Activity itself, and not just the object?
It’s a little odd that this is the recommended payload by Mastodon where to is on the object and not the Activity, since it violates expectations in 7.1 (server to server delivery) which also points to 6.1 (client addressing).
I am not sure if Mastodon is also attempting to fetch the note to verify it exists at that ID, but you definitely want to be serving that created note at that endpoint.
For our purposes, we don’t actually need to host this document publicly
This of course might have changed meanwhile, since the article is 2 years old. So I will give it a try. If anyone knows for sure what is needed and what not, let me know please.
I also had this error when I followed the instructions.
What I can offer you is an undocumented 245 lines nodeJS snippet where the folder name says “worked” but without guarantees
Mastodon does not return 202 if the signature is valid, although we would be well within our rights to per the spec. But for HTTP signatures specifically we always process those synchronously and return a 401 with a specific error reason. Like the spec says, we return 202 if we accept the payload for further asynchronous processing, regardless of whether that processing succeeds or not. (since it’s asynchronous, there’s no way to know)
(If you read the actual issue you linked, you’d know that this is the case, since it concludes by saying "We know now that 202 is okay in terms of signature)
My guess is that the actor profile is being served with the same server, correct? Mastodon needs to be able to fetch your actor’s profile before it can attribute any posts to it, so if neither activity+json or ld+json with profile are responded to then that will cause a failure. I would suggest using mastodon’s “search box” as a debugging tool—put the URL of your actor into the search box, and if a profile comes up successfully, you can check off that step
Right, the actor has the same issue with profile. I did not think about that, because I actually was able to find it on mastodon using angelo@angelo.veltens.org and felt safe.
I wonder why. Might mastodon.social and mastodon.online behave differently?
Or did it work, because mastodon.online already knew about @angelo@angelo.veltens.org, because I did the search there before, but I did not do that on mastodon.social (due lack of account there).
The reason might also be that your IDs aren’t permanent, as in, they contain a #fragment. Posts and their corresponding Create activities are supposed to be resolvable — which means one should be able to send a GET request to the ID URL and get the object back. This can’t be done with an URL that contains a fragment as the fragment is not a part of the HTTP exchange, it’s processed on the client.
Both URIs are permanent. Of course the client will resolve the document URL https://angelo.veltens.org/public/toots/hello-solid but both resources are described in that document.
I guess the problem is, that mastodon.social could not get a JSON-LD representation of the actor, while mastodon.online already had one cached from the webfinger search. Although this still does not explain how it could retrieve the actor during the search.
Feels to me like that’s not a good thing. These are expected to be two distinct URLs — one that returns the Note wrapped in Create, and another one that returns the Note by itself.
See for yourself how Mastodon does it. Try sending a GET request with Accept: application/activity+json to these URLs: https://mastodon.social/users/Gargron/statuses/104517499488193307/activity https://mastodon.social/users/Gargron/statuses/104517499488193307
@aveltens yes, this is certainly the reason! Mastodon will not try to (or need to) resolve your account again if it already knows about it
My guess is that the webfinger -> URL code is slightly less strict about the Accept header, because it already knows it’s looking for an AS2 document.
I don’t think this is absolutely required—mastodon had a #activity URL for a long time. Since the network as a whole already uses this same behavior widely for #main-key, I can’t see where the harm would be in allowing it to be used here as well
I don’t think fragments offer any information about where to actually find the object unless the implementation walks every node looking for a matching string
All you need to do is keep track, when deserializing, of the different “id” nodes, and build a hashmap to them—or even just keep a single pointer to the id you’re looking for. It’s not going to be a performance bottleneck in most applications.
(Mastodon does not currently do this, but we’re very flexible about whether implementations want to send us the activity or the object, and tend to treat them interchangeably, so i don’t think we’d run into any problems here)
Is this JSON-LD processing something that Mastodon does?
I know go-fed does not do JSON-LD processing at runtime, which means it simply assumes performing a GET request to an IRI will yield an ActivityStreams payload that has that identifier as its root object.
) benefits of JSON-LD