From 38a2b43df9d247823517cf1f24de2a3a06d1a81d Mon Sep 17 00:00:00 2001 From: DanConwayDev Date: Wed, 14 Jan 2026 12:12:41 +0000 Subject: [PATCH] issue: update overlapping issues with reference to ec1f strategy --- 1f4f-poor-naughty-list-identification.md | 4 ++++ 2cdc-nip-86-relay-management-api.md | 4 ++++ 76fe-repository-count-metric.md | 3 +++ 7d0b-management-dashboard.md | 4 ++++ 8430-storage-limits-and-quota-management.md | 4 ++++ d6ee-defensive-relay-features.md | 4 ++++ 6 files changed, 23 insertions(+) diff --git a/1f4f-poor-naughty-list-identification.md b/1f4f-poor-naughty-list-identification.md index 58eda89..8aef72b 100644 --- a/1f4f-poor-naughty-list-identification.md +++ b/1f4f-poor-naughty-list-identification.md @@ -2,6 +2,10 @@ **ID:** 1f4f +> **⚠️ COORDINATION REQUIRED:** This issue is part of the Administrator Observability and Management Strategy (issue ec1f). +> **Before starting work:** Check issue ec1f for current phase, dependencies, and coordination requirements. +> This issue contributes to **Phase 4 (Enforcement)** and depends on Phase 3 (blacklist API) completion. + ## Issue Summary We need to detect malicious behavior from clients and relays to protect our system from abuse, DoS attacks, and bandwidth exhaustion. This should feed into a reputation system or connection throttling/banning mechanism. diff --git a/2cdc-nip-86-relay-management-api.md b/2cdc-nip-86-relay-management-api.md index 6db7cfa..ad1b47c 100644 --- a/2cdc-nip-86-relay-management-api.md +++ b/2cdc-nip-86-relay-management-api.md @@ -2,6 +2,10 @@ **ID:** 2cdc +> **⚠️ COORDINATION REQUIRED:** This issue is part of the Administrator Observability and Management Strategy (issue ec1f). +> **Before starting work:** Check issue ec1f for current phase, dependencies, and coordination requirements. +> **STATUS:** Deferred in favor of simpler HTTP API first (see ec1f Phase 3). NIP-86 compliance planned for post-Phase 3. + ## Issue Summary Implement NIP-86 (Relay Management API) to provide authenticated administrative control over the relay. This enables operators to blacklist users, delete repositories, ban event posting, and perform other management actions through a standardized API. diff --git a/76fe-repository-count-metric.md b/76fe-repository-count-metric.md index 3066fcb..ff5e9f2 100644 --- a/76fe-repository-count-metric.md +++ b/76fe-repository-count-metric.md @@ -2,6 +2,9 @@ **ID:** 76fe +> **⚠️ COORDINATION REQUIRED:** This issue is part of the Administrator Observability and Management Strategy (issue ec1f). +> This metric should be verified during **Phase 1 (Observability)** when testing the Prometheus/Grafana setup. + **Date Discovered:** 2026-01-12 **Date Resolved:** 2026-01-12 **Priority:** Medium diff --git a/7d0b-management-dashboard.md b/7d0b-management-dashboard.md index 9fc5dea..606dc30 100644 --- a/7d0b-management-dashboard.md +++ b/7d0b-management-dashboard.md @@ -2,6 +2,10 @@ **ID:** 7d0b +> **⚠️ COORDINATION REQUIRED:** This issue is part of the Administrator Observability and Management Strategy (issue ec1f). +> **Before starting work:** Check issue ec1f for current phase, dependencies, and coordination requirements. +> This issue is the **primary deliverable for Phase 2 (Insights)**. + ## Issue Summary We need a web-based management dashboard to monitor relay health, view storage and usage statistics, and provide basic operational visibility. This dashboard should display key metrics about relay operations, resource utilization, and usage patterns. diff --git a/8430-storage-limits-and-quota-management.md b/8430-storage-limits-and-quota-management.md index 26d5137..e90d879 100644 --- a/8430-storage-limits-and-quota-management.md +++ b/8430-storage-limits-and-quota-management.md @@ -2,6 +2,10 @@ **ID:** 8430 +> **⚠️ COORDINATION REQUIRED:** This issue is part of the Administrator Observability and Management Strategy (issue ec1f). +> **Before starting work:** Check issue ec1f for current phase, dependencies, and coordination requirements. +> This issue is the **primary deliverable for Phase 4 (Enforcement)** and depends on Phase 3 (management API) completion. + ## Issue Summary We currently have no storage limits or quota enforcement, allowing users to push arbitrarily large repositories (e.g., 20GB+) and potentially fill the relay's disk. We need configurable storage limits at multiple levels and graceful handling when approaching disk capacity. diff --git a/d6ee-defensive-relay-features.md b/d6ee-defensive-relay-features.md index 75e76b7..ab08ca6 100644 --- a/d6ee-defensive-relay-features.md +++ b/d6ee-defensive-relay-features.md @@ -2,6 +2,10 @@ **ID:** d6ee +> **⚠️ COORDINATION REQUIRED:** This issue is part of the Administrator Observability and Management Strategy (issue ec1f). +> **Before starting work:** Check issue ec1f for current phase, dependencies, and coordination requirements. +> This issue contributes to **Phase 4 (Enforcement)**. Only Phase 1 (config-based protection) is currently approved. + ## Issue Summary ~~Implement defensive rate limiting and resource controls to protect the relay from abuse. Focus on per-connection and per-IP rate limits using rust-nostr relay-builder capabilities and custom extensions where needed.~~