Files
ngit-grasp/docs/reference
DanConwayDev a6b5e3a9f6 fix(relay): preserve bursty client sessions
rust-nostr 0.45 added a connection-wide 300-frame-per-minute bucket and
closes a WebSocket when it is exhausted. Production recorded 5,020 such
disconnects before this change; Caddy correlation showed both a rapid source
sending more than 300 frames in roughly 1.5 seconds and legitimate
gitworkshop.dev, gittr.space, armada.buzz, and localhost browser sessions
crossing the same ceiling. This predates and is independent of the
subscription-budget ledger.

Select a fixed 6,000-message-per-minute allowance for ngit-grasp. An initial
1,200/minute production candidate reduced closures to one in 29 minutes, but
that remaining localhost development client legitimately sustained about
44-45 frames/second. A 100-frame-per-second token rate gives that observed
traffic useful headroom while retaining a finite catch-all for malformed and
non-operation traffic.

The tighter independent limits for EVENT writes, queries, and authentication
events remain unchanged, so this does not expand those operation budgets. No
new configuration option is added because clients cannot discover or adapt
to a non-standard frame quota.

Add scenario coverage proving a 1,201-frame burst remains connected and
completes a subsequent REQ/EOSE exchange, while a rapid 6,001-frame burst is
still closed. Update the changelog and relay hardening/scaling references in
the same commit.

Per-IP admission fairness and upstream rust-nostr policy remain deliberately
out of scope.

Validation:
- nix develop -c cargo test --test relay_message_rate (46 passed)
- nix develop -c cargo test --lib (643 passed on the initial candidate)
- nix build .#ngit-grasp (initial candidate; final package rebuilt by deploy)
2026-08-07 09:36:21 +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.