Currently the Monero Core Team is responsible for a number of things that are critical to Monero, and as a result there is a great level of trust implicit in them. For instance, a malicious Monero Core Team member could hijack the domain, and serve up malicious Monero downloads right after a new release. No matter how quickly this is detected, there will be many affected downloads, and could cause massive financial and privacy-related network damage. The recent CSS wallet incident is also an example of risks that the Core Team presents.
Additionally, this has been a thankless job that the Core Team has taken on (for no compensation), although even if there were compensation and constant praise it would still be a centralising force that we should try and eviscerate.
My suggestion, and I encourage us to use this thread to iterate on it in public, is to break the Core Team up into 6 self-assembling workgroups. This is not a complicated exercise, apart from the community coming to consensus as to who should form part of the workgroups. I would suggest we aim for a January 1st, 2025, cutover date for this.
Existing Core Team members can, naturally, choose to join a particular workgroup (or workgroups), if the community agrees they should. I, personally, will not be participating in any of these proposed working groups, and will use this as an opportunity to step back from any last vestiges of administrative involvement or perceived leadership in Monero.
Open questions that we should use this thread to answer is: (1) what should we use to quickly spin up some sort of loose consensus mechanism for the workgroups (eg. Strawpoll)? (2) how many members should be part of each workgroup?
Some basics that I think should be set in stone are: given the sensitivity of these workgroups, community members that do not have a long multi-year history should simply not be considered. Community members should also be familiar with secure communications platforms, GPG, and similar. Their GPG keys should preferably be a matter of public record already, or inserted into source tree as soon as possible. Many of the roles and responsibilities aren't just technical, but require building a deep relationship with service providers who are familiar with the sensitive nature of Monero's software and support the project's mission, so it would generally require individuals in those particular roles to not be abrasive, and to be warm and understanding and friendly with the individuals they deal with at those service providers. Finally, some of these workgroups simply CANNOT have any form of multisig / ACL / group access, and by definition each individual on the workgroup can exercise complete control and abuse their position (or be wrench-attacked, or be compromised). I've tried to note that below.
General Donation Fund Workgroup
This workgroup can use multisig to share control.
Responsible for determining what General Donation Funds should be spent on, and dispensing them. The download server and CDN are the primary recurring costs, and we have a whole structure setup that pays those monthly via card / wire transfer and is reimbursed by the GF. They can choose to continue to use that, or they can do their own thing.
CCS Workgroup
This workgroup can use multisig on the wallet, but some other aspects might inherently be more centralised.
Responsible for managing the CCS, approving proposals, managing milestones, etc. This obviously includes dispensing funds.
IP and DNS Workgroup
This workgroup can democratise some aspects of it, but ultimately there will need to have a super-administrator for both domains and DNS (this can be a shared account).
Responsible for IP (as in intellectual property) which includes domains, trademarks, copyrights, service marks, anything along those lines. They're mostly going to be responsible for renewing the domains on an annual basis, ensuring the domains aren't stolen / socially engineered (I built an extremely deep relationship with our registrar, Gandi, over the last decade to prevent these attacks which occur very frequently). For multiple reasons we use Cloudflare to handle the DNS (including their embracing and facilitating Tor routing and access from Tor exit nodes, and their exceptional DDoS prevention). Of course, this workgroup is welcome to transfer the domains somewhere else, as well as move the DNS elsewhere.
Servers and CDN Workgroup
This workgroup might be able to democratise some access, but as with the previous one there is a need for some super-administrator access (this can be a shared account).
Responsible for the CDN and server infrastructure. Currently there is a single, very beefy server on a 10gbps unmetered, well-peered uplink, that serves the Monero website and the downloads. We have a well architected, hardened configuration that was designed by Gus, formerly of Tari Labs, and Dan (pigeons), from Cypherstack. The CDN is one that we specifically chose because it has a network of endpoints in China, and thus bypasses the Chinese GFW to serve the Monero website and downloads. Of course, this workgroup is absolutely entitled to move the infrastructure elsewhere, switch off the CDN, etc.
Git Workgroup
This workgroup likely can't democratise much at a high level (some nuance below), and will also require a super-administrator account (this can be a shared account).
Responsible for the monero-project GitHub organisation, managing GitHub issues and pull requests, managing maintainers, and managing releases. There is some democratisation in the form of individual repo access. In other words, an individual who isn't even part of the workgroup can be given write access (ie. maintainer role) on an individual repo. They are welcome to re-run the experiment we ran with self-hosted GitLab a few years ago, but I think we've demonstrated that GitHub is fine as a platform for collaboration, knowing that we will detect any malicious activity on GitHub's part really quickly as git acts almost as a blockchain, distributing the code (and its branches and history of changes) on the computers of thousands of Monero contributors and users.
Community Channels Workgroup
This workgroup can democratise some individual channels, but it will require a require a super-administrator account (this can be a shared account).
Responsible for managing the various community channels, like the Telegram groups, the subreddit, the IRC channels, etc. Obviously these channels already exist, and this workgroup might choose to fold the existing moderators of the subreddit (for instance) into the workgroup. They could also exist as a distinct workgroup, working with those moderators and letting them handle changes to their moderation team. They would generally be expected to maintain some of the guidelines and standards we have for community channels (eg. no price talk in most channels / forums, there are specific places for that) and ensure that these guidelines are largely accepted and enforced where relevant. They would also be responsible for some more sensitive things like controlling the Monero namespace on Libera (the IRC server we use), which is an elevated level of access that allows the workgroup to take over any channel that starts with "monero" (useful for channels that are trying to scam or impersonate).
This is an interesting proposal. From what I have heard, core doesn't do all that much these days besides getting blamed when something goes wrong. Splitting up their responsibilities and decentralizing them sounds like a good option for Moneros future.
Of course it'd be great to decentralize core activity and not rely on a few individuals. However there are two major issues we will encounter:
Staffing each group with 3 people means we need 18 people total, and the requirements for the positions are quite strict. Sure, we do have many good people, but most of them are at capacity with there current tasks and work load.
If the multiple small groups have even slightly different targets or do not want to work together for whatever reason, we risk that community splits.
Considering this the 1st Jan 2025 is an ambitious timeline, and there are many open questions left. I'd advocate to take our time to handle this transition well, be mindful about keeping our vision and not get lost in squabbles.
we’ve demonstrated that GitHub is fine as a platform for collaboration, knowing that we will detect any malicious activity on GitHub’s part really quickly as git acts almost as a blockchain
I don’t worry about source code integrity, but purely privacy-wise, it’s far from being ideal that users must access GitHub, monitored and recorded everything by Micro$oft.
The CCS Wallet Incident is sad but not surprising. Something that could happen as a human may make a mistake.
“Normal” Monero users still love to use Reddit, Twitter, Windows 10, or Github, which is much more puzzling.
I am fairly new to this community, so I have no official say. But has Core considered distributing Monero binaries via Nostr, IPFS, Arweave, akash, Session, or other decentralized means? This would allow for more decentralization of staff and censorship resistance than a credit card government domain. Also could be both. just more options. And then different core members could do the different official channels, which would quickly raise alarm bells if Nostr has a different binary than getmonero.org