Matrix misrepresenting its users base... By counting users that ever connected once, test accounts, spam accounts, bot accounts, bridged accounts, single ever used nicks... as a marketing strategy to give an illusion of relevance... that would be a first! /s
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.
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)
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?):
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.
rmayayo@lemmy.world if I click on this link in boost, it opens in the browser, and then when I share from there, the only boost related action I can see is to create a post. Would it be possible to have an action to "handle" the link and open the thread in boost? Eternity has this capability, fyi :)
That's often the case with articles coming out of the conversation.com :)