Support https://ntfy.sh (and self-hosted deployments) #184

New issue

Open

opened 2025-12-30 13:48:30 +00:00 by mih · 3 comments

mih commented

2025-12-30 13:48:30 +00:00

(Migrated from github.com)

access token to submit notification (32-char string)
notification topic URL (e.g. https://ntfy.sh/curation-alert)
notification behavior mode
- on every single post to an inbox
- after X minutes and at least one post to an inbox
- a daily summary of inbox stats
- ...

besides the config, this is just a single POST https://docs.ntfy.sh/#step-2-send-a-message

This would be useful to notifying a curator on, e.g., incoming submissions. The access control for the notifications can be left to the ntfy config. For dumpthings it would be sufficient to configure: - access token to submit notification (32-char string) - notification topic URL (e.g. `https://ntfy.sh/curation-alert`) - notification behavior mode - on every single post to an inbox - after X minutes and at least one post to an inbox - a daily summary of inbox stats - ... besides the config, this is just a single POST https://docs.ntfy.sh/#step-2-send-a-message

mih commented

2026-01-07 11:58:01 +00:00

(Migrated from github.com)

Here is an attractive use case that would be supported by this feature.

The server could be configured to post incoming records (in full) to a private notification channel. One or more subscribers for this channel could exist (processes running in different environments with different access to information -- this is the main difference to a "hook"-based system, where logic could live next to the service). A subscriber would check a record, and perform an action, if it understands it (ignore if not).

An example subscriber would be a publication record-enricher. It would look for publication records, and then act on a doi property. It would fetch information from the DOI and enrich the record. Once done, it would submit the enriched record -- possibly into the same inbox (with curator permissions).

With such an approach, a human curator would already see a machine-curated/enhanced record, and manual labor would be minimized.

Here is an attractive use case that would be supported by this feature. The server could be configured to post incoming records (in full) to a private notification channel. One or more subscribers for this channel could exist (processes running in different environments with different access to information -- this is the main difference to a "hook"-based system, where logic could live next to the service). A subscriber would check a record, and perform an action, if it understands it (ignore if not). An example subscriber would be a publication record-enricher. It would look for publication records, and then act on a `doi` property. It would fetch information from the DOI and enrich the record. Once done, it would submit the enriched record -- possibly into the same inbox (with curator permissions). With such an approach, a human curator would already see a machine-curated/enhanced record, and manual labor would be minimized.

mih commented

2026-01-07 12:10:14 +00:00

(Migrated from github.com)

And maybe as an additional argument: with ntfy, a receiver can be implemented with little to no overhead. Even a bash for-loop would be enough as a listener

https://docs.ntfy.sh/subscribe/api/#subscribe-as-json-stream

And maybe as an additional argument: with ntfy, a receiver can be implemented with little to no overhead. Even a bash for-loop would be enough as a listener https://docs.ntfy.sh/subscribe/api/#subscribe-as-json-stream

mih commented

2026-01-16 07:30:15 +00:00

(Migrated from github.com)

Another use case: watch for a particular property change. E.g. XYZPerson.delegated_by[].ended_at to indicate an extension of a workplace relationship.

Another use case: watch for a particular property change. E.g. `XYZPerson.delegated_by[].ended_at` to indicate an extension of a workplace relationship.