Hacker News Reader

Comment by jchw | Hacker News Reader

I enjoy the Pinephone, but it certainly has its issues. I’d kill for better performance; it’s very close to usability. I also have some issues with the hardware (it seems my battery has stopped working entirely, recently.)

On the other hand, there is one confounding software issue that I think makes it the hardest as a full replacement for a modern smartphone: push notifications. An equivalent for APNS or FCM that allows for relatively low power consumption, low latency push notifications would need to be devised, financed and actually adopted. It’s nice to imagine a world where apps on phones are like how apps on desktop are and just keep, for example, active WebSocket connections at all times, but this doesn’t appear to be something practical with current technology.

Maybe federated, E2EE push notifications could come into existence? A sort of ActivityPub of pushes... It’s a pipe dream, but one can hope.

View on HN

The lack of a self-hosted push notification system is a massive hole in the user privacy story for users of all phones.

I dream of being able to configure my phone (be it android, linux, or ios) to proxy all communication with push services through a host I control.

At the nitty-gritty implementation level, I kind of hope the LinuxPhone world adopts Matrix as a standardish notification transport.

MQTT seems way more suitable for push. Maybe some system/os level integration needed to make it efficient?

Without mass-market and the scale that comes with it (including returning income from existing users) it's near impossible to provide the same nice UX as an iPhone or a Google-riddled Android phone.

That's the whole problem with most projects and why they neither produce acceptable usability nor a an acceptable price point. It's not that it's not technically possible, it's just infeasible without becoming yet another android vendor.

Even just having an 'alternative OS' on existing hardware is a non-existent market, and those projects try very very hard. Adding the hardware problem in to the mix makes it harder, not easier.

I’m not very concerned with it competing per se; they managed to put out a fairly compelling package and sell through 30k units. Yeah, they won’t be fabbing custom ARM cores any time soon, but it ain’t nothing.

Open source software is a slow burn. It takes time, but projects can grow for a very long time even when things seem dormant, and then suddenly seemingly out of nowhere things are actually pretty good. I certainly was impressed with how well they were able to bring GNOME onto phones so far.

It’ll always work best if people don’t consider them to be on the same level as commercial software; it has a different appeal, but one that should not be discounted. Just as there have been so many “year of the Linux desktops,” so to have there been many incorrect calls about the death of it.

I keep wondering why nobody just supersets Android. Even just having an Android phone which is designed to be repairable and have drivers in the kernel tree so it isn't tied to a specific kernel version, people would pay for that.

And then on top of it you can add all of your Google-alternative libraries and services, which need not be perfect immediately to get people to use it because they can start off running Android apps and buying it for the open hardware. But as you get more users, the software improves too.

The mass market does not care about repairable hardware or open drivers.

Using niche open SoC will make the device slower and/or more expensive. The mass market cares about price and performance.

> The mass market does not care about repairable hardware or open drivers.

The evidence for this is that people didn't refuse to buy the first generation of unrepairable devices. Because nobody told them they were unrepairable until they broke, and by then they already owned it. And by then the unrepairable devices were all you could get.

How many people would buy a phone if you could honestly market it as lasting for ten years instead of three and having a lower repair cost when you drop it on the concrete?

> Using niche open SoC will make the device slower and/or more expensive. The mass market cares about price and performance.

The mass market doesn't care about performance on mobile devices. They can't even tell the difference. It's all marketing. Even the phones that are actually faster on paper aren't faster in practice when the "slower" one still does everything instantaneously.

Agreed.

Even on the deskstop, linux arguably has a less stable GUI. At least on the desktop you can drop into a CLI and fix things. Even if you don't know what you're doing, you can google your way to a script and copy + paste.

Mobile and touch is 100% GUI dependent.

I have a librem 5 and it seems quite a bit smoother than the pine videos I've seen.

In some pine videos I've seen people swiping multiple times before the touch is detected or an action is taken.

I don't know if purism has tighter driver integration, or if the hardware is just faster.

I haven't figured out how to get good apps though.

I found this ubuntu touch video on another type of phone (?) and it looks like stuff is out there:

https://youtu.be/Nf_DnsZHwdE

Someone at Purism once said the issue was related to memory IIRC. So it’s possible that is a piece of the puzzle.

RAM is almost 3 times faster indeed, but it's not the only thing that matters (CPU clock and double the L2 cache, much more powerful GPU, faster eMMC, better thermals). That's not "tighter integration", that hardware is simply more powerful.

Conversations.im does jabber on Android without push notifications. It just leaves an idle TCP socket. I haven't noticed latency issues with that, but I'm not a heavy user

Having each app run in the background and manage its own notifications can work, but also causes battery life issues with more apps.

I mean, if you just have a select() command blocking, I don't see why having a 100 sockets open would be any different than 1 socket.

Part of the problem is that Linux desktop apps typically aren't designed to conserve on network usage and/or don't have mechanisms to do so without a push server.

For example, Matrix clients on Android/iOS will stay suspended entirely, then will wake up when you receive a push notification. Desktop clients, on the other hand, will stay running and receive every message, even if they're not messages that you necessarily care about/that would notify.

The protocol could in theory have an in-band way to tell the server "hey, I really only care about notifications now, could you only send me those?" but currently it doesn't. By contrast, most Android/iOS apps can rely on push notifications and suspend completely when they're not in the foreground - meaning they're not receiving anything but what's important enough to notify about.

> For example, Matrix clients on Android/iOS will stay suspended entirely, then will wake up when you receive a push notification.

Doesn't the protocol already need to do something to support that? Presumably it's an out-of-band notification, and they needed to add support for that. If they already added FCM an APNS, they'll have to add something to support a 3rd OS. It could be in-band or out-of-band, but either way sending a message on a TCP connection is really all that is needed.

As a side note, Jabber did add an in-band way as you suggest, but then also had to add OOB signalling because Apple disallows open sockets for background apps.

> Doesn't the protocol already need to do something to support that? Presumably it's an out-of-band notification, and they needed to add support for that.

Yep, it does, so you could do this; the problem for the Linux desktop is just that there isn't a standardized out-of-band push notification system yet. (I saw another commenter mention UnifiedPush, which sounds interesting - in any case it's not widely supported yet.)

> As a side note, Jabber did add an in-band way as you suggest

It's been a while since I looked into this in detail, but IIRC Jabber generally doesn't have a server-side way to determine which messages should notify? As I recall, the protocol was designed with smart clients and dumb servers in mind, though I'm sure some of that has changed over time - but that design decision doesn't lend itself as well to clients on battery-constrained devices.

Although with that said, the fact that you aren't required to be in the same set of MUCs on every device helps in battery-constrained devices; for example I only stay joined to the rooms that my friends are in from my phone, unless I need to join another one temporarily.

Re: jabber

https://xmpp.org/extensions/xep-0352.html

Client state indication helps for things like suppressing presence updates, but it doesn't go as far as to e.g. let you only be notified for messages that would highlight you in a large MUC, right? So either you're joined to the MUC and receive all messages in it, or you leave the MUC and don't get notified about any of them.

Although now that I read the spec again, it seems general enough that maybe it could be used to implement behavior like that? I don't think I've seen any servers that do, though.

Prosody has an option for filtering MUC messages with mod_csi_battery_saver (which is the currently recommended community module for CSI), I don't think ejabberd does though.

> groupchat messages must set a subject or have the user’s username or nickname mentioned in the messages (or be encrypted) to count as “important”.

You need to keep the connection alive, which means regular traffic, which means regularly sending data, which needs energy. More connections mean a) more traffic and b) unless you add some coordination mechanism, waking up the modem more often at random times, which is energy-intensive in itself.

> unless you add some coordination mechanism, waking up the modem more often at random times, which is energy-intensive in itself.

You just need to coalesce timer wakeups, which Linux supports already at the kernel level AFAICT.

I see, we need some coordination mechanism, and at that point, why not just use a central server to manage notifications :)

The radio is a massive battery draw, so you want it to be off as much as possible. The built-in push notification service will batch low priority packets and send them all alongside the next high priority one it receives.

UnifiedPush is something that's looking to address this.

Mozilla has mobile style push notifications for Firefox and you can just leave eg a mail client running in the background using the IMAP IDLE feature for mail. As long as you restrict that sort of thing to just a couple apps it's fine.

More than push notifications the WiFi firmware needs a feature to whitelist IPs that can wake the phone from sleep so you get instant notifications from services.

> A sort of ActivityPub of pushes...

Now that you mention it, ActivityPub itself wouldn't be bad for this!

Telegram is pretty good at going ding when there's a new message.

Reply on news.ycombinator.com