Behind every line of code, there's a woman who paved the way. Discover their stories. 🌐 nowebwithoutwomen.com/
It's a cluster now!
I also installed #Proxmox on each node from scratch to have #zfs instead of #lvm. Restoring containers and VMs from backups was an easy task, but the #firewall made me struggle a bit. I won, but realized that it was misconfigured previously allowing terrific between guests. Now every guest is isolated and only required ports from strict sources are allowed. I'm happy for now )
#homelab #cluster #selfhosted #selfhosting #proxmoxve #proxmoxcluster #homeserver
reshared this
Open Science Community Twente reshared this.
Sure is weird how advocates for gender affirming care bans consistently end up with clowns as "experts".www.assignedmedia.org/breaking-new...
Congratulations to Geoff Hinton for receiving the Nobel Prize in Physics!
Hinton has been awarded the 2024 Nobel in Physics with John J. Hopfield for foundational discoveries and inventions that enable machine learning with artificial neural networks.
Hinton received the 2018 ACM A.M. Turing Award with Yoshua Bengio and Yann LeCun for conceptual and engineering breakthroughs that have made deep neural networks a critical component of computing.
nobelprize.org/prizes/physics/…
nobelprize.org/prizes/physics/…
mastodon.social/@tzimmer_histo…
I may never travel again, if I have to go through Chrome River to do it. It's truly evil, and the clumsiest software I've ever dealt with.
freethoughtblogs.com/pharyngul…
Quattordici stati statunitensi hanno fatto causa a TikTok con l’accusa di avere spinto gli utenti più giovani a un uso eccessivo della piattaforma
Secondo gli stati, TikTok sarebbe stato progettato in questo modo con piena consapevolezza dei danni che il suo funzionamento era in grado di creare in molte persone giovani.
Informa Pirata reshared this.
informapirata ⁂ :privacypride: reshared this.
@naixke insomma, quando dicono che fa male ai bambini intendono dire che fa male al bimbo che è in noi... 😁
#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.
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?
Piki mai, kake mai! Come on in!
> 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.
LPS likes this.
> 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?
(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.
(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.
(3/3)
This is also the model for the Bridge Seat Co-op hosting service we're working on here in Aotearoa;
@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.
> we are currently using an ejabberd component
FWIW ejabberd supports Matrix as well as XMPP, with the same server;
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! 
Sensitive content
Sensitive content
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
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.
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.
(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.
(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.
(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.
@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.
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.
> 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.
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:)
LPS likes this.
@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
@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.
like this
bjoern and Rasheed Ahmed like this.
Rasheed Ahmed reshared this.
@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.
Pirate Praveen likes this.
Pirate Praveen reshared this.
LPS likes this.
LPS likes this.
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
> 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
> 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.
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
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.
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
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
LPS likes this.
here you go, you'll find it among other massive security fails. And this was not even a thorough audit of their code
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.
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
@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
(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
(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?
LPS likes this.
@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
> 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).
@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.
(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.
(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.
(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;
While not feature-complete, they're a better test of the "weight" of the protocol itself.
@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.
@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?
> 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.
@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
@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
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
@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!
(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
(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.
(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 ; )
> 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.
(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.
(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.
(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 ...
> 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.
A trans woman came out to her great-grandma & her response is melting hearts around the world - LGBTQ Nation
https://www.lgbtqnation.com/2024/10/a-trans-woman-came-out-to-her-great-grandma-her-response-is-melting-hearts-around-the-world/?utm_source=flipboard&utm_medium=activitypub
Posted into LGBTQ Nation @lgbtq-nation-LGBTQNation
its not inexplicable. nbc universal wants trump to win.
'Shadow Beneath the City' by Rithick S
blenderartists.org/t/shadow-be…
#b3d #blender3d #blenderart #blenderrender #blendercommunity
There has never been a better time to be able to see what version of #Mastodon an instance is running! Congrats to the entire team on shipping these improvements 🎉🥳🎈
techcrunch.com/2024/10/08/x-ri…
Grab Mastowatch here to see if your favorite instance is running the new build yet: apple.co/3VUPytt
Yehor 🇺🇦
in reply to Yehor 🇺🇦 • • •It is complete!
#homelab #proxmox #cluster
Yehor 🇺🇦
in reply to Yehor 🇺🇦 • • •Oh, look! There is a summary of a cluster. Nice =)
#homelab #proxmox #cluster
p̻̻̥r̥̻̥o̻j̤͛ec͔t̞dp
in reply to Yehor 🇺🇦 • • •Yehor 🇺🇦
in reply to p̻̻̥r̥̻̥o̻j̤͛ec͔t̞dp • • •Ghost: blog.yevi.org
yevi.org
Home Assistant VM
Two Minecraft servers
Zoraxy as an ingress
Gitea action runner for CI/CD
FreshRSS
Umami Analytics
Dawarich
Bar Assistant
#homelab #selfhosted #selfhosting
BLACKVOID ⚫️
in reply to Yehor 🇺🇦 • • •