Skip to main content


#debutsav #kochi group photo. We had a session to introduce #FreeSoftware and #Debian Then people with a debian based system joined for packaging workshop. Others went for documentation sprint.

I showed updating node-del package from 7.0.0 to 7.1.0 and many people followed me and built node-del 7.1.0 in their own machines. Some started working on updating other nodejs / ruby packages to newer minor / patch releases. Hopefully some of them will stick around and contribute.

in reply to Pirate Praveen

How do we make fediverse developer spaces like the FEP process, SocialHub, SocialCG, and SWF more welcoming to people like the ones in this photo?

socialhub.activitypub.rocks/

Piki mai, kake mai! Come on in!

in reply to Strypey

@strypey Fedi developers will need to go to events like this and talk to people outside usual circles. For now I'm focusing on #XMPP as I think replacing #WhatsApp is more important right now.
in reply to Pirate Praveen

> For now I'm focusing on XMPP as I think replacing WhatsApp is more important right now

Fair. 2 questions;

1) Are you familiar with the @snikket_im project to build a modern, easy-to-use chat experience using existing XMPP software? (Full disclose: I've done little bits of paid contracting for it)

2) Why XMPP, and not Matrix, Delta.Chat (E2EE chat over email protocols), or Sup messenger (E2EE chat over ActivityPub)? Just curious.

wedistribute.org/2023/08/sup-b…

#chat #XMPP

in reply to Strypey

@strypey @snikket_im 1. yes, I know about Snikket. I like what they do. I think they are able to reach only a small percentage of the WhatsApp userbase - those who can afford to self host an instance and people in their immediate circles. We can't recommend a random person to use Snikket, as the entry bar is too high. So imho, it has to be a public service like Quicksy, hence we built Prav on Quicksy. Prav is a coop variant of Quicksy. Technically both are very close to each other right now.
in reply to Pirate Praveen

> it has to be a public service like Quicksy, hence we built Prav on Quicksy. Prav is a coop variant of Quicksy

If you mean Quicksy.im that's just a tool for matching phone numbers to JIDs, and a client app. Who hosts the servers you are encouraging people to sign up on? How are the costs of running those servers covered?

in reply to Strypey

@strypey Quicksy app creates accounts on quicksy.im XMPP server, it also has a directory. Prav forked both client and server and we self host the server. Currently it runs on donations, but going forward, we want users to subscribe to cover costs. We are in the process of registering as a coop.
in reply to Pirate Praveen

(1/3)

@praveen
> going forward, we want users to subscribe to cover costs. We are in the process of registering as a coop

Sounds great. The aspirations of @snikket_im and Prav seem very closely aligned, and I'm sure collaboration would be welcome. You may know this already, but for the record, Snikket is is not a co-op, but is it registered as a not-for-profit social enterprise in the UK.

in reply to Strypey

(2/3)

A couple of questions, is the Prav co-op plan for each person with an account to pay a subscription? If so, will this be a requirement for use, or an optional way to support the service?

As you said in an earlier post, not everyone can afford to pay. Which is why Snikket's hosting service charges per server, not per account. The assumption is that a group of people can find a way to fund that cost more easily than each individual alone.

in reply to Strypey

(3/3)

This is also the model for the Bridge Seat Co-op hosting service we're working on here in Aotearoa;

bridgeseat.substack.com/p/comi…

in reply to Strypey

@strypey @snikket_im we were in touch with them to see if they can host the xmpp side, but that did not work out.
1. we are currently using an ejabberd component but they are on prosody so we need to write some glue code

2. they were focusing on self hosting so could offer only 100 user max on an instance.

One other change is base iOS app, they are using Siskin (when they started it had most features), but Quicksy chose to wait for Monal getting features so will be Prav.

in reply to Pirate Praveen

> we are currently using an ejabberd component

FWIW ejabberd supports Matrix as well as XMPP, with the same server;

process-one.net/matrix-gateway…

This entry was edited (1 week ago)
in reply to Strypey

Sensitive content

in reply to Hippo 🍉

A tempting but unworkable idea

Sensitive content

in reply to Hippo 🍉

A tempting but unworkable idea

Sensitive content

in reply to Pirate Praveen

A tempting but unworkable idea

Sensitive content

in reply to Hippo 🍉

A tempting but unworkable idea
@badrihippo
One step at a time, if we get text working, figuring out others will be easier. Even we fail, getting text based interop itself will be a big jump.
@strypey
in reply to Pirate Praveen

A tempting but unworkable idea
@Pirate Praveen @Strypey @Hippo 🍉 Unfortunately, it's more complicated than that. Even if they all implement MLS, the systems use different payload formats (you don't just encrypt the message text, you need to encrypt extra data, which would be XML in XMPP and JSON in Matrix). In addition, MLS is dependent on the user ID. Bridges change user IDs so it would break MLS. That doesn't mean that is completely impossible, but it does mean that it's harder than just implementing MLS in each protocol. Basically, each protocol would still need to be aware of each other.
in reply to Hippo 🍉

Maybe @ejabberd can tell us how their Matrix support works?

@badrihippo
> I wonder how things like group chats would work, since Matrix and XMPP have quite different ideas on that!

Failing that, maybe @hubert or @austin or some other @matrix folks might have some idea?

#chat #GroupChat #XMPP #Matrix

@praveen

in reply to Austin Huang ❤️

Thanks @austin

@mremond;
> only one to one chat is supported for now

Good to know. That's still cool though, allowing anyone on an ejabberd server to talk to people with Matrix accounts is a step towards unifying the federated chat space.

@badrihippo @praveen

in reply to Strypey

@strypey @ejabberd @badrihippo @hubert @austin @matrix I think the main differences are in storage and replication only. In Matrix, the state of the group is stored for long and synced across all participating servers, but in XMPP, it is only stored at one server and for a limited time (a week in case of default prosody setting).
in reply to Strypey

@strypey @badrihippo @hubert @austin @matrix
I agree we need to improve the doc on Matrix support.
For now it is just one to one messages.
The next release (Not 24.10 but the one after, still this year) will support joining Matrix groups.
And the roadmap for next year is even more exciting regarding Matrix support in ejabberd.
in reply to Strypey

@strypey @snikket_im 2. Matrix is too heavy to manage, it needs more computing resources (storage, memory and processing), since it has to keep the full state of every conversation and merge the state between all participating instances (I have experience running both). Due to high storage requirements, backups take longer or you need more costly cloud based storage. You also need more effort to upgrade it. But it could be a good solution for people who can afford it. Sup is too new.
in reply to Pirate Praveen

(1/?)

Right now, whether XMPP or Matrix is the better choice depends on your priorities, and what kind of UX you are trying to replace.

Matrix is designed to decentralise chat room services, like IRC, Slack Discard or TeleGrim. One-to-one chats are an afterthought. They work (with E2EE by default), but with limitations.

XMPP is the opposite. It was designed to replace the one-to-one Instant Messaging popular in the late 90s. Group chats are an afterthought. They work, but with limitations.

in reply to Strypey

(2/?)

@praveen
> it has to keep the full state of every conversation and merge the state between all participating instances

True. But the benefit is that Matrix chat rooms can still work if the originating server is down. Even survive its permanent death. Not the case with XMPP+MUC rooms, nor with IRC channels, for which the originating server is a SPoF.

Which is fine for quick watercooler chats among small groups. But not so good for rooms where permanence and access to history matter.

in reply to Strypey

(3/3)

@praveen
> Due to high storage requirements, backups take longer

This is a cost of decentralising group chat. If XMPP servers stopped depending on one server to store each room's history, it would be the same.

Storage also depends on data retention policy. Keeping full room histories is optional. Also, media files use more space than text messages. So as with fediverse servers, aggressive media-pruning can keep storage loads down, while still storing years of full conversation history.

This entry was edited (1 week ago)
in reply to Strypey

@strypey I understand that benefit. I just find the cost of doing all that very very high compared to the risks it mitigates. If people can afford matrix, go for it. XMPP wins on cost vs benefit and long term sustainability (less resources to burn).
in reply to Strypey

@strypey
I wonder, if Matrix is a good choice, if group chat history matters. My experience with large rooms is, that they need a regular "upgrade" procedure. I.e. old room is closed, everyone gets moved to a newly created one. No history is migrated.

#Jabber is not better, though. There is MUC-MAM, but it doesn't store everything forever. Best you can get is probably an external log.

in reply to Debacle

@debacle @strypey What are the maximum limits of MUC MAM? Can it store like say for 10 years?
in reply to Pirate Praveen

I don't think there is a maximum per se (AFAIK Ejabberd defaults to infinite), but there isn't any good UI to search and find anything in MAM history, so this would be a bit pointless (but depending on chat history for important info is a bad idea anyways).
in reply to Kris

> depending on chat history for important info is a bad idea anyways

That depends entirely on the chat system. Depending on *MUC* history is a bad idea, for sure.

Indymedia used to hold decision-making meetings on IRC, so all channels on our IRC server were logged and publicly searchable.

Matrix comments have a URL and can be linked, just like fediverse posts. Which makes the history of public rooms trivial to search. If we were setting up Indymedia now, we'd use it.

@debacle @praveen

This entry was edited (1 day ago)
in reply to Debacle

(1/2)

@debacle
> My experience with large [Matrix] rooms is, that they need a regular "upgrade" procedure

Room upgrades are optional, and "regular" is a bit of an exaggeration. They happen only when there are breaking changed to parts of the spec that define room behaviour.

@praveen

in reply to Strypey

(2/2)

@debacle
> No history is migrated.

True. But while @austin or @hubert may be able to clarify or correct me, I'm pretty sure the room history is not lost, as it is when a MUC server dies. AFAIK the old room is tombstoned and can still be found to search its history.

Certainly it would create a better UX if an upgraded Matrix room brought its full history with it. Hopefully further updates to the spec will one day make that possible. But it's already far more resilient than a MUC, so ...

in reply to Strypey

@strypey @snikket_im Delta Chat is relatively new and I don't use it. Basically I'm already familiar with #XMPP, then #Quicksy already provides the onboarding and contact discovery familiar to most people through WhatsApp (SMS OTP sign up and contact discovery via phone book).

Unlike most other software, choice of messaging app is not just personal (the social cost of not using WhatsApp is too high and not easy for most people). So we need a different strategy and well coordinated campaign.

in reply to Pirate Praveen

The great thing about #deltachat is that it already uses the largest federated platform on the planet, email :) When users are both using the client conversations are automatically encrypted, and when they're not, you can still send messages to regular emails:)

Just posting this here for others that may be following this conversation delta.chat/en/

Regardless, great choice working with XMPP and all the best!

in reply to LPS

> Delta Chat is relatively new and I don't use it

The app itself, yes. But as @lps says it uses email protocols, which are older than XMPP, and even older than HTTP!

I've been using Delta for about 5 years, with an email account I was already using with friends/ family. Many of them try it, because they can use an existing email account.

FYI I've been trying to get people I know to use XMPP since it was called Jabber, before it was standardised at the IETF. With almost no success.

@LPS
in reply to Strypey

My wish for #deltachat is that they would lean into the email aspect by making it a full-fledged email client that also has direct chat support.

I think this way, anyone that already understands how alternative email clients work would be more likely to install it to replace what they're already using.

It would effectively be bundling two "different" services into one:)

Just my two cents:)

in reply to LPS

@lps @strypey for making Delta a full-fledged e-mail client, we would need people and funds ... FYI thunderbird alone operates on >6 million yearly, not to speak of Outlook, GMail, GMX etc. DC has less than 500K yearly. For now, we rather focus on decentralized secure open-signup messaging with interactive apps, interoperable with e-mail. With sufficient growth there, we may also able to focus more on DC as an e-mail app again ... which several of us sympathize with :)
in reply to Delta Chat

Is there any path to "team up" with K-9 developers for something like this? Or are they completely merged with Mozilla at this point? Am I remembering that correctly?
in reply to LPS

@lps @strypey The K-9 main developer @cketti is indeed working with Mozilla for two years now, together with a colleague, and they are building Thunderbird-Android -- we talk from time to time with @thunderbird folks but there are no joint dev plans. As to the precise relation of Thunderbird and Mozilla, it's better to ask/inquire with them but last we heart, they run on the administrative infrastructure of Mozilla, but Thunderbird has their own separate accounting/leadership.
in reply to Delta Chat

@delta
> The K-9 main developer @cketti is indeed working with Mozilla for two years now, together with a colleague, and they are building Thunderbird-Android -- we talk from time to time with @thunderbird folks but there are no joint dev plans.

The more I think about this, the more I find it mystifying. Why aren't all email apps adding a version of AutoCrypt and a cross-signing QR code so they can auto-E2EE messages between them and Delta Chat?

@lps @praveen @cketti @thunderbird

in reply to Strypey

@strypey @delta @lps @cketti @thunderbird Cross project collaboration and standards beyond the core is very hard, especially the final bits of providing a good UX, on top of the core protocol.

In xmpp also, most projects are too focused on their individual projects and lose the vision of providing a good #xmpp across to all users. Snikket is a good start, it picked a server + android and iOS app as a single branded product. Quicksy recently gained iOS app and Prav, we hope to build an iOS app.

in reply to Strypey

I agree that should be the default for every email client. Delta shows how "easily" it can be done. Right now encrypted mail is a pain to set up if you don't understand it, which is why so few use it.

Rasheed Ahmed reshared this.

in reply to LPS

@lps
> Right now encrypted mail is a pain to set up

You have to be highly motivated. About 20 years ago, as an Indymediatista, I wrote a HowTo for direct action activists, on using email+PGP with only Free Code apps; @thunderbird, Enigmail + GNUPG. I found few other people who used email+PGP, and ran into many problems using it across devices.

Even I didn't keep using it, and AFAIK the UX hasn't improved. These days I only send encrypted messages over email via @delta Chat.

@praveen @cketti

in reply to Strypey

I was a really big fan of the app pep as an email client for this reason. Its defunct now, but I still haven't found and easier way to send and receive secure messages. When another user also had this app everything was automatically encrypted, no matter who their provider was. We need more focus on these types of solutions or these technologies simply won't be used:(

Pirate Praveen reshared this.

in reply to LPS

@lps @delta @strypey @thunderbird @cketti I was also a big fan of pep, but pep and autocrypt not being interoperable was a big hurdle. I was fine with manually creating keys, but wanted to suggest pep to people, but if we can't talk to each other, that is a big fail. People creating similar things but not talking or collaborating with each other and fragmenting is a recurring theme.
in reply to Pirate Praveen

@lps @delta @strypey @thunderbird @cketti for the record, autocrypt was and is a collabaration between several mail app implementors, coming from different organizations. Pep was done by a single well funded entity and there were several attempts from autocrypt's community to collab with it.
in reply to holga

@hpk
When I talked to people at pep (Sva), they initially implemented early versions of autocrypt but could not keep up with changes. They were willing to implement autocrypt support, but the project itself was shut down. Would it make sense to adopt automatic key generation and trust words from pep in autocrypt? At least in Thunderbird, you still need to generate keys manually. Not sure about Delta Chat. May be it is just a matter for Thunderbird?
@lps @delta @strypey @thunderbird @cketti
in reply to Pirate Praveen

> At least in Thunderbird, you still need to generate keys manually. Not sure about Delta Chat

All key management is automated in DC.

There's some improvements that could be made to the UX of exporting and importing backups. But the need for this is mostly avoided by having the app on more than one device. As in Element and a few other apps, transferring keys is as easy as scanning a QR code.

@hpk @lps @delta @thunderbird @cketti

in reply to LPS

> When another user also had this app everything was automatically encrypted, no matter who their provider was

This is exactly what Delta Chat does. There's even a setting for receiving all new email to the inbox, so I use it to handle all my email to that address.

@delta @praveen @thunderbird @cketti

This entry was edited (3 days ago)
in reply to Delta Chat

@delta
> With sufficient growth there, we may also able to focus more on DC as an e-mail app again

With the setting that allows normal email (not sent as a reply to a DC message) to appear in the app, I find it totally adequate as a friends and family email app.

What's missing for you @lps?

in reply to LPS

mmm. Interesting because I've been of the opinion that Delta would benefit from focusing on being a federated Signal alternative and not promote as much that the underlying transport is just SMTP/IMAP. I think this is more likely to confuse people and also make them not want to make a new "email account" just for chatting. (and connecting to an existing email account works, but doesn't provide as good of an experience as using a purpose-configured Chatmail server)

If people want encrypted email the existing options fit the needs of those who care deeply about PGP.

But for a self-hosted E2EE messenger/chat experience (which can federate) there aren't any options that provide a good UX across all major platforms and DeltaChat can fill this void

in reply to feld

I'm not sure how you entice new users to "yet another secure messenger" which is why I think the bundling would help, but I see your point about the less optimal experience with an existing email provider vs chatmail servers being anonymous and secure w no metadata.

Okay, wish number 2:)

If anyone is familiar with #yunohost please, if possible, package a Chatmail installer so we can make this much easier to self-host.

apps.yunohost.org/catalog

in reply to LPS

I've gone down the rabbit hole of doing Chatmail server with my own Chef cookbook (almost complete, perhaps this weekend)

and then I wanted to see about making a docker image as well that can bootstrap itself from some ENVs. I haven't used Yunohost before -- is the core app/service hosting piece done in Docker as well? That would make it reasonably straightforward to port over anyway

in reply to feld

I'm not technically proficient enough to answer that question, which is why I use Yunohost, ha ha

Does this help? yunohost.org/en/packaging_apps

in reply to LPS

it does, and sadly it looks like it will be more complicated to do than I hoped. But it's still possible, of course.
in reply to LPS

@lps
> If anyone is familiar with yunohost please, if possible, package a Chatmail installer so we can make this much easier to self-host.

@yunohost and @buoyantair might have thoughts about this. Also @bob may have done something similar for LibreServer.

@praveen @feld

in reply to feld

@feld
> But for a self-hosted E2EE messenger/chat experience (which can federate) there aren't any options that provide a good UX across all major platforms

Matrix?

@praveen @lps

in reply to Strypey

I think UX is worse, onboarding is much worse (Chatmail: scan QR code and instantly get account), hardware requirements are massive in comparison
in reply to feld

Delta's crypto is much more thoroughly audited in comparison, likely has less metadata to worry about, and Matrix devs admitted to leaving a side channel open so I think the entire project should just be written off at this point
in reply to feld

@feld
> Matrix devs admitted to leaving a side channel open

That is a bold claim, sir. Citation please, or withdraw.

@feld
in reply to Strypey

here you go, you'll find it among other massive security fails. And this was not even a thorough audit of their code

soatok.blog/2024/08/14/securit…

in reply to feld

The content at that link does not justify the comment;

@feld
> Matrix devs admitted to leaving a side channel open

... as a quick skim of the intro and addendum make clear. This is the equivalent of the attention-seekers who claim XMPP is broken and unusable because metadata. Clownshoes indeed.

But if you're so motivated to slam Matrix that you'll make a claim that strong, on the basis of evidence this flimsy, I doubt anything I say will comvince you.

@feld
in reply to Strypey

How complicated is "they knew about the vulnerability for years, never documented it, never warned users, never fixed it" ?

These are not serious people you trust

in reply to feld

@feld

> How complicated is "they knew about the vulnerability for years, never documented it, never warned users, never fixed it" ?

Did you even read the page at the link you gave me?

It was documented. It was an edge case vulnerability that couldn't be made to work over a network. Even if it could, the data theoretically at risk of being exposed wasn't significant payload. It wasn't fixed because it was purely theoretical, not a production vulnerability of any significance.

@vhns

in reply to Strypey

it's only theoretical until someone spends the time and money to make it exploitable. This is like the entire basis of why the Linux kernel is just reporting every bug as a CVE now. You can't be certain what is really exploitable without expending a lot of resources.
in reply to feld

(1/2)

@feld
> it's only theoretical until someone spends the time and money to make it exploitable

You need to read the fine print. Properly scoped vulnerability reports come with trigger conditions. The seriousness of a CVE and whether it needs to be fixed, totally depends on how likely those are.

A theoretical vulnerability can be reported, even if the only way to trigger it is to be sitting in front of your machine, with full root access. But it's not a serious threat in production.

@vhns

in reply to Strypey

(2/2)

People trying to make a name for themselves as security researchers comb through the repos of prominent projects, looking for the most theoretical of vulnerabilities to report. That's not a bad thing, they might occasionally find one that matters.

But people with an axe to grind will collect the nit-picking reports as an excuse to slam projects they have grudges against. Can either of you point me to a serious production vulnerability in Matrix, the protocol or *current* implementations?

in reply to Strypey

@strypey @lps I can relate to your experience of not able convince people to use #XMPP. That is why #Quicksy is so important. I have found success getting people on Quicksy, compared to other XMPP clients. Quicksy simplifies XMPP to have a very similar on boarding and contact discovery flow used by apps like WhatsApp, Telegram or Signal, but still fedrating with rest of XMPP network behind the scenes.
in reply to Pirate Praveen

@strypey @snikket_im one of the problems with conversations/quicksy is their UI isn't so much on pair with WhatsApp/Telegram/Signal.

For the non tech user this makes a huge difference

in reply to Pirate Praveen

> Monocles Chat has some nice additions on top of conversations

As do the Snikket apps, which can be used with any server. But Monocles is my main XMPP app for now (strypey@jabber.org).

@xmppbrasil @snikket_im

in reply to Strypey

@strypey @xmppbrasil @snikket_im If you like to follow the progress of Prav, we are on XMPP as well join.jabber.network/#prav@chat… (did not want to host it directly on prav.app to be able to talk in case problems with the service itself).
in reply to Strypey

@strypey @snikket_im Hi,

only regret, took me about 15 years to know about #xmpp.
only 2, to get know about #matrix.

If i would had to choose now, I would take #xmpp, forever... far of being the best :
-#encrypted comm with #omemo protocol
-#various clients, #software or #applications, on several #platforms/#OS (#mobile, #computer)*
-can handle #voice/#video communicaton (#jingle protocol)
-#uncentralized and #federated
-far more #lightweight than #matrix.

it's a bit the cousin of sip for telephony over ip... but matrix just get the big part of cake with millions ;)
I saw in serveral months several disadvantages of matrix, going to become the "#nerds's #whatsapp" as #discord is, somewhat..

on my own, for people I know well : either XMPP, or SIP. If not, emails, phone and SMS..

*I strongly recommend #dino-im for computers (and #postmarketos - it manages #jingle), #monal/#quicksy for #iOS, #conversations/#quicksy for #android (#fdroid)

in reply to tkr

(1/?)

Hi @tkr, I've been using XMPP since it was called Jabber, before the IETF standardised it as XMPP. That's about 25 years. So I don't need the beginner's notes, thanks all the same ; )

Matrix has all the qualities you list as benefits of XMPP.

> encrypted comm with omemo

E2EE encryption is baked into the Matrix protocol itself. Same with group chat, which in XMPP needs the MUC add-on, and OMEMO+MUC = Headaches. Which get worse as the number of member in E2EE group chats increase.

@tkr
in reply to Strypey

(2/?)

Element joined the IETF group standardising MLS. So I expect Matrix protocol to be updated to use MLS by late 2025, or sooner. Allowing it to encrypt huge groups.

To achieve the same in XMPP will require protocol updates (or replacements) for both OMEMO and MUC. Then implementation of these in both servers and clients.

Based on what I've read from XMPP folks, they haven't started planning any of this yet. So I expect to wait at least 5-10 years for them to have usable MLS.

@praveen

in reply to Strypey

(3/?)

> far more lightweight than matrix

I hear this a lot. It's usually based on;

a) not comparing apples with apples. See;

mastodon.nzoss.nz/@strypey/113…

b) judging the protocol by the Python prototype server. Often based on the state it was in years ago, not how it performs now.

There are replacement servers in development, using production languages like C++, Rust and Go;

matrix.org/ecosystem/servers/

While not feature-complete, they're a better test of the "weight" of the protocol itself.

in reply to Strypey

@Strypey @Pirate Praveen I'm one of the Matrix developers that participated in the IETF MLS group, and FWIW, while we do work for Element, we participated in the IETF group with our Matrix.org Foundation hats on, rather than with our Element hats. And it's a bit hard to predict when Matrix will have MLS support, as work on it is a bit sporadic because it depend on getting funding to work on it. Also, Matrix's architecture doesn't quite agree with MLS's architecture, so it's non-trivial to add MLS to Matrix.

XMPP's architecture agrees more with MLS's architecture, since each MUC room is hosted by a single server. So it would be easier to use MLS in XMPP, though I don't know if there's anyone working on it. (I *think* that I heard of someone working on it, but I don't remember who, and I don't know the status of it.)

in reply to Hubert Chathi

@hubert
> we participated in the IETF group with our Matrix.org Foundation hats on

My mistake, sorry. But hats aside, the same group of people, yes?

> it's a bit hard to predict when Matrix will have MLS support ... because it depend on getting funding to work on it

I'm confused. I thought you said ...

> we do work for Element

Doesn't Element want to increase the practicality and efficiency of large group encryption in Matrix? Isn't MLS now a standardised a way to do that?

@praveen

in reply to Strypey

@Strypey @Pirate Praveen

> My mistake, sorry. But hats aside, the same group of people, yes?

Yes, the Matrix people involved with MLS are also currently employed by Element. So it's an easy mistake to make.

> Doesn't Element want to increase the practicality and efficiency of large group encryption in Matrix? Isn't MLS now a standardised a way to do that?

Yes, switching to MLS is something that we want to do, but there are other things that we also want to do, and we have a limited number of people to do it with. There are several factors that affect our decision on what to work on, and unfortunately, it's meant that the MLS project is currently on hold.

in reply to Hubert Chathi

@hubert
> unfortunately, it's meant that the MLS project is currently on hold

Good to know. I guess I better retract that claim that MLS will be usable in Matrix by the end of the year @praveen. But I'd still be willing to put money on it being usable in Matrix a few years before it is in XMPP.

in reply to JoinJabber

> It's being actively worked on via an NLnet grant

Thanks for the link. This is good news.

Has the funding been confirmed, or is this a proposal? Normally NlNet pages for confirmed grants have a lot more information about who is receiving the grant and doing the work, and so on.

@hubert @praveen

This entry was edited (5 days ago)
in reply to Strypey

@strypey @hubert Confirmed and being worked on already for several months as far as we know. But yes, details are a bit sparse so far.
in reply to JoinJabber

@joinjabber
> Confirmed and being worked on already for several months as far as we know

This is the word I got from Matt at Snikket too.

Well, well. I guess I'll have to retract the claim about MLS support in XMPP taking 5-10 years too. I clearly got hold of completely the wrong end of that sword. No wonder my hand was hurting. How embarrassing : P

#MeaCulpa

@hubert @praveen

in reply to Strypey

@strypey @tkr To claim that you need any add-ons for encryption or that this would cause headaches is quite disingenuous. These "add-ons" are already built into modern XMPP clients and you don't need to care about this as the user. To claim that anything is "baked in" or would cause less headaches from the difference if the specification is in multiple documents or a (constantly changing) single one is laughable.
in reply to uexo

@uexo
> These "add-ons" are already built into modern XMPP clients

Sure. Problem is, it's not always obvious from the outside which of the many XMPP clients is "modern". Attempts to solve this problem by with universal adoption of OMEMO by XMPP apps are met with the usual XMPP dev pushback; 'who cares about anyone else's needs? My client is XMPP compliant, go away'.

If a Matrix app doesn't do E2EE, it's not spec compliant. That's a difference and I do think it's been significant.

@tkr

@tkr @uexo
in reply to Strypey

Note that the list of historical XEPs for encrypted messages include at least 3 different E2EE protocols (OpenPGP, OTR and OMEMO), and for some of these protocols, there's more than one XEP for how to use it with XMPP. So tell me again how ...

@uexo
> To claim that you need any add-ons for encryption or that this would cause headaches is quite disingenuous

Because I get a headache just *thinking about* trying to figure out which clients support which E2EE XEPs now.

@tkr

@tkr @uexo
in reply to Strypey

@strypey @tkr Here is a list of clients which support OMEMO, the other ones aren't relevant anymore: omemo.top/

I hope it won't cause you any headaches that there will be old Matrix clients which don't support MLS after Element implements it. You could invent yet another incompatible protocol like Matrix did though. This will probably solve the problem once and for all!

in reply to uexo

(1/3)
@uexo
> Here is a list of clients which support OMEMO, the other ones aren't relevant anymore

The situation has improved a lot in recent years, thanks to the work of the ModernXMPP folks and others. In large part because having competition (ie Matrix) made XMPP folks realised they had to pull their sock up, or fade into irrelevancy for good.

Without Matrix, it's questionable whether ModernXMPP would have happened.

@tkr

@tkr @uexo
in reply to Strypey

(2/2)

@uexo
> I hope it won't cause you any headaches that there will be old Matrix clients which don't support MLS after Element implements it.

No it won't. Because they'll still be spec compliant, in which case there'll be graceful degradation. Or if they're not spec compliant, word will soon get around that they're not really Matrix clients anymore. So they'll be shamed into either becoming compliant, or dropping the name Matrix from their promotion.

This is not even vaguely comparable.

in reply to Strypey

(3/3)

@uexo
> You could invent yet another incompatible protocol like Matrix did though

The Matrix creators built products around XMPP for years. Then instead of putting up with all the headaches of trying to use it to build a modern E2EE group chat system, they wrote their own protocol to simplify things. Now a lot of people that use instead.

Build a bridge and get over it ; )

in reply to Strypey

@strypey

> Without Matrix, it's questionable whether ModernXMPP would have happened.

Funny, but very much citation needed :D

> So they'll be shamed into either becoming compliant

I will dig up an abandoned Matrix project in a few years and claim it causes me headaches ;)

I will take a look at Matrix again if it becomes compliant with the internet standard XMPP. I don't want to get invested in custom protocols of random VC funded startups that disappear again, when they run out of money.