Hacker Newsnew | past | comments | ask | show | jobs | submit | inputmice's commentslogin

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.


> 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.


>> "But there is a lot of FUD if not outright lies in that blog post. "

For example...


* 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)


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

It's trivial to use TLS without writing your own certificate parser. Doing this means taking on a lot of unnecessary risk, such as CVE-2023-33202.

Your encrypted messaging application shouldn't need to have a separate X.509 or ASN.1 parser built into it. If you're going to use them from TLS, you should rely on the library your OS vendor maintains for you, since they have an incentive to keep theirs secure anyway.

"Ominously pointing out" that the Conversations project has taken on an unhealthy amount of complexity and risk isn't FUD, it's a criticism of how the project is managed. Confuse the two at your own peril.


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.


> 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)


That'd be quite cool :) I've been using maddy for a self hosted mail server, itd be nice to replace it with stalwart and give ltt.rs a try... and convince the hosted mail i use to start using a JMAP supported server


AFAIK Cyrus has JMAP support. We are using it for more than 20 years at work without any issues. However, we are lacking compelling client support for JMAP (via using SoGo via IMAP currently). Would be great to have a good static webclient for security reasons. Configurable notifications would be another plus.


> 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


Is there a way to sign up to it which is as simple for tech-illiterate people as WhatsApp/Signal? I recall the last few times I, a developer, have tried to functionally use any sort of XMPP based thing it has been a confusing and inconsistent experience.


That's exactly what quicksy.im is for, it's a build flavor of conversations that uses the users phone number as jabber id with auto discovery


Can't see an App Store link :(



What's your business model?


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



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.


Like with websites and password managers, rate limiting works fine when going via the expected auth service. Doesn't help at all when NSA/MSS/Mossad have popped the contact hash database off Whispersystem's backend.

(Admittedly, if that's your threat model, I hope you have enough magic amulet's in the submarine you now live in...)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: