Notification support via Apprise

[enticedwanderer]

Is your feature request related to a problem? Please describe. Rather than spend time on adding support for individual notification channels, it would be much more practical to add support for a pubsub proxy let users route all notifications to channels of their own choice.

Describe the solution you'd like Apprise is already a very capable publishing proxy with tons of supported channels. It can be run within the same docker compose or completely separately, completely decoupling notification needs from the core of what Overseerr provides.

Describe alternatives you've considered Current path of adding native support for all channels inline with Overseerr is expensive to add/maintain and requires effort that could be spent elsewhere.

Additional context Would you be open to a PR contribution?

[samwiseg0]

I disagree, this would be trading one issue for another. This would put all your eggs in one basket vs having a proper integration with multiple providers. I think that native support for each major provider is the way to go long term. The notifications within each provider are not going to be close to the quality of native integration.

[enticedwanderer]

Agreed that it is a trade off between availability and flexibility when considering that with the proxy layer going down you cut off all notifications flowing through it. However, outside of that, I don't see a reason why the fidelity of the proxy layer would be an issue compared to "native" clients. Perhaps I'm missing something but, for example, Appraise is just a shim around all of those native implementations that allows you to offload the configurations for them and call a central endpoint that knows how to deliver arbitrary payloads.

The way I see it, you could gain 60+ notification channels with just a single integration rather than pursue 60+ integrations independently. Another example of this is that different channels, come and go every day; it's not likely you will be integrating with random channels users request constantly.

Real world example is that I wanted to add Mattermost notifications to my local overseerr but the only option is to use the existing slack channel which is not directly compatible from what I can tell (mattermost rejects it). With something like Appraise, Overseerr would package the payload but not care what the channel is, let the user pick in Appraise to which channel it's delivered and how through config.

Not a big deal either way, just thought the project could get a great boost/integration point by going in this direction, which is why I suggested it.

[samwiseg0]

Real world example is that I wanted to add Mattermost notifications to my local overseerr but the only option is to use the existing slack channel which is not directly compatible from what I can tell (mattermost rejects it). With something like Appraise, Overseerr would package the payload but not care what the channel is, let the user pick in Appraise to which channel it's delivered and how through config.

This is a good example of why I think supporting this is not a good idea. Many notification engines allow for incoming webhooks. Mattermost is a perfect example. Adding the ability to create your own custom webhook will allow most services to work. We don't have to create every single integration. We just need to hit the major ones and then make sure we also have the ability to send generic webhooks just like Tautuli does today. The ability to create custom webhooks is a planned feature.

[ankarhem]

How does apprise handle rich text in notifications? I have a hard time trying to figure out if that's possible?

[sct]

How does apprise handle rich text in notifications? I have a hard time trying to figure out if that's possible?

This is my concern as well. Glancing through the docs I don't see any way to really customize how the messages are sent to each service.

When we do our own implementations we can customize the message format to best fit the service. Discord is using RichEmbed, Slack using their new Block Kits, mail using our mail templates. I don't see how this can be achieved with Apprise?

[enticedwanderer]

How does apprise handle rich text in notifications? I have a hard time trying to figure out if that's possible?

This is my concern as well. Glancing through the docs I don't see any way to really customize how the messages are sent to each service.

When we do our own implementations we can customize the message format to best fit the service. Discord is using RichEmbed, Slack using their new Block Kits, mail using our mail templates. I don't see how this can be achieved with Apprise?

These are great points, and I think that's what I was missing. The unstated assumption is that there are no differences in the payload across channels, i.e. they wouldn't be rich text. Apprise only repackages the envelope and from what I can tell cannot transcode the payload formats. To do so, would likely require it to understand and parse all the formats natively and provide (likely) lossy translation since not all formats are equal in their capabilities. If the notifications are plain text, then Apprise or equivalent would work, but for rich text or any interactivity, especially callbacks it isn't capable.

I also didn't realize this until looking at their docs in more depth. So if rich text is desirable, this is not tenable, and direct native implementations are the only way to go. I then also agree that down the line, custom webhook support in Overseerr would be more practical so users can adopt the payloads into Apprise or anything else as desired in a more structured manner (provide raw structured data/metadata and let the user formulate the best template/message from it).

[caronc]

Hi,

I don't generally get a lot of constructive feedback about Apprise, so I usually have to search out and find it (and do this quite regularly). I came across this thread tonight and just to be up front: in no way trying to convince you to use Apprise. :slightly_smiling_face:

But if i can at-least answer a question/unknown I see here to help out (spoiler!! -> yes it will be a bias response - please forgive me).

How does apprise handle rich text in notifications? I have a hard time trying to figure out if that's possible?

• Apprise supports markdown, html, and text. If you're using the CLI, then it defaults to text unless you otherwise change this using a --input-format or (-i) switch.
  • Basically every upstream endpoint supports 1 or more type (email just supports html and text) where as SMS messages only support text. Telegram expects markdown or html, etc, Slack supports text and markdown, etc...
  • Apprise is smart enough to convert the input to the matching output depending on the service you're using. All services have a default setting (so Email for example defaults to html). But you can easily over-ride this too. Apprise can take markdown and convert it to HTML prior to delivery, for example if it knows what you're feeding it. Similarly it can format text into html if required as well (depending on the upstream service)
• Apprise also handles all situations where message lengths are important too. For example an SMS message can't exceed 160 characters where as Email has no limit. Twitter sits at 280 characters today, Discord has a 2000 character limit, and the list goes on. Apprise can format the message so it will always fit the other end (breaking the message in parts if it exceeds the limits or simply truncating it all and only sending one message. It can also just pass the content as-is and let the upstream service deal with it.
• Apprise also respects that you (the developer) may want to do your own payload manipulation, your own truncating, formatting, etc. if you're a developer using the library directly, by default it does not interfere or manipulate what it is passed in anyway at all (data in is effectively data out). But all of what is discussed above (splitting, truncating, identifying the output and/or input format, etc) can be easily set on a per-need global or individual basis.
• Users who've added more then notification service they use can leverage the asyncio and have everything notified concurrently (and not in sequence).

So Yes, to answer your question: Apprise can and will manage the payload options for you.

This would put all your eggs in one basket vs having a proper integration with multiple providers.

But what is a proper integration?

• Perhaps it's reading on-line API docs and spending several hours/days to write a Python file/library with all of your logic in it:
  • handing of html, markdown, or text
  • truncating/splitting larger messages
  • dealing with API upstream version changes when they come.
  • Maybe get fancy and add attachment support.
• Perhaps it's increasing your projects dependencies with libraries (and their dependencies) your end users may or may not use?
  • You'll likely only use 25% of the library you pull down in most cases for just the users that do want to leverage this specific notification service.
  • You'll still have to write your own if/else logic wrapping one library to another while you format the payload you want to pass into it while deciding which service to notify (if you support more then one).
• In either case above, you'll have to create a form/input mechanism that is unique per service you add support for (capturing the users API Key, channel names, streams identifiers, target email addresses, etc.

I saw this, challenged it, and solved it (and I did it for every service I possibly could). Everything is a single maintainable file without the overhead of the custom bulky library that would otherwise go with it on a per service basis. I also pulled off 100% code coverage of the entire project and all of the supported services (this took months).

Adding the ability to create your own custom webhook will allow most services to work.

Unfortunately you'll learn that every single service you chose to support (literally every one) will require their own webhook contents, arguments, and options. Each one will require very different (HTML) Header information as well during the HTTP POST. Some will pre-require you to authenticate and get a token that you'll use for subsequent calls, etc. So this may not apply for everything, but I have no doubt you'll make something creative and it will work well!

Anyway... again, please take all of this with a grain of salt. I only want to spread the love (lol) :heart: :slightly_smiling_face: . My bias opinions are that of my own. I'm a very active developer and am more then happy to help and add any feature/function I'm missing to Apprise if it will help someone and/or their project out (including yours)!

My constructive feedback from all of this thread (and the reason I'm bothering you all :wink: ) is to increase my documentation. The lack of Apprise documentation is my own fault.

p.s. Sorry for writing so much!

[sct]

Hi @caronc thanks for the input!

Correct me if im wrong, because I don't know all that much about Apprise. But isn't everything you are proposing need to be done by deploying and customizing Apprise ourselves? We publish Oveseerr as an all in one container. We have no plans to make it more difficult to deploy this project than simply launching that one container. We also are not a python project, so including it as a dependency is just not possible.

A few of the people who have suggested we use Apprise keep bringing up the fact that they can run their own Apprise container and we just push notifications to that. But then, doesn't the burden of deployment/setup and rich formatting lie on the user implementing Apprise? What does that do for our less experienced users? We still end up having to build our own notification agents anyways for them. That also increases the deployment complexity of Overseerr. Something we want to avoid.

Unfortunately you'll learn that every single service you chose to support (literally every one) will require their own webhook contents, arguments, and options. Each one will require very different (HTML) Header information as well during the HTTP POST. Some will pre-require you to authenticate and get a token that you'll use for subsequent calls, etc. So this may not apply for everything, but I have no doubt you'll make something creative and it will work well!

The suggestion here is a custom webhook which allows the user to design a JSON payload to their liking and have that sent to wherever they like. (It could be sent to their own Apprise setup in a format Apprise expects)

Unfortunately, I don't see Apprise making anything easier for us. I am welcome to more feedback though or if you have other ideas. It's possible I still am missing something!

[caronc]

Unfortunately, I don't see Apprise making anything easier for us. I am welcome to more feedback though or if you have other ideas. It's possible I still am missing something!

I fully respect your point of view. All I can add is a brief description of how you might perform the implementation with little to no code changes and/or complexity on your part.

So Apprise is a standalone CLI tool and/or Python Library. But I also put together a docker container as well which might be what you're requests were relating to... I'm not sure... The container supports persistent and non-persistent storage setup allowing users to park all of their notification configuration in one place. But for a very simple solution, and using the Apprise container at it's most basic level, your Docker container might introduce something like:

# New Environment Variables (if left blank or not defined, then don't use them):
APPRISE_SERVER=http://myserver.local:8000

# Comma (and/or space) delimited, add as many as you like (up to 65+ options today)
APPRISE_URLS=mailto://user:pass@hotmail.com, discord://token-details, etc

Then (on your side), if these environment variables are defined, you would just have to do the following:

# Send your notifications directly (use Go, Python, PHP, whatever); here is a curl example:
curl -X POST -d 'urls=mailto://user:pass@gmail.com&body=test message' \
    http://localhost:8000/notify

# Or send your notifications directly using JSON:
curl -X POST -d '{"urls": "mailto://user:pass@gmail.com", "body":"test message"}' \
    -H "Content-Type: application/json" \
    http://localhost:8000/notify

# Hence (with respect to your variable you might introduce), your call might be:
curl -X POST -d '{"urls": "${APPRISE_URLS}", "body":"test message"}' \
    -H "Content-Type: application/json" \
    ${APPRISE_SERVER}/notify

There are a few other options you can pass into the post, but this is the most basic. Based on your previous comments and the ability to provide some rich text experience, you might also pass in format=markdown or format=html implying that that is what your input is (the body). Apprise will automatically handle the upstream provider knowing this information.

The Apprise Persistent storage solution changes things around a wee bit, but it's another approach too. In this case you don't need to define the APPRISE_URLS on your end. This way is a bit more security this way since users don't have to have their notification credentials being passed over the network. If you're interested in this approach, I can explain it in detail too but I know I talk/write to much as it is, so I'll end here for your thoughts :slightly_smiling_face:

[mouzzampk2014-zz]

Recently Hydra2 developer added Apprise too and its look like that

So basically body template picks the default template and then let users choose if they want to change it or not. I never changed it as default template is good enough.

And I am calling this inside container as an environment and thats all

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.