You shouldn't have shipped that bug in the first place, I would say. If the bug comes from an Android update, I assume that developers have had access to betas long before the system update is rolled out.
The computer itself won't really do anything. But I'm sure suicides go up when people lose all their money, or get personal private details leaked, and so on.
For me searching my old messages is really useful. I don't scroll back through history but I'll search for things like "plumber" to find the number of a plumber a friend texted me a while back.
Make a single cross-platform client that implements every non-humorous XEP. If you tell people "on Android you should use this app, on iOS use that app" - you lose regular people fast. If you have a feature that only exists in one app on one platform, you also really lose people.
People don't really sign up for protocols, they download apps. Like I often refer to the fediverse as "Mastodon" even though I know that's not entirely correct, because it's the fastest, easiest way to communicate what I'm talking about - microblogging. So you really need a single, good app you can just tell people to download.
Also a self-hosted server with opinionated defaults. The year is 2026, and most users expect persistent history without having to add mod_mam themselves. Discord won from zero because it's IRC with history. I cannot believe that chat history, mentions, etc. is still not settled.
This is effectively settled. Every client worth using has standardized on certain extensions, and there are server capability testers for it [0].
There are still a LOT of things very much up in the air, such as message deletion, which work inconsistently from client to client, but message history is not it.
call me out if I am wrong, but isn't history dependent on the server of the chatroom creator, and doesn't every server have different history settings and does it not handle encrypted messages fully?
Yes, XMPP server implementations typically give admins full control over data retention. Different use cases demand different settings, so it's quite adaptable to whatever needs you have.
I'm not sure what you mean by not handling encrypted messages fully, it handles encrypted messages fine.
> so it's quite adaptable to whatever needs you have.
as a user you cannot, even if you self host, because you are not the one controlling message storage
> I'm not sure what you mean by not handling encrypted messages fully, it handles encrypted messages fine.
you can load encrypted messages (including keys if they are needed to decrypt them if necessary) using a fresh login such that you can read them again?
This may sound stupid to a predominantly GNU/Linux audience, but as a FreeBSD user(and Linux user!), when a daemon is not available for FreeBSD, it's a very bad sign.
"Because Snikket is designed natively as a tightly integrated suite of Docker containers built around the Prosody XMPP server, running it natively on FreeBSD is complex."
FWIW I'm the founder of both the Snikket and Prosody projects. If you're a FreeBSD user, or even an experienced hands-on Linux sysadmin, I'd probably recommend going with Prosody, unless docker is your thing.
Snikket aimed to fill the gap for people who wanted an "out of the box" XMPP distribution kind of thing, and it's good at that. But shipping a bunch of software components with opinionated configurations doesn't really mesh well with distribution-level package management, and only really works with a container kind of ecosystem.
Both routes exist and are equally viable. Prosody has ports available for all the popular BSDs, and installing it should be a breeze. Just be prepared to then also set up a TURN server if you want calls, and potentially some web server stuff to if you want some of those features. After installing Prosody you can run 'prosodyctl check features' and it will tell you if you're missing any of the common stuff people want in a modern messaging app.
> People don't really sign up for protocols, they download apps.
This is both true and also if followed would fly in the face of what XMPP (and the Mastodon-flavored ActivityPub-powered fediverse of microblogs-and-more) is supposed to be about. And it's also both true and yet people understand what "email" means and how to use it without constantly and consistently running into issues trying to bang out a reply to alice@gmail.example even when the sender's inbox is hosted @yahoo.com—nor do folks spend much time thinking about how and why AT&T's SMSes (for example) are able to make their way to their friend's device even though they use Verizon (to give another example—and if they even know which provider their friend uses at all).
One thing that Jabber (and, later, Mastodon) did wrong was to take the unfortunate stance that it wouldn't be too big of a deal to adopt email-like identifiers without actually being email or implying that Internet-standard email services are available; it was felt that users would just be smart enough to adapt to it. This was a mistake.
The confusion with email, though, can be exploited as useful momentum—something that the network has going for it, instead of a flaw.
If the author and the rest of the Jabber/XMPP community wants the public to "give Jabber/XMPP a shot", then it probably does need (a) a flagship instance (a la mastodon.social) that controls multiple domains (the way that many email providers like Runbox or Fastmail do) and requires the user to pick which one they want their handle to be associated with at signup, in order to introduce email-like decentralization to the userbase as early as possible, and that (b) raises the bar by setting a standard among Jabber/XMPP instances and actually offering email services to that userbase (prior art: Google married (XMPP-based) Gtalk with Gmail in the early days).
While undertaking all of this, an effort to update the XMPP protocol (a la JMAP, but in a backwards-compatible way) while simultaneously reconciling it with legacy email (also in a backwards-compatible way) wouldn't hurt—where "backwards-compatible" here means "to gracefully degrade and provide a fallback" (prior art: Delta Chat).
Mastodon too has several client (web)apps. The Fediverse is itself a more neutral protocol with more heterogeneous platforms based on it (e.g. Lemmy, Pixelfed, etc), so Mastodon refers more to the platform (schema, UX, wider community) than the individual UI you use to access it, which just happens to usually be whatever your instance admin serves by default.
As for apps, people simply prefer instant messengers purposefully designed for their platform. There is genuinely a lot of platform-specific quirks around things like push notifications, which a non-iPhone developer not have the motivation to figure out. Besides that, a lot of these predate contemporary cross-platform technologies like Flutter.
Re: fediverse my point is - regular people just do not care about any of the fediverse-y parts of it. If I share a post I saw, I don't say "here's a thing I saw on the fediverse" - I just say "here's a thing I saw on Mastodon."
Plus the reality of the fediverse is if you want to use multiple platforms, you wind up needing multiple accounts anyway. Like if I want to upload to Peertube, I need to make a Peertube account, so we're back to where we started of having multiple places to follow people since I can't use my Mastodon account to upload to Peertube. I'm able to have some cross-platform interaction, like commenting on videos from mastodon - but there's issues there like, Pixelfed only showing people posts with images.
When talking to most people I just call the whole thing Mastodon and treat it like its a single app/service, because that's what people are used to. If I start trying to tout how the fediverse is a decentralized platform of multiple applications and you can kinda/sorta interact across platforms - people's eyes glaze right over. They just do not care.
For apps - I've never met a person that picks a messenger because its tweaked for their platform. They just prefer whatever their friends are on. iMessage is something of a odd case since Apple just rolls you into it automatically and presents it via the default app.
Re: Re: Fediverse. My point was more than indeed the Fediverse is more a technical detail than an actual cohesive platform, so it only makes sense to talk about Mastodon, whereas XMPP is more cohesive by virtue of instant messenging being a lot less opinionated.
It just so happens it splits into well-maintained projects supporting the concensus features, and dead or dying projects that don't, modulo a couple contrarians, with a couple more features floating in limbo, having finalized or draft specs that nobody really implements.
That sort of problem isn't best fixed by centralization on one client/server but just certification, which Conversations/ModernXMPP already leads.
As for apps, yes normal people aren't very conscious of what a native app is, but they do feel when their app lags on their older phone, doesn't recieve push notifications, or just looks a little odd in places, which can happen in a one size fits all app. Some of the most popular messengers, like WhatsApp or Telegram, to my knowledge use platform specific tooling, and normal people genuinely appreciate how snappy they feel.
But the issue is more so about developer time. Yes a cross platform app lets you reuse the same work everywhere, but the lead developer still has personal blind spots, and might simply not consider or be able to test things like bespoke Apple workarounds for non-iCloud/encrypted chat push.
Plus it's a communication protocol, like email; we should be expecting people reimplementing it in the weirdest of places. For software like this, the duplication of effort is what drives you to make an elegant design in the first place.
Sorry but I just fundamentally disagree about the app centralization.
If you want xmpp to gain traction you need an app that exists on both mobile platforms. It can (and should) have per-platform tweaks and everything to be performant. But a person needs to be able to just tell their friend a single app, they need to be able to find it in their app store.
The question is "how does xmpp gain traction?" and the answer is having a single flagship app that runs on everything.
If a person needs to recommend a single app is because most people are tech illiterate and don't understand what protocols are, because no one tells them.
I can expect this from our parents and grandparents, but not from younger generations that were born with PCs and smartphones. They need to learn; we need to educate them. Otherwise they will stay being the perfect fodder for Big Corpos and their monopolistic tactics.
We need to start focusing on the protocols, not the platforms.
Pidgin 2.x (latest stable branch) is unfortunately over a decade behind at this point. The developers are working on a big rewrite (3.x) but it's nowhere near complete or ready for use yet.
In short, I wouldn't recommend Pidgin for someone who wants a modern messaging app.
That was the biggest issue since the beginning - the mix and mash of supported features just meant nothing just worked - like sending files might work depending on which contact you send it to, which is experience nobody wants.
It just needs feature versions - you support this one, means you support all of the features deemed important for users, no partial mishmash.
>If you tell people "on Android you should use this app, on iOS use that app" - you lose regular people fast.
People don't use single browser and single email client, why IM should be different? It's a deficiency when you're forced to use a single "official client".
Based on web browser statistics I've seen, most people use Chrome, some of them use Safari on their phones. There are also people who use Edge sometimes.
But most people seem to use Chrome on every device, no matter how much I wish they didn't.
This comes from the before times when Internet Explorer was full of holes and Chrome was a usable browser with regular updates and before Firefox worked with all websites well.
Google has since spent the time making Chrome more locked down and user-hostile from a privacy perspective but the conventional wisdom for years was “just use Chrome” (for good reason) and that inertia continues :/
Plus the sad reality is even if they're not using Chrome they're probably still using Chrome - most browsers are based on Chromium. You have Safari and Firefox, nearly everything else is just Chrome.
Also last I checked - on iOS devices even if you use Chrome, you're really using Safari - I believe apple forces all web content to be rendered using the built-in WebKit.
For email - most people use the official app and assume they have to use it.
You sign up for Gmail, you get the Gmail app. You sign up for Outlook, you get the Outlook app. 1 service = 1 app.
For browser - on mobile most people use whatever the default browser on their device is. On desktop - Chrome. Pretty much everybody just downloads and uses Chrome.
Nothing else, I think what the're more concerned with is how open an architecture is.
I think with RISC-V if you wanted to design your own chips and stuff you can just do it, whereas ARM doesn't let you do that.
I'm not about to build my own chips so it doesn't matter all that much to me but I understand where the person is coming from. They'd rather write assembly for the more open architecture.
Exactly what I am doing: I have even a small interpreter to run RISC-V machine code, to a certain extend ofc, on x86_64, and I could just do that on arm64 too: since The 'R' is RISC-V, means "Reduced", such implementation is more than reasonable, even for one average dev.
You could argue well, if you have to open the file to read it anyway may as well look for magic numbers.
That doesn't work well with text documents which won't have any kind of magic number. So now you're doing some heuristics to determine is this text/plain, text/html, text/svg? You're pretty much just guessing at that point.
A good number of file formats out there are just Zip files with a particular structure. JAR files, docx - so relying on magic numbers doesn't really work for those, either.
Also to service a HEAD request you'd have to open the file and read a few bytes that you just discard.
If you just do it by extensions you don't need to read files at all or perform heuristics, and no ambiguity for what mimetypes to use for text documents, zip-based formats, etc.
Honestly requiring DMARC was overall a good thing.
I was an email admin for a university. In the past - each college ran their own email. Before DKIM, before SPF, you'd just have basically random servers on the internet sending email as (school).edu. Tons of random subdomains too. math.(school).edu and so on.
Email was eventually centralized but you'd have parts of the university still running their own things. Insisting they're special and can't be brought into the fold.
So, we had a lot of stuff out there just not passing authentication. A lot of spammers could just impersonate our domain.
We'd go to leadership and say "hey we should really get our act together" - but everything was working. Our emails were still getting out. Hard to justify spending the time, getting various higher-ups within departments to give up their things, and so on.
Unless you can get like, the president to back your initiative- universities are very decentralized and it becomes an issue of "do we have the political capital to spend here." The overall relationship between central IT and the various college-based IT departments was terrible, often bordering on combative.
Google and Yahoo made it so we could go to leadership and say "people will not get our emails if we don't get this straightened out" and it became a priority. When I left our DMARC reports were showing something like a 99% pass rate when it was previously like, 50.
So, I'm glad Google and Yahoo made that call, it gave us the kick in the pants we needed to get our own shit together. I am 100% certain we were not the only org like this.
Plus for a small host - where you're just running a single mail server or something - you just need a few things to pass DMARC.
A DMARC record, and an SPF record, and for your emails to pass SPF. You technically don't need to do DKIM signing (though I'd still recommend it because that survives automated forwarding).
Lookalike domains are a problem but in my opinion the bigger problem is when attackers figure out how to hijack a real domain.
For example, making a company named "there's a problem with your account call this number" on a site like PayPal and getting it to generate emails. They'll be from actual paypal.com and pass all authentication.
The other issue I'll often see is subdomain takeovers. Company makes a subdomain a CNAME to some other, external domain. Usually with the intention of hosting a webpage externally or whatever.
That other domain expires, but the CNAME doesn't. Somebody buys up the external domain, now they can publish SPF records and pass DMARC relaxed alignment on the organizational domain.
Now you can send all the emails you want with literally anything you'd like and the providers will say "yep, this passed DMARC."
reply