[Research] Look into simplifying notification channels #1620
Description
@alexjustesen I do wanted to have a look to simplify the notifications as some are similar. And maybe optimize the page as well. Let me know what you think
☺️
Originally posted by @svenvg93 in #1578 (comment)
Extracting our conversation to its own issue...
Yes, I want to go through and looks for optimization opportunities as well. We have a bunch of webhook based notifications that could probably be consolidated and where possible I want to do it "the framework way".
Laravel provides out of the box support for various notification channels and there are even more maintained 3rd party channels that could potentially make the code base simpler.
Metadata
Metadata
Assignees
Projects
Milestone
Relationships
Participants
Activity
svenvg93 commentedon Jul 22, 2024
When I was looking for ntfy integration I did found a third party one https://github.com/wijourdil/ntfy-notification-channel.
Didn’t use it as I wasn’t sure if third party is the way you wanted it. As it makes it dependent of others to keep things working
alexjustesen commentedon Jul 22, 2024
I'm ok with 3rd party deps as long as the follow/hook right into the framework notification pattern and are actively maintained.
"Actively maintained" means updates within the last year.
svenvg93 commentedon Jul 30, 2024
This might be outside of my capabilties 😉 I will leave this up to the more skilled developers to do it right ;)
alexjustesen commentedon Jul 30, 2024
I'll take a whack at it at some point, I've been super busy with non-code stuff lately so it's been tough to find time to work on speedtest tracker.
svenvg93 commentedon Aug 14, 2024
Otherway might be to integrate Apprise https://github.com/caronc/apprise . As it hooks in to basically every service out there. No need to maintain it yourself.
bwirt commentedon Sep 24, 2024
+1 for Apprise
svenvg93 commentedon Sep 24, 2024
Not sure Apprise will work after more investigations, there is no Php libary to use, and requiring the users to run a additional app for the notifications seems the wrong way to do it. Installing it within the container using pip and calling it with system() seems a bit weird to do as there are php frameworks for most services.
bwirt commentedon Sep 25, 2024
Doesn’t need to be a requirement but is a nice option if feasible.
I’m already running an Apprise container which basically functions as a notification proxy so I only ever have to configure email, Signal, telegram, whatever else just one time in one place.
There may be a way to do this with the webhook already, though it’s not clear how to use this or set POST body, etc. Will explore when I have time.
armond-avanes commentedon Dec 5, 2024
I have the same configuration to centralize all my notification setup in a single Apprise API container:
https://github.com/caronc/apprise-api
+1 for Apprise (or Apprise API) support.
etuck commentedon Apr 17, 2025
Another +1 for Apprise. I think a majority of self-hosters are probably already running it.
alexjustesen commentedon Apr 17, 2025
Quick update on this, @svenvg93 and I are actively evaluating a pattern to implement Apprise to support additional notification channels. Expect the following to change:
svenvg93 commentedon Jun 4, 2025
@etuck @armond-avanes @bwirt As the Apprise experts, I’m looking for guidance on implementation. Currently, I have it set up so that you define the Apprise Sidecar endpoint (http://apprise/notify) and the service URL (e.g., discord://12345/1223445323).
Is there a need to configure multiple Apprise Sidecars? Are there any specific features or considerations you’d recommend for the implementation?
bwirt commentedon Jun 4, 2025
I’m not sure a sidecar is the best approach; I’d expect users of Apprise to already have an instance on their system, so you’d just need the ability to configure the endpoint and send a REST request for the notification. If there was just an option for a generic webhook that would work, and allow sending to other custom endpoints.
svenvg93 commentedon Jun 4, 2025
With Sidecar I do mean the instance running on their system. We do need tell the app where that instance can be found. As well as the endpoint to send the request to (discord etc).
armond-avanes commentedon Jun 7, 2025
@svenvg93 It's nice to see this great progress here! Just a question before I answer your questions... How have you implemented this integration? Is it through direct integration of
Appriselib/CLI (https://github.com/caronc/apprise) into SpeedTest-Tracker? OR you're just calling the Apprise RESTful API as a generic webhook?I'm asking this because if you've done lib/CLI integration and according to their documentation on their GitHub page (the first line of
Productivity Based Notificationstable content), you can just useapprise://[host]:[post]/tokenformat if a user has a standalone Apprise-API server/container to centralize all their notifications in one place (like what I do in my HomeLab). OR if another user just wants to directly deal with e.g. Discord without hosting Apprise API, they can usediscord://webhook_id/webhook_tokenformat. That's the whole point of this kind of integration. So even in the case of standalone Apprise API server, you don't need to have a separate URL for Apprise Sidecar and another for the Service URL. You just need one URL and you pass the URL to either the lib or the CLI and they will handle the rest for you. You should just mention on the UI that the format of the URL must match one of the supported URL schemas/formats in the Apprise docs (which means you'll have the support for 100+ notification types).In a more advanced use case, one might want to have multiple notifications (Discord, Telegram, a standalone Apprise API server, MQTT, etc) and you might want to support a list of URLs, but again the main point here is that all those URLs must be in one of the supported schemas and most probably you will have to have a separate call on the lib/CLI for each URL. This will provide the ultimate flexibility for your users which will cover any possible scenario; and you'll never need to touch the notifications again!
And finally a quick feedback for your implementation: The way you're representing it on the UI (which needs a URL to Apprise Sidecar/Server) is forcing users to have a standalone Apprise API server running in their homelabs which is very limiting in my opinion.
Hope I've been clear enough in my explanations. Please let me know otherwise, or if I'm missing something here.
svenvg93 commentedon Jun 8, 2025
Hi @armond-avanes,
Thanks for the feedback much appreciated!
The implementation is just calling the Apprise RESTful API in the format it expects. As mentioned by @alexjustesen earlier the end user will need to run the Apprise API themself (https://github.com/caronc/apprise-api). There is no direct integration of Apprise lib/CLI.
I'm still tweaking the UI part, but as the user needs to run the Apprise API, we need to tell the Speedtest Tracker where to find it 😄. Of course the user can specify multiple notifications schemas (Discord, Telegram, ntfy etc) to use, we will just loop thought them when sending the notifications.
armond-avanes commentedon Jun 8, 2025
@svenvg93 Is there any particular reason you've chosen not to directly integrate with its lib or CLI?
Don't get me wrong. This will actually work for me since I'm already running Apprise API. But I'm not sure it's a good idea to force users to install that server, just to get the support to send notifications to e.g. Discord, Telegram, etc.
Direct lib/CLI integration will eliminate this step (users won't be forced to have Apprise API) and it will be like you're supporting hundreds of notification channels directly! Just my personal opinion.
alexjustesen commentedon Jun 9, 2025
So this was an architecture decision that Sven and I chatted about pretty extensively. Essentially by not baking Apprise into the application it allows us to have separation of services, keep the Docker image lean and most importantly keep maintenance and support to a minimum.
My long term goal for this project is to provide the flexibility to integrate with just the services you need to meaningfully track metrics either because you're a data hoarder or you need to keep your ISP honest.
On a side note, it's really hard to know who's using what for features in the application without adding some tracking mechanism and I am ABSOLUTELY NOT DOING THAT.