[GH-ISSUE #762] Allow local attachments in "Publish as JSON" feature #549

New issue

Open

opened 2026-05-07 00:25:20 +02:00 by BreizhHardware · 3 comments

BreizhHardware commented

2026-05-07 00:25:20 +02:00

Owner

Originally created by @codebude on GitHub (Jun 1, 2023).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/762

💡 Idea
#133 brought us the wonderful "Send notification as JSON feature" (documented here: https://docs.ntfy.sh/publish/#publish-as-json)
But one thing is missing: Local attachments. Would it be possible to pass files/attachments via the JSON structure?
I think the whole point of implementing this feature, was to support sender systems that aren't able to set/modify headers, but rely totally on the body. To enable those systems to (directly) send files, it would be great, to add another/new field to the JSON structure, that could handle data. E.g.

{
  "topic": "test",
  "filename": "picture.jpg",
  "data": "4AAQSkZJRgABAQAAAQABAAD/2w ... lots of encoded bytes here ... BDAAMCA="
}

An alternative idea that came to my mind (and one that would avoid introducing a new field) is allowing data-uris in the attach field. E.g.

{
  "topic": "test",
  "filename": "picture.jpg",
  "attach": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2w ... more data"
}

(I'm not sure if Go supports this out of the box as web browsers do, but there's at least a package for it: https://github.com/vincent-petithory/dataurl)

💻 Target components
ntfy server

Originally created by @codebude on GitHub (Jun 1, 2023). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/762 :bulb: **Idea** #133 brought us the wonderful "Send notification as JSON feature" (documented here: https://docs.ntfy.sh/publish/#publish-as-json) But one thing is missing: Local attachments. Would it be possible to pass files/attachments via the JSON structure? I think the whole point of implementing this feature, was to support sender systems that aren't able to set/modify headers, but rely totally on the body. To enable those systems to (directly) send files, it would be great, to add another/new field to the JSON structure, that could handle data. E.g. ``` json { "topic": "test", "filename": "picture.jpg", "data": "4AAQSkZJRgABAQAAAQABAAD/2w ... lots of encoded bytes here ... BDAAMCA=" } ``` An alternative idea that came to my mind (and one that would avoid introducing a new field) is allowing data-uris in the attach field. E.g. ```json { "topic": "test", "filename": "picture.jpg", "attach": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2w ... more data" } ``` (I'm not sure if Go supports this out of the box as web browsers do, but there's at least a package for it: https://github.com/vincent-petithory/dataurl) :computer: **Target components** ntfy server

BreizhHardware added the

enhancement

label

2026-05-07 00:25:20 +02:00

BreizhHardware commented

2026-05-07 00:25:20 +02:00

Author

Owner

@binwiederhier commented on GitHub (Jun 2, 2023):

There is a proposal for multipart on the "POST ntfy.sh" endpoint, see use case 4 in https://github.com/binwiederhier/ntfy/issues/69#issuecomment-1183839284

I'd much rather do that than base64 encoded data in JSON. Would that work as well? I really don't want to allow giant JSON blobs in memory. Right now, I limit it to 16k, which is ok. If I allow attachments as part of the JSON, I'd have to read the entire thing first into memory before deciding whether it's allowed or not. It's really not feasible at scale.

@binwiederhier commented on GitHub (Jun 2, 2023): There is a proposal for multipart on the "POST ntfy.sh" endpoint, see use case 4 in https://github.com/binwiederhier/ntfy/issues/69#issuecomment-1183839284 I'd much rather do that than base64 encoded data in JSON. Would that work as well? I really don't want to allow giant JSON blobs in memory. Right now, I limit it to 16k, which is ok. If I allow attachments as part of the JSON, I'd have to read the entire thing first into memory before deciding whether it's allowed or not. It's really not feasible at scale.

BreizhHardware commented

2026-05-07 00:25:20 +02:00

Author

Owner

@codebude commented on GitHub (Jun 2, 2023):

Ok, that's a valid point. I still think there's a use Case for blobs in JSON but I understand your argument from a design perspective.

@codebude commented on GitHub (Jun 2, 2023): Ok, that's a valid point. I still think there's a use Case for blobs in JSON but I understand your argument from a design perspective.

BreizhHardware commented

2026-05-07 00:25:20 +02:00

Author

Owner

@kk7ds commented on GitHub (Dec 27, 2024):

I'm fine with really any method of doing this (blob or multipart or whatever) but would definitely like to have it. I want to always publish as json instead of needing a different code path for "is there a picture in this one?".

@kk7ds commented on GitHub (Dec 27, 2024): I'm fine with really any method of doing this (blob or multipart or whatever) but would definitely like to have it. I want to always publish as json instead of needing a different code path for "is there a picture in this one?".

BreizhHardware referenced this issue

2026-05-07 01:01:36 +02:00

[PR #549] [CLOSED] Use pre-commit #1331