What about an /e/ xmmp service supporting omemo as part of the /e/ account?

Hi !

I’m wondering if the /e/ foundation has explored has explored providing XMMP servers supporting omemo, for those having /e/ accounts. If not, is it possible for it to be considered?

There are options like Signal, Threema and Matrix, but certainly for one reason or another, XMMP with omemo support (with clients encrypting everything, chats, voice messages, voice calls, video calls) keeps being the privacy champion, with way less metada leakage, not requiring phone number, and so on. Also the level of involvement of for profit orgs into the non profit orgs is fuzzy on some, and some that advertise themselves as open source at least, it’s questionable how their servers are really open, and on some federate, but when having to interact between different instances, in particular groups, then there’s a mess of metadata leaking… Or so I’ve come to understand after some reading…

So, although there are some non profit orgs offering free XMMP services, and also there ere paid services, I’d think by /e/ accounts offering XMMP services would make it easier not only adoption, but also the inconvenience of searching for the server, or even self hostig one, which not everyone can…

Hopefully this will be considered, :slight_smile:

9 Likes

I would like XMPP service by /e/foundation as well. As soon as I am concerned, a XMPP server does not consume much resources

2 Likes

I’d say the future are distributed services such as Matrix and not again a centralized XMMP server where I can only talk to users registered on that specific server. This would be just another Google Talk and lock us all in. What I love about /e/ is its openness, e.g. by /e/ using NextCloud I can just switch to another provider and this is the freedom I am looking for.

A Matrix instance has already been proposed here [FEATURE PROPOSAL] Start a Matrix instance and I think it could be an option. Although I think that /e/ should focus on its core functions to do the one thing they do really good.

1 Like

Xmpp is not a centralized service. It’s similar to matrix as it is a federated network. I really like the idea with an xmpp servie. There are good xmpp opensource apps on android.

XMMP is as federated as Matrix is. Users connected to a particular service can easily communicate with users connected to other services. And that happens way more privately than with the Matrix protocol which leaks way more metadata.

Matrix is no different by the way, which is NOT distributed, it’s federated. And both XMMP and Matrix, can be de-centralized, as long as you self host. But if you have a Matrix account, or an /e/ one for that matter, that’s not de-centralized at all, you are using a central service, wherever it comes from. It becomes only de-centralized if you self host, be it XMPP or Matrix. But not all of us can self host, :frowning:

BTW hosting a Matrix service, I’ve read, requires much more computing resources, besides the fact it leaks way more metadata, particularly when you interact with people using other Matrix services, and even further when using groups. So hosting XMMP with omemo support is lighter, and depending on your client, even video calls are omemo encrypted (they are about to be on Dine, and they already are on conversations), whereas the video calls are not e2ee encrypted on Matrix clients, they use the webRTC encryption, provided by jitsi, which is used as a plugin on element, and moreover not all Matrix clients support e2ee, neither are as polished as the Element client, which is sadly an electron client for the desktop, which won’t change.

So again, if /e/ provides XMPP services, that would be just great, and though it’s impossible not to have impact on storage and computing resources, those wouldn’t compared to what hosting Matrix requires.

So I still hope the /e/ foundation gives some thought to this request… The same storage limits already in place might apply in conjunction with the XMMP service, for free accounts, and the different payed plans. Or perhaps there could be a bit of increase to the limits for all accounts types. But for sure, it would be another step forward towards privacy and security, making it easy to adopt, if for example conversations is there by default on the /e/ phones. People would be ready to go and use XMMP without burden.

4 Likes

An example of a nice integrated XMPP service that could be reproduced by /e/ :

they propose a very nice app (with audio and video calls) and webclient.

1 Like

I rather like plain XMMP service, and having conversations installed by default on /e/ phones, than something like a wrapper/special version of XMMP… Built on top of XMMP doesn’t sound good to me. There’s a bunch of commercial non native XMMP services:

And I strongly believe such non native services, or wrappers or special versions of XMMP must be avoided… Having special clients for full features support sounds wrong to me as well… Not sure if that’s the case of blabber though. I’d prefer a XMMP service for sure, than a service built on top of XMMP (that on top actually makes me wonder)…

Such a service, hopefully native, must allow full features on any clients (on phones and desktops), in particular FLOSS ones, and federates with users on any other services (there are several XMMP services scattered around), it’s fine.

BTW, as this is a community forum though, I have no clue if making suggestions here is actually reviewed by devs, :thinking:

Thanks for the important information!! Both services are definitely more efficient and private, but that really makes me think hard about going with XMPP.

I like the idea of making XMPP usage easier. I have an XMPP account and Jitsi but would rather not run my own servers. At the same time family and friends are using Signal or WhatsApp so a bridge would be pure gold worth. (These guys will never go through the work of setting up an XMPP account.)

This topic was automatically closed after 30 days. New replies are no longer allowed.