There is no such thing as "Push" notifications. It's always Pull, regardless if you use Google, Apple or Unified Push apps. Some app is always "Pulling"

That's why Pokey will win. If something has to pull, we will have the best pulling system ever because you can choose the pull client and the relay server at will.

Reply to this note

Please Login to reply.

Discussion

damus notifications are not pull

Arent you using Apple? That's pull. Apple pulls for you.

what? We push to apple and apple pushes to the phone. Polling would be inefficient

Apple runs a service on iOS that connects to their server from time to time to pull your notifications. It's always Pull.

Not sure i believe that. Our notifications are basically instant in many cases. I doubt all ios phones are polling the server every second

Same for Google. It's instant. But still completely pull.

One connection pulling a reliable feed for the whole phone isn't the same as a dozen apps trying to do the same

Yep. And that's why Pokey wins.

Correct, the connection is "constant" (unless the device is not being used for a long time), which is the same in the other systems.

That doesn't mean that it is Push. It is a pull system. The app pulls it.

Otherwise, they would have to have a hole punch server to open firewalls everywhere.

Is this semantically meaningful?

Yep. Just because the device maker offers a push scheme, it doesn't make it an actual push.

Except it is. APNS pushes to the phone over an established connection.

The connection is the holepunch. The phone opens and maintains a socket connection to apns. The socket just needs to do occasional pings to keep the connection alive across firewalls. This is just conntrack ESTABLISHED logic on ip tables.

This is the same how any connection works, including websockets.

If the phone has to start anything, it's not push. Pokey is the same, the app registers with the relay and the relay sends it at will. Should we call Pokey Push as well?

This is incorrect. When people mean push they mean the server is pushing the payload to the phone. The connection is an implementation detail and is for hole-punching.

Right, so Nostr is then a Push system. That doesn't make any sense.

it is a push system, it pushes new notes that you subscribed to to your device.

Then, most things are push systems. I don't think it makes any sense to broaden the definition. If the client app or service has to start a connection (every time the user moves networks), it is a pull system. Calling it a "Push" is misleading.

i wouldn’t consider a request-response system like http to be push system just because i temporarily open a connection, make a request, and a response is *pushed* to me.

Push to me is about the initiator of the event.

What if I created a request and got a response? This is not push because i had to “poll” to get the other peer to generate a reaponse.

What if someone generates an event on the network and i am subscribed? Then yes, a user pushed a message to the relay and the relay pushed the message to my device.

The connection is just the thing that enables messages to go back and forth. I don’t think it makes sense to define push/poll based on how the channel was created.

So websockets are push systems now?

The subscriber has to establish a connection with a server and subscribe to a topic.

My point is that they are not because they always require the client to start the connection and "subscribe" to things. They are always pulling.

If the server could start the connection, then it would be a real Push.

they are full duplex channels. its both and neither. you choose the pattern: push, pull, pub/sub, fire‑and‑forget, or a mix.

Yeah, but you agree that the phone is initiating the event, right? It sends the initial payload to subscribe to events. If the phone switches networks, it has to restart the connection. It's not like an HTTP server that receives new connections at will. That would be a Push system.

I separated these concepts in nostrdb because they are unnecessarily complected:

REQ up until EOSE are pull/poll

Notes pushed to you via subscriptions are push (according to my definition in terms of the initiator)

That means every client has Push Notifications from the start. I don't think it means what people expect it to mean (getting notified when the app is in the background or off entirely).

Yes all clients have push notifications until they are closed. Apple/Google just maintains another connection to keep the push notifications alive for when the app is not open.

Just to make sure i wasn’t taking crazy pills i put our argument into 4o to see what it thought:

https://chatgpt.com/share/67fd79aa-f54c-800f-b755-ec6b5787f60c

That feels like how Apple, Google and Samsung would answer this question so that they can sell their own infrastructure as a "Push". :)

An interesting history: BlackBerry, the creator of Push Notifications, did sell the BlackBerry Enterprise Server that would run inside the NAT and open connections directly to phones. Outside of enterprise service, the phone has to make the connection to their server as it happens today.

first pull, then subsequently push (and when network changes, repeat).

this is a mouthful though, so they just say the one that sounds cooler

This is like suggesting a laptop is named wrong because most of the time they're not placed on people's actual laps.

Looking at this from the point of view of the TCP/IP network model, the connection establishment occurs at the Internet/transport layers. This needs to be device to server since most devices will sit behind NAT and firewalls. At the application level however, once the connection is established, the notifications are sent from server to device without the device polling so I would agree with this being called push.

https://theapplewiki.com/wiki/Apple_Push_Notification_Service

pokey is just redundant resource and data usage. also, i don't want to install a whole app to just receive notifications.

Redundant is having each nostr app having to the same events over and over again.

they show me notifications related to themselves. and ill never install same nostr apps doing same thing!

But they download all notifications. Because you can't filter them by app. You have to download everything and then filter locally.

kinds? :eyes:

Lol, that's not how notifications work.

at some point we need to filter new events to make notifications for nostr.

can't we? do you have any resources? :thinking:

Picture 5 Twitter like apps downloading 5 times the same event set.

Now lets talk about making drafts actually delete.

That's all on your relay of choice.

is there a way to turn off drafts? Or just store on local device?

Use citrine as a local relay, then they are totally under your control.

Is it possible to for example other non Nostr app like Simplex integrated with nostr:npub1h2685kkxa4q50qpexuae9geqep7frr0u8t8pcy9zj0xnza9phvtsnkd9tm?

SimpleX app could technically create a notification to your npub and send it to your local relay.

I used apple for most of my days but now ik on gos and the notifications thing is mad bro

I didn't know so much was needed for notifications to work properly

All these apps made for notifications, if you're not using Google or apple, are draining the battery like crazy or we need to keep an open connection like wirg molly foss

This needs some dedicated love and building to resolve without selling ones soul to the Big D

Pokey is cool but I don't want social media notifications. Only things I really want for notifications are messaging, transacting, and calendar/reminder stuff.

You can set it up foressages only

My phone isn’t a server, so I used to wonder — how is push notification even technically possible? After looking into it, I came to the same conclusion: in the end, our phones have always had to pull notifications from a big company like Google or Apple.

When I first encountered Nostr, I couldn’t understand why notifications didn’t work — but now it makes perfect sense.

But then I started thinking — if IPv6 becomes mainstream, could we finally have true push notifications in the literal sense? If every phone can essentially be a server, then yeah — I think it might be possible!

There would be some privacy issues, of course, but still.

And since we’re talking about Pokey, I’ve noticed that alerts often didn’t seem to work properly. I suspect there are two possible reasons:

1. Pokey doesn’t pull from the user’s own nip65-based read relays, but just fetches from some popular relays.

2. The socket connection between my phone and the read relays gets dropped when the phone goes idle.