28 Aug
2025
28 Aug
'25
3:35 a.m.
- The communications platform *is* apolitical. It does not distinguish between
"bad" things (like enabling C&C systems for malware) and "good"
things (like rapid triage of pressure sores). So people use it for both.
We'll just have to agree to disagree here. My point about OMEMO is that the UK and a
number of other countries have just passed legislation that aims to backdoor all E2EE
communication platforms. Like it or not, refusing to backdoor OMEMO will become an
explicitly political position, along with its current technical and ethical
underpinnings.
Regardless of its applied usage, the point is like you said for the server operators /
protocol to be ignorant of the contents of E2EE messages. While there may be attacks
outside the protocol, the XSF is entering into an ethical stance that it will not
knowingly compromise the security of OMEMO. At least, I hope XSF makes this
commitment.""
The "Four Horseman of the Cryptocalypse" is a classic line of argument, I'm
sure you're aware, used to strip people of their civil liberties/rights, in the name
of the "good" guys protecting from the "bad" guys.
My point is, XSF may be apolitical regarding the usage of the protocol (and I really
question that), but the choices around infrastructure, Code of Conduct, Bylaws, software
license, etc are all political-social-ethical choices at some level. Maybe not primarily,
but at some level these choices have implications in those realms.
- And to be sure, I can't see myself engaging if a bunch of malware authors started
working on improvements to the protocol to support their use cases, and if governments
started asking for backdoors in OMEMO, I assume you'd not help them either. But
they're welcome to try, I suppose.
If someone is explicitly a malware author, it would make me very suspect of any
contribution they would make towards any standard. And, no, I'm not interested in
helping anyone build backdoors into protocols, especially ones so critical to user
safety.
Anyway, I understand XSF members being overworked, and I'm not looking to contribute
more to that workload. Much the opposite, I want to find a way to contribute that helps
alleviate that burden.
In an ideal world, where we already have forge federation, this platform issue would be a
largely moot point. Perhaps a workable middle-ground could be to do a weekly/monthly
roll-up of patches sent to mirrored repos to a mailing list.
Like I said, I'm going to put in some work to see what it looks like to re-implement
current Github CI/tooling usage on Codeberg. I've setup an account, and am willing to
hand that off to XSF membership if/when they want: https://codeberg.org/xsf
After looking at the automation in the xeps repo, I see what you mean about how much work
has been put into GIthub integration. Wish me luck
On Wednesday, August 27th, 2025 at 11:26 PM, Dave Cridland <dave(a)cridland.net>
wrote:
On Thu, 28 Aug 2025 at 00:00, Elle
<[elle+xmpp-standards@weathered-steel.dev](mailto:elle%2Bxmpp-standards@weathered-steel.dev)>
wrote:
- IANAL, but the use of any of the XSF materials
is covered by our IPR statement and I believe that explicitly allows any such use as
training LLMs. I don't see this as a negative for the XSF. This doesn't negate
concerns for *other* organizations or projects.
I understand that given the licensing, LLM training may be permissible. That wasn't
the point. As an org, and personally, I do not want to contribute to a technology largely
designed to destroy my profession. Unfortunately, a number of projects I care about are
still hosted on platform owned by one of the biggest developers of LLM tech.
You mentioned before that contributors are free to mirror XSF/XMPP repos on other
platforms. This sounds like a good first contribution for our org. I'm willing to put
in the work to mirror the repos, and try to coordinate any issue triage that gets
submitted on the mirrors.
Absolutely, go for it. But at the moment, the bulk of the effort has gone into supporting
our use of Github, so unless there's real critical mass in what you're attempting,
you may find it results in no change.
- It is very demotivating for people working on
this to get side line opinions without actual ongoing involvement.
Apologies if this sounded like sidelining, that wasn't my intention. I was giving
voice from my perspective on why I am demotivated from contributing to projects hosted on
Github, and offered some viable alternatives.
And I get that. But I also get that Github is easy to find, and saves the (overworked)
team a lot of work. Github isn't great, but burn-out is far worse.
- I will not go into my personal opinions on
political, societal, or ethical choices or opinions, by anyone or any corporation, here. I
do have them, as many here can attest, and they usually go with a beverage in a private,
in-person setting.
Right, because FOSS, decentralized communication platforms are completely apolitical, and
detached from society. There's obviously no ethical considerations, either. Mind
backdooring OMEMO for any government that asks?
The technology does what the technology does.
Some people might (probably do) use OMEMO to hide unethical and illegal things from
governments, too. Governments themselves use XMPP for all kinds of things, and I'm
sure that you may well have opinions on which of those are ethically aligned with your
beliefs.
The communications platform *is* apolitical. It does not distinguish between
"bad" things (like enabling C&C systems for malware) and "good"
things (like rapid triage of pressure sores). So people use it for both.
What you (or I) choose to support is up to us - the protocol has no views, and I'm
broadly with Ralph on saying that carries over to the XSF.
And to be sure, I can't see myself engaging if a bunch of malware authors started
working on improvements to the protocol to support their use cases, and if governments
started asking for backdoors in OMEMO, I assume you'd not help them either. But
they're welcome to try, I suppose.
Dave.