Better push notifications

[sorin-davidoi]

Welcome notification

When the push subscription is registered, we currently send a welcome notification to verify that the endpoint is valid. I think this should allow the user to actually enable push notifications - makes them more likely to use the feature. We should probably also use the occasion to explain that they will work even if Mastodon is not open.

Integrate with the onboarding modal

Showcase the feature and allow the users to enable it - only if it is supported on the device.

Integrate with active session

Would show an icon next to the session if a push subscription is associated with the given session. Maybe even a button to send a test notification to that device.

Integrate with admin feature

When #1209 is implemented, maybe it would make sense to provide a checkbox to send push notifications to all users on the instance.

Payload too big

The specification requires push providers to accept a payload of at least 4 KB. This is not handled at all right now, pushing a bigger payload will silently fail. We should construct the payload, measure its size, and if it is too big we should trim the body of the notification.

Confusion regarding notification types

Users will be confused: what is the difference between desktop notifications and push notifications? If both are enabled, they will receive the notification twice (deduplicated by the OS since they have the same tag but still confusing). Best thing would be to have just one toggle in the UI and use push notifications when available and standard ones as fallback.

Grouping

If you wake up and turn your WiFi on, you will be bombarded by all the notifications that you received over night. Not true, see comment. If you received more than a couple, it can be overwhelming - and annoying.

I think that if you have more than a fixed number (four or five should do it) of notifications, they should be grouped:

• Title: "N new notifications'
• Body: Concatenation of the titles of the notifications (e.g. "X mentioned you \n Y favorited your status \n Z boosted your status")
• Actions: just the default - clicking it takes you to the notifications page

[beatrix-bitrot]

Please have clicking a notification open the status in the existing tab if there is one! Thanksssss~

[clworld]

Is it possible to make this usable from 3rd-party apps?
Currently some app does it by providing additional server listening streaming-api.
(for example:
tusky-api https://github.com/Gargron/tusky-api
mastodon-streaming-listener https://github.com/tateisu/mastodon-streaming-listener)
(App maintainer still need WebPush -> FCM bridge but It's maybe simpler than listening streaming-api I think.)

[sorin-davidoi]

Should be doable, the entire implementation is based on open standards. I guess they need to host the push service themselves (e.g. https://github.com/mozilla-services/autopush).

[clworld]

@sorin-davidoi
Is it usable from 3rd-party apps already?
I think some problem exists to use it from 3rd-party apps.

• Web::PushSubscription is tied with sessions. 3rd-party apps does not have session as I know.
• /api/web/push_subscriptions is for Web UI and not for 3rd-party apps. API endpoint like /api/v1/push_subscriptions is needed for 3rd-party apps.
• applicationServerKey(VAPID public key) is provided only on home_controller. It can't be seen by 3rd-party apps. (Is it should be provided on /api/v1/instance ?)

[sorin-davidoi]

3rd-party apps does not have session as I know.

Did not know that.

/api/web/push_subscriptions is for Web UI and not for 3rd-party apps

True, but that endpoint does not care who operates the push endpoint it receives - could be browser vendors or application developers.

applicationServerKey(VAPID public key) is provided only on home_controller

True, that should be exposed via an API.