Mentions and notifications over the fediverse

julian

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 @[email protected] (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 with the @ prefix

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

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?

Marcus Rohrmoser 🌻

Hi @julian @trwnh, no sadly not familiar - other than silent failures being gruesome and wouldn't have to be.

I wonder about the @ stripped off the handle when mastodon even has them double. Shoudld't make a difference as the actor url should be the thing.

@renchap @MastodonEngineering, shouldn't it?

Renaud Chaput

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

Thanks

@trwnh

julian

Resolved thanks to the help of @[email protected]! 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 @[email protected] for letting me know about the issue, and @[email protected] for forwarding me along to the issue tracker.

Marcus Rohrmoser 🌻

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

Clairement crevée

@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

julian

@[email protected] 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 @[email protected]

Clairement crevée

@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

julian

@[email protected] 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 @[email protected]

Marcus Rohrmoser 🌻

Hi @julian @Claire - but sending incorrect json you get neither as of today, do you?