ezst

Congrats, you just described XMPP

Yeah, because the obvious solution to the problem of having too much bots is… more bots.

Conversations is a XMPP client, it's essentially the same protocol that delivers reliable notifications to every Android, Nintendo switch, etc. Unless you have an Android distro that kills every background app indiscriminately, you will be fine with Conversations delivering messages and notifications to you.

Interestingly, the link you posted relates to Unified Push, which is a protocol that relies on a "distributor" app which acts as a proxy, receiving reliable notifications on behalf of other applications. And it happens that Conversations can be configured as a UP distributor, because of how good it is at that/how well the XMPP protocol lends itself to it.

Long way to say you should give XMPP a shot, it really works well!

Notebookcheck¹ measured 17.5h of wifi+websurfing battery life and 12.5h at 500+ nits, how long are the days on your planet effectively?

Also, that's on Ryzen AI 7 PRO 450, you might be getting even more out of the Panther Lake alternative.

¹ https://www.notebookcheck.net/Excellent-business-laptop-with...

I feel we've been there before, I clearly remember the compiz/beryl years: they were not just about bling being added to traditional window manager and desktop environments, new window management paradigms were being experimented with (using 3d walls to stick windows and icons on, circular action menus, etc). Whatever stands to supersede the ubiquitous WIMP paradigm has to come up with substantial gains.

But that's not answering my question? What do you expect to get from today's ARM chips that's fundamentally impossible otherwise? And how is that a step forward?

T14 gen7?

And how exactly does that matter? How close do you have your head to x86 assembly for the instructions set to matter?

My side of the Engineering discipline is about designing and building plants (energy, pharmaceutical, petrochemical, ...), here standards are written from the blood of the killed or injured, engineers are very aware of it all, and yet, you should see how our C-suite get hyped by the LLM fad, and distributes promotions for whoever is the latest to find new ways to cut new corners or introduce unwarranted randomness in previously well established processes. It's awkward, to say the least.

"look, MacOS is following the same trend as windows as to become measurably worse over time, with bloat, slop, user hostile/dark pattern, removing freedoms configuration and escape hatches"

"KDE is immune to those by design"

"Then use Windows"

I'm surely convinced!

Not sure what the point of this would be? Devalued street creds for running something nobody else does? Who cares?

KDE. KDE is all you need.

Yup, I would love to try it in-hands (I looked it up on emulator many years ago, and that was frankly underwhelming). I'm also not sure about their open source situation, which was the premise of this thread.

And yet, the single vastly dominant source of electricity at around 55%. It's a long way you go and a long shot to call it clean.

> at least the energy comes from solar

If by that you misspelled coal, sure

https://ourworldindata.org/grapher/share-elec-by-source?coun...

I would say that I've been doing most of that already with a reverse proxy+SSO/IDP for a very long time. Not the same, but close-enough and open to the "traditional internet" in a manner that does not require my users to install and configure tailscale, which is a massive plus. I do appreciate tailscale for the option to keep my effective host IP address hidden/local, but then I've been having a front on the internet (with a public IP/domain/...) for decades and I don't see a problem continuing.

Not even wearing rose tinted glasses right now, for having daily driven them back in the days, maemo and then WebOS had touch ergonomics and multitasking abilities which took Android/iOS decades to incompletely mimic. Maemo/Nokia N900's design principle seems to have been "let's provide the user with desktop-level productivity tools, and shrink the desktop into their pocket", the package was massive for the era's standards, but is tiny for today's, and those dumb-down/low density ergonomics we have now give us less capabilities for more screen estate and weight (even something like an iPod pro is a "dumb" content consumption device in comparison). WebOS on the other hand was not about "producing/delivering on the go" so much as it was about getting your digital must haves (booking an appointment, updating a contact details, moving a meeting, ...) done and out of the way with just a couple key presses and finger flips as so distract as little as possible from the present. Only some advanced Android launchers get close, but it's never the focused, well polished and distraction-free experience it was back then (and for the same reason, Android/iOS are addictive content delivery vehicules meant to sink your eyeballs and time as to sell you stuff or collect and merchandise your data).

I'm interested and wishing to see a future mobile OS that does not pander to the "attention economy" like Android/iOS are, but with billions now addicted and trapped by it, I'm realistic that it won't be an overnight success.

> I don’t want to dwell on drama, but it is perhaps worth mentioning that we reached a sad end for jemalloc in the hands of Facebook/Meta even though most of the people involved were acting in good faith.

Far from the only case. Trillion dollar companies having sudden interest in your open source project is not necessarily a long term benefit.

At what point exactly are those companies going to be held accountable and punished for their irresponsible behaviour and overall disregard and negligence for security and ethics practices?

If a researcher causes harm by accidentally unleashing a virus, it's his/his company's fuckup, but if a researcher causes harm by accidentally unleashing a virus by proxy of a LLM running commands, it's because AIs are too powerful? If I run over someone in a speeding car accident, can I too blame it on cars being "too fast and powerful"?

For the curious, the note taking app Trilium has a "standalone" mode¹, built on top of OPFS² and sqlite OPFS persistence, such that your notes (~web pages here) are stored in sqlite locally, offline-available, optionally syncing with a remote, while being a pure local web app (after the app assets have been downloaded once). If you want to take your whole personal notes/wiki/pkms for offline access on a device you don't own/have install rights, that's the only way I know. I suspect that OP could have gone this route instead had he known about it?

¹: https://app.triliumnotes.org/

²: https://developer.mozilla.org/en-US/docs/Web/API/File_System...

³: https://sqlite.org/wasm/doc/trunk/persistence.md#opfs

Teams. Your CFO keeps telling your head of Projects/Engineering that he's already paying for it anyway. And your helpdesk loves it because it's sharepoint all the way down and up, and they can shine their "Microsoft Certified Kung-Fu level Sharepoint Master Accreditee" certification.

Precisely, which isn't much, and on top of that, you would have those modified as well to map to XMPP concepts and specifics. That said, I do believe that XMPP deserves a beautiful Qt client. There is Kaidan (QtQuick), but it's very opinionated (practically incompatible with groupchats and preferring a mobile UI paradigm)

Are you a LLM? In this context, a third party client clearly refers to "a Signal app/client software that's not distributed by Signal",

The point I was making is that this goes against Signal's terms of service, and can get your user account terminated. That's a very oppressive clause in practice, you may want to use a non-signal client for all kinds of legitimate reasons (porting to a non supported platform, to adapt for accessibility needs, for privacy, for compliance, to remove nagging and dark patterns, etc). Signal don't want that, they want to control your user experience, even if this makes it worse for their user.

As a XMPP user in the modern times, XMPP ecosystem and its alleged fragmentation affects me and my users about… never. Every major platform has at least one decent client that support all essential features (reactions, message corrections, A/V calls, easy onboarding, modern encryption, …) and every one of them receives a healthy flow of contributions. Client developers talk to one another, coordinate protocol discussion and features roll-out (reactions for instance didn't happen "overnight", but pretty close).

I'm certainly not willing trade a theoretical minor annoyance in exchange for my (literally) vital messaging needs to be subject to enshittification, or abuse by a single actor (which controls whether I can access the network, when, whom I can speak with, what features I am allowed to use, and whether it's time to rope me into buying some cryptoshitcoin).

I've been self-hosting XMPP for slightly more than 10 years now. I started out of necessity with 2/3 family members, so I would have reliable messaging while travelling on a tight bandwidth, and/or to places that would censor the usual alternatives. This turned into 20+ family members over time. Old friends, then colleagues, joined in about similar proportions. I'm experienced enough to never have "pitched it" or tried to "sell it" to them. I only tell them that this is what I use, and that, unlike the other commercial things they may be familiar with, it will keep working for as long as I'm alive to pay the hosting bills. That generally gets them curious-enough to try. About colleagues, some eventually start using it among themselves because it's a more "relaxed" experience than using Teams on their phone. I won't change the world that way (nor do I intend to), I just think that there is room for more than just one monopolistic and slowly-enshittifying network, and plenty for XMPP.

I'm just a hobbyist sysadmin, but I did get a ton of exposure over the decades deploying some pretty random stuff, often taking the long and painful way as a learning experience (rarely using containers, often compiling from source, …). I vividly remember deploying ejabberd for the first time in disbelief: for all it was doing, it was just a fire and forget/good defaults/good logging/self-healing experience. Highly recommend.

It doesn't matter as much as you think. Office workers around the world are using email(/IMAP) just fine. Jabber/XMPP was used today to the satisfaction of everyone when I video-called my 90 years-old relative. All she had to do was to scan some QRCode a decade or so ago when I on-boarded her. XMPP isn't going anywhere. As I wrote in a sibling post, it survived 2 or 3 generations of commercial messengers, and only got better and more relevant in that timespan. It's far from dead. I'll probably be dead myself long before it does.

I really don't understand this attitude. The landscape has changed in 25 years, XMPP was built from the ground-up for extensibility. And that was the right approach, since it managed to improve continuously, and is now on par with the dominant alternatives. In that timespan, it survived 2 or 3 generations of messengers. It will survive Facebook, WhatsApp, Telegram and others (which, by their proprietary and centralized nature, are prone to enshittification).

For anyone paying attention, it should be the clear "safe bet" for what to try next/keep at hand somewhere.

And Google Talk. And WhatsApp.

https://www.process-one.net/blog/whatsapp-facebook-erlang-an...

1) I think that's by design: you've got two ways to use OMEMO, the "friendly (default)-way" (with BTBV, Blind Trust Before Verification), and the "paranoid-way" (where you verify each and every device). In the latter, you don't want your messages to be encrypted for a new, unverified device (as it could potentially be that of an attacker): you can either verify the new device yourself, or your contact can verify theirs and you verify them again. Like I said, that's not for everyone. And if you are not that paranoid, then verification is an afterthought anyway and you don't lose or gain much with verification anyway.

2) That's where MLS¹ kicks in, essentially a new encryption scheme that's suitable for large group chats. There are projects² for its adoption in XMPP. I have no strong opinion about MLS, but I tend to think that it's more for the gimmick and having XMPP score well in random protocol benchmarks: if you've got such a large groupchat that OMEMO doesn't scale anymore, you have a groupchat with so many participants that it is only private in name and more or less encryption doesn't matter.

¹: https://en.wikipedia.org/wiki/Messaging_Layer_Security

²: https://nlnet.nl/project/XMPP-MLS/