Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)KI
Posts
72
Comments
281
Joined
4 yr. ago

  • I use it, but on wayfire, because I like it more than kitty, though I have to use alacritty with screen, since it doesn't support tabs, which is the only thing I wish alacritty would add, but I can deal with screen OK. What do you mean with window decorations? They look pretty normal to me, like the ones on electron apps now a days...

  • The phone doesn't poll, instead it goes to sleep, and gets awakened by the push notifications. Just like GCM/FCM ones. Part of the key thing, because not any one can self host, is that it requires very little information in comparison, and some providers are open source and even free SW. The one I use is ntfy, there's the next cloud (next push), and not long ago you can use the conversation push service (up.conversation.im) through the Convesations xmpp client. I was aware of Conversations capable of becoming a unified push distributor, but actually was looking for it to use a unified push distributor instead.

    But I was informed already it's not necessary, and doesn't make much sense, by being very low power consumer, even though it requires to keep unrestricted battery consumption on the background. So no issues by Conversations not supporting using a unified push notifications distributor.

  • ohh, I see, is there a setting, besides unrestricted battery use, one can should set as well then? I remember another about background use, but can't seem to find it...

    This is the first post that clarifies why there's no need for unified push notifications, but still conversations supports GCM/FCM push notifications. I seem though for those phones unified push notifications would help, the same way GCM/FCM does? At any rate, for battery purposes I got it's not required.

    Many thanks !

  • It depends on the distributor:

    https://unifiedpush.org/users/distributors

    And how much info they collect. I understand the ntfy requires is really bare minimum compared to what GCM/FCM asks and collects.

    On mobile, it's sort of a needed if you one doesn't wand to use GCM/FCM which is really bad privacy wise, and particularly needed on peer to peer applications, because they tend to drain the battery...

    Some other benefit is that for those who can, they can self-host ntfy, nextcloud with unified push provider, and so on...

    On the list of apps supporting unifid push, I even see element (matrix), but I don't identify any xmpp one:

    https://unifiedpush.org/users/apps

  • Yeap, I noticed it being a unified push distributor, actually in its settings on can find the option to enable it.

    OK, I won't worry about battery usage then. But the argument about unified push notifications not being useful, but the GCM/FCM actually found useful is somehow hard to understand. But I understand what you're saying about battery usage. Thanks a lot !

  • Ohh, thanks, I'll try asking there...

    BTW, before molly supported unified push notifications, it was also using websocket and that still required to enable unrestricted use of battery, as currently conversations does. Once I the unified push molly version showed up, such unrestricted use of battery was no longer needed. Websocket definitely is much better than GCM/FCM, but it implies, I believe more battery consumption, though perhaps not unbearable.

    Jami was also using websockets and required to allow consuming battery on the background as well, and then moving to unified push no longer required that, but in the case of Jami, by being peer to peer, the effect is more noticeable.

    All that to say, that other apps have moved to unified push notifications for better battery savings, even though they used websockets before, and curiously enough conversations does take advantage of GCM/FCM push notifications, so is not clear to me why disregarding unified push ones, but it's always up to the developers/maintainers, and what they need/want to invest on... So that's why I mentioned I don't quite get what was mentioned on the github issue, though it was clear to me there's no intention to provide the support.

  • Ohh, thanks for that... I noticed when under the office's VPN, it doesn't work, :( Which is really bad to me, since it then block any services from it, :(

    It seems like disroot doesn't like the office's cert when connected through VPN...

    Thaks for replying !

  • If the distro supports apparmor, then firejail + apparmor offer together sandboxing for quite a set of applications (apparmor includes few profiles by itself, but firejal has quite a few, and one can enable apparmor on all, or the ones wnated). Arch has pretty good wikies about firejail + apparmor.

  • Bloated and unnecessary if freeSW or openSW. That's what system shared libraries are for. If sandboxing is a thing, then firejail is availble, which can be combined with apparmor if looking for extra MAC security.