#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.
Strypey
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!
Pirate Praveen
in reply to Strypey • • •LPS likes this.
Strypey
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
Pirate Praveen
in reply to Strypey • • •LPS likes this.
Strypey
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?
Pirate Praveen
in reply to Strypey • • •Strypey
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.
Strypey
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.
Strypey
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…
Pirate Praveen
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.
Strypey
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…
Hippo 🍉
in reply to Strypey • • •Sensitive content
@strypey I heard about ejabberd's Matrix support too; it's good to know and not ideal but a step forward from what we have right now!
I wonder how things like group chats would work, since Matrix and XMPP have quite different ideas on that!
Hippo 🍉
in reply to Hippo 🍉 • • •Sensitive content
Pirate Praveen
in reply to Hippo 🍉 • • •Sensitive content
Hippo 🍉
in reply to Pirate Praveen • • •Sensitive content
Pirate Praveen
in reply to Hippo 🍉 • • •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
Hubert Chathi
in reply to Pirate Praveen • • •Strypey
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
Austin Huang ❤️
in reply to Strypey • • •Strypey
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
Pirate Praveen
in reply to Strypey • • •ejabberd
in reply to Strypey • • •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.
Pirate Praveen
in reply to Strypey • • •Strypey
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.
Strypey
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.
Strypey
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.
Pirate Praveen
in reply to Strypey • • •Pirate Praveen
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.
LPS
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!
like this
Strypey, Ulli and Rasheed Ahmed like this.
Strypey
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:)
Delta Chat
in reply to LPS • • •like this
LPS and nthia like this.
LPS
in reply to Delta Chat • •Delta Chat
in reply to LPS • • •LPS likes this.
Strypey
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
like this
feld and LPS like this.
Pirate Praveen
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.
Delta Chat
in reply to Pirate Praveen • • •LPS
in reply to Strypey • •like this
bjoern and Rasheed Ahmed like this.
Rasheed Ahmed reshared this.
Strypey
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
LPS
in reply to Strypey • •Pirate Praveen likes this.
Pirate Praveen reshared this.
Pirate Praveen
in reply to LPS • • •LPS likes this.
holga
in reply to Pirate Praveen • • •LPS likes this.
Pirate Praveen
in reply to holga • • •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
Strypey
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
Strypey
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
Strypey
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?
feld
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
LPS
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
feld
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
LPS
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
feld
in reply to LPS • • •LPS likes this.
Strypey
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
Strypey
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
feld
in reply to Strypey • • •feld
in reply to feld • • •Strypey
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…
Strypey
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
Strypey
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
feld
in reply to Strypey • • •Strypey
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
Strypey
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?
Pirate Praveen
in reply to Strypey • • •LPS likes this.
XMPP Brasil
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
Pirate Praveen
in reply to XMPP Brasil • • •LPS likes this.
XMPP Brasil
in reply to Pirate Praveen • • •Strypey
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
Pirate Praveen
in reply to Strypey • • •tkr
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)
LPS likes this.
Strypey
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.
Strypey
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
Strypey
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.
Hubert Chathi
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.)
LPS likes this.
Strypey
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
Hubert Chathi
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.
Strypey
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.
JoinJabber
in reply to Hubert Chathi • • •Hubert Chathi likes this.
Strypey
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
JoinJabber
in reply to Strypey • • •Strypey
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
uexo
in reply to Strypey • • •Strypey
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
Strypey
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
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!
Strypey
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
Strypey
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.
Strypey
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 ; )
uexo
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.
Strypey
in reply to uexo • • •(1/2)
Me:
> Without Matrix, it's questionable whether ModernXMPP would have happened.
@uexo
> citation needed
Correlation does not prove causation, but which came first? Unless ModernXMPP came first, I think the onus is on you to prove that it was a response to something *other* than the growth of interest in Riot/ Matrix.
Strypey
in reply to Strypey • • •(2/2)
@uexo
> I will dig up an abandoned Matrix project in a few years and claim it causes me headaches
Oh I'm sure you will ; )
> I will take a look at Matrix again if it becomes compliant with the internet standard XMPP
Two can play at that game. I will take a look at XMPP again if it becomes compliant with the internet standard SMTP, or HTTP, or JSON ; )
But seriously, I find myself able to track the progress of more than one decentralization protocol at a time.
Pirate Praveen
Unknown parent • • •Strypey
Unknown parent • • •(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
Strypey
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 ...
Strypey
Unknown parent • • •> 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
Kris
in reply to Pirate Praveen • • •