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(a)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(a)xmpp.org > To unsubscribe send an email to standards-leave(a)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(a)fedora.email> wrote: _______________________________________________ Standards mailing list -- standards(a)xmpp.org To unsubscribe send an email to standards-leave(a)xmpp.org

Hi Elle, Le vendredi 29 août 2025, 08:19:14 heure d’été d’Europe centrale Elle a écrit : reviewing the Github CI workflow, and the `tools/github_auto_triage_pr.sh` script. which aims to be a replacement for the `gh` tool. 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

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(a)ik.nu> wrote: _______________________________________________ Standards mailing list -- standards(a)xmpp.org To unsubscribe send an email to standards-leave(a)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?

- 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.

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

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.

Le 28 août 2025 10:21:38 GMT+02:00, Guus der Kinderen <guus.der.kinderen(a)gmail.com> a écrit : 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

Hello, Le jeudi 28 août 2025, 10:21:38 heure d’été d’Europe centrale Guus der Kinderen a écrit : 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(a)xmpp.org To unsubscribe send an email to standards-leave(a)xmpp.org

Hello, Le jeudi 28 août 2025, 10:21:38 heure d’été d’Europe centrale Guus der Kinderen a écrit : 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.

[..] At any meeting of the Board of Directors, each Director present

- 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 &lt;dave(a)cridland.net&gt; 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

- 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 &lt;ralphm(a)ik.nu&gt; 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 > &lt;elle+xmpp-standards(a)weathered-steel.dev&gt; 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 >> &lt;ralphm(a)ik.nu&gt; 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. >>>>> Link 2: >>>>> https://github.com/xsf/xeps/pull/1407 >>>> >>>> +1, thanks for writing this. >>> >>> I reviewed and approved both PRs. >>> >>> Kind regards, >>> >>> Ralph Meijer >>> --------------------------------------------------------------- >>> >>> Standards mailing list -- standards(a)xmpp.org >>> >>> To unsubscribe send an email to standards-leave(a)xmpp.org >> >> --------------------------------------------------------------- >> >> Standards mailing list -- standards(a)xmpp.org >> >> To unsubscribe send an email to standards-leave(a)xmpp.or

On Wed, 27 Aug 2025 at 21:16, Ralph Meijer &lt;ralphm(a)ik.nu&gt; wrote: 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(a)xmpp.org To unsubscribe send an email to standards-leave(a)xmpp.org

On 28/08/2025 13.21, Tedd Sterr wrote: This!