Mentions and notifications over the fediverse
-
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 includestype
,href
, andname
:type
isMention
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 🌻replied to julian on last edited by
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?
-
-
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 ofnull
or nothing at all.)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 @[email protected] to @[email protected]) [Mastodon] Navigate to the sender's profile (https://crag.social/@juli...
GitHub (github.com)
Thanks @[email protected] for letting me know about the issue, and @[email protected] for forwarding me along to the issue tracker.
-
Marcus Rohrmoser 🌻replied to julian on last edited by [email protected]
-
Clairement crevéereplied to Marcus Rohrmoser 🌻 on last edited by
-
@[email protected] I could be wrong, but I don't think normative use of
Reject
is documented or seen anywhere.NodeBB actually does send
Reject
s on some things, but a project looking into how non-2xx responses andReject
s are used could be helpful. -
-
@[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 (aka202 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"
-
Marcus Rohrmoser 🌻replied to julian on last edited by