[GH-ISSUE #1278] Relay notifications from one public server to a private one #901

New issue

Closed

opened 2026-05-07 00:28:35 +02:00 by BreizhHardware · 2 comments

BreizhHardware commented

2026-05-07 00:28:35 +02:00

Owner

Originally created by @schklom on GitHub (Feb 18, 2025).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1278

💡 Idea
I have a self-hosted ntfy instance at my_ntfy_url.domain.
Problem: my URL is unique, so giving it out to the Internet somewhat identifies me.
What I tried and failed: On ntfy.sh, if I subscribe to my_ntfy_url.domain/topic1, my browser (and phone app) connects to my_ntfy_url.domain.
Solution: On my_ntfy_url.domain/topic1, subscribing to ntfy.sh/topic2 should make the notifications received by ntfy.sh/topic2 go to my_ntfy_url.domain/topic1 and then to my device. Similar to https://docs.ntfy.sh/config/#ios-instant-notifications, but also for other client devices, so topic2 would be the sha256 of my_ntfy_url.domain/topic1.

The easy alternative is to connect my devices to both servers, but on a phone this requires battery to maintain 2 Websocket connections.
This feature would let my phone maintain only 1 connection (to my_ntfy_url.domain) instead of 2 (ntfy.sh + my_ntfy_url.domain), and the notification sender would only know about ntfy.sh instead of my_ntfy_url.domain.

If usable with UnifiedPush, this would solve the privacy issue from https://github.com/simplex-chat/simplex-chat/issues/1081 where the self-hosted ntfy server can be used to uniquely identify its owner, because the other party would only post to ntfy.sh/topic2. Ideally, this feature can be used with and without UnifiedPush.

I understand this would add a connection from the server to ntfy.sh, but at the same time this would allow to avoid connections from devices because they would only need to keep a connection to my_ntfy_url.domain instead of my_ntfy_url.domain + ntfy.sh.
In my situation, i have a few phones that would stop connecting to my_ntfy_url.domain + ntfy.sh, and only connect to my_ntfy_url.domain.
So the load on ntfy.sh might decrease a little.

To relay with UnifiedPush, maybe a toggle in the mobile app settings could say "Relay new UnifiedPush subscriptions via the following server: (default ntfy.sh)".

💻 Target components

ntfy server (functionality to relay notifications)

Originally created by @schklom on GitHub (Feb 18, 2025). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1278  :bulb: **Idea** I have a self-hosted ntfy instance at my_ntfy_url.domain. Problem: my URL is unique, so giving it out to the Internet somewhat identifies me. What I tried and failed: On ntfy.sh, if I subscribe to my_ntfy_url.domain/topic1, my browser (and phone app) connects to my_ntfy_url.domain. Solution: On my_ntfy_url.domain/topic1, subscribing to ntfy.sh/topic2 should make the notifications received by ntfy.sh/topic2 go to my_ntfy_url.domain/topic1 and then to my device. Similar to https://docs.ntfy.sh/config/#ios-instant-notifications, but also for other client devices, so topic2 would be the sha256 of my_ntfy_url.domain/topic1. The easy alternative is to connect my devices to both servers, but on a phone this requires battery to maintain 2 Websocket connections. This feature would let my phone maintain only 1 connection (to my_ntfy_url.domain) instead of 2 (ntfy.sh + my_ntfy_url.domain), and the notification sender would only know about ntfy.sh instead of my_ntfy_url.domain. If usable with UnifiedPush, this would solve the privacy issue from https://github.com/simplex-chat/simplex-chat/issues/1081 where the self-hosted ntfy server can be used to uniquely identify its owner, because the other party would only post to ntfy.sh/topic2. Ideally, this feature can be used with and without UnifiedPush. I understand this would add a connection from the server to ntfy.sh, but at the same time this would allow to avoid connections from devices because they would only need to keep a connection to my_ntfy_url.domain instead of my_ntfy_url.domain + ntfy.sh. In my situation, i have a few phones that would stop connecting to my_ntfy_url.domain + ntfy.sh, and only connect to my_ntfy_url.domain. So the load on ntfy.sh might decrease a little. To relay with UnifiedPush, maybe a toggle in the mobile app settings could say "Relay new UnifiedPush subscriptions via the following server: (default ntfy.sh)". :computer: **Target components**   ntfy server (functionality to relay notifications)

BreizhHardware

2026-05-07 00:28:35 +02:00

closed this issue
added the
enhancement
label

BreizhHardware commented

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

Author

Owner

@binwiederhier commented on GitHub (Feb 2, 2026):

This is an interesting feature, though you are effectively asking ntfy.sh be your VPN-like traffic forwarder.

I currently have no interest in implementing this feature, nor would I accept PRs for this, I think. Unless there is something that I'm missing, there are no upsides for ntfy.sh itself

@binwiederhier commented on GitHub (Feb 2, 2026): This is an interesting feature, though you are effectively asking ntfy.sh be your VPN-like traffic forwarder. I currently have no interest in implementing this feature, nor would I accept PRs for this, I think. Unless there is something that I'm missing, there are no upsides for ntfy.sh itself

BreizhHardware commented

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

Author

Owner

@schklom commented on GitHub (Feb 2, 2026):

There is a small upside to ntfy.sh: the number of websocket connections to ntfy.sh should decrease in exchange for forwarding the notifications. So the network load on ntfy.sh should be a little lower.

I mean that with this, my phone would only need 1 connection to my_ntfy_url.domain, instead of 1 to my_ntfy_url.domain + 1 to ntfy.sh.
In return, ntfy.sh would forward a small (feel free to limit) amount of messages back to my selfhosted ntfy instance.

It's not a major upside, so I understand if you're still not interested.

@schklom commented on GitHub (Feb 2, 2026): There is a small upside to ntfy.sh: the number of websocket connections to ntfy.sh should decrease in exchange for forwarding the notifications. So the network load on ntfy.sh should be a little lower. I mean that with this, my phone would only need 1 connection to my_ntfy_url.domain, instead of 1 to my_ntfy_url.domain + 1 to ntfy.sh. In return, ntfy.sh would forward a small (feel free to limit) amount of messages back to my selfhosted ntfy instance. It's not a major upside, so I understand if you're still not interested.

BreizhHardware referenced this issue

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

[PR #901] [MERGED] Fix typo "aliase" -> "alias" #1456