@Sean
Relays (5)
- wss://premium.primal.net – read & write
- wss://relay.bitesize-media.com – read & write
- wss://relay.momostr.pink/ – read & write
- wss://relay.mostr.pub – read & write
- wss://relay.primal.net – read & write
Recent Notes
I can’t tell if you live in Cumbria or just love the place. These photos are not how it looks right now!! Soon though, very soon.
Anyway, gm ☕️
It reminds me that there’s peace somewhere, amongst all the chaos the media portrays the country to be in
GM ☕️
12
https://blossom.ditto.pub/9a51db6b476dcc82a6d6bfb98887f869ea8e514ad7b8438223288689c0178df9.jpeg
Why is the depth between the two middle prongs on the fork so deep compared to the others?
1
Is that true of Pokey of NTFY?
I’m not sure, but here’s what I found in a relavent search based on your question:
no, MIP-05 and Pokey/ntfy are solving the same problem but in completely different ways. Pokey with ntfy bypasses Apple/Google push infrastructure entirely by maintaining its own connection to relays, so the encrypted token and decoy mechanism MIP-05 describes is irrelevant to how they work. MIP-05 is specifically for the Marmot/WhiteNoise ecosystem where push notifications are being sent through Apple/Google, and the privacy engineering is about minimising what the notification server can learn in that scenario.
If anything, the commenter's question highlights a useful distinction you could draw out — there are broadly two strategies here: avoid the Apple/Google push pipeline (Pokey/ntfy/UnifiedPush approach) or use it but strip it of meaningful metadata (MIP-05 approach). Both are valid, with different tradeoffs. Pokey's approach works great on Android but doesn't solve for iOS at all, which is exactly the gap MIP-05 is designed to fill.
no, MIP-05 and Pokey/ntfy are solving the same problem but in completely different ways. Pokey with ntfy bypasses Apple/Google push infrastructure entirely by maintaining its own connection to relays, so the encrypted token and decoy mechanism MIP-05 describes is irrelevant to how they work. MIP-05 is specifically for the Marmot/WhiteNoise ecosystem where push notifications are being sent through Apple/Google, and the privacy engineering is about minimising what the notification server can learn in that scenario.
If anything, the commenter's question highlights a useful distinction you could draw out — there are broadly two strategies here: avoid the Apple/Google push pipeline (Pokey/ntfy/UnifiedPush approach) or use it but strip it of meaningful metadata (MIP-05 approach). Both are valid, with different tradeoffs. Pokey's approach works great on Android but doesn't solve for iOS at all, which is exactly the gap MIP-05 is designed to fill.
“Push notifications are the privacy hole that most encrypted messengers ignore. Your messages may be mathematically secure, but the push notification that woke your phone still traveled through Apple or Google's infrastructure, logging the fact that you received a message from a particular app at a particular time. For governments, that metadata can be more valuable than message content.
MIP-05 accepts that Apple and Google's push services are unavoidable on mobile devices but removes the need to trust the notification server with anything meaningful. The mechanism is elegant: your device token (the identifier Apple or Google uses to reach your phone) is encrypted with the notification server's public key using an ephemeral keypair generated specifically for that encryption. The server can decrypt the token and forward the notification, but it cannot link the encrypted token to your Nostr identity or correlate tokens across groups to determine which ones belong to the same user.
Payload padding ensures that all encrypted tokens are exactly 280 bytes regardless of platform, preventing group members from inferring whether someone uses iOS or Android based on token size. Decoy tokens from other groups are mixed in with real ones when triggering notifications, obscuring group sizes and preventing the server from building social graphs by observing which tokens are bundled together”
🔥🔥
naddr1qqgx...
MIP-05 accepts that Apple and Google's push services are unavoidable on mobile devices but removes the need to trust the notification server with anything meaningful. The mechanism is elegant: your device token (the identifier Apple or Google uses to reach your phone) is encrypted with the notification server's public key using an ephemeral keypair generated specifically for that encryption. The server can decrypt the token and forward the notification, but it cannot link the encrypted token to your Nostr identity or correlate tokens across groups to determine which ones belong to the same user.
Payload padding ensures that all encrypted tokens are exactly 280 bytes regardless of platform, preventing group members from inferring whether someone uses iOS or Android based on token size. Decoy tokens from other groups are mixed in with real ones when triggering notifications, obscuring group sizes and preventing the server from building social graphs by observing which tokens are bundled together”
🔥🔥
naddr1qqgx...
62🖤1
