2 ms·

> push notification... That is so totally the fault of the mobile networks and OS people The issue for mobile is that unrestricted push notifications are a ser

by afiori 6y ago

> push notification... That is so totally the fault of the mobile networks and OS people The issue for mobile is that unrestricted push notifications are a serious battery drain. I think that JMAP makes the correct choice here, a push notification is just an external action/url, how the notification is delivered to the human is left out of the protocol. I would say that it allows for both openness and centralization without a bias for one or the other.

saurik 6y ago
Yes, I both understood that, acknowledged it, and then not only noted that a better solution was available but actually sketched how that better solution would work ;P. Given the poor incentives on the platform players here, I will thereby repeat the part where I understand and acknowledge the issue, but am going to then once again note how sad I am that we are in a world that didn't just solve this issue in an egalitarian way that doesn't require middle-man (using a flow control layer for wireless IP, rather than simulating that using an oligopoly of middle boxes).
- afiori 6y ago
  oh, the reason for my answer is that I implicitly assumed that something like `a flow control layer for wireless IP` capable of solving the problem could not exist. Or better I cannot even imagine how it could work. My understanding is that a important property is that the device does not receive network packets that are not "replies". So that it has control on when it is fine to power down the network (in a very gross simplification) So maybe something like what you are describing would be a protocol where the client can say "pin me back with this for this category of events but no sooner than X minutes", but at a network level, like a tagged TCP sleep function. I never thought of this possibility. In the form I have imagined it it is technically inferior, but it would be an interesting approach to decentralization and surely could be improved.

by afiori 6y ago

saurik 6y ago

Yes, I both understood that, acknowledged it, and then not only noted that a better solution was available but actually sketched how that better solution would work ;P. Given the poor incentives on the platform players here, I will thereby repeat the part where I understand and acknowledge the issue, but am going to then once again note how sad I am that we are in a world that didn't just solve this issue in an egalitarian way that doesn't require middle-man (using a flow control layer for wireless IP, rather than simulating that using an oligopoly of middle boxes).

afiori 6y ago
oh, the reason for my answer is that I implicitly assumed that something like `a flow control layer for wireless IP` capable of solving the problem could not exist. Or better I cannot even imagine how it could work. My understanding is that a important property is that the device does not receive network packets that are not "replies". So that it has control on when it is fine to power down the network (in a very gross simplification) So maybe something like what you are describing would be a protocol where the client can say "pin me back with this for this category of events but no sooner than X minutes", but at a network level, like a tagged TCP sleep function. I never thought of this possibility. In the form I have imagined it it is technically inferior, but it would be an interesting approach to decentralization and surely could be improved.