Yes, the whole app will be Linux Mobile ready soonish, but priority was to have the main screen first and get everything ready in-time for Debian stable inclusion
422 karma · joined May 29, 2015
Every now and then, when a new compliance suite is published, I'd need to update the one concatenated document aka. monolithic spec. A new compliance suite in XMPP "activating" a XEP is like "merging" an MSC. For as long as a XEP is not part of the compliance suite, it's not part of the monolithic spec (it's still just an MSC) and you don't have to mess with it.
The only real difference is that the current version of XMPP spec is a document with links to other documents whereas the current version of Matrix spec is a document with links inside the document itself.
They do happen. And whenever someone does make use of them, that's considered unlawful - which is absurd considering that the bug is part of the code and thus part of the law.
Regarding moderation and spam: I think a company with €7.5B yearly revenue should be reasonable able to build something such that moderation and spam prevention are also possible with federation. Google already does a pretty decent jobs in spam filtering with e-Mails, I guess they should be able to do something similar with IM.
Dino already supports some kind of "double encryption", where even if DTLS-SRTP is terminated at a media routig or bridging server, there is another SRTP encryption layer. This allows for end-to-end encryption even when DTLS-SRTP is terminated by a server for WebRTC compliance (as WebRTC requires to encrypt using DTLS-SRTP even if transported media was already encrypted through other means).
The XMPP Standards Foundation publishes a document once a year stating a set that decent XMPP clients and servers should implement. The current one, https://xmpp.org/extensions/xep-0459.html even has a specific section on calling (it doesn't cover group calls yet).
I run my own server (any 5 bucks VPS can do), but there is a large number of public servers that also work good. Make sure to pick one with a good ranking at https://compliance.conversations.im/
> <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).
But: - HTTP forms might be less flexible when it is about structured data. - HTML needs a complex renderer software
Remember that this stuff might need to work on low resource devices and over low bandwidth connections.
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.
My Laptop's fan always runs full speed when being in a Jitsi conference for more than a few minutes.
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.
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).
> 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.
Beside that, Dino does support peer-to-peer file transfers using Jingle.
It's definitely something that is now becoming more relevant after the first release.
tls-sni-02 requires the generated self-signed certificate to contain an additional subjectAltName (SAN B) that is not send as part of the request and thus only known to the actual client, not to any host that automatically generates self-signed certificates (if such hosts exist).
Not doing so reveals there actual reason: control. Forcing every manufacturer to ship Play Services and thus being able to force various things on their devices is a major financial benefit. It also ensured that Amazon or Nokia were unable to set up a commercially viable Android Fork without Google.
Also note that most Google ToS don't specifically forbid third party usage (and some also specifically allow them), the only thing that's forbidden is to misuse APIs in a harmful way. Just another example would be the login/account management part of microG, that uses the publicly described OAuth APIs, obviously intended for third-party use.