fix(webhooks): send ntfy.sh URLs ntfy's native format
Our generic JSON envelope is unusable on ntfy. With a topic in the URL,
ntfy treats the whole request body as the message text, so subscribers
got a raw JSON dump instead of a notification — and once that body grows
past ~4 KB, which any alert with a few dozen matched auctions does, ntfy
converts it into a file attachment, so the notification only reads "You
received a file: attachment.json". Posting the envelope to an instance
root instead fails outright with `40009 topic invalid`, because ntfy's
own JSON publish format expects a `topic` field. Both routes were
reported by a user, and the settings copy has been advertising ntfy
support the whole time.
ntfy.sh URLs now get a plain-text body plus X-Title/X-Click/X-Tags
headers. Publishing that way needs no topic parsing, so every alias a
user might paste (`/topic`, `/topic/publish`) behaves identically, and
the body is a one-line summary that stays well clear of the attachment
threshold. Titles outside printable ASCII are RFC 2047-encoded, since
fetch rejects non-latin-1 header values and alert names are
user-supplied.
Detection is limited to the hosted service: self-hosted instances live
on arbitrary domains and can't be recognised from the URL alone, so they
keep receiving the JSON envelope. Non-ntfy endpoints are unchanged. The
settings Test button imports the same formatter the worker uses, so it
exercises the real wire format rather than a parallel one.
Verified against a local ntfy instance: title, click action, tags and
UTF-8 alert names all round-trip, with no attachment fallback.
fix(webhooks): send ntfy.sh URLs ntfy's native format
Our generic JSON envelope is unusable on ntfy. With a topic in the URL,
ntfy treats the whole request body as the message text, so subscribers
got a raw JSON dump instead of a notification — and once that body grows
past ~4 KB, which any alert with a few dozen matched auctions does, ntfy
converts it into a file attachment, so the notification only reads "You
received a file: attachment.json". Posting the envelope to an instance
root instead fails outright with `40009 topic invalid`, because ntfy's
own JSON publish format expects a `topic` field. Both routes were
reported by a user, and the settings copy has been advertising ntfy
support the whole time.
ntfy.sh URLs now get a plain-text body plus X-Title/X-Click/X-Tags
headers. Publishing that way needs no topic parsing, so every alias a
user might paste (`/topic`, `/topic/publish`) behaves identically, and
the body is a one-line summary that stays well clear of the attachment
threshold. Titles outside printable ASCII are RFC 2047-encoded, since
fetch rejects non-latin-1 header values and alert names are
user-supplied.
Detection is limited to the hosted service: self-hosted instances live
on arbitrary domains and can't be recognised from the URL alone, so they
keep receiving the JSON envelope. Non-ntfy endpoints are unchanged. The
settings Test button imports the same formatter the worker uses, so it
exercises the real wire format rather than a parallel one.
Verified against a local ntfy instance: title, click action, tags and
UTF-8 alert names all round-trip, with no attachment fallback.
fix(webhooks): send ntfy.sh URLs ntfy's native format
Our generic JSON envelope is unusable on ntfy. With a topic in the URL,
ntfy treats the whole request body as the message text, so subscribers
got a raw JSON dump instead of a notification — and once that body grows
past ~4 KB, which any alert with a few dozen matched auctions does, ntfy
converts it into a file attachment, so the notification only reads "You
received a file: attachment.json". Posting the envelope to an instance
root instead fails outright with `40009 topic invalid`, because ntfy's
own JSON publish format expects a `topic` field. Both routes were
reported by a user, and the settings copy has been advertising ntfy
support the whole time.
ntfy.sh URLs now get a plain-text body plus X-Title/X-Click/X-Tags
headers. Publishing that way needs no topic parsing, so every alias a
user might paste (`/topic`, `/topic/publish`) behaves identically, and
the body is a one-line summary that stays well clear of the attachment
threshold. Titles outside printable ASCII are RFC 2047-encoded, since
fetch rejects non-latin-1 header values and alert names are
user-supplied.
Detection is limited to the hosted service: self-hosted instances live
on arbitrary domains and can't be recognised from the URL alone, so they
keep receiving the JSON envelope. Non-ntfy endpoints are unchanged. The
settings Test button imports the same formatter the worker uses, so it
exercises the real wire format rather than a parallel one.
Verified against a local ntfy instance: title, click action, tags and
UTF-8 alert names all round-trip, with no attachment fallback.