I've seen people mention that the Loops push notifications...

All posts dansup's posts Post Back to profile

I've seen people mention that the Loops push notifications are dark patterns, and that is not my intention at all

I'm not encrypting the notifications and they can be collected by various parties (NSA, Apple, Google) so I didn't want to include any more metadata than I needed to

Hope you understand!

#loops #pushNotifications

Like 27 April at 13:37 | Open on mastodon.social

15 comments

Emelia 👸🏻

@dansup why not just encrypt the notifications?

1 27 April at 13:38 | Open on hachyderm.io

dansup

@thisismissem I will eventually, I don't know if Expo even supports that, because that is what I'm using for now.

27 April at 13:39 | Open on mastodon.social

Lyyn ☮️🦄 #2024-02-16

@dansup @thisismissem I am not sure how it works in the Apple ecosystem, but on Android the solution most apps use is sending just a ping in the push message, and then the app fetches everything it needs and displays the notification itself. It adds some latency, but not very noticeable.
I really think that what Google and Apple calls push notifications (where the push message actually contains all the data for the notification) is a bad thing and should not be generally used. Especially because it's really inconvenient to encrypt.

Expand text...

27 April at 13:50 | Open on mastodon.ml

alina 🌸

@lyyn@mastodon.ml @dansup@mastodon.social @thisismissem@hachyderm.io

> ping in the push message, and then the app fetches everything it needs and displays the notification itself

yeah afaik on ios that requires a special entitlement by apple which they are quite unwilling to give away

27 April at 14:13 | Open on very.stupid.fish

Григорий Клюшников

Lyyn ☮️🦄 #2024-02-16, Mastodon's push notifications work by sending the data in the notification itself, encrypted by your server. This makes it more reliable than just a ping that "something happened" that would make the app do an API request to retrieve the actual notification.

Unfortunately, you can't sidestep the need for a centralized notification service if you care about battery life, which I imagine most people do. So end-to-end encryption will have to do.

2 27 April at 14:31

Lyyn ☮️🦄 #2024-02-16

@grishka @dansup What I proposed does use centralized notification service (although changing it to UnifiedPush would be preferable, and it's even worse there wrt encryption afaik) and does not drain battery.

Why do you think it's more reliable? I think the only downside is that the app needs to do another request, process all the state, and only then can it show a notification, which, as I said, adds latency.

27 April at 14:34 | Open on mastodon.ml

Григорий Клюшников

Lyyn ☮️🦄 #2024-02-16, if your network connection is unstable, e.g. due to a weak signal or being on a subway train, there might not be a chance to do that request. You have to always assume that any network request can fail, and given enough users, it will fail, every day, thousands of times. So if you can avoid making an additional request, do avoid it.

1 27 April at 14:39

Lyyn ☮️🦄 #2024-02-16

@grishka @dansup Agreed.
I'm still skeptical about WebPush's encryption, partly because I remember there being some differences between WebPush and UnifiedPush which make them incompatible when encrypted.
And in the end the app decrypts the message, right? Or is it the "distributor" (in UnifiedPush terminology)? I would prefer for the decryption key to not leave the app.