It would be possible for Matrix to indicate that a room is a "raw room" and that clients should send and expect raw messages in that room - losing a few features on the go. Such raw room could be bridged over to XMPP fully end-to-end-encrypted (with small changes on either side to adjust for the differences between OMEMO and OLM).
But I doubt anyone at Element will invest time into doing it and for the XMPP side it's much more work to do it "on their own" (by implementing parsing support for the encrypted JSON of Matrix as shown above).
Having raw text in the encrypted content is by the way still the normal way how things work in XMPP world and is supported by every client doing E2EE - because it is basically free to implement (barely any additional code needed).
Which modern serialized protocol do you envision here? That comes with good extensibility by design?
Just the fact that XML is old, doesn't mean it's bad. It might be a bit unnecessary verbose or hard to parse for constrained devices, but luckily there is EXI to solve these issues when efficiency is key.
microG GmsCore is a FLOSS (Free/Libre Open Source Software) framework to allow applications designed for Google Play Services to run on systems, where Play Services is not available.
Dino is native, which means it is more likely to get proper support of hardware accelerated video encoding/decoding, best case leading to less energy consumption during video calls.
My Laptop's fan always runs full speed when being in a Jitsi conference for more than a few minutes.
We fixed some issues with OMEMO in the last months, so if your experience is a little bit older, those might be fixed already. If not, please report.
Dino has a very limited plugin system, extending it is planned for future releases. We are also interested in adding support for A/V calling and we already have some pieces of code for it, though nothing in a quality for actual usage.
Last time I checked, Pidgin lacked proper support for multi device by not supporting Message Carbons (XEP-0280, required to receive messages on multiple devices when both are online at the same time) and Message Archive Management (XEP-0313, required to catch up with messages received while only another device was online).
There is probably also other examples of XMPP features that Pidgin does not and likely will never support, due to its nature of being multi-protocol (basically limiting features to the smallest common feature set).
No. OTR was not considered due to its lack of multi device support. OTRv4 now supports multi device, so it could be an additional option once it becomes standardized for XMPP. We are also monitoring development around MLS.
We are aiming for support for the Librem 5 and other smartphones that use a more GNU/Linux-ish environment. For Android there is conversations.im with a similar feature set.
There is a section on motivation in the blog post (it literally has "Motivation" in the title):
> A number of clients already exist for the XMPP protocol, however Dino sets a different focus. Existing clients target tech-savvy power users. The XMPP ecosystem lacks a client that is enjoyable to use while providing the features people expect from a modern chat application. Dino fills that gap by aiming to be secure and privacy-friendly while at the same time providing a great user experience.
http://pidgin.im seems to be pretty easy. Doesn't require any tech-savvyness other than entering your credentials in a nice, intuitive interface, unless I'm missing something?
Pidgin is a very bad XMPP client these days - at least until you have spent quite a lot of time on gathering and configuring all the plugins needed for modern XMPP experience.
> <message type="chat"><body>Hi there!</body></message>
or raw text
> Hi there!
In Matrix, it's always encrypted JSON
> {"type": "m.room.message", "content": {"msgtype": "m.text", "body": "Hi there!"}}
It would be possible for Matrix to indicate that a room is a "raw room" and that clients should send and expect raw messages in that room - losing a few features on the go. Such raw room could be bridged over to XMPP fully end-to-end-encrypted (with small changes on either side to adjust for the differences between OMEMO and OLM).
But I doubt anyone at Element will invest time into doing it and for the XMPP side it's much more work to do it "on their own" (by implementing parsing support for the encrypted JSON of Matrix as shown above).
Having raw text in the encrypted content is by the way still the normal way how things work in XMPP world and is supported by every client doing E2EE - because it is basically free to implement (barely any additional code needed).