Re: [Board] Board meeting info + voting
[CC'ing standards@, as I'd like to engage the community regarding our usage of Github] On 07/08/2025 18.50, E.M. wrote:
Dear all,
hereby I will post on today's Board Meeting. Ref: https://wiki.xmpp.org/ web/Board-Meeting-2025
We have a two items to vote for, too. Please clearly indicate how (+1, 0, -1) and on what you are voting (topic).
Furthermore, we are proposing to have another Board meeting in one week at Thursday, 14 Aug 2025 Time: 16:00 UTC / 18:00 CEST (Can anyone update the calendar if we agree here?)
Please comment if there are any other topics or input on the items.
Cheers, Eddie _______________________________________________________________________
* XEP-0001 and 0143 changes need approval from Board ** Call to provide you input to the changes and place a comment or review. Link 1: https://github.com/xsf/xeps/pull/1412
This contains some good changes, like the advise to read, understand, and agree to our IPR. However, I find the the strong emphasis on Github PRs very problematic. Especially the part where we tell people that if they don't have a github account and are not willing to sign up for one, they should find someone who has one. The XSF should not require the usage of a propriety service for contributions. On the other side, I do acknowledge that using a CI-based system for contributions has its advantage. Therefore, a change which mentions that we also accept contributions via Github, outlining the existence of a CI there, would be acceptable to me. But it is my strong believe that we should always accept contributions via mail. Therefore -1, as is. On a side note: We may also want to point out that it is possible to validate changes locally. And we probably should look into codeforge alternatives. But that is outside of the scope of this PR.
+1, thanks for writing this.
Link 3: ?
Do we have this link by now?
* Update on Fiscal Hosting ** Background: The platform we have been using for fiscal hosting is to begin moving to a new pricing structure in January, and this affects us. Details: https://pricing-2026.opencollective.com/ *** Votes: The XSF Board votes to close the fiscal hosting offering via Open Collective without replacement and asks the community to suggest alternatives instead of publishing a survey.
+1, as per Matt's analysis, opencollective seems to be to expensive for us.
* Confusion in protocol name (XMTP) ** Background: See Board mailing list ** Comment: We don't see that we can do much about it, as XMPP is not a trademark and they are already aware.
I think there is not much we can do after the fact.
* Propose Gonzalo Nemmi (gnemmi) to become member of the XSF CommTeam ** Background: Gonzalo is publishing and providing great efforts along the team and work well with the XSF and Community. This deserves recognition. ** Votes: The XSF Board votes that if Gonzalo Nemmi (gnemmi) will be accepted as XSF member,
I don't think Board is the right body to approve new members.
that Gonzalo Nemmi (gnemmi) can join the XSF CommTeam.
+1, assuming they fulfill the prerequisites (e.g., being an XSF member).
** Comment: Jcbrand will be unlisted after not responding but is always welcome to support and comeback.
Thanks for your work JC! - Flow
On the other side, I do acknowledge that using a CI-based system for contributions has its advantage. Therefore, a change which mentions that we also accept contributions via Github, outlining the existence of a CI there, would be acceptable to me.
Codeberg exists :) As well as Sourcehut. My org has moved all of our projects over to Codeberg, and the experience has been great (aside from the AI scrapebots plaguing the internet). Their hosted Woodpecker CI is also pretty easy to configure, with an option to host your own CI. Federation is also in the works, so a self-hosted Forgejo instance would be able to sync up with contributors on Codeberg. Anyway, thank you for keeping the email-based workflow intact. All the best
I would want to add that I have a strong desire to collaborate over the XSF repositories, yet I am currently very reluctant to do so because of where it is currently hosted at. So the mentioned services be reasonable for me to begin to collaborate. Schimon On Wed, 27 Aug 2025 14:15:28 +0000 Elle <elle+xmpp-standards@weathered-steel.dev> wrote:
On the other side, I do acknowledge that using a CI-based system for contributions has its advantage. Therefore, a change which mentions that we also accept contributions via Github, outlining the existence of a CI there, would be acceptable to me.
Codeberg exists :) As well as Sourcehut.
My org has moved all of our projects over to Codeberg, and the experience has been great (aside from the AI scrapebots plaguing the internet). Their hosted Woodpecker CI is also pretty easy to configure, with an option to host your own CI. Federation is also in the works, so a self-hosted Forgejo instance would be able to sync up with contributors on Codeberg.
Anyway, thank you for keeping the email-based workflow intact.
All the best
Piling on to express support for non-GitHub options. XSF related pulls is more or less the only reason I'm still on GitHub. I have it on my bucket list to set up a "sign in with XMPP" option for Forgejo and then pitch in to help the XSF host our own instance, hopefully with federation implemented by that time... ...but until that distant future I'd be happy with Codeberg (or an email-based flow). ~Badr On 27/08/25 8:58 pm, Schimon Jehudah wrote:
I would want to add that I have a strong desire to collaborate over the XSF repositories, yet I am currently very reluctant to do so because of where it is currently hosted at.
So the mentioned services be reasonable for me to begin to collaborate.
Schimon
On Wed, 27 Aug 2025 14:15:28 +0000 Elle <elle+xmpp-standards@weathered-steel.dev> wrote:
On the other side, I do acknowledge that using a CI-based system for contributions has its advantage. Therefore, a change which mentions that we also accept contributions via Github, outlining the existence of a CI there, would be acceptable to me. Codeberg exists :) As well as Sourcehut.
My org has moved all of our projects over to Codeberg, and the experience has been great (aside from the AI scrapebots plaguing the internet). Their hosted Woodpecker CI is also pretty easy to configure, with an option to host your own CI. Federation is also in the works, so a self-hosted Forgejo instance would be able to sync up with contributors on Codeberg.
Anyway, thank you for keeping the email-based workflow intact.
All the best
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Badri. Good day. On Wed, 27 Aug 2025 23:36:21 +0530 Badri <badrihippo@disroot.org> wrote:
Piling on to express support for non-GitHub options. XSF related pulls is more or less the only reason I'm still on GitHub.
I have it on my bucket list to set up a "sign in with XMPP" option for Forgejo and then pitch in to help the XSF host our own instance, hopefully with federation implemented by that time...
This is interesting. I guess that doing so would influence XMPP people to join. I suppose that utilizing OAuth would be of at most benefit. https://xmpp.org/extensions/xep-0235.xml https://xmpp.org/extensions/xep-0493.xml Schimon
...but until that distant future I'd be happy with Codeberg (or an email-based flow).
~Badr
On 27/08/25 8:58 pm, Schimon Jehudah wrote:
I would want to add that I have a strong desire to collaborate over the XSF repositories, yet I am currently very reluctant to do so because of where it is currently hosted at.
So the mentioned services be reasonable for me to begin to collaborate.
Schimon
On Wed, 27 Aug 2025 14:15:28 +0000 Elle <elle+xmpp-standards@weathered-steel.dev> wrote:
On the other side, I do acknowledge that using a CI-based system for contributions has its advantage. Therefore, a change which mentions that we also accept contributions via Github, outlining the existence of a CI there, would be acceptable to me. Codeberg exists :) As well as Sourcehut.
My org has moved all of our projects over to Codeberg, and the experience has been great (aside from the AI scrapebots plaguing the internet). Their hosted Woodpecker CI is also pretty easy to configure, with an option to host your own CI. Federation is also in the works, so a self-hosted Forgejo instance would be able to sync up with contributors on Codeberg.
Anyway, thank you for keeping the email-based workflow intact.
All the best
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hi Badri and Schimon, I have started work on porting over the [xsf/xeps](https://codeberg.org/xsf-org/xeps) repository. At the moment, it is just a mirror, and I have started reviewing the Github CI workflow, and the `tools/github_auto_triage_pr.sh` script. There is a [codeberg-cli](https://codeberg.org/Aviac/codeberg-cli) tool which aims to be a replacement for the `gh` tool. I also spent a good portion of time reviewing the current state of the Codeberg/Forgejo implementation of the ForgeFed (https://forgefed.org/) protocol. So far, they look to have implemented submitting "Likes" (equivalent of GitHub stars) on repositories from other Forgejo instances, Mastodon, and a couple other sources. While somewhat tangential to the main porting effort, I think contributing to ForgeFed will solve especially the issue of maintenance burden for email-submitted PRs/Issues. If we want to start a MUC to discuss development / coordination, just let me know. Regarding my "reproval" of the XSF, that again was not my intention. I was making a point that even deeply technical decisions, like not backdooring an encryption protocol, have philosophical and political components, as well. If the usage of "apolitical" in this community is meant to be "politically neutral", as was stated earlier in the thread, then I understand and agree with the XSF stance to a certain degree. However, Schimon your framing of "red" vs. "blue" political "teams" is highly reductionist. Political, social, and ethical convictions consist of a much more subtle and varied set of ideas. Even the idea of political tolerance of one's ideological opposites is itself a political position, not an "apolitical" one. That term, "apolitical", is usually thrown around as a defense of the status quo and entrenched power structures. Usually under the guise of being an "enlightened", or more rational standpoint. Regardless, this is indeed a technical forum, and it was not my intention to delve into a philosophical/political discussion. Apologies for any derailment. As others have suggested, the technical and risk reduction benefits of switching to a FOSS platform (like Codeberg + Forgejo) are enough to speak for themselves. I have all intentions of putting in the work to provide a proof-of-concept that the migration can be made, and will ultimately lead to a long-term reduction in maintenance burden. On Friday, August 29th, 2025 at 5:28 AM, Schimon Jehudah <sch@fedora.email> wrote:
Badri. Good day.
On Wed, 27 Aug 2025 23:36:21 +0530 Badri badrihippo@disroot.org wrote:
Piling on to express support for non-GitHub options. XSF related pulls is more or less the only reason I'm still on GitHub.
I have it on my bucket list to set up a "sign in with XMPP" option for Forgejo and then pitch in to help the XSF host our own instance, hopefully with federation implemented by that time...
This is interesting.
I guess that doing so would influence XMPP people to join.
I suppose that utilizing OAuth would be of at most benefit.
https://xmpp.org/extensions/xep-0235.xml
https://xmpp.org/extensions/xep-0493.xml
Schimon
...but until that distant future I'd be happy with Codeberg (or an email-based flow).
~Badr
On 27/08/25 8:58 pm, Schimon Jehudah wrote:
I would want to add that I have a strong desire to collaborate over the XSF repositories, yet I am currently very reluctant to do so because of where it is currently hosted at.
So the mentioned services be reasonable for me to begin to collaborate.
Schimon
On Wed, 27 Aug 2025 14:15:28 +0000 Elle elle+xmpp-standards@weathered-steel.dev wrote:
On the other side, I do acknowledge that using a CI-based system for contributions has its advantage. Therefore, a change which mentions that we also accept contributions via Github, outlining the existence of a CI there, would be acceptable to me. Codeberg exists :) As well as Sourcehut.
My org has moved all of our projects over to Codeberg, and the experience has been great (aside from the AI scrapebots plaguing the internet). Their hosted Woodpecker CI is also pretty easy to configure, with an option to host your own CI. Federation is also in the works, so a self-hosted Forgejo instance would be able to sync up with contributors on Codeberg.
Anyway, thank you for keeping the email-based workflow intact.
All the best
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Elle. Good day. On Fri, 29 Aug 2025 06:19:14 +0000 Elle <elle+xmpp-standards@weathered-steel.dev> wrote:
Hi Badri and Schimon,
I have started work on porting over the [xsf/xeps](https://codeberg.org/xsf-org/xeps) repository. At the moment, it is just a mirror, and I have started reviewing the Github CI workflow, and the `tools/github_auto_triage_pr.sh` script.
There is a [codeberg-cli](https://codeberg.org/Aviac/codeberg-cli) tool which aims to be a replacement for the `gh` tool.
I also spent a good portion of time reviewing the current state of the Codeberg/Forgejo implementation of the ForgeFed (https://forgefed.org/) protocol. So far, they look to have implemented submitting "Likes" (equivalent of GitHub stars) on repositories from other Forgejo instances, Mastodon, and a couple other sources. While somewhat tangential to the main porting effort, I think contributing to ForgeFed will solve especially the issue of maintenance burden for email-submitted PRs/Issues.
Good. I will be glad to know of further progress. Please do inform me if I can be of help.
If we want to start a MUC to discuss development / coordination, just let me know.
Regarding my "reproval" of the XSF, that again was not my intention. I was making a point that even deeply technical decisions, like not backdooring an encryption protocol, have philosophical and political components, as well. If the usage of "apolitical" in this community is meant to be "politically neutral", as was stated earlier in the thread, then I understand and agree with the XSF stance to a certain degree.
The argument being public is mostly not good. I do have arguments against concerns with XSF members and they do respond, albeit I am often not content with their responds. Hence, suggesting a system would be more workable than arguing with some of them.
However, Schimon your framing of "red" vs. "blue" political "teams" is highly reductionist. Political, social, and ethical convictions consist of a much more subtle and varied set of ideas. Even the idea of political tolerance of one's ideological opposites is itself a political position, not an "apolitical" one. That term, "apolitical", is usually thrown around as a defense of the status quo and entrenched power structures. Usually under the guise of being an "enlightened", or more rational standpoint.
It was a general realization. I wanted to write a short argument.
Regardless, this is indeed a technical forum, and it was not my intention to delve into a philosophical/political discussion. Apologies for any derailment.
As others have suggested, the technical and risk reduction benefits of switching to a FOSS platform (like Codeberg + Forgejo) are enough to speak for themselves. I have all intentions of putting in the work to provide a proof-of-concept that the migration can be made, and will ultimately lead to a long-term reduction in maintenance burden.
Yes. I think that your assessment is correct. Schimon
On Friday, August 29th, 2025 at 5:28 AM, Schimon Jehudah <sch@fedora.email> wrote:
Badri. Good day.
On Wed, 27 Aug 2025 23:36:21 +0530 Badri badrihippo@disroot.org wrote:
Piling on to express support for non-GitHub options. XSF related pulls is more or less the only reason I'm still on GitHub.
I have it on my bucket list to set up a "sign in with XMPP" option for Forgejo and then pitch in to help the XSF host our own instance, hopefully with federation implemented by that time...
This is interesting.
I guess that doing so would influence XMPP people to join.
I suppose that utilizing OAuth would be of at most benefit.
https://xmpp.org/extensions/xep-0235.xml
https://xmpp.org/extensions/xep-0493.xml
Schimon
...but until that distant future I'd be happy with Codeberg (or an email-based flow).
~Badr
On 27/08/25 8:58 pm, Schimon Jehudah wrote:
I would want to add that I have a strong desire to collaborate over the XSF repositories, yet I am currently very reluctant to do so because of where it is currently hosted at.
So the mentioned services be reasonable for me to begin to collaborate.
Schimon
On Wed, 27 Aug 2025 14:15:28 +0000 Elle elle+xmpp-standards@weathered-steel.dev wrote:
On the other side, I do acknowledge that using a CI-based system for contributions has its advantage. Therefore, a change which mentions that we also accept contributions via Github, outlining the existence of a CI there, would be acceptable to me. Codeberg exists :) As well as Sourcehut.
My org has moved all of our projects over to Codeberg, and the experience has been great (aside from the AI scrapebots plaguing the internet). Their hosted Woodpecker CI is also pretty easy to configure, with an option to host your own CI. Federation is also in the works, so a self-hosted Forgejo instance would be able to sync up with contributors on Codeberg.
Anyway, thank you for keeping the email-based workflow intact.
All the best
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hi Elle, Le vendredi 29 août 2025, 08:19:14 heure d’été d’Europe centrale Elle a écrit :
Hi Badri and Schimon,
I have started work on porting over the [xsf/xeps](https://codeberg.org/xsf-org/xeps) repository. At the moment, it is just a mirror, and I have started
reviewing the Github CI workflow, and the `tools/github_auto_triage_pr.sh` script.
There is a [codeberg-cli](https://codeberg.org/Aviac/codeberg-cli) tool
which aims to be a replacement for the `gh` tool.
I also spent a good portion of time reviewing the current state of the
Codeberg/Forgejo implementation of the ForgeFed (https://forgefed.org/) protocol. So far, they look to have implemented submitting "Likes" (equivalent of GitHub stars) on repositories from other Forgejo instances, Mastodon, and a couple other sources. While somewhat tangential to the main porting effort, I think contributing to ForgeFed will solve especially the issue of maintenance burden for email-submitted PRs/Issues. FYI, I'm also working on XMPP based decentralized forge (and it predates ForgeFed). I'll probably do a gateway to Github in a not-to-distant future. The big advantage is that it's fully XMPP already, accessible by standard pubsub. I'm also currently working on an email gateway. With those bricks in place, it should be relatively easy to code a small script to create a PR on a XSF Github if an email is received on a specific address, and have all that accessible by XMPP directly. I may extend the current ActivityPub gateway to implement ForgeFed extensions and make it work with the XMPP forge, but it's very low priority at the moment (by lack of resource, not lack of will). Anyway, those technical details can be discussed elsewhere. Best, Goffi
Goffi. Good day. On Fri, 29 Aug 2025 12:14:05 +0200 Goffi <goffi@goffi.org> wrote:
Hi Elle,
Le vendredi 29 août 2025, 08:19:14 heure d’été d’Europe centrale Elle a écrit :
Hi Badri and Schimon,
I have started work on porting over the [xsf/xeps](https://codeberg.org/xsf-org/xeps) repository. At the moment, it is just a mirror, and I have started
reviewing the Github CI workflow, and the `tools/github_auto_triage_pr.sh` script.
There is a [codeberg-cli](https://codeberg.org/Aviac/codeberg-cli) tool
which aims to be a replacement for the `gh` tool.
I also spent a good portion of time reviewing the current state of the
Codeberg/Forgejo implementation of the ForgeFed (https://forgefed.org/) protocol. So far, they look to have implemented submitting "Likes" (equivalent of GitHub stars) on repositories from other Forgejo instances, Mastodon, and a couple other sources. While somewhat tangential to the main porting effort, I think contributing to ForgeFed will solve especially the issue of maintenance burden for email-submitted PRs/Issues.
FYI, I'm also working on XMPP based decentralized forge (and it predates ForgeFed).
I'll probably do a gateway to Github in a not-to-distant future. The big advantage is that it's fully XMPP already, accessible by standard pubsub.
I'm also currently working on an email gateway. With those bricks in place, it should be relatively easy to code a small script to create a PR on a XSF Github if an email is received on a specific address, and have all that accessible by XMPP directly.
I may extend the current ActivityPub gateway to implement ForgeFed extensions and make it work with the XMPP forge, but it's very low priority at the moment (by lack of resource, not lack of will).
Anyway, those technical details can be discussed elsewhere.
I would advise to create a news mailing-list called General, or even restore mailing-list JDev. Schimon
Best, Goffi
Hi Goffi, Since you're already working on that solution, and it sounds like you're much further along than I am, I'll probably focus more of my work on implementing ForgeFed. Will probably still complete the porting of the `xeps` repo to use Codeberg infrastructure if for nothing else than to serve as an example for others. Thanks for making me aware of your work. On Friday, August 29th, 2025 at 10:14 AM, Goffi <goffi@goffi.org> wrote:
Hi Elle,
Le vendredi 29 août 2025, 08:19:14 heure d’été d’Europe centrale Elle a écrit :
Hi Badri and Schimon,
I have started work on porting over the xsf/xeps repository. At the moment, it is just a mirror, and I have started
reviewing the Github CI workflow, and the `tools/github_auto_triage_pr.sh` script.
There is a codeberg-cli tool
which aims to be a replacement for the `gh` tool.
I also spent a good portion of time reviewing the current state of the
Codeberg/Forgejo implementation of the ForgeFed (https://forgefed.org/) protocol. So far, they look to have implemented submitting "Likes" (equivalent of GitHub stars) on repositories from other Forgejo instances, Mastodon, and a couple other sources. While somewhat tangential to the main porting effort, I think contributing to ForgeFed will solve especially the issue of maintenance burden for email-submitted PRs/Issues.
FYI, I'm also working on XMPP based decentralized forge (and it predates ForgeFed).
I'll probably do a gateway to Github in a not-to-distant future. The big advantage is that it's fully XMPP already, accessible by standard pubsub.
I'm also currently working on an email gateway. With those bricks in place, it should be relatively easy to code a small script to create a PR on a XSF Github if an email is received on a specific address, and have all that accessible by XMPP directly.
I may extend the current ActivityPub gateway to implement ForgeFed extensions and make it work with the XMPP forge, but it's very low priority at the moment (by lack of resource, not lack of will).
Anyway, those technical details can be discussed elsewhere.
Best, Goffi_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
On 27/08/2025 12.55, Florian Schmaus wrote:
[CC'ing standards@, as I'd like to engage the community regarding our usage of Github]
On 07/08/2025 18.50, E.M. wrote:
[..]
* XEP-0001 and 0143 changes need approval from Board ** Call to provide you input to the changes and place a comment or review. Link 1: https://github.com/xsf/xeps/pull/1412
This contains some good changes, like the advise to read, understand, and agree to our IPR. However, I find the the strong emphasis on Github PRs very problematic. Especially the part where we tell people that if they don't have a github account and are not willing to sign up for one, they should find someone who has one.
The XSF should not require the usage of a propriety service for contributions.
On the other side, I do acknowledge that using a CI-based system for contributions has its advantage. Therefore, a change which mentions that we also accept contributions via Github, outlining the existence of a CI there, would be acceptable to me.
But it is my strong believe that we should always accept contributions via mail.
Therefore -1, as is.
On a side note: We may also want to point out that it is possible to validate changes locally. And we probably should look into codeforge alternatives. But that is outside of the scope of this PR.
We have discussed this at various occasions in the past. The outcome was that we need to make technology choices and create and maintain tooling to maintain the processes of the XSF. A choice was made, after consulting the Infrastructure Team and the XMPP Council, to (continue to) use GitHub and associated tooling. Reasons for doing it this way is familiarity with the tooling, minimizing maintenance, and low appetite for retooling. The XSF is an organization that entirely depends on volunteers to do anything. It is already hard to get our core functions staffed and actually have work done. The effort required for retooling *and subsequent maintenance* is better spent on progressing on our core functions. I also do not agree the XSF cannot use proprietary services. The XSF is an open standards organization for the entire XMPP community which includes projects and contributors in the Free Software and/or Open Source Software communities (take your preferred one), as well as closed source and everything in between. Commercial companies and non-commercial entities alike. There is no inherent or implied leaning to any choice made here, nor is there a need for a preference. The changes (including the one below) simply outline the current process, with XEP-0001 deferring to XEP-0143 for the details. XEP-0143 clearly provides a way to provide changes or initial contributions without using GitHub, and people are free to clone our repos to facilitate people to interact more directly with Git without GitHub.
+1, thanks for writing this.
I reviewed and approved both PRs. Kind regards, Ralph Meijer
Hi Ralph, I'm not sure to what extent you're using Github's tooling, but the CI config for Woodpecker is very close to Github's CI. I understand the effort in retooling is non-trivial, but Github is becoming increasingly hostile to FOSS projects. They are very close to forcing use of AI on hosted projects, and of course their AI already scrapes all existing hosted projects. With no way to reasonably opt-out. Plus you know, Microsoft actively supporting the genocide in Gaza. On Wednesday, August 27th, 2025 at 8:16 PM, Ralph Meijer <ralphm@ik.nu> wrote:
On 27/08/2025 12.55, Florian Schmaus wrote:
[CC'ing standards@, as I'd like to engage the community regarding our usage of Github]
On 07/08/2025 18.50, E.M. wrote:
[..]
* XEP-0001 and 0143 changes need approval from Board ** Call to provide you input to the changes and place a comment or review. Link 1: https://github.com/xsf/xeps/pull/1412
This contains some good changes, like the advise to read, understand, and agree to our IPR. However, I find the the strong emphasis on Github PRs very problematic. Especially the part where we tell people that if they don't have a github account and are not willing to sign up for one, they should find someone who has one.
The XSF should not require the usage of a propriety service for contributions.
On the other side, I do acknowledge that using a CI-based system for contributions has its advantage. Therefore, a change which mentions that we also accept contributions via Github, outlining the existence of a CI there, would be acceptable to me.
But it is my strong believe that we should always accept contributions via mail.
Therefore -1, as is.
On a side note: We may also want to point out that it is possible to validate changes locally. And we probably should look into codeforge alternatives. But that is outside of the scope of this PR.
We have discussed this at various occasions in the past. The outcome was that we need to make technology choices and create and maintain tooling to maintain the processes of the XSF. A choice was made, after consulting the Infrastructure Team and the XMPP Council, to (continue to) use GitHub and associated tooling. Reasons for doing it this way is familiarity with the tooling, minimizing maintenance, and low appetite for retooling.
The XSF is an organization that entirely depends on volunteers to do anything. It is already hard to get our core functions staffed and actually have work done. The effort required for retooling and subsequent maintenance is better spent on progressing on our core functions.
I also do not agree the XSF cannot use proprietary services. The XSF is an open standards organization for the entire XMPP community which includes projects and contributors in the Free Software and/or Open Source Software communities (take your preferred one), as well as closed source and everything in between. Commercial companies and non-commercial entities alike. There is no inherent or implied leaning to any choice made here, nor is there a need for a preference.
The changes (including the one below) simply outline the current process, with XEP-0001 deferring to XEP-0143 for the details. XEP-0143 clearly provides a way to provide changes or initial contributions without using GitHub, and people are free to clone our repos to facilitate people to interact more directly with Git without GitHub.
+1, thanks for writing this.
I reviewed and approved both PRs.
Kind regards,
Ralph Meijer
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hi Elle, My main point remains that I'd rather have the XSF spend time on improving XMPP itself rather than bikeshed on tooling every once in a while. It is very demotivating for people working on this to get side line opinions without actual ongoing involvement. 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 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. I also do not believe that the XSF should take positions or make statements and will make every effort to keep it that way. Cheers, ralphm On 27 August 2025 22:32:10 CEST, Elle <elle+xmpp-standards@weathered-steel.dev> wrote:
Hi Ralph,
I'm not sure to what extent you're using Github's tooling, but the CI config for Woodpecker is very close to Github's CI.
I understand the effort in retooling is non-trivial, but Github is becoming increasingly hostile to FOSS projects. They are very close to forcing use of AI on hosted projects, and of course their AI already scrapes all existing hosted projects. With no way to reasonably opt-out.
Plus you know, Microsoft actively supporting the genocide in Gaza.
On Wednesday, August 27th, 2025 at 8:16 PM, Ralph Meijer <ralphm@ik.nu> wrote:
On 27/08/2025 12.55, Florian Schmaus wrote:
[CC'ing standards@, as I'd like to engage the community regarding our usage of Github]
On 07/08/2025 18.50, E.M. wrote:
[..]
* XEP-0001 and 0143 changes need approval from Board ** Call to provide you input to the changes and place a comment or review. Link 1: https://github.com/xsf/xeps/pull/1412
This contains some good changes, like the advise to read, understand, and agree to our IPR. However, I find the the strong emphasis on Github PRs very problematic. Especially the part where we tell people that if they don't have a github account and are not willing to sign up for one, they should find someone who has one.
The XSF should not require the usage of a propriety service for contributions.
On the other side, I do acknowledge that using a CI-based system for contributions has its advantage. Therefore, a change which mentions that we also accept contributions via Github, outlining the existence of a CI there, would be acceptable to me.
But it is my strong believe that we should always accept contributions via mail.
Therefore -1, as is.
On a side note: We may also want to point out that it is possible to validate changes locally. And we probably should look into codeforge alternatives. But that is outside of the scope of this PR.
We have discussed this at various occasions in the past. The outcome was that we need to make technology choices and create and maintain tooling to maintain the processes of the XSF. A choice was made, after consulting the Infrastructure Team and the XMPP Council, to (continue to) use GitHub and associated tooling. Reasons for doing it this way is familiarity with the tooling, minimizing maintenance, and low appetite for retooling.
The XSF is an organization that entirely depends on volunteers to do anything. It is already hard to get our core functions staffed and actually have work done. The effort required for retooling and subsequent maintenance is better spent on progressing on our core functions.
I also do not agree the XSF cannot use proprietary services. The XSF is an open standards organization for the entire XMPP community which includes projects and contributors in the Free Software and/or Open Source Software communities (take your preferred one), as well as closed source and everything in between. Commercial companies and non-commercial entities alike. There is no inherent or implied leaning to any choice made here, nor is there a need for a preference.
The changes (including the one below) simply outline the current process, with XEP-0001 deferring to XEP-0143 for the details. XEP-0143 clearly provides a way to provide changes or initial contributions without using GitHub, and people are free to clone our repos to facilitate people to interact more directly with Git without GitHub.
+1, thanks for writing this.
I reviewed and approved both PRs.
Kind regards,
Ralph Meijer
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
- 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. - 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. - 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? On Wednesday, August 27th, 2025 at 8:51 PM, Ralph Meijer <ralphm@ik.nu> wrote:
Hi Elle,
My main point remains that I'd rather have the XSF spend time on improving XMPP itself rather than bikeshed on tooling every once in a while. It is very demotivating for people working on this to get side line opinions without actual ongoing involvement.
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 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. I also do not believe that the XSF should take positions or make statements and will make every effort to keep it that way.
Cheers,
ralphm
On 27 August 2025 22:32:10 CEST, Elle <elle+xmpp-standards@weathered-steel.dev> wrote:
Hi Ralph,
I'm not sure to what extent you're using Github's tooling, but the CI config for Woodpecker is very close to Github's CI.
I understand the effort in retooling is non-trivial, but Github is becoming increasingly hostile to FOSS projects. They are very close to forcing use of AI on hosted projects, and of course their AI already scrapes all existing hosted projects. With no way to reasonably opt-out.
Plus you know, Microsoft actively supporting the genocide in Gaza.
On Wednesday, August 27th, 2025 at 8:16 PM, Ralph Meijer <ralphm@ik.nu> wrote:
On 27/08/2025 12.55, Florian Schmaus wrote:
[CC'ing standards@, as I'd like to engage the community regarding our
usage of Github]
On 07/08/2025 18.50, E.M. wrote:
[..]
* XEP-0001 and 0143 changes need approval from Board
** Call to provide you input to the changes and place a comment or
review.
This contains some good changes, like the advise to read, understand,
and agree to our IPR. However, I find the the strong emphasis on
Github PRs very problematic. Especially the part where we tell people
that if they don't have a github account and are not willing to sign
up for one, they should find someone who has one.
The XSF should not require the usage of a propriety service for
contributions.
On the other side, I do acknowledge that using a CI-based system for
contributions has its advantage. Therefore, a change which mentions
that we also accept contributions via Github, outlining the existence
of a CI there, would be acceptable to me.
But it is my strong believe that we should always accept contributions
via mail.
Therefore -1, as is.
On a side note: We may also want to point out that it is possible to
validate changes locally. And we probably should look into codeforge
alternatives. But that is outside of the scope of this PR.
We have discussed this at various occasions in the past. The outcome was
that we need to make technology choices and create and maintain tooling
to maintain the processes of the XSF. A choice was made, after
consulting the Infrastructure Team and the XMPP Council, to (continue
to) use GitHub and associated tooling. Reasons for doing it this way is
familiarity with the tooling, minimizing maintenance, and low appetite
for retooling.
The XSF is an organization that entirely depends on volunteers to do
anything. It is already hard to get our core functions staffed and
actually have work done. The effort required for retooling and
subsequent maintenance is better spent on progressing on our core
functions.
I also do not agree the XSF cannot use proprietary services. The XSF is
an open standards organization for the entire XMPP community which
includes projects and contributors in the Free Software and/or Open
Source Software communities (take your preferred one), as well as closed
source and everything in between. Commercial companies and
non-commercial entities alike. There is no inherent or implied leaning
to any choice made here, nor is there a need for a preference.
The changes (including the one below) simply outline the current
process, with XEP-0001 deferring to XEP-0143 for the details. XEP-0143
clearly provides a way to provide changes or initial contributions
without using GitHub, and people are free to clone our repos to
facilitate people to interact more directly with Git without GitHub.
+1, thanks for writing this.
I reviewed and approved both PRs.
Kind regards,
Ralph Meijer ---------------------------------------------------------------
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-leave@xmpp.org
---------------------------------------------------------------
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-leave@xmpp.org
On Thu, 28 Aug 2025 at 00:00, Elle <elle+xmpp-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.
- 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@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.
On 28 August 2025 02:35:04 CEST, Elle <elle+xmpp-standards@weathered-steel.dev> wrote:
- 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.
First off, while the XSF is currently the major focus point of concerted protocol development for, and promoting the use of, XMPP, it is not the end all and be all of all things XMPP. The core protocols are defined over at the IETF, and you'll find it has a similar approach to try and keep its workings as neutral as possible. Also, the protocol *and* the community are intentionally distributedly extensible. That means that stuff can, and does, happen outside of the XSF. Second you are correct that nothing is absolute, including views on political, social, or ethical topics. My job as a director, and chair, is finding the delicate balance between the personal views of individuals in the XSF Membership and the XMPP community in general, and the stated goals of the XSF. Our mission statement (<https://xmpp.org/about/xsf/mission/>) is quite clear on the position the XSF takes. We also expanded this in our procedures (e.g. <https://xmpp.org/extensions/xep-0001.html>) and design guidelines (<https://xmpp.org/extensions/xep-0134.html>). Your concern with regard to OMEMO can be held to all those documents, just as I use them to guide my work as a director. Also note that we have already been the target of related pressure, and will continue to push back. Again I want to stress that the XMPP community includes people not just rooted in FOSS and its varied(!) political leanings, but equally from corporations, non-profits, education, government, supranational organisations, and military organizations. This all is why trying to elicit a specific response with the casual mentioning of a major geopolitical event is not helpful to me, and why I made the general stance on my approach. -- ralphm
Moving away from GitHub will take a not-to-be-underestimated amount of effort and dedication. A couple of years ago, there was an experiment with moving away from GitHub to GitLab. Quite some effort has been put into that, but in the end, it didn't take off. The remnants are still accessible at https://gitlab.com/xsf My estimation is that we have less volunteer-resources available today. As such, I don't see how we would realistically pull off a migration, let alone start to maintain that new infrastructure. I'm happy to be proven wrong. As I am skeptical that this will ever successfully happen, I urge Board to find a compromise (with regards to Florian's -1 vote) to let the item under vote pass. Please decouple the effort to improve the workload in existing processes (which is taxing people that have been and still are volunteering today) from a migration effort. One should not need to block the other. - Guus On Thu, Aug 28, 2025 at 8:51 AM Ralph Meijer <ralphm@ik.nu> wrote:
On 28 August 2025 02:35:04 CEST, Elle < elle+xmpp-standards@weathered-steel.dev> wrote:
- 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.
First off, while the XSF is currently the major focus point of concerted protocol development for, and promoting the use of, XMPP, it is not the end all and be all of all things XMPP. The core protocols are defined over at the IETF, and you'll find it has a similar approach to try and keep its workings as neutral as possible. Also, the protocol *and* the community are intentionally distributedly extensible. That means that stuff can, and does, happen outside of the XSF.
Second you are correct that nothing is absolute, including views on political, social, or ethical topics. My job as a director, and chair, is finding the delicate balance between the personal views of individuals in the XSF Membership and the XMPP community in general, and the stated goals of the XSF. Our mission statement (<https://xmpp.org/about/xsf/mission/>) is quite clear on the position the XSF takes. We also expanded this in our procedures (e.g. <https://xmpp.org/extensions/xep-0001.html>) and design guidelines (<https://xmpp.org/extensions/xep-0134.html>).
Your concern with regard to OMEMO can be held to all those documents, just as I use them to guide my work as a director. Also note that we have already been the target of related pressure, and will continue to push back.
Again I want to stress that the XMPP community includes people not just rooted in FOSS and its varied(!) political leanings, but equally from corporations, non-profits, education, government, supranational organisations, and military organizations.
This all is why trying to elicit a specific response with the casual mentioning of a major geopolitical event is not helpful to me, and why I made the general stance on my approach.
-- ralphm _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
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
Elle, I would be happy to help with these efforts. I have not worked much with automation (Woodpecker or otherwise) but have have been managing a few small Forgejo instances and am reasonably familiar with how it works. There has also been talk in the group (more on the speculative side) about the XSF running our own Forgejo instance (to which I suggested we can implement an option to sign in via one's XMPP account). Whether that takes off or not, the fact that Codeberg runs Forgejo means any tooling we write there can more easily be shifted. I think it would be good for us to use standards-based systems (such as Forgejo which is working on ForgeFed) as much as possible, as those are what make for a more sustainable open web.
Moving away from GitHub will take a not-to-be-underestimated amount of effort and dedication. A couple of years ago, there was an experiment with moving away from GitHub to GitLab. Quite some effort has been put into that, but in the end, it didn't take off. The remnants are still accessible at https://gitlab.com/xsf Thanks Guus for providing some context. There does seem to be a lot of interest in moving away from GitHub, though unfortunately less so in terms of volunteers available to actually set up and maintain alternate tooling. I wasn't aware that people had actually attempted to start moving to Gitlab. My estimation is that we have less volunteer-resources available today. As such, I don't see how we would realistically pull off a migration, let alone start to maintain that new infrastructure. I'm happy to be proven wrong.
On a related note, I've also been meaning to help out with the infrastructure team. Knowing how the existing setup works sounds like a good first step to figuring out how to change it :-) that aside, given what I hear about the team being overworked and the fact that I know my way around sysadmin tasks, I think it's a place I can contribute meaningfully. Maybe this thread will provide me the push to get started! ~Badri PS: Guus, heads-up that I'm receiving this discussion on the Standards mailing list. You may want to confirm if you copied it to the Board list as well
Le 28 août 2025 10:21:38 GMT+02:00, Guus der Kinderen <guus.der.kinderen@gmail.com> a écrit :
Moving away from GitHub will take a not-to-be-underestimated amount of effort and dedication. A couple of years ago, there was an experiment with moving away from GitHub to GitLab. Quite some effort has been put into that, but in the end, it didn't take off. The remnants are still accessible at https://gitlab.com/xsf
My estimation is that we have less volunteer-resources available today. As such, I don't see how we would realistically pull off a migration, let alone start to maintain that new infrastructure. I'm happy to be proven wrong.
As I am skeptical that this will ever successfully happen, I urge Board to find a compromise (with regards to Florian's -1 vote) to let the item under vote pass. Please decouple the effort to improve the workload in existing processes (which is taxing people that have been and still are volunteering today) from a migration effort. One should not need to block the other.
- Guus
On Thu, Aug 28, 2025 at 8:51 AM Ralph Meijer <ralphm@ik.nu> wrote:
On 28 August 2025 02:35:04 CEST, Elle < elle+xmpp-standards@weathered-steel.dev> wrote:
- 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.
First off, while the XSF is currently the major focus point of concerted protocol development for, and promoting the use of, XMPP, it is not the end all and be all of all things XMPP. The core protocols are defined over at the IETF, and you'll find it has a similar approach to try and keep its workings as neutral as possible. Also, the protocol *and* the community are intentionally distributedly extensible. That means that stuff can, and does, happen outside of the XSF.
Second you are correct that nothing is absolute, including views on political, social, or ethical topics. My job as a director, and chair, is finding the delicate balance between the personal views of individuals in the XSF Membership and the XMPP community in general, and the stated goals of the XSF. Our mission statement (<https://xmpp.org/about/xsf/mission/>) is quite clear on the position the XSF takes. We also expanded this in our procedures (e.g. <https://xmpp.org/extensions/xep-0001.html>) and design guidelines (<https://xmpp.org/extensions/xep-0134.html>).
Your concern with regard to OMEMO can be held to all those documents, just as I use them to guide my work as a director. Also note that we have already been the target of related pressure, and will continue to push back.
Again I want to stress that the XMPP community includes people not just rooted in FOSS and its varied(!) political leanings, but equally from corporations, non-profits, education, government, supranational organisations, and military organizations.
This all is why trying to elicit a specific response with the casual mentioning of a major geopolitical event is not helpful to me, and why I made the general stance on my approach.
-- ralphm _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
As someone who sees moving from github as an action that would make the XSF process more robust, and less dependent on a corporate entity that I personally consider malignant at best, I believe we could only shift the process onto another service if: * someone (or several people) volunteers to migrate the tooling 1:1 to the new platform * board preemptively accepts that if those conditions are met and no new blocker is found, process can be moved * the platform is free to use for our use case, and for contributors as well * we have confidence the platform will continue to operate for a long time (OR/AND it is FOSS software that has several identical offerings on the web that we can move to effortlessy) As a middle ground for people who do not want to interact with github at all, something I can certainly understand, maybe a more reasonable task for a volunteer would be to build a bridge that replicates the xep repo and merge requests to allow them to contribute and -crucially- without giving more work to the editor. Mathieu
Mathieu. Good day. On Thu, 28 Aug 2025 12:08:25 +0200 Mathieu Pasquet <mathieui@mathieui.net> wrote:
Le 28 août 2025 10:21:38 GMT+02:00, Guus der Kinderen <guus.der.kinderen@gmail.com> a écrit :
Moving away from GitHub will take a not-to-be-underestimated amount of effort and dedication. A couple of years ago, there was an experiment with moving away from GitHub to GitLab. Quite some effort has been put into that, but in the end, it didn't take off. The remnants are still accessible at https://gitlab.com/xsf
My estimation is that we have less volunteer-resources available today. As such, I don't see how we would realistically pull off a migration, let alone start to maintain that new infrastructure. I'm happy to be proven wrong.
As I am skeptical that this will ever successfully happen, I urge Board to find a compromise (with regards to Florian's -1 vote) to let the item under vote pass. Please decouple the effort to improve the workload in existing processes (which is taxing people that have been and still are volunteering today) from a migration effort. One should not need to block the other.
- Guus
On Thu, Aug 28, 2025 at 8:51 AM Ralph Meijer <ralphm@ik.nu> wrote:
On 28 August 2025 02:35:04 CEST, Elle < elle+xmpp-standards@weathered-steel.dev> wrote:
- 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.
First off, while the XSF is currently the major focus point of concerted protocol development for, and promoting the use of, XMPP, it is not the end all and be all of all things XMPP. The core protocols are defined over at the IETF, and you'll find it has a similar approach to try and keep its workings as neutral as possible. Also, the protocol *and* the community are intentionally distributedly extensible. That means that stuff can, and does, happen outside of the XSF.
Second you are correct that nothing is absolute, including views on political, social, or ethical topics. My job as a director, and chair, is finding the delicate balance between the personal views of individuals in the XSF Membership and the XMPP community in general, and the stated goals of the XSF. Our mission statement (<https://xmpp.org/about/xsf/mission/>) is quite clear on the position the XSF takes. We also expanded this in our procedures (e.g. <https://xmpp.org/extensions/xep-0001.html>) and design guidelines (<https://xmpp.org/extensions/xep-0134.html>).
Your concern with regard to OMEMO can be held to all those documents, just as I use them to guide my work as a director. Also note that we have already been the target of related pressure, and will continue to push back.
Again I want to stress that the XMPP community includes people not just rooted in FOSS and its varied(!) political leanings, but equally from corporations, non-profits, education, government, supranational organisations, and military organizations.
This all is why trying to elicit a specific response with the casual mentioning of a major geopolitical event is not helpful to me, and why I made the general stance on my approach.
-- ralphm _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
As someone who sees moving from github as an action that would make the XSF process more robust, and less dependent on a corporate entity that I personally consider malignant at best, I believe we could only shift the process onto another service if:
* someone (or several people) volunteers to migrate the tooling 1:1 to the new platform * board preemptively accepts that if those conditions are met and no new blocker is found, process can be moved * the platform is free to use for our use case, and for contributors as well * we have confidence the platform will continue to operate for a long time (OR/AND it is FOSS software that has several identical offerings on the web that we can move to effortlessy)
As a middle ground for people who do not want to interact with github at all, something I can certainly understand, maybe a more reasonable task for a volunteer would be to build a bridge that replicates the xep repo and merge requests to allow them to contribute and -crucially- without giving more work to the editor.
Yes. This is a solution which would be convenient to me. Schimon
Mathieu
Hello, Le jeudi 28 août 2025, 10:21:38 heure d’été d’Europe centrale Guus der Kinderen a écrit :
[SNIP] One should not need to block the other.
Rest of the discussion put aside, I very much disagree with this. Board and Council members have been elected for a limited period, and the very basis of a consensus is that one can veto a decision. This is not solved by pressuring the person who disagree, saying "you should not block the others", but by discussion and evolution of the proposition, or the idea people have of it, or both until a consensus is found. Best, Goffi
Hi Goffi, I'm not sure if I'm understanding your disagreement? I was trying to say that I hope that Board could find a compromise (which I think is what you're also saying) so that one proposal (that facilitates existing processes) does not need to be delayed/postponed until another proposal (to migrate such processes to different infrastructure) has been worked out. In that sense "one [proposal] should not need to block the other [proposal]" in the sense that both can be developed in parallel. I was certainly not trying to imply that people are blocking each-other, if that is how my comment came across. Kind regards, Guus On Thu, Aug 28, 2025 at 2:22 PM Goffi <goffi@goffi.org> wrote:
Hello,
Le jeudi 28 août 2025, 10:21:38 heure d’été d’Europe centrale Guus der Kinderen a écrit :
[SNIP] One should not need to block the other.
Rest of the discussion put aside, I very much disagree with this. Board and Council members have been elected for a limited period, and the very basis of a consensus is that one can veto a decision.
This is not solved by pressuring the person who disagree, saying "you should not block the others", but by discussion and evolution of the proposition, or the idea people have of it, or both until a consensus is found.
Best, Goffi_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Le jeudi 28 août 2025, 14:48:14 heure d’été d’Europe centrale Guus der Kinderen a écrit :
Hi Goffi,
I'm not sure if I'm understanding your disagreement? I was trying to say that I hope that Board could find a compromise (which I think is what you're also saying) so that one proposal (that facilitates existing processes) does not need to be delayed/postponed until another proposal (to migrate such processes to different infrastructure) has been worked out. In that sense "one [proposal] should not need to block the other [proposal]" in the sense that both can be developed in parallel. I was certainly not trying to imply that people are blocking each-other, if that is how my comment came across.
Kind regards,
Guus
Hi Guus, Oh, absolutely, my bad. I've misread your message and though that you implied that one person should not block the others. Sorry for that. Best, Goffi
On 28/08/2025 14.21, Goffi wrote:
Hello,
Le jeudi 28 août 2025, 10:21:38 heure d’été d’Europe centrale Guus der Kinderen a écrit :
[SNIP] One should not need to block the other.
Rest of the discussion put aside, I very much disagree with this. Board and Council members have been elected for a limited period, and the very basis of a consensus is that one can veto a decision.
This is not solved by pressuring the person who disagree, saying "you should not block the others", but by discussion and evolution of the proposition, or the idea people have of it, or both until a consensus is found.
This might be good moment to point out that unlike in Council (Bylaws section 8.1), a negative vote in Board does not constitute a veto (section 5.7):
[..] At any meeting of the Board of Directors, each Director present at the meeting shall be entitled to cast one (1) vote on any question coming before the meeting. Except as otherwise provided in these Bylaws, a vote of the majority of the Directors present at a meeting in which a quorum is present shall be the act of the Board of Directors. If the Board consists of an even number of Directors, the Executive Director of the Corporation shall be empowered to cast a tie-breaking vote in any matter except selection of the Executive Director.
The XSF operates on rough consensus, not unanimous agreement. This does not mean that a decision made with negative votes cannot be discussed again, of course. Objections matter, and that's why are having this discussion. -- ralphm
Guus. Good day. On Thu, 28 Aug 2025 10:21:38 +0200 Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:
Moving away from GitHub will take a not-to-be-underestimated amount of effort and dedication. A couple of years ago, there was an experiment with moving away from GitHub to GitLab. Quite some effort has been put into that, but in the end, it didn't take off. The remnants are still accessible at https://gitlab.com/xsf
My estimation is that we have less volunteer-resources available today. As such, I don't see how we would realistically pull off a migration, let alone start to maintain that new infrastructure. I'm happy to be proven wrong.
If that is the issue, then I would advise to publicize an offer over XMPP.org and asking for volunteers for that specific concern. I might join to that effort. Schimon
As I am skeptical that this will ever successfully happen, I urge Board to find a compromise (with regards to Florian's -1 vote) to let the item under vote pass. Please decouple the effort to improve the workload in existing processes (which is taxing people that have been and still are volunteering today) from a migration effort. One should not need to block the other.
- Guus
On Thu, Aug 28, 2025 at 8:51 AM Ralph Meijer <ralphm@ik.nu> wrote:
On 28 August 2025 02:35:04 CEST, Elle < elle+xmpp-standards@weathered-steel.dev> wrote:
- 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.
First off, while the XSF is currently the major focus point of concerted protocol development for, and promoting the use of, XMPP, it is not the end all and be all of all things XMPP. The core protocols are defined over at the IETF, and you'll find it has a similar approach to try and keep its workings as neutral as possible. Also, the protocol *and* the community are intentionally distributedly extensible. That means that stuff can, and does, happen outside of the XSF.
Second you are correct that nothing is absolute, including views on political, social, or ethical topics. My job as a director, and chair, is finding the delicate balance between the personal views of individuals in the XSF Membership and the XMPP community in general, and the stated goals of the XSF. Our mission statement (<https://xmpp.org/about/xsf/mission/>) is quite clear on the position the XSF takes. We also expanded this in our procedures (e.g. <https://xmpp.org/extensions/xep-0001.html>) and design guidelines (<https://xmpp.org/extensions/xep-0134.html>).
Your concern with regard to OMEMO can be held to all those documents, just as I use them to guide my work as a director. Also note that we have already been the target of related pressure, and will continue to push back.
Again I want to stress that the XMPP community includes people not just rooted in FOSS and its varied(!) political leanings, but equally from corporations, non-profits, education, government, supranational organisations, and military organizations.
This all is why trying to elicit a specific response with the casual mentioning of a major geopolitical event is not helpful to me, and why I made the general stance on my approach.
-- ralphm _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Elle. Good day. As I have previously stated, I agree with your suggestion. However, admonishing the XSF is not helpful, and is probably unrelated. Just offer a new system, and persuade people to join you on your efforts to improve the current avenue for XSF related activities. I sense, that once you would have such system, the XSF would have lesser stronger arguments against your offer. It is important to mention that I have quite a few disagreements with Peter, Ralph, and other XSF members, some I have stated and some I did not. Yet, reproving them, even if my arguments be correct, is not helpful. Schimon On Thu, 28 Aug 2025 00:35:04 +0000 Elle <elle+xmpp-standards@weathered-steel.dev> wrote:
- 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@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
Dave. Good day. On Thu, 28 Aug 2025 00:26:12 +0100 Dave Cridland <dave@cridland.net> wrote:
On Thu, 28 Aug 2025 at 00:00, Elle <elle+xmpp-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 appears that "critical mass" does not occur at once, even though it should, similarly to online video games in which people want to have a server full with players at once, otherwise they leave very fast instead of patiently waiting for more to join. So, there should be a possibility to communicate with the current server of choice from other servers. Once more people would utilize that different system, we would be able to switch from the current server to other servers.
- 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.
Elle. Good day. I agree with your approach, and I would probably start to collaborate once there be a repository or a mirror thereof over normal git (git-email), subversion, or cvs platform. As I have stated, I am not collaborating because of the current platform, and it is not only because hostility to foss, llm, but about forcing me to connect to their ECMAScript-enabled HTML interface, which is the reason that I spend as less time as I can over there. On Wed, 27 Aug 2025 22:59:46 +0000 Elle <elle+xmpp-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.
- 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.
- 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?
Please. Be careful with your words. Please. Read my respond. I disagree with your statement. Your statement has been proven false. I use the phrases "blue" and "red" movements in order to avoid unecessary arguments. Once most decentralized communities are of the "blue movement", they ban the instances of the "red movement", together, and discourage people who are not actively promoting "values" of the "blue movement". This issue is easy to observe when exploring the blocked instances over ActivityPub, and even the rumors against Pleroma, which is one of the few platforms that intend to support XMPP and whos developers are extremely nice to me, even though they are well aware that I am affiliated (yet not supportive) with a group which is hostile to their freedoms. That practice of excommunicating over decentralized platforms is bad, because it then returns people to the centralized platforms, and the "blue movement" people then wonder why decentralized platforms are not more popular. Apolitical means APOLITICAL; that is, without discremination, and no campaigns to excommunicate people because they are of another opinion. Otherwise, decentralized is as decentralized as the "email" cartel which blocks home and SOHO email servers. If you disagree, then use or invent another word, but do not mix words with different definitions. P.S. If you ask for a solution, filtering would be more practical as done over the Nostr network, some relays allow some information and other relays do not.
On Wednesday, August 27th, 2025 at 8:51 PM, Ralph Meijer <ralphm@ik.nu> wrote:
Hi Elle,
My main point remains that I'd rather have the XSF spend time on improving XMPP itself rather than bikeshed on tooling every once in a while. It is very demotivating for people working on this to get side line opinions without actual ongoing involvement.
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 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. I also do not believe that the XSF should take positions or make statements and will make every effort to keep it that way.
Cheers,
ralphm
On 27 August 2025 22:32:10 CEST, Elle <elle+xmpp-standards@weathered-steel.dev> wrote:
Hi Ralph,
I'm not sure to what extent you're using Github's tooling, but the CI config for Woodpecker is very close to Github's CI.
I understand the effort in retooling is non-trivial, but Github is becoming increasingly hostile to FOSS projects. They are very close to forcing use of AI on hosted projects, and of course their AI already scrapes all existing hosted projects. With no way to reasonably opt-out.
Plus you know, Microsoft actively supporting the genocide in Gaza.
On Wednesday, August 27th, 2025 at 8:16 PM, Ralph Meijer <ralphm@ik.nu> wrote:
On 27/08/2025 12.55, Florian Schmaus wrote:
[CC'ing standards@, as I'd like to engage the community regarding our
usage of Github]
On 07/08/2025 18.50, E.M. wrote:
[..]
* XEP-0001 and 0143 changes need approval from Board
** Call to provide you input to the changes and place a comment or
review.
This contains some good changes, like the advise to read, understand,
and agree to our IPR. However, I find the the strong emphasis on
Github PRs very problematic. Especially the part where we tell people
that if they don't have a github account and are not willing to sign
up for one, they should find someone who has one.
The XSF should not require the usage of a propriety service for
contributions.
On the other side, I do acknowledge that using a CI-based system for
contributions has its advantage. Therefore, a change which mentions
that we also accept contributions via Github, outlining the existence
of a CI there, would be acceptable to me.
But it is my strong believe that we should always accept contributions
via mail.
Therefore -1, as is.
On a side note: We may also want to point out that it is possible to
validate changes locally. And we probably should look into codeforge
alternatives. But that is outside of the scope of this PR.
We have discussed this at various occasions in the past. The outcome was
that we need to make technology choices and create and maintain tooling
to maintain the processes of the XSF. A choice was made, after
consulting the Infrastructure Team and the XMPP Council, to (continue
to) use GitHub and associated tooling. Reasons for doing it this way is
familiarity with the tooling, minimizing maintenance, and low appetite
for retooling.
The XSF is an organization that entirely depends on volunteers to do
anything. It is already hard to get our core functions staffed and
actually have work done. The effort required for retooling and
subsequent maintenance is better spent on progressing on our core
functions.
I also do not agree the XSF cannot use proprietary services. The XSF is
an open standards organization for the entire XMPP community which
includes projects and contributors in the Free Software and/or Open
Source Software communities (take your preferred one), as well as closed
source and everything in between. Commercial companies and
non-commercial entities alike. There is no inherent or implied leaning
to any choice made here, nor is there a need for a preference.
The changes (including the one below) simply outline the current
process, with XEP-0001 deferring to XEP-0143 for the details. XEP-0143
clearly provides a way to provide changes or initial contributions
without using GitHub, and people are free to clone our repos to
facilitate people to interact more directly with Git without GitHub.
+1, thanks for writing this.
I reviewed and approved both PRs.
Kind regards,
Ralph Meijer ---------------------------------------------------------------
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-leave@xmpp.org
---------------------------------------------------------------
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-leave@xmpp.or
On Wed, 27 Aug 2025 at 21:16, Ralph Meijer <ralphm@ik.nu> wrote:
The changes (including the one below) simply outline the current process, with XEP-0001 deferring to XEP-0143 for the details.
I think this is the important point. However much we might prefer that our process didn't depend as much on GitHub - and I totally and entirely sympathize with this view - at the moment it does, and these PRs exist to ensure we document what we do. If we, as a community, wish to change our process we should do so and update the documentation to match. As Ralph also said, though, we depend entirely on volunteers. The reason we lean on GitHub is because this reduces the load on our volunteers, and in particular on Daniel as XMPP Editor. I might want us to be primarily list-based for XEP changes as well as discussion, but not at the expense of more effort on Daniel's part. If we had a team of volunteers (and authors) willing to manage an independent source control and provide updates that way, I'd love it. But we are where we are, and hope is not a strategy. So, in summary, the PR is written to match current process, and while I would welcome change I'm not sure it's realistic. Dave.
Your website is a scam. I had some money to my account, but I didn’t receive it. Didn’t show in my balance في أربعاء، 27 أغسطس، 2025 في 4:55 م، كتب Dave Cridland <dave@cridland.net>:
On Wed, 27 Aug 2025 at 21:16, Ralph Meijer <ralphm@ik.nu> wrote:
The changes (including the one below) simply outline the current process, with XEP-0001 deferring to XEP-0143 for the details.
I think this is the important point.
However much we might prefer that our process didn't depend as much on GitHub - and I totally and entirely sympathize with this view - at the moment it does, and these PRs exist to ensure we document what we do.
If we, as a community, wish to change our process we should do so and update the documentation to match.
As Ralph also said, though, we depend entirely on volunteers. The reason we lean on GitHub is because this reduces the load on our volunteers, and in particular on Daniel as XMPP Editor. I might want us to be primarily list-based for XEP changes as well as discussion, but not at the expense of more effort on Daniel's part. If we had a team of volunteers (and authors) willing to manage an independent source control and provide updates that way, I'd love it. But we are where we are, and hope is not a strategy.
So, in summary, the PR is written to match current process, and while I would welcome change I'm not sure it's realistic.
Dave. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
On Wed, 27 Aug 2025 at 22:26, Ahmed Moqbel <ahmedaliusa73384@gmail.com> wrote:
Your website is a scam. I had some money to my account, but I didn’t receive it. Didn’t show in my balance
بالأسف، نحن لسنا بنكًا ولا نملك أي حسابات. أعتقد أن الشخص الذي احتال عليك كان شخصًا آخر تمامًا. (I am sorry. We are not a bank and do not have accounts. I believe whoever scammed you was a completely different person)
Arguments over gitberghutlabejo aside, I believe Florian's veto is predicated on direct email submissions no longer being an option. The current wording reduces to "use GitHub or publicly beg someone else to do that for you;" the XSF has always accepted email submissions (if only because this was initially the only practical solution) and to rule it out now would be both limiting and discouraging. So, acknowledging the additional overhead for editors in processing email submissions, a possible rewording might be: • XEPs should be submitted via a GitHub Pull Request that adds the XML file (and changes no other XEPs) to the "inbox" directory. (See <link url="#maintain">below</link> for a typical working pattern.) • Contributors without a GitHub account are advized to request help from the community in the XSF MUC (xsf@muc.xmpp.org) or via email to the &SSIG; (standards@xmpp.org). • If neither of the above submissions options are possible, an email submission may be sent to the &EDITOR; team (editor@xmpp.org) with the subject containing the word "XEP". Note, however, that this causes additional work for editors and therefore may result in a delay in processing.
On 28/08/2025 13.21, Tedd Sterr wrote:
Arguments over gitberghutlabejo aside, I believe Florian's veto is predicated on direct email submissions no longer being an option. This! It seems I failed to make this clear. At least, for some reason the discussion seems have drifted towards our general usage of github.
My main concern is that the wording reads like github is the only option for contributions. It is imperative that we *do not* require people to sign up with github (or to chase down other people with an github account) in order to be able to contribute. - Flow
On Thu, Aug 28, 2025 at 09:38:52PM +0200, Florian Schmaus wrote:
On 28/08/2025 13.21, Tedd Sterr wrote:
Arguments over gitberghutlabejo aside, I believe Florian's veto is predicated on direct email submissions no longer being an option. This!
Precisely! -- Zash
participants (13)
-
Ahmed Moqbel -
Badri -
Badri Sunderarajan
-
Dave Cridland -
Elle -
Florian Schmaus -
Goffi -
Guus der Kinderen -
Kim Alvefur -
Mathieu Pasquet -
Ralph Meijer -
Schimon Jehudah -
Tedd Sterr