Skip to content

Is it possible to actively revoke already sent notifications from the server? #782

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

Open
2 of 6 tasks
skafau opened this issue Mar 14, 2025 · 3 comments
Open
2 of 6 tasks
Labels
question Further information is requested

Comments

@skafau
Copy link

skafau commented Mar 14, 2025

Have you read the documentation?

  • Yes, but it does not include related information regarding my question.
  • Yes, but the steps described in the documentation do not work on my machine.
  • Yes, but I am having difficulty understanding it and want clarification.

You are setting up gotify in

  • Docker
  • Linux native platform
  • Windows native platform

Question

I need my server to be able to actively revoke already sent notifications from all clients. By revoke I mean that the already shown notification should be hidden automatically w/o any user interaction.

Is this possible?

I did not find any information on this in the docs, so I guess it is not possible but I wanted to be sure.

My use case

I have a personal reminder app to which multiple clients are subscribed to (e.g. desktop pc & mobile). When interacting with the notification on 1 client, it should be removed/revoked on all other clients. E.g. when clicking on the notification on a desktop pc, it should be automatically removed on my mobile and vice versa.

Also:

  • The notifications shall be revokable from my server w/o any direct user interaction with any notification.
    E.g.: The notification has been sent to all clients. I don't click on any of the notifications but open the reminder directly within my web app -> All notifications shall be revoked.
  • If a client is offline whilst the notification is being sent and the notification is revoked before it comes online, the notification shall never appear on the client.

Some more context:

ATM I'm using web push in combination with a PWA. This works technically and allowed me to implement all the features I need (revokability etc.). However, notifications on Android are very unreliable. Some appear an hour after they have been sent by the server, some don't ever appear at all. I'm therefore looking for alternative ways to notify my clients.

@skafau skafau added the question Further information is requested label Mar 14, 2025
@eternal-flame-AD
Copy link
Member

It is not currently possible with just an application token, you need a client token to delete messages.

Regarding your issues on delay, I think it is likely your android app did not have battery saving turned off, did you do this ?

@skafau
Copy link
Author

skafau commented Mar 15, 2025

I'm very sure that I disabled all possible battery optimizations for my app (the installed PWA) and for Chrome (which kind of "runs" the PWA). Just FYI, I'm on a Pixel 8a with stock Android.

Regarding "... you need a client token to delete messages. ...":
Is this something I could manage/configure using the current version of your server & app or something which you'd need to build into the server (and client)?

@eternal-flame-AD
Copy link
Member

Thanks for the response.

We don't use PWA for android, that might be the reason for your delay because I don't think PWA is allowed to keep a websocket connection regardless of OS battery optimization, please try https://github.com/gotify/android

If you could have a setup that makes it acceptable to have a client token on the sender side (for ex. the sender is in a computer you control), you could just use the client token to delete the message yourself, otherwise patching the access control might be needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Development

No branches or pull requests

2 participants