We lack a unixy API for “the radio is now on, do your reconnects or send your queues”
The platforms always hoist this stuff higher level and it rarely works that well.
Platform leads insist the platform will do it better, but it’s never true. They also insist that persistent connections are battery killers - which for sure they _can be_ but done properly (and with the aforementioned api) it can work just fine.
Establishing such an API in the Linux and BSD ecosystem would make a good step toward encouraging its exposure in the places we need it.
It is definitely the case that doing such things efficiently, especially in the world of evolving radio technology, is beyond the absolutely overwhelming majority of mobile app developers, and apparently in many cases even very good ones. It also seems unlikely that having the platform poll a process to then do the push (as your API would, in response to something like a radio burst about to be made) is a good idea, as keeping the app process asleep if at all possible is distinctly preferable, and most devs struggle with what is a real time constraint. An API to achieve this is definitely buildable though, it does require offloading a certain amount to the platform.
The truth is centralized services are strategic for the platform owner these days, so any technical argument for them will really be on that basis.
There’s however a big difference between an interface coming online, an interface getting its addresses, a particular address being resolvable and reachable, and the particular address being routed to the place you actually want to reach. In an ideal world, you want all four; NM kinda sorta has it. There are d-bus APIs, just maybe not easy to use in shell scripts CLI tools.
Would be interested to hear how you & others approach this. Perhaps I’m not thinking systemd-y enough hah.
There is no way around it: “everyone freaking out” is actually powered by attention seeking algorithms taking shots at what works.
Apple has taken a very strong stance on privacy. This forces everyone else to keep up. But without any understanding of technical complexity, most customers only really have faith and marketing to go off. These headlines deliver serious blows to that image.
I think this is great news for the rest of us. We should be weary of every detail of how these devices work. And if they’re claiming to take the high road, we should be paying attention closely when they’re not.
Man I went to a supermarket website the other day and received 87 cookies for free
I like Zoho stability and pricing. And, the client is somewhat poor compared to Gmail, to be honest. I like the scheduled send and snooze options of Gmail, but cannot figure out if Zoho provides similar functionality.
What is the best client for non-Gmail? Scheduled-send and snooze are probably server side functionality, so it isn't just the client. But, there must be a better client than the Zoho one!
I configure Zoho into my clients devices for them in their phone mail app (with iPhone I use EAS so they get the email instantly with push). For my personal Zoho addresses (admin stuff) I have them send to my FastMail account. I really like FastMail's web app and Android app. So much better than Gmail and I have had only one or two minor issues with the Android app, usually when I have a spotty connection.
I'm not sure I understand which clients and which services you use here. You use Fastmail, which is a paid service for email, right? But it sounds like you also use Zoho services as well. Why both?
Zoho is so cheap: I pay $12/yr for multiple domains and multiple email addresses on each domain. It was a little tricky to validate the domains and get them added, but it's been smooth sailing ever since.
Should I add Fastmail in the mix? What does that add here?
That is too much I think? It would be weird to trust one notification provider for some stuff, and another one for others? Every user should be able to choose a "Notification Provider" is IMO enough.
On that front, there is already a push standard which is called WebPush which allows to do this seemlessly. Except it's only in browsers (also I don't think any major browser allows customizing it?). On non-Google Android, you have UnifiedPush. (It isn't a standard. Not sure it would make sense to make a standard of an Android API?)
I've been thinking of making a OwnerOS: a bare Android who lets users pick every component they want. You select which store you want, which assistant you want, which notification provider you want, which SystemUI you want etc. All of which currently require to root your device to customize.
My understanding is that this uses centralized servers maintained by each browser vendor.
> We're here to stop surveillance by corporations like Google and Apple. That's why we replaced Google’s FCM with our own notification system and keep Apple Notification Data at a minimum. Read on to learn why this is important.
Edit/Note to self (and maybe others): Be conscious of how much time I spend reading about actually doing things and their details vs reading/discussing a meta to actually doing things. Certain meta discussions are useful, others only feel useful but don't amount to anything.
I agree with the writer, SSEs have a lot of untapped potential and they're way less resource-hungry than Websockets. But if every app implements its own SSE manager, it'll still be a lot of overhead on the system as a whole. Better rely on a 3rd+party open app like ntfy that takes care of forwarding/dispatching all the notifications, and other apps don't need to create a separate listener.
It does not matter who is providing the notification service. No amount of encryption (actual E2EE encryption) prevents that ability for a government agency or criminal enterprise to functionally compromise the service to determine which users are getting push notifications from which other users or services.
It also does not matter if you use push notifications (which are vastly better for performance by every metric), or polling. Necessarily the intermediary (Apple, Google, Signal, FB, etc) know the origin and the destinations of anything that would currently be a notification. Requiring polling does not stop that.
Having lots of different services does not stop it either: the orders given to google and apple can just as easily be given to any other company or organization, and more importantly it sounds like google and apple were only able to say anything because a US Senator explicitly asked them so we have no way to know if any organization that was not explicitly asked is also subject to the same orders. The same applies to a criminal organization compromising such a service, only providers aren't prohibited from saying anything, they're just oblivious.
If you are using a service that necessarily involves a third party, that third party can be subject to orders that require them to turn over anything about you or messages you send or receive, or criminals compromising the provider watching the same thing. Encryption (real encryption, not just TLS, not "no one other than you or the provider can access it") can only protect the actual content, the sender and the receiver cannot be protected.
Nobody is going to break the law on your behalf. Nobody. Not even this smug email provider who did what they did because they didn't want Google to have metadata.
Developer documentation has stated, from the very beginning, not to put sensitive info into push notifications. If you absolutely must, encrypt it with a key that they don't have. An ideal push notification is "Hi", and the app should know what to do with that. Whatever shows up on your phone screen was generated entirely on your phone and isn't sent to any server, and can't be recovered using these legal requests. Unless the app developer is stupid, in which case why would you think that another service is going to change that fact?
The only problem is that no one is using it.
A bit longer comment on it:
https://gist.github.com/indigane/70ed13d5287c2d18b3e8e5d4f0c...
Second, the Web Push API is just a unified API for websites to use Google/Apple/Mozilla notification services, which the article is trying to avoid.
I ditched a samsung galaxy note because of that, it would do stupid things like send me a notification for each local NFL game, which I couldn't disable. Amazon's kindle app and amazon prime video app did similar.
It's pretty easy, I'd expect anyone that values their attention to remove the app or silence the notifications.
I don't get why people allow marketing notifications. If an app gives me a marketing notification without a way to disable it, that app gets uninstalled immediately. (Apps shouldn't even put up marketing notifications without you opting in first, but sadly this is the world we live in.)
But sometimes the notifications are useful… taxi/Uber has arrived, SMS/Messages, calendar reminders, important Slack channels, etc.
How about messaging via wide-spectrum dead-drop hopping? (redundant array of inexpensive drops?)
I like Pushover's protocol design: <https://pushover.net/api/client#websocket>
If every app uses its own push notification services, an average consumer may end up with half dozens of those notification agents running consuming more RAM and battery life. For Android devices this might be OK (8-16GB RAM nowadays) but for Apple, this may not even be possible for its RAM size (<=8GB).
Remove computers completely, they’re just noise.
Nothing but Stone Age tech allowed.
as lenin said, the best way to control the opposition is to lead it. for me, unless the company has been raided by the government they simply cannot be trusted.
apple proudly advertises privacy on huge billboards while sharing everything they are asked under shadow laws. absolute hypocrisy and double standards. but then they wouldnt be where they are without government money and favours.
I don’t know anyone who interprets Apple’s stance on Privacy as “They will break the law for you”, only in contrast to… everyone else (?) selling your advertising data?
> I don’t know anyone who interprets Apple’s stance on Privacy as “They will break the law for you”, only in contrast to… everyone else (?) selling your advertising data?
I know that most people will assume that everything is private and hidden away based on their marketing campaigns; assuming that privacy = breaking the law is something you are foisting on, and is in poor form.
Either you are deep inside the HN/Apple reality distortion field or avoiding acknowledgment that a problem has existed for a long time, which needs addressing. This isn't uncommon on HN sadly, I will usually see similar mental gymnastic performed whenever there's any slightly negative news about Apple.
