Just a call out for help from fedidevs re: ActivityPub. For some reason that I have yet to discern, my mentions are not reaching end users if they're on a Mastodon instance.

The annoying thing is they used to work, but seem to have broken somewhat recently.

(Thanks @trwnh@mastodon.social (who ironically, will not be notified of this mention) for letting me know about the issue.)

I include each mention in the tag property, and it includes type, href, and name:

• type is Mention
• href is the url of the user (not the ID)
• name is the full handle without the @ prefix

{
  ...
  "tag": [
    {
        "type": "Mention",
        "href": "https://crag.social/users/devnull",
        "name": "devnull@crag.social"
    }
  ]
  ...

The post is successfully federated, and when queried, the mention is clickable and goes to the local account page for that user (as opposed to linking out to the remote page like a regular URL).

Alas, the mention does not generate a notification on the receiving end.

Does this seem familiar to anyone else?

Just a call out for help from fedidevs re: ActivityPub. For some reason that I have yet to discern, my mentions are not reaching end users if they're on a Mastodon instance.

The annoying thing is they used to work, but seem to have broken somewhat recently.

(Thanks @trwnh@mastodon.social (who ironically, will not be notified of this mention) for letting me know about the issue.)

I include each mention in the tag property, and it includes type, href, and name:

• type is Mention
• href is the url of the user (not the ID)
• name is the full handle without the @ prefix

{
  ...
  "tag": [
    {
        "type": "Mention",
        "href": "https://crag.social/users/devnull",
        "name": "devnull@crag.social"
    }
  ]
  ...

The post is successfully federated, and when queried, the mention is clickable and goes to the local account page for that user (as opposed to linking out to the remote page like a regular URL).

Alas, the mention does not generate a notification on the receiving end.

Does this seem familiar to anyone else?

@julian Can you open an issue in the Mastodon repository with some details so we can look at it?

Thanks

@trwnh

Resolved thanks to the help of @Claire@social.sitedethib.com! The issue as it turned out, was me sending an improper data structure in the replies property ([] instead of null or nothing at all.)

https://github.com/mastodon/mastodon/issues/31230

Thanks @trwnh@mastodon.social for letting me know about the issue, and @renchap@oisaur.com for forwarding me along to the issue tracker.

Notifications not generated for mention received from NodeBB · Issue #31230 · mastodon/mastodon

Steps to reproduce the problem [NodeBB] Create a new post and tag a user on a mastodon instance (in this case, it was @julian@bb.devnull.land to @devnull@crag.social) [Mastodon] Navigate to the sender's profile (https://crag.social/@juli...

GitHub (github.com)

Hi @renchap and @julian @Claire @trwnh
glad he issue could be resolved quickly, do you think #Mastodon could in such cases return a 400 Bad Request or send an asynchronous https://www.w3.org/TR/activitypub/#reject-activity-inbox?

@mro @renchap @julian @trwnh Mastodon did not reject the post, but rather failed halfway processing it because it was malformed; in other words, the failure was not intentional, a bug in NodeBB triggered a bug in Mastodon

@mro@digitalcourage.social I could be wrong, but I don't think normative use of Reject is documented or seen anywhere.

NodeBB actually does send Rejects on some things, but a project looking into how non-2xx responses and Rejects are used could be helpful.

cc @Claire@social.sitedethib.com

@julian @mro i'm indeed not aware of a normative use of Reject being described, and there is also some talk about using Reject for e.g. messages rejected by a user's policy to block messages from strangers, so those would be two quite different use cases

@Claire@social.sitedethib.com That's the thing, isn't it... that a 400 could indicate a malformed request, whereas a reject might be better suited for policy violations.

... but we actually do have a response code for a policy violation, 403 Forbidden!

The technical difference is that a Reject is better suited for when an incoming request is queued for processing (aka 202 Accepted is sent), and later rejected.

Either way I think we're at the point where some pseudo-standard on error handling would be welcome. The current situation as-is is: "sometimes instances send non-2xx, sometimes they send rejects. Either way it could mean absolutely anything so just re-send it again later"

cc @mro@digitalcourage.social