Subsystem: fork model / git.
Status: should align with the broader fork-model rethink (discussions#131 and AGit) — these are about the fork model as it stands today and should land wherever that goes. Kept separate from Issue A so creation control isn't blocked by this redesign. This ticket was split off from (discussions#477.
Problem
Under open registration we need finer control over who may fork and what a fork copies, beyond the instance-wide on/off switch.
Why current options don't cover it
DISABLE_FORKSis instance-wide only — no per-repository allow-list for who may fork.- Forking appears to copy all branches, with no default-branch-only option (unconfirmed — please confirm; GitHub has had default-branch-only forks since 2022).
Asks
- Repository/org-managed fork permissions — let a repository admin allow forks broadly or restrict to specific users/teams, instead of only the instance-wide switch. (This is how an outside contributor is granted the ability to fork under the umbrella scenario.)
- Default-branch-only forks — option to copy just the default branch when forking, rather than all branches.
Coordination
Asks here should align with the fork-model rethink (discussions#131) and AGit. Please link any existing issues/discussions to consolidate with.
Umbrella context
Who's asking: This request comes from Zentrum SDS, the Swiss public-sector digital-sovereignty initiative (anchored at the Bern University of Applied Sciences), which is planning the Forgejo-based opencode.ch code platform. "We" throughout refers to this group.
Open instances need open registration so people can file issues and contribute (fork → PR). But open registration also lets anyone create new repositories, which raises two problems:
- Resource use — new repositories accumulate and consume shared Actions runner resources.
- Content moderation — arbitrary repositories (spam, abuse, off-topic or unlawful content) on a public-sector-branded platform.
Both force operators to police and delete repositories by hand (a known pain on code.forgejo.org itself). The shape we want: anyone participates, only approved users create repositories.
How existing public-sector platforms handle it:
opencode.de(GitLab-based) — anyone can register to comment and file tickets; creating new repositories is gated by an email-domain allow-list. The planned Swissopencode.ch(Forgejo-based) needs the same. (How an outside contributor is granted the ability to fork is exactly the gap Issue B addresses.)code.overheid.nl(Forgejo-based) — avoids the problem by closing registration to government organisations only. Valid, but it hinders adoption of and contribution to the code hosted there (outside contributors, civil society, vendors can't easily fork and send PRs), undercutting the "public money, public code" goal.
This request is for operators who want registration to stay open — so the code on the platform gets real external engagement — while still controlling who creates repositories and how forks work.
Shared notes (apply to both issues):
- Forward-looking: relation to federation. Long term, federation (ForgeFed/ActivityPub, NLnet-funded) addresses the cross-instance version of "participate without us maintaining external accounts": an external contributor keeps their home-forge identity and forks/PRs across instances, so the host never provisions accounts for them — and the "fork yes / create-repository no" split falls out naturally. These local controls and federation are complementary, not competing: federation is still experimental (federated stars/follows today; federated forks/PRs and, explicitly, access control & moderation not yet built), so the controls here are what work now; and even once federation lands, the creation allow-list (Issue A) still applies for local open registration. If anyone on the federation/moderation side has related work underway, please flag it so the access-control model doesn't diverge.
- We'd rather upstream this than carry a soft fork, and are interested in co-designing and helping fund the work. Happy to write an RFC and prototype.
- External-IdP deployments: where Forgejo consumes OIDC from an external identity provider (Keycloak/Zitadel/Authelia), the allow-list in Issue A is most naturally expressed as a group/claim rule at the IdP, consumed by Forgejo's existing group→team mapping. The email-domain gate is then just one way to populate that group.
**Subsystem:** fork model / git.
**Status:** should **align with the broader fork-model rethink** ([discussions#131](https://codeberg.org/forgejo/discussions/issues/131) and AGit) — these are about the fork model *as it stands today* and should land wherever that goes. Kept separate from Issue A so creation control isn't blocked by this redesign. This ticket was split off from ([discussions#477](https://codeberg.org/forgejo/discussions/issues/477).
### Problem
Under open registration we need finer control over **who may fork** and **what a fork copies**, beyond the instance-wide on/off switch.
### Why current options don't cover it
- `DISABLE_FORKS` is **instance-wide only** — no per-repository allow-list for who may fork.
- Forking appears to copy **all branches**, with no default-branch-only option (unconfirmed — please confirm; [GitHub has had default-branch-only forks since 2022](https://github.blog/changelog/2022-07-27-you-can-now-fork-a-repo-and-copy-only-the-default-branch/)).
### Asks
1. **Repository/org-managed fork permissions** — let a repository admin allow forks broadly or restrict to specific users/teams, instead of only the instance-wide switch. (This is how an outside contributor is granted the ability to fork under the umbrella scenario.)
2. **Default-branch-only forks** — option to copy just the default branch when forking, rather than all branches.
### Coordination
Asks here should align with the fork-model rethink ([discussions#131](https://codeberg.org/forgejo/discussions/issues/131)) and AGit. Please link any existing issues/discussions to consolidate with.
## Umbrella context
**Who's asking:** This request comes from [Zentrum SDS](https://zentrumsds.ch/), the Swiss public-sector digital-sovereignty initiative (anchored at the Bern University of Applied Sciences), which is planning the Forgejo-based **opencode.ch** code platform. "We" throughout refers to this group.
Open instances need **open registration** so people can file issues and contribute (fork → PR). But open registration also lets anyone **create new repositories**, which raises two problems:
- **Resource use** — new repositories accumulate and consume shared Actions runner resources.
- **Content moderation** — arbitrary repositories (spam, abuse, off-topic or unlawful content) on a public-sector-branded platform.
Both force operators to police and delete repositories by hand (a known pain on `code.forgejo.org` itself). **The shape we want: anyone participates, only approved users create repositories.**
How existing public-sector platforms handle it:
- **`opencode.de`** (GitLab-based) — anyone can register to comment and file tickets; creating new repositories is gated by an email-domain allow-list. The planned Swiss **`opencode.ch`** (Forgejo-based) needs the same. (How an outside contributor is granted the ability to *fork* is exactly the gap Issue B addresses.)
- **`code.overheid.nl`** (Forgejo-based) — avoids the problem by **closing registration** to government organisations only. Valid, but it **hinders adoption of and contribution to the code hosted there** (outside contributors, civil society, vendors can't easily fork and send PRs), undercutting the "public money, public code" goal.
This request is for operators who want registration to stay **open** — so the code on the platform gets real external engagement — while still controlling who creates repositories and how forks work.
**Shared notes (apply to both issues):**
- **Forward-looking: relation to federation.** Long term, [federation](https://nlnet.nl/project/Federated-Forgejo/) (ForgeFed/ActivityPub, NLnet-funded) addresses the *cross-instance* version of "participate without us maintaining external accounts": an external contributor keeps their home-forge identity and forks/PRs across instances, so the host never provisions accounts for them — and the "fork yes / create-repository no" split falls out naturally. These local controls and federation are **complementary, not competing**: federation is still experimental (federated stars/follows today; federated forks/PRs and, explicitly, access control & moderation not yet built), so the controls here are what work *now*; and even once federation lands, the creation allow-list (Issue A) still applies for *local* open registration. **If anyone on the federation/moderation side has related work underway, please flag it** so the access-control model doesn't diverge.
- We'd rather **upstream this than carry a soft fork**, and are interested in **co-designing and helping fund** the work. Happy to write an RFC and prototype.
- **External-IdP deployments:** where Forgejo consumes OIDC from an external identity provider (Keycloak/Zitadel/Authelia), the allow-list in Issue A is most naturally expressed as a **group/claim rule at the IdP**, consumed by Forgejo's existing group→team mapping. The email-domain gate is then just one way to populate that group.