MattJ100

28 ms·

271.
by MattJ100 5y ago
> There is one problem the author mentioned which applies to XMPP but not to email/ActivityPub: presence tracking. [...] clients and servers to advertise the presence status (online, away) to the entire world, and that's a hug
272.
by MattJ100 5y ago
Basically all the issues listed in the article apply equally to Matrix, and most other communication platforms too. There are some alternatives that overcome most of the issues with a "serverless" approach (hint: no practical comm
273.
by MattJ100 5y ago
The main problem with this article is that all the points apply equally to other services, but the article frames it such that it implies the problems are unique to XMPP. Half the article is dedicated to obsessing that the server can see yo
274.
by MattJ100 5y ago
The ones to watch are Gajim and Dino. Both are likely candidates for the emerging Linux phone platforms. Though neither quite there yet, there is a lot of activity across the projects. Dino: OMEMO for one-to-one and group chats. Calls (encr
275.
by MattJ100 5y ago
I hear you (and others), which is why we're trying to solve these kinds of barriers to XMPP adoption, with Snikket. It's a preconfigured server that can be self-hosted, or there is a hosted service available (you can migrate betwe
276.
by MattJ100 5y ago
A mere protocol will never "hit the bigtime" without some compelling (non-protocol) reason. It's unfortunate that businesses choose to build silos time and time again, but that's where we are - it's not an issue tha
277.
by MattJ100 5y ago
> Instead, 5 years later there's Conversations, "information is not trivial to find" and "check your server for compliance". If you think nothing happened in 5 years then you're very much mistaken. As I said
278.
by MattJ100 5y ago
> And that's the only client in existence that supports the XEPs required for XMPP to be a viable alternative in the modern world. That's not true, but admittedly that information is not trivial to find right now for end users.
279.
by MattJ100 5y ago
There are at least hundreds of implementations of XMPP that are interoperable (at 5-6 actively developed server implementations, many more libraries and many client applications). There are at least hundreds of thousands deployed XMPP servi
280.
by MattJ100 5y ago
> But why are these protocols frozen? They're not "frozen". As mentioned in a sibling comment I wrote a blog post about this very topic - https://snikket.org/blog/products-vs-protocols/ Your poin
281.
by MattJ100 5y ago
Many people, including myself, disagree with Moxie's stance towards decentralization. I wrote a blog post comparing Signal's approach to the approach taken by many decentralized networks: https://snikket.org/blog&#
282.
by MattJ100 5y ago
Yes. It's client-dependent for all other systems too. For example Signal's end-to-end encryption only works if both parties are using Signal. For XMPP the difference is that there are multiple E2EE clients to choose from (see htt
283.
by MattJ100 5y ago
The story is not quite the same for XMPP. For example, with XMPP you can determine ahead of time whether or not a contact has OMEMO. And clients configured to only use OMEMO won't "fall back".
284.
by MattJ100 5y ago
My family use XMPP daily for messaging and calling each other, and I know many others who do the same. That's not to say my perspective is average, or that the federated XMPP network is anywhere near as popular as WhatsApp, Slack or Si
285.
by MattJ100 5y ago
Contrary to popular belief, XMPP continues to innovate. This is an advantage of the modular protocol design which allows evolution of the protocol by adding new extensions and phasing out old ones. Every year the XMPP Standards Foundation p
286.
by MattJ100 5y ago
Yes! That's what people do. I don't know about Traefik specifically, but we have docs for many other reverse proxies: https://github.com/snikket-im/snikket-server/blob/master/doc... If you feel
287.
by MattJ100 5y ago
> This leaves a whole lot of room for an active attacker on the network to prevent all forms of encryption, rendering TLS essentially useless. This is a common misconception about STARTTLS. It is certainly possible to implement it poorly
288.
by MattJ100 5y ago
> It's a draft XEP, so it's not widely implemented yet. Just to pick on this, sorry. The XSF terminology is not obvious (it was inherited from other standards organizations). Draft here means the protocol is absolutely in use
289.
by MattJ100 5y ago
This project is certainly aiming to push things forward. Indeed a decade ago it would be totally unsurprising to see a client with a drop-down for "STARTTLS", "Direct TLS", "No TLS" (!). I think it's best
290.
by MattJ100 5y ago
That's a growing list of documents over the course of XMPP. It doesn't really prove anything other than... XMPP has been around a long time, and people continue to develop it. People saying "look at all this stuff" is on
291.
by MattJ100 5y ago
In fairness, by 2014 it was fairly obvious that Google was no longer interested in furthering Google Talk. It was about the time that they were pushing folk to Google+ and Hangouts. Google's XMPP server continued to accept unencrypted
292.
by MattJ100 5y ago
Author here. Yes, Movim is a great project! The Movim author has indeed contributed to the Modern XMPP documentation. As one of the other commenters pointed out, most of the current docs here are aimed at a particular use-case of XMPP, whic
293.
by MattJ100 5y ago
XMPP is fully Unicode-aware and always has been, so clients lacking emoji support are probably due to platform-specific issues. I'd be interested in specific examples if you can name names. libpurple (and derived clients such as Pidgin
294.
by MattJ100 5y ago
You're right. I take responsibility for the name, but naming things is hard! As for the focus, you're right, there is a bunch of advice that is specific to this class of personal messaging apps. As time, resources and interest all
295.
by MattJ100 5y ago
Sure, but I don't think that applies here. The section in question is about a settings screen where (for some reason) the user is manually entering all the connection parameters. There is no way to detect (without probing) whether the
296.
by MattJ100 5y ago
Names and mascots are hard :) Also important to note that this project is still aimed at developers (as is XMPP and all the protocol documentation). What's needed are friendly projects promoting to end-users. Current work in that area
297.
by MattJ100 5y ago
Hi, thanks for your support of our project, and all the users and developers of XMPP in 2021 :) Google closing down XMPP support was indeed a sad day for everyone. But there are plenty of us supporting the idea that Google does not control
298.
by MattJ100 5y ago
Agreed! As in my sibling comment just now, I've updated this section to say basically that.
299.
by MattJ100 5y ago
You're completely right, thanks for the spotting that and the feedback! I was going to remove it, but I don't think that's the problem. The whole section you mention is the problem - all these options should be auto-discovere
300.
by MattJ100 5y ago
Yeah, if your needs are simple enough and your clients are small, MQTT is a good choice. Two or three XMPP servers even have built-in MQTT bridges for supporting very lightweight clients. From what I've seen, XMPP is used in IoT more f

More ›