ezst

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/

> Some use cases like business chat actually can't have E2EE, and that'd probably be Jabber's foot in the door because no other open solution has taken off in business

So, Cisco Jabber (now Webex)? You can't really compete against Microsoft and its bundling strategy. Even Slack is dying, unfortunately.

Of note, Conversations and some other XMPP clients can act as UnifiedPush Distributors (i.e. they use their own reliable persistent connection to proxy notifications for other apps). Some mastodon (tusky, fedilab, …), matrix (fluffy chat, element x, …) clients use it¹

¹: https://unifiedpush.org/users/apps/

Re: P2P, it's kind of making an impromptu comeback. If you want some trivia, IIRC, the developer of Conversations was on some trans-continental flight few months ago and realized that XMPP works just fine on the free onboard internet plan (being considered by the firewall as legitimate "social-usage"), except for HTTP upload. So now, when your HTTP upload fails, Conversations asks if you want to try again with P2P, so you can send your images for free from the plane :-)

I looked into that very briefly about a decade or so ago: it would be very difficult to get it done and maintained in practice. XMPP leans towards the "dumb server/smart client" side of the trade-off, while Telegram is the exact opposite: while an XMPP client establishes and maintains a session and its state, retrieves a list of discussions, for each, requests and processes new messages, and infers reas markers and counts (a bit like a traditional mail client like thunderbird), Telegram maintains the session and the client state on the server and the client is a thin layer to just display it.

XMPP is so bad on mobile that this persistent connection thingy and the whole XMPP protocol itself are effectively what prop up every single push notification on Android and Nintendo switch. True, Android vendors made a habit of killing background apps for misguided battery optimization reasons (less the case nowadays), which XMPP taught itself to work around in 2014/2015.

Same for media, it just works, you should try it? And funny you mention WhatsApp, it's effectively a dialect of XMPP running on a fork of ejabberd.

> if you're a human rights activist or journalist in an oppressive country, I'd stick to Signal

So that the state actor can listen on the edge of the network and infer with whom you are taking and when? Or maximize their chances of finding a 0-day in the client considering that it's the same client that everyone else's using? Or throwing it all away anyways when it's using Apple/Play services for notifications delivery?

I mean, as opposed to using something like XMPP which you can completely use over Tor and never even reveal which server you use/that you use XMPP, from a client running a secure and minimalistic OS and no service-in-the-middle ?

Some would label Signal as a honeypot and it would be difficult to falsify that.

That's a defeatist take that's been vastly debunked, someone linked the Matrix version and here is the XMPP one: https://gultsch.de/posts/objection/

In short, yes, building a standard takes some effort, but that serves your users and to future-proof your solution. Moxie's post boils down to "1- I know better than my users and I don't need input to protocol-design, 2- I'm not willing to put in the effort to standardize and document, 3- I reserve the right to change the deal for whatever reason if I ever feel the need" which is not a good look

Realistically nothing is ever perfect, but XMPP comes very close. You've got Signal-introduced double-ratchet encryption if forward secrecy is your jam (so it's as "E2E-secure" in practical terms) and you've got a healthy ecosystem of independent client and server implementers, and service providers to choose from.