u_tamtam @ u_tamtam @programming.dev

Posts

6

Comments

454

Joined

2 yr. ago

Many communities went back to IRC, though, because Matrix still is a hot mess, and the most visible ones which didn't (Mozilla, KDE, ...) are not hosting their own Matrix instance but letting New Vector do that for them, which makes in practice a disproportionate amount of users and accounts be managed by a single organization. I do think it's better than discord, but barely so.

Sliding sync is just your client running on the server. Now your server's load is even worse. If you self host, well, too bad. Be a New Vector customer I guess?

Don't ever bring this to the people in charge or you might be told "sorry for that" "but now it's been fixed, deployed any week now" "you are a liar, this has never been true" and "it doesn't really matter for the general case" either in the same post or few responses apart. Matrix has been in a permanent state of unstable mess, and the leadership disingenuous attitude made me lose hope that this will ever change. More people should start reading through the fanfare and superlative blog posts, which, admittedly is the thing they do the best and much better than the other projects out there.

Ohh cut the drama already, that's just bzseless speculation.

The person you're talking too can be on a different one and their admin can see them too.

That very much depends on the protocol and type of federation, but a good point indeed

Also, I wouldn't want to be able to access content from any user - it's a "no trust needed" thing.

Sure, but e2ee also comes with lots of trade-offs and strings attached, that almost only ever make sense in case of extreme centralization (i.e. in a non-federation, where trust in the faceless provider is not an option). PFS means that setting up a new device is a PITA because you can't access your full messages history on new devices without off-band synchronization, no server-side search means that clients are either limited in this area or have to carry large histories and inefficiently search themselves, MITM/server-mediated attacks are only mitigated with verification (on top of encryption), which is a UX disaster for users non-versed into crypto (and this complexity is imposed upon such users no matter what), etc, etc.

Of course I'm not advocating against e2ee in the general case (and quite the opposite at that), but if you self host (topic of this community) for yourself and few family members, the downsides quickly outweigh the benefits and so I believe that e2ee should be left at the discretion of the users.

If your system is based on docker, couldn't you just use the official docker image I linked? Besides, I wouldn't recommend openfire, not because it's not a capable server (it's been to long since I tried it to have a meaningful opinion), but because it has less widespread usage than ejabberd/prosody, and by extent, probably less resources to help you configure it to your needs.

I know it's not the topic of this thread, but you are not making a convincing case (to me!) for a "docker-compose simplified one click solution" that pulls you away from the most popular and well maintained alternatives :)
And you will also likely encounter things down the road pertaining to firewall configuration, domain name resolution and port multiplexing that containerization will turn into a configuration and troubleshooting nightmare, so… enjoy! (or not)

If you wonder about raw performance, the two were benchmarked by phoronix recently

https://www.phoronix.com/review/raspberry-pi-5-benchmarks

It says it's federated. When you are your own provider, e2ee doesn't matter nearly as much (you probably have a bunch of personal files, backups, services running on the same box anyway).

Edit: I would gladly take constructive comments with the downvotes. For a moment I thought we were on "selfhosted", where "you are your own provider" should resonate in with most

No idea what the heck casaOS, but here you get your turnkey XMPP servers (if you really don't want to use a distro that packages prosody/ejabberd, which are all the ones worthy to be used anyways?):

• https://snikket.org/
• https://www.process-one.net/en/ejabberd/downloads/

😂

I have no idea what compromises you are talking about. I have SO, parents and many more, of all ages, abilities and systems having joined XMPP

...and by that, I meant not just them logging into XMPP, but XMPP effectively dislodging WhatsApp and all other centralized proprietary apps, for the whole family. There is absolutely nothing they miss in terms of features using XMPP for day to day communications, and even the less savvy/older folks understand and appreciate that the niece's birthday pictures are stored on the family NAS and not on some facebook server.
Compared to Matrix, they get something that's fast, light on their battery, light on their data plan, that has instant message delivery, that works behind firewalls (thanks to SRV and https multiplexing), has zero downtime, and more importantly, zero vaporware features like threads and spaces that barely work. I created our very first family room in 2015, and we've been using it uninterruptedly every single day since.

Matrix is no alternative to XMPP for us. I tried very hard to make it work, but the running costs, the admin overhead and the constant need for user support (because you've got to explain basic features which are counter-intuitive like encryption, not to use this or that feature, why we've got to migrate rooms, why messages to the outside and to bridges sometimes take a long time to reach without notice nor warning, ...) just makes it impractical and gives a bad impression. Matrix just isn't that good when self-hosting.

You mentioned siskim as the best alternative for iOS which - looking at the main page and open github issues - does not seem to support reactions or group messaging.

I can assure you that Siskin supports groups. And reactions is a good example where Matrix could learn a lesson or two from XMPP and its extensibility and concern for compatibility: instead of splitting the world between clients that support the feature (i.e. Element and the poor suckers left behind), in XMPP land, reactions appear as reactions in clients supporting them, and as cited messages + emojis elsewhere. Not supporting reactions is sometimes a conscious choice by developers (for e.g. performance, accessibility reasons or limits of some platforms e.g. TUI), and this is totally acceptable because the meaning/intent of the discussion isn't degraded.

especially considering the smashing success that they've had pushing out Intel

That's kind of the point being made in the article, though: they could succeed in the chip game thanks to a multi-decades head-start from ARM, and a decade on top of that of co-developing semi-custom designs for the mobile market. Apple management convinced themselves that this would be a repeatable feat, oblivious to the fact that modem is a the completely different beast.

Apple should eventually find success in going vertical with the modem, and when that happens, Qualcomm will learn what being difficult costs.

Apple is throwing billions a year at a problem they vastly underestimated, and is far from done yet. If one thing, they are only now grasping the true cost of what they were paying for (and complaining was too expensive). I hate Broadcom just like the next guy, but Apple was just employing bully's tactics to have Broadcom cave, and in the end they were right not to. In the end Apple may succeed, and that will only be good for us, consumers.

XMPP had all that, but there was no single application that implemented all of that.

You seem to underestimate a lot the messaging landscape of back then :) It wasn't a "XMPP thing" to implement those for laughs and giggles, it was the qualifying feature set of every popular app then, and XMPP clients like Gajim, Psi, Pidgin, … were competing against multi-protocol clients like Adium, Trillian, Telepathy, … and 3rd party ones (like aMSN, KMess, …) to implement the features of MSN, Yahoo, ICQ, … Yup, it was a zoo, but it was not XMPP's. The only point of shame I see here is that we lost pretty much all the fun and innovation when everything became "mobile-first".

I understand your defense of open standards and I’d love if the bazaar model could’ve worked for XMPP. Unfortunately, it didn’t. It is taking a Cathedral to come up and implement something that is at very least workable in all major platforms and still open for those that want to deviate from the main effort.

I don't think this analogy is relevant there, and I certainly don't think that the multitude of XEPs I listed are evidence of XMPP being akin to a bazaar: the XMPP protocol is very lean and coherent, and kept that way by the XSF. Those XEPs were meant to document and standardize the practices of the time.

But I can have my wife and my parents install Element on their phones (android or iOS) and be talking with them in less than 10 minutes, but I can not do the same with XMPP without having to accept a huge amount of compromises.

I have no idea what compromises you are talking about. I have SO, parents and many more, of all ages, abilities and systems having joined XMPP, with no difficulty whatsoever. The experience probably even is better here than on Matrix because not only can you generate invite links/qrcodes that contain a bootstrapped contacts list, there is also the option to discover contacts via mobile phone numbers (e.g. from quicksy.im, choegram) that comes handy in some contexts.

Yeah, that's what strikes me about Moonraker and its UIs: they seem more rigid and limiting than octoprint and its plugins ecosystem (I can spin one up in mere minutes to do pretty much anything), but those who love fluidd and mainsail them love them very much. I'd like to have someone explain to me why Moonraker is getting the lion share of the nerdier side of the community, it feels like I'm missing something obvious :)

• Emoji support

XMPP had that in 2002, before emojis was a thing outside japan :)
https://xmpp.org/extensions/xep-0038.html

• Reactions

2006: https://xmpp.org/extensions/xep-0201.html

• Share location in real-time

2003: https://xmpp.org/extensions/xep-0080.html

• Threads in conversation

2006 (see reactions)

• Media embeds

Which media? You had whiteboards in 2001 (https://xmpp.org/extensions/xep-0010.html), games in 2002 (https://xmpp.org/extensions/xep-0047.html), stocks in 2003 (https://xmpp.org/extensions/xep-0067.html), rich text (beyond markup) in 2003 (https://xmpp.org/extensions/xep-0071.html), mood (https://xmpp.org/extensions/xep-0107.html), activity (https://xmpp.org/extensions/xep-0108.html), maps (https://xmpp.org/extensions/xep-0110.html), tune (https://xmpp.org/extensions/xep-0118.html), co-browsing (https://xmpp.org/extensions/xep-0151.html), calls (https://xmpp.org/extensions/xep-0166.html), serverless (https://xmpp.org/extensions/xep-0174.html)

and all those were added to XMPP because they were in widespread use in the popular messengers of that era (for the history lesson, XMPP was built first and foremost to bridge and unite all messengers). So, yeah, the trend has been going towards simplification over the years, not the opposite, and there were many many things that you could do in MSN Messenger in 2005 that you won't be able to do in FB/WA/TG/Matrix/… :)

I wouldn’t give too much on the speculations and opinions of any one person, even if he’s the Matrix project lead. Probably especially the project lead, because part of his job is being optimistic about changes so they actually happen.

Yep, I think that's a very peculiar aspect of Matrix, about how it's run and why I have such a hard time trusting and recommending it. It's uncommon for opensource projects (especially "essential" ones) that adoption and fame must precede stabilization, as a condition to get to keep the cashflow and the lights on.
I don't think Matrix, starting up on venture capital, with an original but completely unproven idea, downplaying alternatives with FUD and superlative marketing, over-promising and constantly deflecting, was good community building.
Had they kept a lower profile and not an antagonizing one, they could probably have built and integrated better with the other communities in this space (and I'm not just talking about XMPP, which was on the receiving end of the FUD, but also about libera.chat whose OPs are right to be fed-up with NV).

so perhaps you just read too much into his more optimistic posts and comments?

Arathorn, 2023-09-23:

It's also true that 8 years ago, everything was flakey as hell. However, whether you like it or not, we fixed it. The federation problems were resolved before the time of Matrix 1.0 back in 2019, and since then we've focused on making everything go fast too - e.g. Faster Room Joins in Matrix 2.0.

I don't know any admin who considers federation problems to be solved, and I don't think Matrix 2.0 to be ready for the general public, so I call this denial, but heh, this is subjective :)

Do "more modern and polished UIs" make up for the loss of extensibility via plugins? Octoprint has bazillion of them, and I would take killer and productive ones like spool manager over subjectively better look

I share your sentiment, but I also defend the idea that we shouldn't let the biggest tech monopolies get away with making bank from other people's work and creations without their consent first. It's a bit like licenses in the open source world: it's not because I put code up there that I mean it to be used for closed source/commercial applications without compensation/consent (GPL), or I mean that, actually (MIT). Similarly, there are CC licenses (and alternatives) to navigate the field of creative works, and we should put Google, Facebook, Microsoft and others back at their place for completely shitting on that. And if the copyright law isn't the right tool for the job, then let's find it!

Not to dismiss the work of FOSS developers, but siskin seems quite primitive.

Fair, but it does that in ways that do not deceive its users, as in, what it does it does pretty well.

It does provide the very basic functionality that you could expect from any messenger from about 10 years ago but that's about it.

As far as I'm concerned, Instant messaging was a solved problem 20 years ago, we had practically more features in Yahoo and MSN Messengers (of which XMPP was a superset, for bridging and compatibility purposes), and Whatsapp, telegram and the rest have been removing the most distracting features. What are you missing for effective communication essentially?

I may try to take another look, but I did have a ejabberd server that was passing pretty much all the tests in the conversations suite

Are you talking about

Which is kind of my beef with frustration with XMPP. There was never a whole combination of client/servers that would work consistent.

There will never be a client nor a server that will implement all XEPs, because that's not desirable: some fringe/IoT/obsolete cases just have no meaning nor use for most users, though there are some compatibility levels, updated regularly, that all maintained clients and developers target (e g. https://xmpp.org/extensions/xep-0479.html ). Under those circumstances you have a pretty good user experience.

As long as this working implementation is working and it is open source with some community oversight, I don't mind having a clear leader in the project.

But how about the implementation not working so well in practice and with enormous trade-offs, and the leader being essentially a marketing agency running for funds while covering up those trade-offs or blatantly lying about them?

The alternative is this eternal push-pull of forces that we had in XMPP, where we end up with a fragmented ecosystem which is never universally accessible.

Beyond the facade of new vector's products, Matrix is as much fragmented if not more. Why would it be otherwise? Nothing is fundamentally better: there's a spec and people chasing it. Except that in the case of Matrix, the spec is just there for reference and eventually consistent with what's in the code of synapse running matrix.org, which is actually what matters (and might be quite different from what your server is doing for a bunch of good and bad reasons). I've bumped into more client to server and server to server incompatibilities hosting Matrix for few months than I did over years and years of operating XMPP. Things are just so much more stable and mature there (and slow, and boring, which users and admins alike tend to appreciate for something so central to their lives).

It's not like global decentralized instant messaging with all the usability, bells and whistles of centralized services is an easy problem to solve.

Yup, absolutely, and being in this space myself as an enthusiast, that's an interesting problem to see being worked on and having significant brain power allocated to, though that doesn't remove anything from the fact that

a finished product

..is precisely what Matrix developers are advertising Matrix to be, and actively marketing it to be. You can go on hackernews right now and observe Arathorn telling everyone that everything is fine and solved now, even when shown evidence that it is not, like he has done since the beginning.

I believe people should know what they are engaging with.