If you automate all aspects of your life, what have you got?

Don’t fall for the scam that is “AI”, think. Computers cannot think for you.

I’ll spend more time talking to people, plotting Linux phone world domination type stuff and planning to take people off WhatsApp with XMPP folks, tbh

Apparently some interesting XMPP talks, but I haven’t had a closer look at the schedule yet

What’s the post about?

XMPP shows pretty well that XML can do things that cannot be done easily without it. XMPP wouldn’t work nearly as well with JSON. Namespaces are a super power.

That’s not a feature, that’s just control.

Proticols dont do any thing. Platforms/implementations do

Protocols ensure interoperability between implementations, platforms are not necessary. XMPP works just fine without it.

there are extentions that support e2e, I was just saying that is core to Matrix spec and thus every implementation.

No, there are many implementations that in fact do not support E2EE and also many that cannot keep up with the many protocol changes.

Heck, I’d think Matrix, Nostr, and XMPP would better than email, which itself is better than shudders propritary “social” media, or plutocrat accounts like Google, Apple, or Microsoft.

I partly agree. Email has issues, but largely works. Proprietary “social” media is just hell. I haven’t looked into Nostr yet, but am going to. Matrix is slow, XMPP has proven to work well for a while, it has been around since 1999 after all. It is extensible, which means you can make it work just as well in the future.

Not a fan of Matrix in particular, but I guess it’s still better than Facebook, but that’s not a high bar.

Are they extensions of core spec?

Also, the client projects cannot keep up and Element has defacto a monopoly and could always do what they want.

Meanwhile, XMPP has RFCs and therefore is an internet standard. Extensions can be created anytime and go to different states when implementations show up and demonstrate interoperability. There are sets of XEPs that should be implemented depending on use-case, such as instant messaging.

See this post as well:

When one vendor controls all parts of a service (e.g., both a client and server), it has the means to create a boxed platform. Controlling both the server and client allows a vendor to update the client and server without worrying about breaking compatibility with other clients/servers in the larger network. It could update the client to point users to a server that uses a completely different, closed protocol. This is what happened to many XMPP users in the early 2000s.

Problems may arise when development of the spec and production-grade reference implementation grow tightly coupled, leaving third-party implementation feasibility out of the decision-making process.

Case study: Matrix and Element

The only client that implements all the necessary features is Element. In addition to being the most popular client, Element practically serves as the reference client implementation: it’s developed by the same company that builds the dominant servers and most of the spec. The tight coupling between Element and the Matrix spec allow it to add features at a rate too fast for other clients too keep up; pretty much every Matrix user has to open up Element at some point to perform an action that isn’t supported in any other client. On the server side, Synapse is the only server that implements enough of the spec to be usable, with Dendrite coming in second. Both are made by the same company that develops Element.

As a user, consider using clients and servers made by different groups of people to make platform boxing more difficult. Pick implementations that suffer from less feature creep beyond spec compliance. What distinguishes a client shouldn’t be what features it has, but how it implements its features. Obviously, having some unique features is great; problems arise when the number of unique features crosses a certain threshold. Following both these practices encourages implementations to stick to standards compliance, reliability, and compatibility rather than “innovation”. Choose boring technology over shiny new features.

Try venturing outside the mainstream by taking a look at a less popular provider or client. All implementations start somewhere, and a diversity of implementations prevents a rule by oligopoly.

https://seirdy.one/posts/2021/02/23/keeping-platforms-open/

XMPP? It’s literally the internet standard for that. But it’s not a platform, it is a protocol. Platforms aren’t a good thing.

I thought it was about reinventing the wheel in a more complicated way that needs more resources and is slower. ¯_(ツ)_/¯

Came here thinking it’d be about the Gemini browser, instead it is about a chat bot :/

Matrix? For account creation? WTF?

Why not use an existing internet standard instead? There are so many RFCs, something would work.

Like… IRC. Or XMPP.

That’s what RFCs are for.

If Google decides to, it can remove anything from AOSP, as it has done countless of times. Android is deeply controlled by Google.

Yes, that seems all like neat technology, but what is the use-case for that?

I was trying to find a summary of what it does, but couldn’t. That’s how far I’ve got.

Not sure what they complain about, but to me that self promotion is annoying.

We need to stop using legacy IP.

Probably, but building all that takes far more effort than adding an alias. Or many.

No, it cannot know for sure whether the first email is spam.