inputmice

Author here: Indeed, 15% is fine. They do provide some services. They provide the CDN for downloading the APK. They handle sales taxes in the various countries, which would be a PITA to handle yourself. Similar-ish services like Patreon charge a fee too. The 30% they charged a couple of years back was bad. But I could live with 15% if the support were anything other than zero.

XMPP at 11 years old would place us in the year 2010. Requirements were different in those times. Psi on my desktop and Bombus (a J2ME client) on my Nokia E71 worked great. The transition from that into the mobile-first age was rough though. The article says that too. It only improved in 2014-2015.

Indeed. And on a Google-free Android phone the XMPP client Conversations can utilize its existing, permanent XMPP connection to deliver push notifications to other (mostly open-source) apps using an alternative to Google push (FCM) called UnifiedPush.

There was a talk at FOSDEM about that.

https://gultsch.video/w/gRGZqKKvNBvvMesyWNQzoK

XMPP these days often gets used as a friends-and-family style messenger (Think WhatsApp, iMessage, Signal replacement) rather than something communities would use (Discord/IRC). A lot of users of XMPP are also out of the public eye. NATO, police forces and intelligence agencies use it. The community style channels are supported though and a search engine for them can be found here: https://search.jabber.network/channels/1

The blog post you are referencing explains the changes the XMPP community has to do to keep up with what Lets encrypt did. TLDR: People just need to upgrade their servers.

Maybe the first but not the only one. Ltt.rs (an email client using JMAP) does this as well. BTW you can also directly deliver WebPush notifications to FCM servers. No need for a proxy/rely run by the app developer.

Ltt.rs has support for both UnifiedPush and FCM and is fully open source. The code difference between UP and FCM is very very minimal since - as I said - both are just WebPush endpoints.

There are certificates that are valid for the XMPP domain example.com but not for the regular (HTTP) server on example.com. Off-the-shelf verifier don’t have support for that.

* Conversations uses two different OpenPGP implementations. (It doesn’t)

* The auth tag truncation was 'silently' introduced in the spec. It wasn’t. The author retracted that but only barely

* ominously pointing out that Conversations has a SASL implementation (In fact Conversations can use that to detect some MITM attacks; which is pretty cool)

* ominously pointing out that Conversations has a certificate parser (yes and so does almost everything that uses TLS)

> Also relevant https://soatok.blog/2024/08/04/against-xmppomemo/ recently.

Signal, Matrix, Telegram, XMPP; Use whatever you want. But there is a lot of FUD if not outright lies in that blog post. The author looked at Conversations for all but five minutes, desperately trying to dig up some dirt.

> and attacks like this are just downright scary

> https://notes.valdikss.org.ru/jabber.ru-mitm/

With an up to date Conversations on a modern server we have a pretty good chance to detect or prevent that style of attack due to a mechanism called SASL Channel Binding.

JMAP (IMAP+Submission replacement) has support for WebPush. If I have a minute I’ll implement UnifiedPush in https://Ltt.rs - Sadly JMAP doesn’t have a lot of server implementations. (Yet? Maybe)

> Causing all extensible JSON-based protocols to eventually reinvent them:

That's funny because it's true. To add to your list: JMAP (https://jmap.io/) has namespaces too.

Quicksy.im / Conversations.im developer here. I promise I’ll never implement crypto currency into my messenger apps.¹

Even if I break my promise you could just use a fork of my app since XMPP servers don’t prevent third party clients from connecting.

¹: I don’t have to either because I have a working business model that’s not a ponzi scheme

The existing JMAP bridge is broken. But it would cool if 'IMAP API' used JMAP instead of coming up with its own protocol. (Which covers a very similar feature set than JMAP)

This would allow you to use the api with any JMAP client like Ltt.rs for example.

> If your use-case is just wanting to fetch emails from a bunch of inbox folders in real-time, potentially with some querying/filtering,

Nobody says you need to implement all of JMAP (from a client perspective). Just implement Email/query Email/get

https://xmpp.org/extensions/xep-0030.html :)

As someone who has thought a good deal about contact discovery the mitigation techniques section is actually pretty interesting. Quicksy.im, an XMPP client but based on phone numbers and with built in contact discovery, I developed ~2 years ago, already does very strict rate limiting, but the paper mentions some other techniques as well that I should probably look at.

Congratulations on acquiring the funding.

> Support for encrypted two-party calls that are compatible with Conversations should be ready by the end of this year or early next year.

Exactly a year ago I made the same announcement with the same timeline for Conversations. In the end it took me until ~April of this year and I giant kick in the butt from a global pandemic to finish it.

Let's hope that they beat my timeline.

Two issues here:

Models like these existed. Flattr and Liberapay. The latter had to switch away from the pooling model because turns out when you do the pooling you essentially become a bank and that’s difficult to do legally.

Those models only work if users actually visit your website or your Github. I’m developing an app targeted at end users and I bet 90% of them have never been on Github or even know what that is.

Does this mean we are only 10 years away from fusion?

The problem JMAP is addressing is quite complex that’s why the JMAP spec is long. I do not however find it to be bloated. On the contrary I actually found it quite easy to read. (I've implemented jmap-mail on the client side.)

One could potentially write JMAP as a proxy to an existing IMAP server (just like your 'imap-api') therefore the current lack of JMAP servers doesn’t really matter.

I bought a T495 recently. It’s the worst ThinkPad I ever owned. (After a T60, a X301 and a X250). With modern ThinkPads you have the choice between slightly thicker notebooks T4… series and decent cooling and shitty build quality and thinner, higher build quality (T4…s, and X…) and virtually non existing cooling (thermal throttles the minute you are trying to use the CPU) T495 has weird bugs (S and K keys not working after suspend); and is extremely vulnerable to what I assume are static charges; meaning if I push it over my mattress (to make room to climb into the bed) it shuts down. Never had the issue with any notebook before; Never occurred to me that this could be a problem. Battery life is crap as well.

The irony of a talk that speaks out against decentralized systems being only available on decentralized backups of the centralized original…

Have you considered that SaaS is just a terrible business model?

I call BS on the story. But the fact that this is somewhat plausible and probably within Google’s rights is telling.

As someone who has worked extensively with XMPP in the last ~6 years let me tell you that it works fine with network hopping, multiple devices and everything else you'd come to expect from a modern IM experience in the likes of WhatsApp and Signal.

I have written a lengthy article in 2016 in the state of mobile XMPP: https://gultsch.de/xmpp_2016.html

The situation has only improved from there.

No I don’t use it daily. It can’t even send emails yet and you have to set your login credentials at compile time. I got frustrated having to deal with HTML emails and now I’m waiting for the servers to mature a bit. And honestly also for dovecot to announce support. I mean I love what the fastmail+cyrus team is doing; but if Dovecot is not going to support it, it is probably not worth it to build a JMAP-only MUA.

The strong suit of JMAP (among other things) is getting access to specific properties of a server side parsed email. It will do the MIME parsing for you; separate attachments and text bodies from each other and for example allows a client to fetch only Subject and senders instead of the entire email. By brainlessly dumping all that into a Maildir you'd be giving up a lot of the benefits of JMAP. I'm a big fan of JMAP but I don’t see it replacing IMAP for (desktop) clients that will keep a fully synced Maildir locally.

Pretty cool protocol. I've been following this for a couple of years. I had already written a library for an earlier version of JMAP (back then references worked differently / didn’t exist); and it was interesting to see how that improved in the IETF process. I wrote a library [1] and a POC email client for Android [2] earlier this year. It takes a moment to fully understand a now fairly complex protocol but when you get the hang of it it becomes very powerful.

Sadly the server support isn’t really there yet. The support for Cyrus hasn’t been released yet (you need git) and some vital functionality like push [3] is still missing. Also no word from Dovecot yet.

[1]: https://github.com/iNPUTmice/jmap

[2]: https://github.com/iNPUTmice/lttrs-android

[3]: https://github.com/cyrusimap/cyrus-imapd/issues/2714

$8/month is rather steep for some email and IM hosting. So there should be revenue left to share with you and the other upstream projects.

Personal side note: I’m not a fan of branding open source apps. It delays security updates and waters down the original brands; Riot and K9 have good reputations; Why not utilize those?