Day 2 of the Hackathon went great. Marvin (@larma) helped me implement an opt-in feature in #Conversations_im which routes all P2P sessions (calls and files transfers) via the users home server (similar to the feature found in Signal).
I went on a nice walk to a viewpoint on Mount Royal afterwards.
The first day of the Hackathon at #IETF124 in Montreal is coming to an end. We implemented the relatively niche feature of XEP-0444: Message Reactions that allows channels or group chats to restrict the type and number of emoji reactions users can do.¹
This brings us a step closer to advancing and stabilizing the XEP. We didn’t want to do that before, since we aim to have complete implementations before requesting a Last Call.
Please do not use c0nnect. This is an outdated fork of #Conversations_im with several severe security issues (simply due the fact the developers haven't kept up with fixes I made to Conversations over the years.) These days Conversations and aTalk are the only actively maintained Android clients that aren't just bad copies of something else.
In terms of calls not working this does depend on your server (and network situation)
@ratcatcher For the client that is true. (And Molly does for example talk directly to #Conversations_im). However the problem arises when the server sees a new message it needs to do 'something'. Like it needs to tell 'someone'. And that something to someone needs to be standardized.
In the animation on unifiedpush.org/developers/int… the top, purple arrow. That’s WebPush. And Signal doesn’t do that. And then MollySocket is a translation proxy for that.
#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.
fun fact the federated, open source replacement for FCM #UnifiedPush can also be used with #XMPP as a transport with #Conversations_im as a 'distributor'.
@obsoleszenz @delta Political action is important. I was on the streets protesting against the first data retention (Vorratsdatenspeicherung) laws 20 years ago. However we also need a Plan B. "Leaving Europe" is either an empty threat or not helpful at all to the people living here. People need to know that they can rely on Jabber/XMPP in general and #Conversations_im in particular to stay around no matter what.
@tomjennings Chat Control has exceptions for closed, private deployments. For example Slack or Microsoft Teams won't have client side scanning. (That would be stupid and open the door for corporate espionage, and if anything is more important than the children it's capitalism). Jabber/XMPP is just a series of private deployments that occasionally happen to be interconnected. #Conversations_im is a client that can connect to closed, private deployments so it won't get client side scanning.
But Daniel, you might ask, won't the criminals just use Conversations then? Yes, they already do. And thank you for realizing why chat control is stupid.
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.
EU Chat Control won't apply to the federated Jabber/XMPP ecosystem. #Conversations_im is used by various militaries, police forces and intelligence agencies in Europe. They will make sure it won't get any client side scanning.
Well, yes. But tried @Monal these days and they did a pretty well job. Works really nicely combined with #Prosody, #Conversations_im and #Dino. But I think you already joined forces, which is a good thing.
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.
Two minor nitpicks on my GNU Taler experience. (And the fact that I’m complaining about those should be taken as an indication on how well the experiment went otherwise.)
• From checkout (by the merchant) to creation of the QR Code it sometimes took a little bit too long (seconds instead of instant). I think it round trips to the server and maybe the network was slow.
• The wallet app on Android looks very plain and boring. If we integrate this into #Conversations_im it needs to look cooler.
Testing GNU Taler at #Datenspuren was fun. And by fun I mean mostly unspectacular. It just worked. I scanned a QR code. I got some Kolle Mate.
I think some sort of GNU Taler integration into #Conversations_im would be pretty cool.
If you would like to integrate Taler into Conversations there are currently funding opportunities available¹ from @nlnet and both the Taler developer as well as myself are happy to help with scoping.
In Vorbereitung auf die #Datenspuren mal Support für taler:// URIs in #Conversations_im eingebaut und 16 Euro umgetauscht. Keine Ahnung wie es jetzt weiter geht. 😅 Mate, I guess?
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.)
The #Conversations_im update that requires TLS 1.3 is currently rolling out.
Apparently, judging by the bug reports coming in, a good number of servers do not support TLS 1.3 yet.
Please upgrade your servers and/or check their configurations. 🙏
Users can opt out via a setting in the Security section of the app, but this setting will likely go away in 1-2 years. The only correct move here is to fix your servers. Also, check the HTTP servers used by HTTP Upload.
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.
Someone or something at Google started to hallucinate that #Quicksy is collecting the user's email address and would not approve the app update until we declared that in our data policy.
The sign up process in Quicksy hasn't changed in 7 years. I don't even know where the user would enter their email address and I'm not aware of an API that collects this automatically.
LibreTorrent from @fdroidorg is looking very nice now with its new Material Theme. Goes hand in hand with the new magnet URI support in #Conversations_im
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.
The "Conversations" screen (which shows a list of open chats) has always been the main screen of #Conversations_im, following the behavior of Signal, WhatsApp, and Google's Messages (SMS) app. However, after sign-up, users were taken to the "New Chat" screen (which lists all contacts and group chats) on the premise that they have no chats yet and would likely want to start one. This may have confused first-time users about which screen is the main one.
I love @FrOSCon. It was the first conference I ever went to 2̶0̶ 19 years ago. But damn those start times are not hacker friendly. I'm so tired I just tried to put whole beans in my portafilter. Anyway see you there soon. #XMPP #froscon #Conversations_im
