I campaigned for this for years when working on fuchsia, to folks in fuchsia and android folks.<p>We lack a unixy API for “the radio is now on, do your reconnects or send your queues”<p>The platforms always hoist this stuff higher level and it rarely works that well.<p>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.<p>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's disappointing to see everyone freaking out about this while ignoring the hundreds of different analytics SDKs littering every single mainstream app out there that leak even more metadata and store it on the provider's server (unlike push notifications which can be end-to-end encrypted).
I'm using Zoho as my main email hosting provider. Can I use tuta as the client? Should I?<p>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.<p>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!
> Final thought: Every user should be able to choose a "Notification Provider" for every app<p>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.<p>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?)<p>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.
This post is much more informative then I'd expected from title and comments. It opens with:<p>> 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.<p><i>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>
Why not just use UnifiedPush, which is already an open standard? Or, like other libre apps are doing, provide an option for external open providers, such as ntfy, Nextcloud Push etc.?<p>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.
People really don't understand the attack here.<p>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.<p>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.<p>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.<p>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.
We already have a Push API specification that supports arbitrary push server URLs and self-hosting. It's called the Web Push API, although it can be used for mobile push as well.<p>The only problem is that no one is using it.<p>A bit longer comment on it:<p><a href="https://gist.github.com/indigane/70ed13d5287c2d18b3e8e5d4f0c6d119" rel="nofollow noreferrer">https://gist.github.com/indigane/70ed13d5287c2d18b3e8e5d4f0c...</a>
Why don't people disable notifications? It must be really annoying if you have 10 apps and every hour they distract you with messages like "buy now! A new product with 10% discount (and 300% markup)" or "where are you? you haven't been watching videos from StupidBlogger for 1 hour".
The pushing services must be running in the background constantly to provide the push notification services. This is how apps can receive notifications without even running it.<p>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).
rich coming from tuta who still lack a onion based login. this ticket from 2018 was locked as off-topic. <a href="https://github.com/tutao/tutanota/issues/528">https://github.com/tutao/tutanota/issues/528</a><p>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.<p>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.