go-vikunja
[Feature request] Integrate with Gotify or use webhook for notifications
Original issue by SteveDinn on 2021-06-02T16:03:07.000Z
Much of the time email is not the best solution for notifications. It would be great if Vikunja could allow different types of notifications.
Suggestions:
- Integrate with a well-established open-source push notification solution like Gotify
- Allow notifications by webhook: Allow each user to configure a a URL that could accept a POST call with some JSON containing information about the task.
@kolaente commented on 2021-06-02T21:17:56.000Z:
Ideally, you'd have a client which just fetches all reminders from the api and then figures out at what time to show you the reminder on your device without requiring the device to be online at that time. In fact, the PWA is already capable of that but you'll have to enable a chrome flag to be able to use it.
General webhooks are planned though. It should be possible to connect something like Gotify to these once they are ready.
SteveDinn commented on 2021-06-03T13:48:52.000Z:
Whoops...didn't mean to accidentally close this issue.
bolgrov commented on 2021-07-11T14:38:34.000Z:
+1
In my opinion, I think Vikunja is an already highly capable planner application with features that are paid in other closed-source apps or even lacking. It is extraordinary how basically one person has built such an encompassing application.
However, I must note that it is almost funny the fact that with all complex features, Vikunja lacks greatly in notification capabilities which, in my opinion, is a crucial factor for new users cavitation. It should be of paramount importance to be able to get desktop and phone notifications and Vikunja would greatly gain with this addition.
Thank you !
@kolaente commented on 2021-07-11T15:28:15.000Z:
I still think reminders should be mostly a responsability of the client application. If I need to be online (as would be the case with gotify) that's not an ideal solution. Because of that I was always of the opinion that reminders would be a thing done by the flutter app so I didn't really pushed further with that. Now the problem is the flutter app does not work and probably won't for a long time so that's not a great solution (at least for now).
That's why I started moving more of that notification logic to the frontend. The new chrome feature for scheduled notifications is pretty much what I had in mind for that so I added support for it to the frontend. I know it's not perfect but I hope it's a step in the right direction. Maybe that could be expanded to also work in browsers which don't have support for scheduled notifications (yet).
I'm using the PWA and that works great for reminding me of tasks I set reminders for. The tasks.org app also does the same and from what I heard, it does a good job at it.
If none of these are an option, there's still email reminders.
SteveDinn commented on 2021-07-11T15:55:34.000Z:
My intention, when writing this feature request, was specifically for mobile notifications. If there is a way to do this already, I'll try it.
With webhooks, I was also thinking about integrations with other apps (i.e. HomeAssistant)
bolgrov commented on 2021-07-11T16:06:25.000Z:
I still think reminders should be mostly a responsability of the client application. If I need to be online (as would be the case with gotify) that's not an ideal solution. Because of that I was always of the opinion that reminders would be a thing done by the flutter app so I didn't really pushed further with that. Now the problem is the flutter app does not work and probably won't for a long time so that's not a great solution (at least for now).
That's why I started moving more of that notification logic to the frontend. The new chrome feature for scheduled notifications is pretty much what I had in mind for that so I added support for it to the frontend. I know it's not perfect but I hope it's a step in the right direction. Maybe that could be expanded to also work in browsers which don't have support for scheduled notifications (yet).
I'm using the PWA and that works great for reminding me of tasks I set reminders for. The tasks.org app also does the same and from what I heard, it does a good job at it.
If none of these are an option, there's still email reminders.
I completly understand your point, however I was mostly referring to notifications on desktop because I'm aware that the mobile implementation is not finished and notifications are not possible in my case because I refrain from using Chrome and only use Firefox on mobile.
I was actually referring to at least having a good desktop notification implementation (besides email) because I do not get notifications at all (note that I do not the remind by email activated). I would expect that at least a notification would pop up in the browser or desktop app when the reminder for a tasks is due. Another thing that I also miss is the ability to set a default reminder for tasks with a due date: for example in the settings having the ability to choose a default time (10 min, 30 min, 1 hour) to get a automatic reminder before a tasks is due without having to specify a reminder.
Keep up the fantastic work !
@kolaente commented on 2021-07-11T17:43:29.000Z:
I've added an item to the backlog to make notifications also available on other browsers while it is open (I think there's no other way to solve this otherwise).
bolgrov commented on 2021-08-16T09:29:29.000Z:
Hello @konrad ,
Could Vikunja parse all the tasks that had a due date has a CalDav address so that it could be imported any calendar app and in this way get alerts for all tasks with due dates set ? This could be a temporary workaround if it is easy to implement.
Have a nice day !
@kolaente commented on 2021-08-17T19:34:29.000Z:
@bolgrov We had read-only caldav links per list - might add that back in. It would only include the tasks and their due dates, and they weren't compatible with VTODO so they would only work in a calendar, not a task manager client.
bolgrov commented on 2021-08-18T09:19:57.000Z:
@bolgrov We had read-only caldav links per list - might add that back in. It would only include the tasks and their due dates, and they weren't compatible with
VTODOso they would only work in a calendar, not a task manager client.
I was actually referring to something like that, because I don't need the tasks to sync with another task manager because we've already seen that the WedDav protocol doesn't allow for some important things to be synced between for example Vikunja and Tasks.org. So what I was really proposing is just a way of generating a Calendar through CalDav so that one can integrate it with its calendar app or even subscribe to with Nextcloud or Thunderbird and this would have the advantages of:
- Seing your tasks with due dates set along your calendar events for easier management
- Getting notifications for tasks with due dates !
Although this would not work for tasks with reminders I think its a great temporary solution. Cheers !
bolgrov commented on 2021-08-30T09:23:51.000Z:
Hello @konrad !
Still on the topic of CalDav integration, I think this would add value to the application by basically providing a simple way of adding time blocking to Vikunja !
Please note that this should not replace the eventual notification development to be able to notify on web, desktop or mobile (with Gotify or other way). But could be and option in the settings people could use to subscribe to a Calendar of Vikunja, just like in Todoist you can syncronize with Google Calendar. The advantage here, is that since Vikunja lets one set Start and End dates the time blocking would be automatically generated to your calendar for extra productivity !
Have a nice day.
@kolaente commented on 2021-08-30T18:31:09.000Z:
@bolgrov Yeah that's in the backlog.
xeruf commented on 2022-09-07T22:59:05.000Z:
I heartily agree with @bolgrov this is such an elementary feature! My boss still loves to use the calendar to plan tasks, leaving Vikunja dormant most of the time, which this could remedy!
To get to the original topic, yes I would also want to have a generalized notification gateway so I can send them to zulip for example. Gatus solved this quite well by allowing a custom notification configuration to integrate with your favorite provider: https://github.com/TwiN/gatus#configuring-custom-alerts Which somebody then set up with Gotify: https://github.com/TwiN/gatus/issues/239#issuecomment-1013853494
dpschen commented on 2022-09-08T08:55:02.000Z:
Just dropping this here for later reference:
I stumbled over Novu (was trending in GitHub). ~~Currently they don't have a Go implementation but they intend to build one later juging from this screenshot:~~
EDIT: They have a implementation in go although a bit outdated.
It seems to me that this is the kind of service that would make sense for us So it might take a while until it would be useful for us.
I don't know Gotify, so this is really just a future reference ;)
@kolaente commented on 2022-09-08T11:42:28.000Z:
Novu looks very interesting. Only downside is it's written in nodejs and doesn't seem to offer a way to integrate with a webhook or similar.
There's an item in the backlog to integrate Apprise (which supports gotify) as a notification target. Mostly because it can be used as an external service and as a target for a webhook.
The way notifications are implemented in the api should allow for almost-easy integration of other targets (right now only mail).
AquaWolf commented on 2022-12-26T14:26:35.000Z:
I don't know if this suits but I saw this on selfhosted subreddit: https://github.com/svix/svix-webhooks
xeruf commented on 2023-01-04T04:23:07.000Z:
I guess this could also be covered by n8n: https://kolaente.dev/vikunja/api/issues/1249
bolgrov commented on 2023-01-04T10:21:32.000Z:
I guess this could also be covered by n8n: https://kolaente.dev/vikunja/api/issues/1249
This looks very interesting, thanks for letting me know of n8n ! I guess if this could connect to gotify, or even ntfy (so that users just didn't have to selfhost gotify), then we could have notifications for all users.
However, in my opinion, I see this more as a workaround than an actual solution. Because, and correct me if I'm wrong, the easiest way users of Vikunja could get notifications on their phones would be to install ntfy. This is subpar when compared with hypothetical native notifications.
But I do want to point out that n8n integration is something I'm now looking up to 💯 !!
@kolaente commented on 2023-01-04T11:19:25.000Z:
However, in my opinion, I see this more as a workaround than an actual solution. Because, and correct me if I'm wrong, the easiest way users of Vikunja could get notifications on their phones would be to install ntfy. This is subpar when compared with hypothetical native notifications.
Yes it is a workaround until we have a proper solution for this particular feature request. The n8n integration is still very useful for a lot of other things though.
Apologies if this is retreading old ground, but has there been any thought about using the Web Push API for push notifications? It seems like a good fit, given that the primary app at the moment is the PWA. I suspect this wouldn't be very challenging — mostly a matter of adding something like https://github.com/SherClockHolmes/webpush-go to the backend, and some simple PushManager code to the PWA/web client. I've implemented this for other self hosted apps, and would be happy to give it a shot if you're open to a PR!
I'm also seeing that there's some preference for having the client manage push notifications, rather than the server. I think this would be even simpler, if that's the desire — the client can just schedule its own push notifications through its service worker, without any backend integration needed. It may be nice to have both (with some deduplication), in case a reminder is added by a peer that hasn't been synced locally yet, but either approach is probably fine to start.
I'd love an implementation locally in the client, since that will work offline (which will become more important once we'll implement offline capabilities). With offline sync later, we'll have a way to get reminders created on another client as well.
:sigh:. So unfortunately this isn't an option for the PWA. There is no offline-only/client-side mechanism to reliably deliver notifications from a PWA at an arbitrary time in the future, if the user has closed the PWA. The only system for "waking up" a PWA on demand is with the Service Worker Push API, which must be triggered by a server. Sorry, I should have looked closer before proposing it.
@kolaente would you be open to an approach that relies on the Push API? A client-only/offline approach will, unfortunately, only be possible with a native mobile app — in the meantime it might be nice to have this functionality, even if it only works when online?
@smoores-dev no worries! There was an experimental browser API a few years ago which could be used to schedule notifications offline. This worked, but unfortunately the API never got out of the experimental phase and was ultimately removed.
Since the web push API is the next best thing we have, let's go with that instead. Would love a PR.
Some thoughts on implementing this:
- Web Push should be a new notification target (we currently have mail and db). That way it will be possible to re-use pretty much all of the existing notifications without effort.
- There should be a setting for users to enable this (in the web ui, per device)
- What's required to push notifications from the server to the client? A websocket? SSE? Something else? Ideally, this should work out of the box without relying on an external service or extra steps. If it needs either a websocket or SSE, let's go with websockets since there are other features planned which will require one anyways.
@smoores-dev no worries! There was an experimental browser API a few years ago which could be used to schedule notifications offline. This worked, but unfortunately the API never got out of the experimental phase and was ultimately removed.
Since the web push API is the next best thing we have, let's go with that instead. Would love a PR.
❤️ 👍
Some thoughts on implementing this:
- Web Push should be a new notification target (we currently have mail and db). That way it will be possible to re-use pretty much all of the existing notifications without effort.
Makes sense, sounds good.
- There should be a setting for users to enable this (in the web ui, per device)
Sounds good. We'll need to add a new database table to store push subscriptions in. It should be pretty simple (id, userid, endpoint, expiration, keys). The flow would be, I think:
- User opens the settings page in the UI
- User selects the "Send me reminders via push notifications" checkbox
- User presses Save (new setting is saved to backend)
- Browser/OS prompts user to allow notifications
- User accepts notifications
- PWA generates a push subscription (
registration.pushManager.subscribe()) and sends it to the backend - Backend creates a new push subscription row
Then, later:
- Notification is triggered
- Backend sees notification target includes push
- Backend retrieves all VAPID subscriptions for the user
- Backend uses webpush-go to send push notifications for each subscription
- What's required to push notifications from the server to the client? A websocket? SSE? Something else? Ideally, this should work out of the box without relying on an external service or extra steps. If it needs either a websocket or SSE, let's go with websockets since there are other features planned which will require one anyways.
None of the above! Notifications all end up being distributed through OS-specific push notification services (Firebase for Google devices, APNS for Apple devices, Mozilla's Push service for Firefox on Desktop, etc). The browsers/OSes maintain their own connection to those push services, and the push subscription info contains an endpoint to send the push notification to.
The only thing needed from server admins is some additional configuration for VAPID (the protocol that push services use to identify servers). VAPID requires a subject, public key, and private key, which can be provided as environment variables/configuraiton.
This has the downside of being reliant on third-party notification services (though, this is also how all app notifications work, so 🤷), and the upside of working even when a client device can't connect to the Vikunja server, as long as it can still connect to the push server.
We'll need to add a new database table to store push subscriptions in.
Can't we use the already stored notifications? Or would you need this for the settings?
Backend retrieves all VAPID subscriptions for the user
Ah would that (the VAPID) be what will be stored in the database?
The only thing needed from server admins is some additional configuration for VAPID (the protocol that push services use to identify servers). VAPID requires a subject, public key, and private key, which can be provided as environment variables/configuraiton.
Does that mean admins would need to register with Firebase or APNS?
We'll need to add a new database table to store push subscriptions in.
Can't we use the already stored notifications? Or would you need this for the settings?
Backend retrieves all VAPID subscriptions for the user
Ah would that (the VAPID) be what will be stored in the database?
Right, this is how VAPID works. There's a unique endpoint for each device, which needs to be stored in the database when that device creates a subscription. So we need to store a new database row for each device that will be receiving push notifications.
Does that mean admins would need to register with Firebase or APNS?
Nope! This is all done transparently through the device subscription creation flow. The user indicates that they would like to create a subscription for a registered service worker, the device generates a unique endpoint for that service worker for that device, and registers it with the relevant notification service. That gets sent to the backend, and the backend can use VAPID to send push notifications to that device via that endpoint
Nope! This is all done transparently through the device subscription creation flow. The user indicates that they would like to create a subscription for a registered service worker, the device generates a unique endpoint for that service worker for that device, and registers it with the relevant notification service. That gets sent to the backend, and the backend can use VAPID to send push notifications to that device via that endpoint
Sounds pretty straight-forward then!
How sensitive are these credentials? Should we encrypt then when storing? Or wouldn't that make sense because an attacker who has access to the database would be game over anyways
So VAPID uses private/public encryption keys to sign push notification requests. The client sends the public key to the push service, and the push service uses that key to verify that notifications coming from the backend are legitimate. As such, the actual endpoints aren't sensitive, but the private key is. It should be treated with the same amount of ceremony as any service secret, but I think that's already covered by paying it through an environment variable or the config?
Where would that secret come from? I thought admins would not need to configure one to use Web Push. Or does the server generate it?
It's fine if stored in config.
Sorry, I mentioned it earlier but there was a lot of info haha. VAPID requires:
- A subject (this should be the server admin's email address)
- A private key (used to sign and encrypt the push notifications)
- A public key (used by the client/push servicce to decrypt/verify the notification)
So server admins that want to use web push will need to generate a key pair. There are tools like https://vapidkeys.com/ that can help with this.
We could also generate the keys automatically (webpush-go has an API for this), but then we have to be responsible for saving them (presumably in the database).
What do you think?
A subject (this should be the server admin's email address)
Does it have to be the email address?
We could also generate the keys automatically (webpush-go has an API for this), but then we have to be responsible for saving them (presumably in the database).
I think we could add a cli command to generate the keys - it would then just show them to the admin and tell them how to configure it. If we want to make it really fancy, we could also adjust the configuration when running the command, but that won't work in environments where the config can't be edited (for example environment variables).
Does it have to be the email address?
Technically it can be an email address or a publicly accessible HTTPS domain that contains contact information for the application server administrator. I suspect that most users won't have the latter, so I think it makes sense to recommend the former, but we can support either. This is listed as optional by the VAPID spec, but in practice it's required by Apple and Mozilla. It's a good idea, too, as it can be used to allow push service providers to contact the admin if something it wrong with their push notifications (e.g. if someone is trying to impersonate them, for example).
I think we could add a cli command to generate the keys - it would then just show them to the admin and tell them how to configure it.
Cool, yeah this makes sense to me
