~amolith added backend 10 months ago

~amolith added enhancement 10 months ago

~amolith 10 months ago

I doubt I'll get to implementing this until February or after, but a PR would definitely be welcome if you have time.

I don't know yet whether I want to depend on shoutrrr for this though; I was already considering it, but I haven't really dug into it yet to see whether it's a worthwhile dependency. I'll have a deeper look tomorrow and post my thoughts here.

Whoever ends up implementing it, I would want pretty comprehensive support in the config file, possibly along the lines of:

[notifications]
frequency =
enabled_providers = [ "ntfy", "email" ]

[notifications.ntfy]
endpoint = 
token =

[notifications.email]
host =
port =
encryption =
user =
password =
from =

~amolith 10 months ago*

I do think Shoutrrr is something I'm comfortable relying on for this. Looking more at how it works, the simplest way to integrate Willow's config with Shoutrrr's config might be for us to have an array of notification URIs; Willow could just loop through the array and pass the URI strings to Shoutrrr's Send() function.

[notifications]
frequency =
providers = [ 
    "ntfy://username:password@host/topic",
    "smtp://username:password@host:port/?from=fromAddress&to=recipient1,recipient2"
]

We can also do some of our own "understanding" of Shoutrrr URLs and add features specific to each platform. For example, we might check the scheme of the string and set the title of a ntfy:// notification to $PROJECT has a new update, add a button through the actions parameter that would tell Willow to actually perform the update for us (when we eventually™ add that feature), and set the click parameter to open Willow's web UI.

~amolith added backlog 9 months ago