He realized that the discovery server was just handing out another hostname, so even though he couldn't spoof the discovery server since he knew the hostname it was going to provide he put that in his local DNS and point it at his server. Since the RTMP server was on a different domain the best solution would be to make a wildcard for that domain that points at his server, that way it won't break if Twitch shuts down or starts up a new server in his area.
As someone who works with RTMP/S a lot, I suspect the Twitch endpoint is accepting RTMP streams even if it specifies or usually expects RTMPS - I find very often that servers will accept both.
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.
>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.
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.
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 :/
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.
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.
The author mentions that the PS5 uses RTMPS to push video up to twitch - but suddenly it just uses plain RTMP?