I don’t know what I was expecting but it looks more and more like the Messaging Interoperability the EU promised will be each gatekeeper essentially publishing their client to server protocol and then you can either use multi protocol messengers or transports. No s2s federation. Looks like one might be able to log in through the (propriety) c2s API with third party IDs though.
#Conversations_im is doing pretty extensive DNS caching. If you set the TTL of your DNS records relatively high (86400 seconds for example) Conversations can avoid some round trips during connect. Another round trip can be avoided if you prioritize the _xmpps-client SRV entry. This can significantly improve the performance in rough networking environments.
In good networks we can establish a full connection in under 500ms.
We are not going to write open letters on how we are heroically going to withdraw from Europe. We will stay here continuing to operate as usual. We are infrastructure.
In his 'Enter the Matrix' talk¹, @mcnesium suggested donating to the Matrix Foundation to address the issue of one company controlling 90% of the ecosystem and spec.
Here's how the foundation spends its money:²
• Administrative overhead • Operating the matrix.org server • Director’s salary • Hosting Matrix Conf
No funds for software development or spec writing.
Hosting the conference (12.5% of budget) is obviously a good investment.
I must admit the iPhone Air looks pretty cool. Now that Google is locking down #Android, I might as well get one of those and do #Conversations_im for iOS instead.
@kris@joinjabber@nigel As far as I’m aware the oauth support in @prosodyim is for authenticating other apps against existing prosody users. Meaning the user database of Prosody would be the source of truth which would allow Conversations to use channel binding. So yes I agree that this would be the better approach to integrations. But I don’t think Conversations is much involved here.
@kris@joinjabber@nigel@prosodyim To be clear I think integrations are good. We shouldn’t prioritize between integration and channel binding and instead - from the get go - find ways to have both.
@joinjabber@nigel@akkoma something to warn users about with these integrations is that they don't support Channel Binding (or at least I don't think they do).
Channel Binding is something I would like to enable by default in a not too distant future and I hope that other clients move with me.
It will still be possible to disable because there are obviously deployments where this can not be avoided but it would be nice if we could keep those to a minimum.
I'm paying Google ~100 euros a month for their services and the privilege of publishing Conversations on the Play Store.
For a week now, I have been unable to release any updates because I'm still hoping to talk to someone at Google about their false accusation that I'm collecting users' email addresses, and any publication would reset my slot in the queue.
I just bought 20 envelopes and stamps, and I'm packing them with 5x #Conversations_im, 5x #OMEMO, and 5x #XMPP stickers each.
Send me an email if you want one. Put 'Stickers' in the subject so I can filter. While supplies last, obviously. (Though I'm more limited on the stamps than the stickers.)
@micahilbery You mention Slack and Discord so I assume you are looking for team chat. XMPP these days is mostly - though not exclusively - used for personal chat. Think WhatsApp and Signal replacement rather than Discord or Slack.
But it does have a small user base that hang out in what's called 'public channels'.
I completely underestimated how widespread the issue of servers not supporting TLS 1.3 is. Tests in the beta channel gave no indication.
I regret not working harder to at least make the error message better. The error message in master has been improved, but I can't push that fix as long as I have ongoing disputes with Google (putting it out by temporarily admitting to collecting email addresses resets my spot in the queue to maybe talk to an actual person).
Note that #Quicksy users won’t be able to opt out of TLS 1.3.
If you are sending files to Quicksy users (via HTTP Upload), make sure your HTTP server supports 1.3; otherwise Quicksy users won’t be able to receive the file.
According to Google, #Conversations_im is now also collecting users’ email addresses.
Pretty much the exact same thing that happened to Quicksy about a month ago¹ is now also happening to Conversations.
An app update I submitted ~48 hours ago passed review without any issues. A subsequent update just now, which contained very minor bug fixes, was rejected because I failed to declare that I’m collecting email addresses.
Hear me out: what if, instead of maintaining a roster, we just send directed presence to every open chat and tell everyone #XMPP doesn't have a server-side contact list anymore? Obviously, the server could still infer the exact same information, but that's true for Signal as well, and nobody seems bothered by this either.
End-to-end encryption (E2EE) is important. However, on self-hosted or otherwise trusted servers, the client-to-server transport layer presents a much larger attack surface. It’s the first hurdle an adversary must overcome before they can attack E2EE.
That’s why #Conversations_im includes advanced MITM detection called Channel Binding. Turn it on today!
It’s optional for now because not all servers support it. Talk to your admins.
Neither @matrix nor @delta offer comparable protection.
Hacker News is my guilty pleasure. I just love the "How I sold my 'basic Unix tool rewritten as a 300 MB Node.js in a Docker container' startup for $500M" posts.
Half the comments on the "FFmpeg switches to @forgejo" posts are complaints about the anime girl from Anubis.
You Silicon Valley tech-bro motherfuckers who think it's OK to DDoS small websites are the sole reason we had to put her there in the first place.
Project lead on https://Conversations.im & https://Ltt.rs · Council Chair & Editor, #XMPP Standards Foundation · 2.9W/kg · Flat white socialist · Defying Gravity · European Republic