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.
Discussion
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". :)
have to agree with nostr:nprofile1qqsr9cvzwc652r4m83d86ykplrnm9dg5gwdvzzn8ameanlvut35wy3gpzpmhxue69uhkummnw3ezuamfdejsz9thwden5te0wfjkccte9ekk7um5wgh8qatzqyt8wumn8ghj7un9d3shjtnswf5k6ctv9ehx2aq38qmrf on this one
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.