NIP-PL on a self-hosted relay is unreachable by design: the default gateway is push.buzz.xyz and only block can sign APNs for the App Store app

[mattbalza]

Summary

A self-hosted relay can advertise NIP-PL correctly, run the delivery worker, and still never deliver a single push — because the only gateway it can point at is yours, and the only gateway that could hold the APNs key for the App Store client is also yours. I do not think this is a bug so much as a gap in the self-hosting story, and I would like to know which of the two exits you intend.

What we run

wss://buzz.scalarly.org, our own relay, with the public App Store Buzz iOS app as the client. That combination is the whole issue: we operate the relay, you own the app.

The relay half looks healthy. NIP-11 today:

"push": {
  "app_profiles": [
    { "id": "buzz-ios-production", "transport": "apns" },
    { "id": "buzz-ios-sandbox",    "transport": "apns" }
  ],
  "origin": "wss://buzz.scalarly.org",
  "push_kinds": [7, 9, 1059, 40007, 46010],
  "keys": [{ "id": "relay-v1", "current": true, "pubkey": "863d7a6b…" }]
}

supported_extensions includes nip-pl, and the relay logs NIP-PL push matcher and delivery worker started.

What actually happens

Zero leases, ever. select count(*) from events where kind = 30350 → 0. Not one device has published a lease against us.

The delivery URL defaults to yours. With no push env set, DEFAULT_PUSH_GATEWAY_DELIVERY_URL (crates/buzz-relay/src/config.rs:448) is https://push.buzz.xyz/v1/deliveries/apns — block's hosted gateway, which does not know our tenant or our executor key. So the one configuration that "just works" points at a service that will reject us, and it does so silently from the operator's side.

Running the gateway ourselves does not help. crates/buzz-push-gateway/src/config.rs:179-182 requires BUZZ_PUSH_APNS_KEY_PATH, _KEY_ID, _TEAM_ID and _TOPIC. apns_topic is the iOS bundle identifier, and APNs only accepts a push signed by the Apple Developer team that owns that bundle id. The App Store app's bundle id is yours. A gateway we stand up authenticates to APNs as nobody, for an app it does not own. There is no relay-side configuration that fixes this.

The ask

Either of these would close it; I am asking which you prefer rather than proposing one:

1. Onboard self-hosted relays as tenants of push.buzz.xyz. The relay is already pointed there by default, already advertises nip-pl, already runs the worker. If there is a registration path — an executor key you can enroll, a tenant record, a signed origin — this likely starts working with no code change on either side. This is the outcome we would like.
2. Say plainly in the self-hosting docs that iOS push requires shipping your own client build, so operators stop treating a healthy-looking NIP-PL advertisement as a working feature. Today the relay honestly advertises a capability that cannot function, and nothing in the logs says why.

If neither is on the table, a third useful thing: have the relay refuse to advertise nip-pl (or log a warning at startup) when BUZZ_PUSH_GATEWAY_DELIVERY_URL is still the default and the operator is not block. That turns a silent dead end into a startup message.

Happy to test any tenant-onboarding flow against our relay.

[hecarrillo]

Another self-hosted relay with the same shape: our own relay, the public App Store iOS app as the client. We reached the same conclusion independently today. Three things we found are not yet in this thread, and one of them changes the framing.

The schema already names the exit you are asking about

crates/buzz-push-gateway/migrations/0002_application_profiles.sql retires the old profiles and rewrites the constraint:

ALTER TABLE push_gateway_installations
    ADD CONSTRAINT push_gateway_installations_app_profile_check
    CHECK (app_profile IN ('buzz-ios-dogfood', 'buzz-ios-app-store'));

But AppProfile in crates/buzz-push-gateway/src/model.rs has one variant:

pub enum AppProfile {
    BuzzIosDogfood,
}

That is true on main as well as on the current release. crates/buzz-relay/src/nip11.rs advertises [{"id": "buzz-ios-dogfood", "transport": "apns"}] and nothing else. The client agrees: mobile/lib/shared/push/dev_push_lease.dart pins const buzzDevPushAppProfile = 'buzz-ios-dogfood' and rejects a grant for any other profile.

So buzz-ios-app-store is an allowed value in the authority schema with no code path that produces or accepts it. This reads less like "self-hosting is unsupported" and more like a half-landed profile. Knowing which it is would tell operators whether to wait or to stop asking.

This report's NIP-11 premise is now out of date

The issue body shows a relay advertising buzz-ios-production and buzz-ios-sandbox. Those are gone. Migration 0002 deletes every installation and delegation carrying them, on the grounds that they encoded APNs transport environment rather than a verified application identity.

We can confirm the newer behavior. Our relay ran a 0.4-era build that advertised both of those profiles in NIP-11 while BUZZ_PUSH_ENABLED was false. That is a misleading capability advertisement, and it is very likely why our users expected notifications that could never arrive. After upgrading to relay 0.2.1 the same relay reports no push descriptor at all while push stays disabled. That part is a real improvement and worth noting here.

The deployment doc is stale

docs/push-gateway-deployment.md still says the gateway "has exactly one compiled-in application profile, buzz-ios-dogfood" and that another application identity needs "an explicit code, schema, chart, credential, and deployment change". It never mentions buzz-ios-app-store, so a reader cannot tell that the schema change already happened.

Ask

1. Is buzz-ios-app-store intended to ship, or is it a reserved value? A yes or no is enough to unblock operator planning.
2. If it is intended, does it also require the gateway to accept delegations from relays it does not operate? That is the second half of this issue and the schema change alone does not answer it.
3. Please update docs/push-gateway-deployment.md either way. Right now the doc and the migration disagree.

Happy to test against push.buzz.xyz from a self-hosted relay if a public profile lands.

[hecarrillo]

Five-day check-in, with fresh verification rather than a bare ping.

Re-verified against main today (2026-09-14):

• AppProfile in crates/buzz-push-gateway/src/model.rs still has one variant, BuzzIosDogfood. The buzz-ios-app-store value in the migration 0002 CHECK constraint still has no code path that produces or accepts it.
• No commit has touched crates/buzz-push-gateway since 2026-09-08, or crates/buzz-relay/src/handlers/push_lease.rs since 2026-09-01. The repository is pushed daily, so this is not general inactivity.

One further finding that narrows question 2 in my earlier comment. crates/buzz-push-gateway/src/config.rs builds exactly one AppProfileConfig, from BUZZ_PUSH_DOGFOOD_APP_ATTEST_APP_ID, BUZZ_PUSH_DOGFOOD_APNS_CERT_PATH, and BUZZ_PUSH_DOGFOOD_APNS_TOPIC. Self-hosting the gateway therefore needs an APNs client certificate for the target app id. An operator can never hold one for an app they do not own. So "run your own gateway" is not a workaround for self-hosted relays, independent of the profile question.

That leaves one question, and a yes or no unblocks operator planning:

Is buzz-ios-app-store intended to ship, or is it a reserved value?

If the answer is no, please say so in docs/push-gateway-deployment.md. Operators currently read a migration that names the profile and a doc that does not mention it, and reasonably conclude the feature is close.

[fdagostino]

Hi Buzz team — mobile push is currently blocking reliable use of our self-hosted Buzz deployment.

We use the official iOS and Android applications published by Buzz. Messaging works correctly against our self-hosted relay, but neither platform receives OS push notifications.

We do not want to publish or maintain custom mobile builds; we specifically need a supported path for the official App Store and Play Store applications.

We understand that our relay must advertise NIP-PL and enable the push integration. However, before enabling it, we need an officially supported application and gateway path. From the current implementation:

• the iOS gateway appears limited to the buzz-ios-dogfood profile;
• the public App Store application profile is not enabled;
• Android/FCM support remains pending in feat(mobile/android): end-to-end push notifications — FCM registration, POST_NOTIFICATIONS, and banner display #6092;
• feat(push): make gateway origin configurable #7261 makes the gateway origin configurable, but does not appear to add support for the public iOS or Android application identities.

Could Block please confirm and prioritize the intended architecture for official mobile applications connected to self-hosted relays?

1. Will the official iOS and Android applications use a Block-operated push gateway for arbitrary self-hosted relays?
2. Will the public iOS App Store profile be enabled?
3. Is Android FCM support planned for the official Play Store application?
4. What relay configuration and software version will self-hosters need?
5. What remains before this can be considered generally available?

We can beta-test both platforms on physical devices against a production-like self-hosted deployment and provide sanitized, reproducible results.