Mathieu. Good day. On Thu, 28 Aug 2025 12:08:25 +0200 Mathieu Pasquet <[email protected]> wrote:
> Le 28 août 2025 10:21:38 GMT+02:00, Guus der Kinderen > <[email protected]> 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 <[email protected]> wrote: > > > >> > >> > >> On 28 August 2025 02:35:04 CEST, Elle < > >> [email protected]> 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 -- [email protected] > >> To unsubscribe send an email to [email protected] > >> > > 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 > _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
