Maintainers: going deeper
The Maintainers guide covers the everyday roster. This page collects the cases most repositories never meet.
A repository with no lead maintainer
With a lead, every other maintainer's repository coordinate forwards to the lead. In practice everyone clones the same nostr://<lead-npub>/<repo-identifier>.
Without a lead, users clone whichever maintainer's coordinate they happen to choose. If that maintainer later forks the repository, everyone who cloned their coordinate moves away with the fork.
That is why, from ngit v3, a leadless repository has to be a regular and conscious choice: pass --no-lead-maintainer with every ngit repo command. Otherwise the first add by a sole maintainer makes that publisher the lead. There is also nobody for ngit repo follow-lead to follow, so each maintainer keeps their own announcement current by hand.
Listing a maintainer also trusts their list
Maintainership is a recursive, reciprocal graph starting from the maintainer a user selected. If you list a co-maintainer, you also authorise anyone they list, and anyone those people list, until you remove them.
This is also true in the lead model, but tooling normally stops non-leads from adding maintainers, so in practice the lead's list is the whole graph. In a leadless repository nothing stops it, so listing someone means trusting their judgement about who else to list.
An invitee who already has a repository with the same name
If an invited maintainer already publishes a repository with the same name, ngit repo accept cannot simply add the invitation on top of it. ngit reports the conflict and tells you which announcement it would change. Follow that specific error rather than republishing the announcement wholesale.
Inspecting before you repair
bash
ngit repo --offlineAlongside the usual metadata this reports members, lead_source, lead_path, pending_actions and health. Read those before trying to fix an unusual topology.
The protocol model
NIP-34 maintainers covers how announcements reference each other, how clients discover the roster, and the impersonation analysis behind explicit acceptance. Maintainer authority in v3 explains why the model changed and how legacy repositories remain compatible.