Skip to content

Add experimental support for MSC3768: Push rule action for in-app notifications #18720

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 17 commits into
base: develop
Choose a base branch
from

Conversation

Johennes
Copy link
Contributor

@Johennes Johennes commented Jul 23, 2025

This adds experimental support for matrix-org/matrix-spec-proposals#3768.

Pull Request Checklist

  • Pull request is based on the develop branch
  • Pull request includes a changelog file. The entry should:
    • Be a short description of your change which makes sense to users. "Fixed a bug that prevented receiving messages from other servers." instead of "Moved X method from EventStore to EventWorkerStore.".
    • Use markdown where necessary, mostly for code blocks.
    • End with either a period (.) or an exclamation mark (!).
    • Start with a capital letter.
    • Feel free to credit yourself, by adding a sentence "Contributed by @github_username." or "Contributed by [Your Name]." to the end of the entry.
  • Code style is correct (run the linters)

@Johennes Johennes force-pushed the johannes/msc3768-notify-in-app branch 2 times, most recently from 848e221 to 5f921e4 Compare July 23, 2025 13:55
@Johennes Johennes force-pushed the johannes/msc3768-notify-in-app branch from 5f921e4 to 948514a Compare July 24, 2025 09:09
@Johennes Johennes marked this pull request as ready for review July 24, 2025 09:44
@Johennes Johennes requested a review from a team as a code owner July 24, 2025 09:44
@Johennes Johennes force-pushed the johannes/msc3768-notify-in-app branch from 948514a to 389a870 Compare July 24, 2025 10:20
@@ -154,6 +154,9 @@ def check_actions(actions: List[Union[str, JsonDict]]) -> None:
# ignored (resulting in no action from the pusher).
if a in ["notify", "dont_notify", "coalesce"]:
pass
# In-app only notification as per MSC3768
elif a == "org.matrix.msc3768.notify_in_app":
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"org.matrix.msc3768.notify_in_app" should be a constant; along with the others but we should at-least do good with this new one for this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added one for org.matrix.msc3768.notify_in_app in 4215344. I can also add constants for the other three if you're ok with the PR growing a bit? Looks like it'd be 30 to 40 occurrences to replace.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can also add constants for the other three if you're ok with the PR growing a bit? Looks like it'd be 30 to 40 occurrences to replace.

I'd be fine with it but for the sake of others trying to follow along on this PR we should do it separately if you're keen.

@@ -174,6 +174,9 @@ pub enum Action {
Notify,
SetTweak(SetTweak),

// In-app only notification as per MSC3768
NotifyInApp,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to handle this at this spot given "org.matrix.msc3768.notify_in_app" shouldn't result in push notifications?

// Filter out "dont_notify" and "coalesce" actions, as we don't store them
// (since they result in no action by the pushers).
.filter(|a| **a != Action::DontNotify && **a != Action::Coalesce)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, I think this should stay as it is. The doc comment for run says:

/// Returns the set of actions, if any, that match (filtering out any
/// dont_notify and coalesce actions).

dont_notify and coalesce are probably removed because they are literally equivalent to an empty actions array. If we also remove notify_in_app here, I think that would lead to the event not causing any notification at all?

@Johennes Johennes requested a review from MadLittleMods July 25, 2025 14:27
@@ -0,0 +1 @@
Add experimental support for MSC3768 (push rule action for in-app notifications).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given this discussion on the MSC that this might be better suited as a responsibility of the client or OS, should this PR/MSC move forward? (seems like you agree with the points)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking that suppressing pushes on the server could be a MAY. It's relatively simple and saves at least some processing cost. So generally, I'd still like this to go ahead. However, for the sake of the MSC, we could also leave it in draft if you'd rather not merge it. Draft PRs are usually sufficient for the process, especially when they received reviewed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If leaving the PR unmerged is viable to you, that works for me. I'm not really convinced by the concept at the moment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean on the Synapse side or in general?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the current reasoning in the MSC, I'm not seeing the value of this proposal yet. The Synapse implementation appears technically sound, but I'm open to either:

  1. Not merging this PR if you agree, or
  2. Gathering additional perspectives to help us decide.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I see. No, I'm totally fine with not merging this. Just thought you might have feedback on the MSC.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moving this back to draft since it seems like functionally we're done. Thanks a lot for your review. 🙏

@@ -0,0 +1 @@
Add experimental support for MSC3768 (push rule action for in-app notifications).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If leaving the PR unmerged is viable to you, that works for me. I'm not really convinced by the concept at the moment.

Comment on lines +167 to +168
else:
pass # The spec doesn't forbid introducing custom actions
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previous discussion, #18720 (comment)

If we're doing this behavior and can justify it, we should just do it all the time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would basically make the whole function obsolete then?

Copy link
Contributor

@MadLittleMods MadLittleMods Jul 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like mostly. I think we could still validate known rules like set_tweak 🤷 although an unknown variant should also pass by according to the spec.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. 🤔

Well given that we won't merge this at the moment, I'm going to leave this unaddressed for now.

@Johennes Johennes marked this pull request as draft July 30, 2025 13:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants