The Telegram is a honeypot link is flat out dumb.
1. Telegram is very open that they are not end-to-end encrypted by default and never portray themselves as anything else. Secret chats are e2e and nothing more.
1. Cloud chats are encrypted in transit and in storage. Encryption keys are broken up into pieces and stored in various jurisdictions, making it virtually impossible to legally force giving up data to governments.
1. Whatsapp is never secure. As there have been countless exploits in it where you can gain full access to the remote device. No such exploit, or really any, has ever existed in Telegram.
1. TG accepts 3rd party clients to it's open API.
1. TG let's you validate that the mobile client you install on your phone is the same as the source code published in their public repos
1. The backend is closed source but I always thought that was a dumb thing to mention because you have no idea what's actually running on the servers in the end.
1. Signal has suspect funding (read Surveillance Valley)
1. Signal does not allow 3rd party clients to use it's open API (suspect!) and also no way to verify your clients
1. Afaik, no government has ever been successful in forcing TG to give up any data.
1. There is a still unclaimed 6 figure bounty for anyone that can break their encryption (for years now)
1. Finally (I could go all day) I think they are the most open about whatever is going on. That comes off as genuine to me.

Yes, obviously I do like to use Telegram but I wouldn't use it, or any similar service, to send anything that was truly sensitive. Also, does appear to collect more metadata than I'd like but it's still fairly minimal.

Just my $0.02

Telegram makes it easy to make a vary serious mistake

This is one of my biggest gripes about TG honestly. People should be better educated on how to use the tool within it's confines. I mean, all the info is there, but someone has to go looking to read it, which rarely happens. Good point.

I'm not sure about that.
Remember TG started a years before Signal existed and before WA added e2ee to it's messaging. Also they're target user isn't security minded hackers/info sec, etc.

I think they're pretty honest about how the tool works. The homepage messaging is definitely marketing dribble but not inaccurate and I don't think anyone but a small subset of people (like you and I) would read that and think "Ah ok, so everything is e2ee by default".

There's nothing in the homepage messaging that to me means "They are clearly not 100% honest with their users about e2ee" - I think that's you reading it through your specific lens.

I also don't think it means they don't care about user privacy. I think they've overwhelmingly shown the opposite to be true.

Like I said before, I wouldn't use TG (or Signal, or <whatever>) to send truly sensitive information ever. I do still think TG is the best daily driver messaging platform and apps that is mostly open about all things and that my messages (as menial as they may be) are protected.

In the end, regardless which of these services we use, there's a level of trust that has to be given by the end users.

In the end, regardless which of these services we use, there's a level of trust that has to be given by the end users.

Not with XMPP! Self hosted, federated, true e2e chatting my beloved

> XMPP is unusable for most people, because the matrix of which client/server software implements which XEPs is a kilometer deep and a mile long.

> This means I cannot reliably know if the person I will be talking to will have the particular combination of XEPs available.

Wait what? Why would you need to know? It doesn't matter what XEPs their client or server support, you can still easily communicate with them. That's the entire point of the "eXtensible" in the name.

I've had everyone I know on XMPP since 2013ish and have never once had to know or care about what XEPs their software supported.

I'm still unclear on the problem.

You said differing XEP support made XMPP unusable, I said it absolutely did not and doesn't matter. You brought up OMEMO which requires all clients to clearly indicate support, and are now linking lists of XEPs, which again, don't matter...

I'm trying to point out there are no incompatibilities. Virtually the entire public federated XMPP network runs either ejabberd or prosody as a server, both are well maintained and support anything anyone would want.

*Most* everyone runs a modern well supported client, like Conversations, Dino, Siskin, Gajim to name a few, but even if your contact wants the pain of running pidgin that doesn't affect you.

XMPP's only problem is combatting decades of misinformation from people that connected to gtalk using pidgin once in 2006 and found it to be a bad experience (it was terrible!), but it's been the best IM experience for well over a decade at this point, and the only one that is a standard with wide adoption and multiple independent implementations that you can run yourself.

Specifically en.wikipedia.org/wiki/Comparis… are all things that only affect *your* IM experience, you don't need to know or care if your contacts have any, all, or none of them.

eXtensible, it's in the name.

Ok good, because it shouldn't happen, and in my experience, does not.

If you stick with the 2 main servers and any of the 4 different clients I listed (not exhaustive mind you) they support everything you need, no need to look at XEP support or anything else. Compare that with all the non-standardized "messengers" where you only have 1 choice for a client, and when the VC money dries up it goes away. Meanwhile I'll still be using and improving XMPP.

Seriously though if anyone has thoughts on ways to improve anything message me or @xmpp , it's an actual standards organization anyone can contribute to in a meaningful way, not a fly by night company who implements whatever their VC funders want, throws it over the wall, and calls it "open".

This new rendering of clients is based on DOAP: xmpp.org/software/clients/

DOAP: xmpp.org/extensions/xep-0453.h…

We are reviewing if we can expand the information from such files in an extended user-friendly way in the future.