Problems POSTing to Mastodon inbox

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.

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 mastodon.online and it worked!

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).

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 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.

1 Like

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.

3 Likes

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:

https://json-ld.org/playground/#startTab=tab-framed&json-ld=https%3A%2F%2Fangelo.veltens.org%2Fpublic%2Ftoots%2Fhello-solid%23note&frame={"%40context"%3A"https%3A%2F%2Fwww.w3.org%2Fns%2Factivitystreams"%2C"id"%3A"https%3A%2F%2Fangelo.veltens.org%2Fpublic%2Ftoots%2Fhello-solid%23note"}&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).

1 Like

Hi there, just to let you know that the blog tutorial is now broken. The POST request also need to contain a Digest field in the header and a digest in the signed text.

See mastodon/signature_verification.rb at c3aef491d66aec743a3a53e934a494f653745b61 · mastodon/mastodon · GitHub for more information.

1 Like

Hi there @green-coder, welcome to SocialHub :hugs: It might be best to report that to the appropriate Mastodon issue tracker, but in any case cc’ing @Gargron and @nightpool with this…

2 Likes

Bug reported at Blog post "how-to-implement-a-basic-activitypub-server" misses the field `Digest` · Issue #17299 · mastodon/mastodon · GitHub

2 Likes

Sorry, I know this is a huge necro but I’m facing the exact same problem! I attempted to create a post using the example shown in this blogpost (with the addition of a digest), and while I can get replies to show up, if I go to the user’s timeline, it’s empty! “Posts and replies” will show the posts that had inReplyTo set, but nothing else shows.

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://activitypub-sandbox.ollien.com/test-activity2",
  "type": "Create",
  "actor": "https://activitypub-sandbox.ollien.com/user1",
  "object": {
    "id": "https://activitypub-sandbox.ollien.com/test-object2",
    "type": "Note",
    "published": "2023-07-05T23:49:00",
    "attributedTo": "https://activitypub-sandbox.ollien.com/user1",
    "content": "this is a test of having things rooted here...",
    "to": "https://www.w3.org/ns/activitystreams#Public"
  }
}

Is there something that needs to be hosted on my test domain for Mastodon to hydrate the timeline?