what do you think about libsignal-protocol-c?
Conversation
I think that's a lower-level component than libsignal-service-java equivalent to github.com/signalapp/libs. It's the cryptographic protocol rather than the higher level messaging protocol. They use the C code in the iOS app and the Android app and server both use the Java code.
2
yeah, I mean, what do you think about building something on top of it? because i'm annoyed with Signal Desktop badly enough i want to do that.
2
2
I'm wary of building anything on their code or forking anything to make changes because of their hostility towards alternate clients using their servers and their lack of need to preserve any backwards compatibility due to forcing upgrades, which is an overall positive thing.
1
2
There's the option of running the Android app in the official KVM-based Android emulator but that only acts as the main client rather than a secondary client like the desktop app. It honestly probably uses less memory than Signal Desktop, especially after being open a while.
1
i heavily rely on desktop notifications, so if i had to resort to that i'd probably just pick a different client entirely
1
I think KDE Connect can bridge the notifications including replying to them from the desktop but I'm not sure if that requires using KDE. I just feel like trying to use an unofficially supported client is a recipe for ending up needing to do a fair bit of work to keep it working.
2
I use KDE Connect already, but the Android app -also- sucks. Sometimes I get a message on the Desktop app and five minutes later long after I read it the Android one finally sends me a notification.
1
I'm used to the non-GCM push implementation on devices without Google Play which works essentially the same way as the desktop app. GCM is efficient but it's not particularly reliable and often has delays. The efficiency is mostly from apps reusing the same connection anyway.
3
1
I don't see any fundamental reason GCM should be more efficient than a properly written application sleeping in a poll or a thread making a blocking read from the notification socket. It's more a matter of apps being idiotic or maliciously doing other stuff in the background.
1
The reason it's more efficient is that it's a single connection with highly optimized rare polling based on a good heuristics for tuning the frequency of the polling. If the apps all use the same polling interval and coordinate it with flexible alarms it wouldn't be that bad.
It's not what happens in practice though. The apps all have varying quality push implementations, lots of them simply poll rather than using a connection to push notifications. They use different intervals for checking and don't schedule them in a particularly efficient way, etc.
1
Once someone installs 20 apps doing this, it gets pretty bad. That's why they ended up wiping this out with App Standby / Doze and forcing everything towards using GCM unless it runs a visible foreground service and gets a battery optimization exception.
poll does not have a frequency of polling unless you misuse it by passing a timeout. It sleeps until there's data.
1
The issue is that connections often break in practice without notifying you, so you need to regularly wake up and send some data both to keep the connection from being killed and to make sure that it hasn't died yet. It's particularly bad with most mobile data connections.
2
Show replies