Problems POSTing to Mastodon inbox

When I run:

curl -H"Accept: application/activity+json"


curl -H"Accept: application/ld+json; profile=\"\""

I get:

Cannot serve requested type: application/ld+json

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.

JSON-LD without profile is working:

▶ curl\#note -H"Accept: application/ld+json"
  "@context": "",

  "id": "",
  "type": "Create",
  "actor": "",
  "to": "",

  "object": {
    "id": "",
    "type": "Note",
    "published": "2020-07-13T20:33:10+0200",
    "attributedTo": "",
    "inReplyTo": "",
    "content": "<p>Hello from Solid</p>",
    "to": ""

The blogposts states:

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.

so I guess my signature is fine.

Unfortunately probably not.
A known bug in mastodon is that signature errors return 202 !

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 :wink:

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 and felt safe.

But you are right, the actual actor URL does not give a result. This probably needs a fix on Node Solid Server.

Ok, I just tried something else: I responded to a post of my account on and it worked!

I wonder why. Might and behave differently?

Or did it work, because already knew about, because I did the search there before, but I did not do that on (due lack of account there).

Lucky that it worked, but still confused :confused:

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 but both resources are described in that document.

I guess the problem is, that could not get a JSON-LD representation of the actor, while 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:

@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

1 Like

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

That’s not true, and actually ony of the (hard to see :thinking: ) benefits of JSON-LD

Proper framing solves the problem:{"%40context"%3A""%2C"id"%3A""}&context={}

That just looks like tree traversal with extra steps

Yes, technically ActivityStreams is JSON-LD, but very few implementations would actually accept any of the alternative forms

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.

sorry, i had just updated my post at the same time as you posted to clarify mastodon’s implementation vs my general position on the spec!

Gotcha! Thanks. I should have double checked before logging off last night & saved you the trouble.

I don’t mean to continue the derail. If I can summarize, it sounds like the conclusion is that “using JSON-LD framing may cause some federation problems right now (for various software), but is a tractable problem with a solution that could be provided for the future”. Feel free to correct me.

1 Like

I ran into this object id #fragment problem as well. It seems because of some URL normalization, Mastodon will remove the fragment, and drop any additional posts with different fragments (because they become the same url).