#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.
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 and Ulli 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
feld likes 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 • • •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.
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.