>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3580895. --> Reported by: [bertboerland](https://www.drupal.org/user/188) >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>Drupal.org (d.o) is a critical piece of infrastructure for the global Drupal ecosystem, providing code distribution, package metadata, and collaboration tooling. However, the current model raises several structural concerns:</p> <ul> <li><strong>Geopolitical risk</strong>: reliance on centralized infrastructure and specific hosting regions or providers introduces dependencies that are increasingly sensitive in the context of digital sovereignty.</li> <li><strong>Bandwidth and distribution</strong>: global delivery of releases, Composer metadata, and project assets creates significant bandwidth pressure and scaling challenges.</li> <li><strong>Infrastructure cost</strong>: storage, CDN, compute, and especially egress costs continue to grow with ecosystem adoption.</li> </ul> <p>In parallel, the WordPress ecosystem is exploring alternative distribution architectures through the <strong><em>FAIR (Federated and Independent Repositories)</em></strong> initiative, <a href="https://fair.pm/">https://fair.pm/</a>. FAIR introduces a federated model where multiple independent nodes participate in distributing packages and metadata, reducing central bottlenecks and enabling regional autonomy.</p> <p>This raises the question whether similar principles could be explored for Drupal.org to:</p> <ul> <li>Reduce vendor and region dependency</li> <li>Distribute bandwidth across multiple trusted parties</li> <li>Lower operational costs</li> <li>Improve resilience and autonomy in different geopolitical contexts</li> </ul> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <ul> <li>Review the current Drupal.org architecture: <ul> <li>Package distribution (tarballs, Composer endpoints)</li> <li>Git hosting and mirroring</li> <li>CDN usage and traffic distribution</li> </ul> </li> <li>Analyze the WordPress FAIR initiative: <ul> <li>Federated repository architecture</li> <li>Synchronization and consistency mechanisms</li> <li>Trust, signing, and verification model</li> </ul> </li> <li>Compare both approaches in terms of: <ul> <li>Scalability</li> <li>Cost structure</li> <li>Governance and control</li> <li>Security and supply chain implications</li> </ul> </li> <li>Identify potential alignment and gaps</li> </ul> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <ul> <li>Initiate a research spike to explore federated distribution models for Drupal.org</li> <li>Investigate the feasibility of a <strong><em>&ldquo;Drupal FAIR&rdquo;-like approach</em></strong>, including: <ul> <li>Active regional mirrors participating in distribution</li> <li>Federated Composer metadata endpoints</li> <li>Cryptographic signing and trust chains for packages</li> </ul> </li> <li>Design a high-level architecture for a hybrid model: <ul> <li>Central coordination via Drupal.org</li> <li>Distributed delivery via trusted community or partner nodes</li> </ul> </li> <li>Validate the approach using real-world scenarios: <ul> <li>Government use cases (digital sovereignty requirements)</li> <li>Enterprise environments (cost and performance optimization)</li> <li>Community-operated mirrors</li> </ul> </li> </ul> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ul> <li>Document current Drupal.org infrastructure and cost drivers</li> <li>Perform a deeper technical and governance analysis of FAIR</li> <li>Develop a proof-of-concept with a small set of federated nodes</li> <li>Conduct a security and supply chain risk assessment</li> <li>Engage stakeholders (Drupal Association, infrastructure team, community)</li> </ul> <h3 id="summary-ui-changes">User interface changes</h3> <ul> <li>No immediate UI changes required</li> <li>Potential future considerations: <ul> <li>Optional selection or indication of download source (regional node)</li> <li>Visibility into package origin and signature status</li> <li>Health or status indicators for federated nodes</li> </ul> </li> </ul> <h3 id="summary-introduced-terminology">Introduced terminology</h3> <ul> <li><strong>Federated Repository</strong>: a node participating in a distributed network for hosting and serving packages and metadata</li> <li><strong>Active Mirror</strong>: a mirror that participates in synchronization and distribution logic, not just caching</li> <li><strong>Trust Chain</strong>: a mechanism for verifying the integrity and origin of packages</li> <li><strong>Regional Node</strong>: a geographically or jurisdictionally scoped distribution endpoint</li> </ul> <h3 id="summary-api-changes">API changes</h3> <ul> <li>Potential future changes may include: <ul> <li>Extensions to Composer metadata endpoints to support multiple upstream sources</li> <li>Federated metadata aggregation</li> <li>APIs for package signing and verification</li> <li>Node discovery and registry mechanisms for trusted federated nodes</li> </ul> </li> <li>Not yet defined; subject to research outcomes</li> </ul> <h3 id="summary-data-model-changes">Data model changes</h3> <ul> <li>Potential additions may include: <ul> <li>Metadata for package provenance (origin, signatures, trust level)</li> <li>Registry of federated nodes and trust relationships</li> <li>Synchronization state tracking between nodes</li> </ul> </li> <li>Not yet defined; dependent on architectural direction</li> </ul> <h3 id="summary-release-notes">Release notes snippet</h3> <ul> <li>This issue explores a federated distribution model for Drupal.org, inspired by the <strong><em>WordPress FAIR initiative</em></strong>, aiming to improve resilience, reduce infrastructure costs, and address emerging digital sovereignty considerations.</li> </ul>