The relay-owner key is intended to double as the service identity used by ngit-ci, but clients could only discover it through HTTP and owner-authored coordinator events without repository roots failed admission. Sign a minimal kind-0 NIP-05 bot profile at startup — per NIP-24 `name` is always set, here to the scheme-less public URL — alongside a single unmarked kind-10002 relay entry. An operator-customized profile is kept and never overwritten, and no identity event — locally stored or freshly generated — is published before the local database and at least one user-index relay have been successfully checked for that kind, so a database wiped and reseeded during an index outage can never displace a customized profile surviving on the indexes. Every send is preceded by a per-relay re-check: an identity found on an index relay is adopted locally, where replaceable-event semantics keep the newest copy, and is never overwritten, so publication only fills gaps on index relays that individually confirm they hold none; propagating a profile update onto an index that already has one is left to the operator's own client. A kind with no local copy is not even seeded until a reachable user-index relay confirms it holds no identity of that kind. Publication never blocks startup, retries transient failures with a capped backoff, and stops on terminal protocol rejections. With no user-index relays configured, missing kinds are seeded locally right away. In private mode (GRASP-08) identity events are seeded and served locally but never published, so a private relay does not advertise its existence. Trust valid owner-signed events only for kinds without a dedicated admission policy, such as ngit-ci coordinator advertisements that carry no repository root tag. Owner-signed NIP-34 announcements, state events, and PRs run the normal announcement validation, ref alignment, and purgatory git-data handling like any other author, and the relay's own kind 0/10002 identity is always accepted. The NIP-09/NIP-62 deletion gate still runs before any owner acceptance, so replaying a retracted owner event cannot undo its tombstone, and owner deletion/vanish requests keep their lifecycle handling. Because the event blacklist cannot block the owner key, rotating the key is the only remediation if it is compromised; this is documented. NGIT_DOMAIN is assumed to be the documented bare public authority: loopback authorities use ws and other hosts advertise wss, with bare IPv6 authorities bracketed. The test fixture reuses relay-owner keys across TestRelay::restart, and gains caller-provided keys, a private-mode member setup, and explicit user-index relay lists; MockRelay can start pre-seeded so a "recovering" index deterministically holds prior state. Identity retry intervals honor the existing NGIT_TEST fast-timer convention. No new configuration switches or ngit-ci changes are included. Includes rustfmt fixes for src/nostr/policy/announcement.rs and tests/private_mode.rs, which arrived on master unformatted and would otherwise fail the workspace format gate. Validated with rustfmt, strict workspace Clippy, the relay_identity and private_mode integration binaries, and the full workspace test suite. Individual sync/grasp06 integration tests fail intermittently under parallel full-suite load, each passing in isolation and on rerun; the same intermittent failures reproduce on origin/master without these changes.
Reference
Information-oriented documentation - Technical details and specifications.
What Is Reference Documentation?
Reference documentation provides factual, technical information that you look up when needed.
Characteristics:
- ✅ Information-oriented (facts and data)
- ✅ Comprehensive and accurate
- ✅ Structured for lookup
- ✅ Dry and to-the-point
- ✅ Maintained as code changes
Not reference:
- ❌ Learning materials (those are Tutorials)
- ❌ Problem-solving guides (those are How-To)
- ❌ Conceptual explanations (those are Explanation)
Available Reference Documentation
Configuration
Complete reference for all configuration options
Contents:
- Environment variables
- Configuration file format
- Validation rules
- Examples for development/production/testing
Use when: You need to know what a config option does or what values are valid
Git Protocol
Git Smart HTTP protocol specification
Contents:
- Protocol overview
- Pkt-line format
- Request/response structure
- Reference updates format
- Parsing examples
Use when: You need to understand Git HTTP internals
Test Strategy
Testing approach and compliance framework
Contents:
- Test categories (unit, integration, compliance)
- GRASP compliance requirements
- Test isolation strategy
- Running tests
- Coverage requirements
Use when: You're writing tests or need to understand test structure
Planned Reference Documentation
GRASP Protocol
Status: 🔜 Planned
Contents:
- GRASP-01 requirements
- GRASP-02 (Proactive Sync)
- GRASP-05 (Archive)
- Event formats
- Validation rules
API Reference
Status: 🔜 Planned (waiting for main server)
Contents:
- HTTP endpoints
- Request/response formats
- Error codes
- Authentication
- Rate limiting
nostr-sdk Upgrade Guide
Status: 🔜 Planned
Contents:
- Version compatibility matrix
- Breaking changes by version
- Migration examples
- Common patterns
Event Formats
Status: 🔜 Planned
Contents:
- NIP-34 repository announcements (kind 30317)
- NIP-34 state events (kind 30318)
- Custom tags
- Validation rules
CLI Reference
Status: 🔜 Planned
Contents:
- Command-line arguments
- Subcommands
- Environment variables
- Exit codes
How to Use Reference Documentation
- Know what you're looking for - Reference is for lookup, not learning
- Use search or table of contents - Find the specific detail you need
- Check version - Ensure docs match your version
- Verify with code - Reference should match implementation
Not sure if this is what you need?
- New to the topic? → Tutorials
- Trying to solve a problem? → How-To Guides
- Want to understand concepts? → Explanation
Contributing Reference Documentation
When writing reference documentation:
DO:
- ✅ Be accurate and complete
- ✅ Use consistent structure
- ✅ Include all options/parameters
- ✅ Provide examples
- ✅ Update when code changes
- ✅ Use tables for structured data
DON'T:
- ❌ Explain concepts (link to Explanation)
- ❌ Provide tutorials (link to Tutorials)
- ❌ Solve problems (link to How-To)
- ❌ Include opinions or recommendations
Template:
# Reference: [Topic]
**Purpose:** [What this reference covers]
**Audience:** [Who needs this information]
---
## Overview
[Brief description of what's being documented]
---
## [Section 1]
### [Item]
**Description:** [What it is/does]
**Type:** [Data type]
**Default:** [Default value]
**Required:** [Yes/No]
**Examples:**
\`\`\`
[Example usage]
\`\`\`
**Notes:**
- [Important details]
---
## Related Documentation
- [Links to relevant docs]
See Diátaxis: Reference for detailed guidance.
Part of the ngit-grasp documentation using the Diátaxis framework.