l2g

I'm the original developer of Apprise. I started it back in 2017 as a way to give scripts and applications one common interface for sending notifications to services like Discord, Telegram, email, Gotify, Matrix, SMS providers, etc.

v2.0 is the first major overhaul in quite a while. Some of the bigger changes are template variables for keeping secrets out of configs, priority/escalation, smarter retries, parallel delivery, better result reporting, and authentication plus per-configuration access controls in the self-hosted Apprise API.

Apprise can be used as a Python library, CLI, or through the self-hosted API. There are currently 160 supported notification services.

Docs: https://appriseit.com/ API: https://github.com/caronc/apprise-api Release: https://github.com/caronc/apprise/releases/tag/v2.0.0

Happy to answer questions about the v2 changes or architecture.

I found the biggest complaints about Apprise were:

1) lack of documentation - fixed with https://appriseit.com

2) confusion around Apprise URL generation - now fixed with this enhancement! :)

Apprise (https://github.com/caronc/apprise hit 100M+ downloads and I just wanted to thank those who have adapted it into their systems!

  * Entirely a self-hosted solution.
  * Been around since ~2018; so it's had time to mature
  * Written in Python
  * 100% Test Coverage (over 51,000+ lines of code)
  * BSD-2 License
  * Over 15,600+ stars on GitHub!
  * Over 6.6M+ downloads a month on PyPi
  * Over 100M+ total downloads total on PyPi
  * The API version of Apprise has had more than 4.8 million downloads from Docker Hub
  * Use of this effectively centralizes your configuration for all applications and anything else into one single spot.
  * Supports more then 128 Services already (always adding more!)

Official Documentation Site (this is new): https://AppriseIt.com. It is also backed by a new open source repository all can contribute to at https://github.com/caronc/apprise-docs

A showcase of just some of the people who have adapted Apprise here: https://appriseit.com/contributing/showcase/

> no login

That's because the goal is to allow you to stick a proper nginx or webserver infront of it if you need this layer.

> Sometimes doesn't work

Please open a ticket and share why since your able to determine this from your logs. Maybe it can be fixed upstream?

> Secret storage is bad

You can create a string (key) that is randomized > 200+ characters. What can be improved to assist you with your concerns?

They're just used to test different Python environments with. 2 of them for RPM building and testing in RHEL 8 & 9.

They all play a roll with merge requests during (GiHub Actions) pipeline testing and code coverage.

Ntfy is a notification service. Ntfy is 1 of the 100+ notification services Apprise supports. Apprise is basically a switchboard for notifications; a one stop shop.

I finally achieved the milestone of supporting more then 100+ services and just wanted to share with with you all!

What is Apprise?

Apprise allows you to send a notification to almost all of the most popular notification services available to us today such as: Telegram, Discord, Slack, Amazon SNS, Gotify, etc.

  * One notification library to rule them all.
  * A common and intuitive notification syntax.
  * Supports the handling of images and attachments (to the notification services that will accept them).
  * It's incredibly lightweight.
  * Amazing response times because all messages sent asynchronously.

I still don't get it... ELI5

Apprise is effectively a self-host efficient messaging switchboard. You can automate notifications through: - the Command Line Interface (for Admins) - it's very easy to use Development Library (for Devs) - a web service (you host) that can act as a sidecar. This solution allows you to keep your notification configuration in one place instead of across multiple servers (or within multiple programs). This one is for both Admins and Devs.

A lot of systems have already adapted to it such as HomeAssistant, Apache Airflow, ChangeDetection, Uptime Kuma and many others (<https://github.com/caronc/apprise/wiki/showcase#integrations>) which shows the commonality. Mailrise is an incredibly talented program that converts Emails sent to it to trigger notifications via Apprise.

What else does it do?

1. Emoji Support (:rocket:) built right into it!

2. File Attachment Support (to the end points that support it)

3. It supports inputs of `MARKDOWN`, `HTML`, and `TEXT` and can easily convert between these depending on the endpoint. For example: HTML provided input would be converted to TEXT before passing it along as a text message. However the same HTML content provided would not be converted if the endpoint accepted it as such (such as Telegram, or Email).

4. It supports breaking large messages into smaller ones to fit the upstream service. Hence a text message (160 characters) or a Tweet (280 characters) would be constructed for you if the notification you sent was larger.

5. It supports configuration files allowing you to securely hide your credentials and map them to simple tags (or identifiers) like `family`, `devops`, `marketing`, etc. There is no limit to the number of tag assignments. It supports a simple TEXT based configuration, as well as a more advanced and configurable YAML based one.

6. Configuration can be hosted via the web (even self-hosted), or just regular (protected) configuration files.

7. It Supports "tagging" of the Notification Endpoints you wish to notify. Tagging allows you to mask your credentials and upstream services into single word assigned descriptions of them. Tags can even be grouped together and signaled via their group name instead.

8. Dynamic Module Loading: They load on demand only. Writing a new supported notification is as simple as adding a new file; see here: https://github.com/caronc/apprise/tree/master/apprise/plugin...

9. Developer CLI tool (it's like `/usr/bin/mail` on steroids)

It's worth re-mentioning that it has a fully compatible API interface found here: <https://github.com/caronc/apprise-api> or on Dockerhub (<https://hub.docker.com/r/caronc/apprise>) which has all of the same bells and whistles as defined above. This acts as a great side-car solution!

Program Details

  - Entirely a self-hosted solution.
  - Written in Python
  - 99.27% Test Coverage (oof... I'll get it back to 100% soon)
  - BSD-2 License
  - Over 450K downloads a month on PyPi
  - Over 2.8 million downloads from Docker Hub

I would love to hear any feedback any of you have!

Mastodon Support added

Thank you! I feel silly for asking when the answer really was right there in my face. I was able to sign up with a service. Apprise will hopefully have Mastodon support next!

It's not the sending the messages that has me stumped, it's the setup of the server (the hosting of it itself).

Do you know of a public service that exists i could build/test the Apprise plugin against? Would love just even temporary access to a server to perfect its design (then my account could be terminated)

Let me see what I can do about prioritizing this one a bit.

It already is: https://www.home-assistant.io/integrations/apprise/

I would love to hear anyone's thoughts and/or suggestions on what they'd like to see next!

Thanks for the shoutout. As the dev of Apprise, I can tell you that it already supports emails. It also supports attachments too (https://github.com/caronc/apprise/wiki/Notify_email). :)

But none the less, it's still a great effort by OP. It's awesome when you solve a problem and even more rewarding when you can share your efforts!

I'll look into it! Thanks for sharing!

6 months ago [I posted about Apprise here](https://news.ycombinator.com/item?id=19023196) and got a lot of amazing and encouraging feedback! I since took just about everyone's comments and ideas at the time and implemented most of them.

Apprise now supports over 40+ different notification services, including configuration files that can be read from disk and the cloud! The library remains incredible light weight and easy to use.

I just wanted to share an almost completed solution and hope to hit you all up for more of your thoughts and advice!

Thanks,

I'll look into this. I actually added Facebook support, but it was around the time Zuckerberg got in trouble with data leaking. The API at the time became utterly useless (for Facebook).

But I never looked into the WhatsApp side of things. Thanks for the idea!

Thank you for sharing this. I'll definitely investigate this further!

What you're describing you're building might be more complicated then the problems I faced.

For apprise, I focused on what was common across all notification services: all of them had a body, most have a title, and some allow you to attach images. Anything outside of these 3 fields then became very specific to that one (notification) service. The sacrifice made is that if you want in-depth functionality of a specific service with rich features, you won't achieve it with apprise. It can however accomodate some additional attributes via arguments... For example with email you can define the smtp server, from address, etc., but that wouldn't be applicable to say Twitter.

I know I'm drifting from your question, but with respect to what was said: - enforce your own specification as you're right, you'll find everyone solves great problems differently. - use inheritance. Base classes make life soo much easier. - decide what is common or what you want to make common across your API endpoints and stick with that. Like the body, title, image issue I resorted too. Maybe you want to assume you'll always need a user and password too. Prepare to support tokens and open ids out of the gate in your base class - don't try to extend on one endpoint too much regardless of how much feature rich functionality it offers. Focus on getting them all endpoints working using the standards you come up with. This will help you achieve your goal. Build onto it after. - unit tests! They're a pain to learn, but you won't regret knowing your code remains stable!

As per monitoring, I presume you're running a web service at the end of the day. So there are many great monitoring solutions out there that can check your servers availability constantly. Nagios (or forks of it) for example can email you when your service gets disrupted allowing you to take action right away. Heck, Nagios+apprise and you can get a text message. There are lots of more modern monitoring tools as well that can do all this for you.

Sorry for the wordy reply, I hope I answered your questions!

Good luck

Apparently this video is not available to be watched in my country (Canada).

But now that you struck my curiosity, what is the video about? :)

No reason for this other then simply not having a request for it (until now) :).

After some quick Googling, it sort of appears everyone uses this protocol differently with different payloads (I could be really wrong here and would love if someone were to weigh in here). For example Google Talk servers require you to define additional XML which includes a token, where as other services just require you to send the sub/pub standard XML. These differences in payloads would make it difficult to build a simple URL with (while following the current convention).

So rather than support XMPP, maybe it would be better to create a notification per service you want to attach too? Did you have one in mind?

No, unfortunately it only simplifies the use of existing notification services.

I don't recall supporting a service that does that though. Perhaps I need a wrapper for Twilio? That service may at least allow text messages to the specific China phones you speak of... Not sure though.

Hmm... I don't know if I'd want the headache of having everyone's passwords, tokens and API keys on a server I managed and deal with the privacy that goes with it...

But I was thinking of still supporting YAML or JSON formatted files to which users could protect with permissions and store their personal data there instead of being visible on the command line. the url would be something like file://path/to/config.yaml or http://localserver/path/to/config.yaml. So in a way, this kinda/sorta fits with your idea too :).

Thanks for your positive feedback!