The only relevant feature for any instant messaging app (or social app, for that matter) is: Are my friends using it? People will gladly overlook minor inconsistencies or missing features as long as they can communicate with their friends. We shouldn’t recommend #Signal as a stepping stone before Jabber/XMPP becomes "good enough," if goodness is defined by the number of people using it.
@ApostateEnglishman I'm trying to phrase my statements in a way in which they don't sound like an advert, but I'm developing and Android instant messaging client called #Conversations_im which uses a federated instant messaging network called Jabber or XMPP.
Wenn wir das mit der digitalen Unabhängigkeit ernst meinen ist #Signal einfach nur eine Ablenkung.
#Quicksy hingegen ist ein wirklicher Schritt in die richtige Richtung. Quicksy ist so konzipiert, dass man darüber hinaus wächst und ein nahtloser Übergang zu #Conversations_im möglich ist. Quicksy ist die Einstiegsdroge für wirklich unabhängiges Instant Messaging mit #XMPP.
Der #DiDay und die Messenger - Eine einfache Lösung?
Schön wäre ja, wenn mehr Menschen zu offenen, föderierten Messengern wie Matrix oder XMPP wechseln würden.
Die grösste Hürde bleibt oft: Menschen finden.
Ich habe nun Quicksy ausprobiert.
@fluttersh @dino there would be some default 'rewrite proxy' (like up.conversations.im in #Conversations_im for example). And then you would also have some default XMPP server that allows anonymous login but can only connect to said rewrite proxy. I guess one could also allow list certain extensions. But for the domain allow list we already have the building blocks in place. I guess technically the login server and the rewrite proxy could be the same domain even. That's just boring details.
I think #XMPP has a relatively clear and achievable path to drastically reduce the amount of metadata, but I’m increasingly worried that it is not going to move the needle in terms of adoption.
For 99.99% of people, the only relevant feature for an instant messenger is simply 'Are my friends using it?' The other 0.01% are equally divided between people who already use XMPP and don’t mind the metadata, and people who won’t use it anyway.
I always wanted to add push support to #Conversations_im. I think a federated instant messenger is a natural fit because you get the decentralization and the connection for free. And adding it to the messenger is also what Google did with gtalk.
So I was very happy that I found #UnifiedPush as a quasi standard when I finally got around to implement it. Thank you for your for work!
@monocles and #Conversations_im are available for free on your Android device since Dec 24th and until the 31st on Google Play!
Get your friends and family and don’t miss out on the opportunity to install and onboard them in one (or both) of the most featureful #XMPP clients on Android!
Set them free from invasive, data harvesting, centralized IM communications networks!
I consider this a failure on our part but I don’t really know what to do about it. Most arguments against #XMPP don’t hold if you’re building from scratch anyway:
• #Conversations_im looks very outdated: OK, but you are developing your own clients anyway.
• XMPP doesn’t have an SDK: Neither does your #ActivityPub or email stack
• OMEMO is insecure and I would prefer #MLS: Yes, let’s work on that together and you’ll still benefit from XMPP’s 100+ solved IM problems.
If a friend bought the #39C3 ticket for you and sent the .pkpass file via #XMPP, those files are now properly identified in #Conversations_im and display with a nice icon instead of a generic unknown file icon.
„The features matter a lot less than the people who are using the platform. […]
It can sometimes be a bit misleading when you get a lot of ideas and feature requests in a community, and the conversations become, ‘We definitely need feature X to grow because that’s what’s stopping people from using the platform.‘ While that’s true in some cases, the sad reality is that any flaw can be overlooked as long as the people you want to reach are there.“
Fortunately, getting killed by the CIA by means of predator drone strike is not everybody's threat model. For others - certain French judges for example - a real threat can be getting sanctioned by the US government and completely locked out of US services.
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.
#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.
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.)
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.
