Read Notification URLs from predefined YAML file(s) and/or URL(s)

One would simply utilize the file://, http:// and/or https:// URLs as part of their apprise syntax; however their meaning would be interpreted as read to fetch the notifications to load.

The idea is you lock all of your tokens, passwords and usernames in a yaml file that has permissions that only you can access. It’s better than passing this information on the command line.

Here would be an example:

# Open up apprise.yaml and read in the notification URLs
# From there construct all of the notifications to alert:
apprise -b "test body" -t "test title" \
    file:///path/to/yaml/config/file/apprise.yaml

http:// and https:// would work the same as file:// except they’d go to the URL you specify and hope to find a YAML file to read. Ideally you should be passing back the correct mime type for this such as one of the following:

text/yaml
text/x-yaml
application/yaml
application/x-yaml

The most minimal apprise syntax would be as follows:

# A version would be important so that I can anticipate future changes and/or
# ideas if this value is left out, then 'version: 1' would be implied. 
version: 1

# Now the meat and potatos: simply define your notification urls:
urls:
  - pbul://o.gn5kj6nfhv736I7jC3cj3QLRiyhgl98b
  - mailto://test:[e-mail]

To take this feature a step further, the URL should be allowed to be constructed through options. This allows for an easier read (and doesn’t require you to escape special characters such as slashes (/) or ampersands (&) since they otherwise conflict with the URL.

# our version definition
version: 1

urls:
  - pbul://o.gn5kj6nfhv736I7jC3cj3QLRiyhgl98b

    # adding a colon to the end of our URL now makes it something we can apply
    # additional configuration to (thanks to YAML).
  - mailto://test:[e-mail]:

    # associate our mailto object with the tag profile_changes. Without this entry,
    # the profile gets added automatically to the 'default' tag. This will be important
    # when https://github.com/caronc/apprise/issues/34 gets implemented.
    # Right now it's just on standby (and ready to be supported). :)
    tags:
      - profile_changes

    # These over-ride anything otherwise defined in the URL string.
    args:
      # optional over-rides
      - user: caronc
      - password: /234j3jkada52:3&
      - smtp_server: example.com

If we allow all of this, then we might as well additionally support the override of the apprise asset object too. So if we take this configuration one step further:

# our version definition
version: 1

# allow one to over-ride the asset object too
asset:
  # optional asset over-ride
  app_id: MyApp
  app_desc: MyApp Description
  app_url: https://my/apps/website/
  theme: default
  default_extension: .png
  image_path_mask: /optional/path/to/{THEME}/apprise-{TYPE}-{XY}{EXTENSION}
  image_url_mask: https://my/path/to/{THEME}/apprise-{TYPE}-{XY}{EXTENSION}

# You've seen the below already; but lets just stick it in to show a complete
# configuration file:
urls:
  - pbul://o.gn5kj6nfhv736I7jC3cj3QLRiyhgl98b
  - mailto://test:[e-mail]:
    # associate with tags. Without this entry, the
    # profile gets added automatically to the 'default'
    # tag.
    tags:
      - profile_changes

    args:
      # optional over-rides
      - smtp_server: example.com

[philborman]

At the moment our apprise telegram notifier looks like this…

and the old notifier looked like this…

I think it’s a lot easier for the user to handle the old style with clearly defined fields and let the app construct the url. Probably have a dropdown select box to choose the new notifier type from the service_names in apobj.details()[‘schemas’] and then add input boxes for the appropriate arguments for that schema.

[caronc]

Merged into master branch; closing issue.