Files
ngit-grasp/docs/reference
DanConwayDev 7334e04b88 feat(identity): publish relay owner events
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.
2026-08-15 11:17:57 +00:00
..
2025-11-04 10:25:53 +00:00

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

  1. Know what you're looking for - Reference is for lookup, not learning
  2. Use search or table of contents - Find the specific detail you need
  3. Check version - Ensure docs match your version
  4. Verify with code - Reference should match implementation

Not sure if this is what you need?


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.