I'm hoping the boot process for the imx8m SoC is well-documented enough that it would be practical to boot into Redox OS with a Rust boot loader. Rust all the way down the stack.

But for now, I have real work I have to get back to.

I'd rather see a self-serve tax filing system, instead of a "must pay oligarchs a fee and give them all your confidential and sensitive data to do mandatory filings with the Government"

I guess the priorities are NOT Canadian.

I would hope the OQLF would object, but then I'm a dreamer here.

@bougiewonderland but if a menu has the wrong font size, yeah they unleash the wrath.

I would expect that they would have jurisdiction in objecting about the way the federal Govt want to communicate in French with the Province of Québec.

As I said, I'm a dreamer. I dreamer of a world that is functional.

This is one of many examples of why I use a specific 2.x version for all clients and refuse to update. They’re creating security problems by breaking the client in different creative ways every update.

Mind you, I have zero complaints about the server and web sides. It’s **just** the desktop client which is regressive and broken.

Замечательно, спасибо, Даниэль! Можешь ли ты настроить так, чтобы Conversations и Quicksy по умолчанию активировали привязку канала?

И ещё один вопрос: в какой версии Conversations появится возможность выбирать только TLS 1.3, как на скриншоте?

Let's consider how deltachat, in its default mode of operations, works.

What is the purpose of Channel Binding ? It seems to me to be mitm-resistance, but considering that in deltachat, contrary to Conversations, the user doesn't even know their password I don't see how they're going to be phished on a scam website. The only way to connect from another client is starting from an already legit one that will consciously share credentials. The app, like conversations, doesn't make typos when calling the server, so if mitm didn't happen through mistyping the address it happens behind TLS, so it's the same for Conversations.

What happens in the case of a mitm ? In deltachat chats are not mitm-able: the only thing a mitm box will see is gpg-encrypted emails. Recall that in its default setting email addresses are pseudonymous (i.e they have no human meaning and it is expected that one person will use many addresses) so what a mitm will see is that some random address sent some other random address something, and the date. The real mitm that can have an impact is one that can intercept the qr code, or the link it contains, out of band. Nothing can be intercepted in-band. Note that this is true even in the non-default way of using deltachat, with your own account on another server, as long as you use deltachat.
In Conversations, because the server is important, they will be able to do everything the user can do: see/set presence, change omemo keys, publish/subscribe, read and send unencrypted stanzas. The only thing they won't be able to do is to read the content of encrypted content, but they will still see who sent it in which room.

Deltachat massively downgraded the importance of server to the point they are just relays of content. It is parting ways with the 80's and 90's era of a server capable of doing everything and clients only ordering them to; xmpp hasn't. The result of a mitm is catastrophic in that mindset, but for a more p2p app it's more of an inconvenience.

So, no, deltachat doesn't implement channel binding, but contrary to others including Conversations deltachat actually doesn't need to. So that's ok.

It's a bit disingenuous to talk down on other libre and decentralized messengers, especially when xmpp in its current design and deployment is arguably worse on the security aspect, not talking about the metadata aspect that the xmpp world still hasn't heard of somehow. They are not the enemy, Whatsapp and Messenger are. (note: this is also valid for delta fans)

(I might have made some mistakes, feel free to tell me)
@matrix @delta

yes, you can verify keys, but that's just it: only keys are verified. Everything else can't, and there are many things not protected by e2ee.

I don't understand the part about YOLOing the transport though, or is that another subject ?

@delta @matrix

I've got two XMPP accounts, one at Conversations the other on another server.
If I activate it, do you know it it will just be ignored or "break" something when it comes to the other server.

PS. Thanks for a great app! Been using XMPP since early Jabber days, Conversations is my favourite client for it.