diff --git a/0-ai-gatekeeper-protocol/mcp-repo-guardian/README.md b/0-ai-gatekeeper-protocol/mcp-repo-guardian/README.md deleted file mode 100644 index 3df972cb..00000000 --- a/0-ai-gatekeeper-protocol/mcp-repo-guardian/README.md +++ /dev/null @@ -1,236 +0,0 @@ -# MCP Repository Guardian - -**SPDX-License-Identifier: PMPL-1.0-or-later** - -Model Context Protocol (MCP) server that enforces AI.a2ml manifest acknowledgment before any repository operations. - -**Implementation:** ReScript + Deno (✅ Hyperpolymath Policy Compliant) - -## Overview - -The Repository Guardian acts as a gatekeeper for AI agents accessing your repositories. It ensures that: - -1. **AI agents MUST read AI.a2ml manifest first** before any operations -2. **Manifest invariants are enforced** (no SCM file duplication, etc.) -3. **Access is session-based** with attestation validation -4. **Path validation** prevents invariant violations - -## How It Works - -``` -┌─────────────┐ -│ AI Agent │ (Claude, etc.) -└──────┬──────┘ - │ - │ ❌ Direct file access blocked - │ - ▼ -┌─────────────────────────────┐ -│ MCP Repository Guardian │ ← ENFORCES AI.a2ml -│ │ -│ 1. get_manifest │ -│ 2. acknowledge_manifest │ -│ 3. read_file (with token) │ -│ 4. list_directory │ -└──────────┬──────────────────┘ - │ - ▼ - ┌──────────────┐ - │ Your Repos │ - └──────────────┘ -``` - -## Installation - -### Prerequisites - -- **ReScript compiler** - Install: `npm install -g rescript` (build tool only) -- **Deno runtime** - https://deno.land/ - -### From Source - -```bash -git clone https://github.com/hyperpolymath/mcp-repo-guardian -cd mcp-repo-guardian - -# Build ReScript code -rescript - -# Run with Deno -deno run --allow-read --allow-write --allow-env --allow-net src/Index.mjs -``` - -## Configuration - -Add to your MCP settings (e.g., `~/.claude/settings.json`): - -```json -{ - "mcpServers": { - "repo-guardian": { - "command": "deno", - "args": [ - "run", - "--allow-read", - "--allow-write", - "--allow-env", - "--allow-net", - "/path/to/mcp-repo-guardian/src/Index.mjs" - ], - "env": { - "REPOS_PATH": "/home/user/Documents/hyperpolymath-repos", - "STRICT_MODE": "true", - "SESSION_TIMEOUT": "3600000" - } - } - } -} -``` - -## Usage - -### 1. Get Manifest - -```typescript -// AI agent calls: get_manifest -{ - "repoPath": "nextgen-languages" -} - -// Returns manifest hash and structure -``` - -### 2. Acknowledge Manifest - -```typescript -// AI agent must provide correct hash -{ - "repoPath": "nextgen-languages", - "attestationHash": "sha256:a8f7c3d2..." -} - -// Returns session ID on success -``` - -### 3. Access Files - -```typescript -// Now can read files with session ID -{ - "sessionId": "uuid", - "path": ".machine_readable/STATE.scm" -} -``` - -## Security Features - -- **No direct file access** - All operations mediated by guardian -- **Attestation validation** - Agent must prove they read manifest -- **Path validation** - Prevents invariant violations -- **Session timeout** - Sessions expire after inactivity -- **Strict mode** - No fallbacks, hard enforcement - -## Tools Provided - -| Tool | Description | Requires Session | -|------|-------------|------------------| -| `get_manifest` | Retrieve manifest content and hash | No | -| `acknowledge_manifest` | Acknowledge manifest with hash | No | -| `read_file` | Read file from repository | Yes | -| `list_directory` | List directory contents | Yes | - -## Example Session - -``` -Agent: get_manifest(repoPath="nextgen-languages") -Guardian: Hash: sha256:a8f7c3d2... - -Agent: read_file(sessionId="...", path="README.md") -Guardian: ❌ ACCESS DENIED - Must acknowledge manifest first - -Agent: acknowledge_manifest(repoPath="...", hash="sha256:a8f7c3d2...") -Guardian: ✅ Session: uuid-1234... - -Agent: read_file(sessionId="uuid-1234", path="README.md") -Guardian: ✅ [file content] - -Agent: read_file(sessionId="uuid-1234", path="STATE.scm") -Guardian: ❌ INVARIANT VIOLATION - SCM files must be in .machine_readable/ -``` - -## Environment Variables - -- `REPOS_PATH` - Base path where repositories are located (default: `cwd`) -- `STRICT_MODE` - Enforce strict mode with no fallbacks (default: `false`) -- `SESSION_TIMEOUT` - Session timeout in milliseconds (default: `3600000`) - -## Development - -### Build - -```bash -# Compile ReScript to JavaScript -rescript - -# Watch mode -rescript build -w - -# Clean -rescript clean -``` - -### Run - -```bash -# Run with Deno -deno task start - -# Or directly -deno run --allow-read --allow-write --allow-env --allow-net src/Index.mjs -``` - -## Implementation - -- **Language:** ReScript (compiles to JavaScript ES modules) -- **Runtime:** Deno (replaces Node.js/npm) -- **Modules:** - - `Types.res` - Type definitions - - `Manifest.res` - AI.a2ml parsing and validation - - `Session.res` - Session management - - `Guards.res` - Access control - - `Index.res` - MCP server and request handlers - -## Why ReScript + Deno? - -✅ **Policy Compliant:** -- ReScript is the primary application language (Hyperpolymath standard) -- Deno is the standard runtime (replaces Node.js/npm) -- No TypeScript or npm dependencies - -✅ **Type Safety:** -- ReScript provides ML-style type safety -- Catches errors at compile time -- Compiles to clean, readable JavaScript - -✅ **Modern Runtime:** -- Deno has built-in TypeScript support (for dependencies) -- Secure by default (explicit permissions) -- Native ES modules - -## Related - -- [AI Gatekeeper Protocol](https://github.com/hyperpolymath/0-ai-gatekeeper-protocol) - Complete documentation -- [FUSE Wrapper](https://github.com/hyperpolymath/repo-guardian-fs) - OS-level enforcement -- [rsr-template-repo](https://github.com/hyperpolymath/rsr-template-repo) - Template with AI.a2ml - -## License - -PMPL-1.0-or-later - -## Authors - -Jonathan D.A. Jewell - ---- - -**Status:** Production-ready. ReScript + Deno implementation complete. diff --git a/0-ai-gatekeeper-protocol/repo-guardian-fs/README.md b/0-ai-gatekeeper-protocol/repo-guardian-fs/README.md deleted file mode 100644 index a8b3519c..00000000 --- a/0-ai-gatekeeper-protocol/repo-guardian-fs/README.md +++ /dev/null @@ -1,290 +0,0 @@ -# Repository Guardian Filesystem - -**SPDX-License-Identifier: PMPL-1.0-or-later** - -FUSE filesystem wrapper that enforces AI.a2ml manifest acknowledgment before allowing file access in repositories. - -## Overview - -`repo-guardian-fs` provides **universal enforcement** of the AI Gatekeeper Protocol by mounting repositories through a virtual filesystem that: - -- ✅ Blocks ALL file operations until manifest acknowledged -- ✅ Works with ANY AI agent/tool (not just MCP-compatible) -- ✅ OS-level enforcement (cannot be bypassed) -- ✅ Session-based access control -- ✅ Automatic session timeout - -## How It Works - -``` -┌──────────────┐ -│ AI Agent │ → Attempts to read file -│ (any tool) │ -└──────┬───────┘ - │ - ↓ File access via /mnt/guarded-repos -┌──────────────────────────────┐ -│ Guardian Filesystem (FUSE) │ -│ "❌ EACCES - Not acknowledged"│ -└──────┬───────────────────────┘ - │ - ↓ Agent acknowledges via sideband -┌──────────────────────────────┐ -│ Session marked acknowledged │ -└──────┬───────────────────────┘ - │ - ↓ ✅ File access granted -┌──────────────┐ -│ Real Repos │ -└──────────────┘ -``` - -## Installation - -### Prerequisites - -- Rust 1.70+ (`rustup install stable`) -- FUSE3 (`sudo dnf install fuse3` on Fedora) -- Linux kernel with FUSE support - -### Build - -```bash -cargo build --release -``` - -### Install - -```bash -sudo cp target/release/repo-guardian-fs /usr/local/bin/ -``` - -## Usage - -### Basic Mount - -```bash -# Mount repos with enforcement -repo-guardian-fs \ - --source ~/Documents/hyperpolymath-repos \ - --mount /mnt/guarded-repos -``` - -### With Options - -```bash -# Strict mode, 1 hour session timeout, allow root -repo-guardian-fs \ - --source ~/Documents/hyperpolymath-repos \ - --mount /mnt/guarded-repos \ - --strict \ - --session-timeout 3600 \ - --allow-root -``` - -### Unmount - -```bash -fusermount3 -u /mnt/guarded-repos -``` - -## Access Control - -### Session Lifecycle - -1. **Initial Access** - Agent attempts to read file → `EACCES` (Permission denied) -2. **Acknowledgment** - Agent acknowledges manifest (via sideband mechanism) -3. **Granted Access** - Session marked as acknowledged -4. **Operations** - All file operations now allowed -5. **Timeout** - Session expires after inactivity - -### Acknowledgment Mechanism - -**Current Implementation:** Sessions auto-acknowledge for testing - -**Production TODO:** Implement sideband acknowledgment via: -- Unix domain socket (e.g., `/tmp/repo-guardian.sock`) -- Agent sends: `ACK ` -- Server validates hash and marks session acknowledged - -## Configuration - -### Command-Line Options - -| Option | Description | Default | -|--------|-------------|---------| -| `--source DIR` | Source directory with repos | Required | -| `--mount DIR` | Mount point | Required | -| `--strict` | Block ALL ops until ack | `true` | -| `--session-timeout SEC` | Session timeout seconds | `3600` | -| `--allow-root` | Allow root access | `false` | -| `--allow-other` | Allow other users | `false` | - -### Environment Variables - -- `RUST_LOG=info` - Set logging level (debug, info, warn, error) - -## Architecture - -### Components - -**manifest.rs** - Manifest parsing and validation -- Finds AI.a2ml files (0-AI-MANIFEST.a2ml, AI.a2ml, !AI.a2ml) -- Extracts canonical locations and invariants -- Computes SHA-256 hash for attestation - -**session_manager.rs** - Session tracking -- Creates sessions per process ID (UID) -- Tracks acknowledgment status -- Handles session timeout and cleanup - -**filesystem.rs** - FUSE implementation -- Intercepts all file operations -- Enforces acknowledgment check -- Passes through to real filesystem - -**main.rs** - Entry point -- Parses CLI arguments -- Mounts FUSE filesystem -- Handles signals and unmount - -### Security Model - -**Threat Model:** -- AI agents may attempt to bypass manifest reading -- Agents may fork processes to reset sessions -- Malicious tools may try to access repos directly - -**Mitigations:** -- OS-level enforcement - cannot bypass FUSE -- Per-session tracking - each process must acknowledge -- Timeout enforcement - stale sessions auto-expire -- Read-only mode (TODO) - prevent accidental writes - -## Limitations - -### Current Limitations - -1. **No write support** - Read-only enforcement -2. **Simple inode tracking** - All files report same inode -3. **Auto-acknowledgment** - Testing only, needs sideband -4. **No persistence** - Sessions lost on restart -5. **Basic error handling** - Needs improvement - -### Production TODOs - -- [ ] Implement sideband acknowledgment (Unix socket) -- [ ] Add write operation support -- [ ] Proper inode and file handle tracking -- [ ] Persistent session database -- [ ] Extended attributes support -- [ ] Symlink handling -- [ ] Performance optimization (caching) -- [ ] Comprehensive error handling -- [ ] Systemd service unit -- [ ] Configuration file support - -## Testing - -### Unit Tests - -```bash -cargo test -``` - -### Integration Test - -```bash -# Terminal 1: Mount filesystem -cargo run -- --source /tmp/test-repos --mount /tmp/test-mount - -# Terminal 2: Try to access -cd /tmp/test-mount -ls # Should work or be denied based on acknowledgment - -# Terminal 3: Unmount -fusermount3 -u /tmp/test-mount -``` - -## Comparison with MCP Server - -| Feature | MCP Server | FUSE Wrapper | -|---------|-----------|--------------| -| **Platform** | Claude + MCP-compatible | Universal | -| **Enforcement** | Tool-level | OS-level | -| **Bypass Risk** | Agent can use native FS | Cannot bypass | -| **Complexity** | Lower | Higher | -| **Performance** | Native | FUSE overhead | -| **Setup** | Config file | Mount command | - -**Recommendation:** Use MCP server for Claude, FUSE wrapper for other agents. - -## Integration - -### With Claude (MCP) - -Claude users should use `mcp-repo-guardian` for better integration. - -### With Other Agents - -Mount repos through guardian filesystem: - -```bash -repo-guardian-fs \ - --source ~/Documents/hyperpolymath-repos \ - --mount /mnt/guarded-repos - -# Point agent to /mnt/guarded-repos instead of real location -``` - -## Troubleshooting - -### Permission Denied - -**Symptom:** All operations return `EACCES` - -**Fix:** Check session acknowledgment status, ensure manifest exists - -### Mount Fails - -**Symptom:** `fusermount3: mount failed: Operation not permitted` - -**Fix:** Ensure FUSE installed, user has permissions, mount point exists - -### Performance Issues - -**Symptom:** Slow file access - -**Fix:** FUSE has overhead, consider MCP server for performance-critical use - -## Development - -### Building from Source - -```bash -git clone https://github.com/hyperpolymath/repo-guardian-fs -cd repo-guardian-fs -cargo build --release -``` - -### Contributing - -See `CONTRIBUTING.md` in the repository. - -## License - -PMPL-1.0-or-later - -## Related - -- [AI Gatekeeper Protocol](https://github.com/hyperpolymath/0-ai-gatekeeper-protocol) -- [MCP Repository Guardian](https://github.com/hyperpolymath/mcp-repo-guardian) -- [FUSE3 Library](https://crates.io/crates/fuse3) - -## Authors - -Jonathan D.A. Jewell - ---- - -**Status:** Alpha - Proof of concept implementation. Production use requires additional work (see TODOs above). diff --git a/avow-protocol/README.md b/avow-protocol/README.md deleted file mode 100644 index c565ae3b..00000000 --- a/avow-protocol/README.md +++ /dev/null @@ -1,237 +0,0 @@ -# AVOW Protocol - -[![Idris Inside](https://img.shields.io/badge/Idris-Inside-5E5086?style=flat&logo=idris&logoColor=white)](https://github.com/hyperpolymath/proven) -![Protocol Draft](https://img.shields.io/badge/Protocol-Draft-blue) - -Reference site and interactive demo for AVOW Protocol concepts (Authenticated Verifiable Open Web). - -## What It Does - -- Demonstrates AVOW flows end-to-end. -- Shows how verifiable consent and unsubscribe flows could work (demo-level checks). -- Ships a clean, static front end for easy hosting. - -## Where It Is Going - -- Expand the demo to cover more protocol paths. -- Add integration examples for production systems. -- Improve visualization and accessibility of consent flows. -- Publish a full protocol spec with test vectors. - -## Protocol Draft - -See `docs/PROTOCOL.md` for the draft protocol definition and current scope. - -## Architecture - -AVOW Protocol uses a layered architecture with formal verification at every level: - -### Frontend Stack - -- **casket-ssg** - Pure functional Haskell static site generator with compile-time template validation -- **cadre-tea-router** - TEA-specialized routing with type-safe URL parsing/formatting -- **rescript-tea** - The Elm Architecture for ReScript with guaranteed state consistency -- **rescript-dom-mounter** - Formally verified DOM mounting with mathematical guarantees -- **ReScript** - Type-safe compilation to JavaScript -- **Deno** - Build and task runner (replaces Node.js/npm) - -### Cryptography (Post-Quantum) - -- **Dilithium5-AES** - Post-quantum signatures (ML-DSA-87, FIPS 204) -- **Kyber-1024** - Post-quantum key exchange (ML-KEM-1024, FIPS 203) -- **SHAKE3-512** - Post-quantum hashing (FIPS 202) -- **XChaCha20-Poly1305** - Symmetric encryption with 256-bit keys -- **Ed448 + Dilithium5** - Hybrid classical+PQ signatures -- **SPHINCS+** - Conservative fallback for all PQ operations - -### Formal Verification Stack - -- **Idris2** - ABI definitions with dependent type proofs (src/abi/) -- **Zig** - FFI implementation with C ABI compatibility (ffi/zig/) -- **proven** - Idris2 formally verified library for URL validation -- **Coq/Isabelle** - Verification of cryptographic primitives - -### Deployment & Security - -- **Cloudflare Pages** - Static site hosting with global CDN -- **Cloudflare Zero Trust** - Zero Trust/SDP for internal services -- **WASM Proxy** - Request filtering and validation at edge -- **QUIC + HTTP/3** - Modern protocol stack (IPv4/HTTP1.1 terminated) - -### Formally Verified Components - -This application uses multiple layers of formal verification: - -#### rescript-dom-mounter - -- **No Null Pointer Dereferences** - Element existence proven before access -- **No Invalid Selectors** - CSS selector validation at compile time -- **No Malformed HTML** - Balanced tag checking with dependent types -- **Type-Safe Operations** - All DOM operations proven correct -- **Atomic Batch Mounting** - All-or-nothing guarantees - -#### proven (URL validation) - -- **ProvenSafeUrl** - URL parsing with mathematical proofs of correctness -- **ProvenResult** - Type-safe error handling -- **No XSS via URLs** - Security properties proven at compile time -- **No runtime URL parsing errors** - Invalid URLs cannot compile - -#### cadre-tea-router - -- **Type-safe routing** - Route definitions checked at compile time -- **Exhaustive pattern matching** - All routes handled, no 404 bugs -- **URL format correctness** - URLs proven well-formed before generation - -#### libavow (Idris2 + Zig) - -- **Message compliance** - Protocol properties proven at compile time -- **Crypto correctness** - Signatures, key exchange verified -- **No buffer overflows** - Memory safety guaranteed -- **Time-ordering proofs** - Consent chains mathematically ordered - -## Development - -### Prerequisites - -- [Deno](https://deno.com/) v2.0+ -- ReScript ^12.1.0 (auto-installed via Deno) - -### Build - -```bash -# Build ReScript to JavaScript -deno task build - -# Watch mode for development -deno task watch - -# Clean build artifacts -deno task clean -``` - -### Local Development - -```bash -# Serve with any static server -deno run -A jsr:@std/http/file-server . - -# Or use Python -python3 -m http.server 8000 - -# Or open directly -open index.html -``` - -## Features - -### Current Implementation (2026-01-30) - -- **Interactive AVOW Demo** - Step-through demonstration -- **URL Validation** - Demonstrates safe URL checks using build-time proofs -- **Real-time Validation** - Instant feedback on URL correctness -- **TEA Architecture** - Predictable state management - -### Security Features - -- **HTTPS-only** - Enforced for all unsubscribe URLs -- **Proven Validation** - Mathematical proofs prevent malformed URLs -- **No XSS** - Formally verified URL handling -- **CSP Headers** - Content Security Policy (see .well-known/) - -## Project Status - -- ✅ ReScript compilation with Deno -- ✅ proven integration for URL validation -- ✅ AvowApp.res with formal verification -- ✅ Security hardening (.well-known/, headers, DNS) -- ⏳ Full TEA integration (basic render function) -- ⏳ Interactive UI with DOM mounting -- ⏳ Visual consent flow diagram -- ⏳ API integration examples - -## Deploy to Cloudflare Pages - -### Web UI Method - -1. Go to https://pages.cloudflare.com/ -2. Connect `avow-protocol` repository -3. Build settings: - - Framework: **None** (pre-built ReScript) - - Build command: `deno task build` - - Output directory: `/` -4. Custom domain: `avow-protocol.org` - -### CLI Method - -```bash -# Build first -deno task build - -# Deploy with Wrangler -wrangler pages deploy . --project-name=avow-protocol -``` - -## Domain & DNS Setup - -### Cloudflare DNS Records - -``` -CNAME @ avow-protocol.pages.dev (Proxied) -CAA @ 0 issue "letsencrypt.org" -CAA @ 0 issue "pki.goog" -TXT @ "v=spf1 -all" -``` - -### Security Headers (Cloudflare) - -See `.well-known/security.txt` for full configuration. - -- HSTS max-age=31536000 -- CSP: default-src 'self' -- X-Frame-Options: DENY -- COEP, COOP, CORP headers - -## File Structure - -``` -avow-protocol/ -├── src/ -│ ├── AvowApp.res # Main TEA application -│ ├── ProvenResult.res # Result type for error handling -│ ├── ProvenSafeUrl.res # Proven URL validation -│ └── Tea.res # Minimal TEA runtime -├── deno.json # Deno configuration & tasks -├── rescript.json # ReScript compiler config -├── index.html # HTML entry point -├── style.css # Styles -└── .well-known/ # Security & standards - ├── security.txt - └── change-password -``` - -## Performance - -- **Target: 100/100 Lighthouse** -- Zero external dependencies (after build) -- Compiled ReScript (no runtime transpilation) -- Vanilla CSS (no framework bloat) -- Mobile-first responsive design - -## SEO & Standards - -- ✅ Semantic HTML5 -- ✅ Meta descriptions -- ✅ Open Graph tags -- ✅ RFC 9116 security.txt -- ✅ Structured data (Schema.org) - -## License - -PMPL-1.0-or-later - -## Related Projects - -- [rescript-tea](https://github.com/hyperpolymath/rescript-tea) - TEA architecture (now with proven) -- [cadre-tea-router](https://github.com/hyperpolymath/cadre-tea-router) - Routing (now with proven) -- [proven](https://github.com/hyperpolymath/proven) - Idris2 formally verified library diff --git a/avow-protocol/telegram-bot/README.md b/avow-protocol/telegram-bot/README.md deleted file mode 100644 index f0628935..00000000 --- a/avow-protocol/telegram-bot/README.md +++ /dev/null @@ -1,330 +0,0 @@ -# STAMP Telegram Bot - -A proof-of-concept Telegram bot demonstrating the STAMP (Secure Typed Announcement Messaging Protocol) verification system. - -**Status:** MVP (uses mock verification, will integrate real libstamp in Week 2) - -## Features - -- ✓ **Verified Subscriptions** - Cryptographically proven consent chains -- ✓ **Guaranteed Unsubscribe** - One-click unsubscribe with verification proof -- ✓ **Rate Limiting** - Protocol-enforced message limits -- ✓ **Proof Display** - Users can see cryptographic proofs for all actions -- ✓ **Demo Messages** - Periodic verified messages to test the system - -## Quick Start - -### 1. Prerequisites - -- Deno 1.40+ installed (https://deno.land) -- Telegram account -- 5 minutes - -### 2. Create Telegram Bot - -1. Open Telegram and search for `@BotFather` -2. Send `/newbot` -3. Choose a name (e.g., "STAMP Demo Bot") -4. Choose a username (e.g., "stamp_demo_bot") -5. Copy the bot token (looks like `1234567890:ABCdefGHIjklMNOpqrsTUVwxyz`) - -### 3. Configure Bot - -```bash -cd ~/Documents/hyperpolymath-repos/stamp-telegram-bot - -# Create .env file -cp .env.example .env - -# Edit .env and add your bot token -nano .env -# Replace 'your_bot_token_here' with your actual token -``` - -### 4. Run Bot - -```bash -# Install dependencies and run -deno task start -``` - -You should see: -``` -🤖 STAMP Telegram Bot starting... -✓ Bot initialized -✓ Database connected -✓ Demo messages scheduled (every hour) - -🚀 Bot is now running! -``` - -### 5. Test Bot - -1. Open Telegram -2. Search for your bot username (e.g., `@stamp_demo_bot`) -3. Send `/start` -4. Try the commands: - - `/verify` - See proof for last message - - `/status` - Show subscription details - - `/unsubscribe` - Unsubscribe (one-click, proven) - -## Commands - -| Command | Description | -|---------|-------------| -| `/start` | Subscribe to demo messages (creates verified consent chain) | -| `/verify` | Show cryptographic proof for last message | -| `/status` | Show subscription status and consent chain | -| `/unsubscribe` | Unsubscribe with proof of removal | -| `/help` | Show help message | - -## Development - -### Run in Development Mode (Auto-Reload) - -```bash -deno task dev -``` - -### Project Structure - -``` -stamp-telegram-bot/ -├── src/ -│ ├── bot.ts # Main bot logic -│ ├── database.ts # SQLite database layer -│ └── stamp-mock.ts # Mock STAMP verification (temporary) -├── db/ -│ └── stamp-bot.db # SQLite database (created on first run) -├── deno.json # Deno configuration -├── .env # Environment variables (not in git) -└── README.md # This file -``` - -### Mock vs. Real Verification - -**Current (Week 1):** Uses `stamp-mock.ts` -- Implements STAMP interface without dependent type proofs -- Good enough to demo UX and prove concept -- Fast to build and iterate - -**Week 2:** Will integrate real `libstamp` -- Idris2 dependent type proofs -- Zig FFI for performance -- Cryptographically signed proofs -- Just swap `stamp-mock.ts` for `stamp-ffi.ts` - -## Deployment - -### Option 1: Local (For Testing) - -```bash -# Run locally -deno task start - -# Keep running (use screen or tmux) -screen -S stamp-bot -deno task start -# Ctrl+A, D to detach -``` - -### Option 2: fly.io (Recommended) - -```bash -# Install flyctl -curl -L https://fly.io/install.sh | sh - -# Login -fly auth login - -# Create app -fly launch -# Choose name: stamp-telegram-bot -# Choose region: closest to you -# Don't deploy yet - -# Set secrets -fly secrets set BOT_TOKEN=your_bot_token_here - -# Deploy -fly deploy - -# Check status -fly status - -# View logs -fly logs -``` - -### Option 3: Docker - -```bash -# Build image -docker build -t stamp-bot . - -# Run container -docker run -d \ - --name stamp-bot \ - -e BOT_TOKEN=your_bot_token_here \ - -v $(pwd)/db:/app/db \ - stamp-bot - -# View logs -docker logs -f stamp-bot -``` - -## Testing - -### Manual Testing Checklist - -- [ ] `/start` - Subscribe successfully -- [ ] Receive demo message with proof -- [ ] `/verify` - See cryptographic proof -- [ ] `/status` - See subscription details -- [ ] `/unsubscribe` - Unsubscribe successfully -- [ ] Verify no more messages received after unsubscribe -- [ ] `/start` again - Can re-subscribe - -### Expected Behavior - -**After `/start`:** -``` -✓ Subscription Confirmed - -Consent Chain Verified: -└─ Requested: 2026-01-30T10:00:00.000Z -└─ Confirmed: /start command (explicit) -└─ Token: 1234567890_abc123... -└─ Proof: Cryptographically signed ✓ - -You will receive demo messages periodically. -Each message includes STAMP verification. -``` - -**After `/verify`:** -``` -🔒 STAMP Verification Proof - -Message: Weekly STAMP Demo Update -Sent: 2026-01-30T11:00:00.000Z - -Verification Details: -{ - "type": "unsubscribe_verification", - "data": { ... }, - "timestamp": 1706698800000, - "signature": "mock_sig_..." -} - -✓ This proof is cryptographically signed -✓ Cannot be forged or tampered with -✓ Verifiable by anyone -``` - -**After `/unsubscribe`:** -``` -✓ Unsubscribed Successfully - -Proof of Removal: -└─ Removed: 2026-01-30T11:05:00.000Z -└─ Latency: 87ms -└─ Status: Confirmed ✓ -└─ Signature: sig_1706699100_30_abc... - -You will NOT receive future messages. -(This is mathematically proven ✓) -``` - -## Demo Script (For Showing Investors/Users) - -1. **Show the problem:** - - "Current email: unsubscribe often doesn't work" - - "No proof consent was given" - - "No way to verify sender is legitimate" - -2. **Demo STAMP bot:** - - Subscribe: `/start` - - Show consent chain with proof - - Receive message - - Show verification: `/verify` - - Unsubscribe: `/unsubscribe` - - Show proof of removal - -3. **Key points:** - - "Consent is cryptographically proven" - - "Unsubscribe is tested and proven to work" - - "All actions include verifiable proofs" - - "This is just a demo - works with email, social media, etc." - -## Roadmap - -### Week 1 (Current) ✓ -- [x] Mock verification library -- [x] Telegram bot with all commands -- [x] SQLite database -- [x] Demo messages -- [x] Deployment instructions - -### Week 2 (Next) -- [ ] Integrate real libstamp (Idris2 + Zig FFI) -- [ ] Real cryptographic signatures -- [ ] Actual HTTP testing of unsubscribe URLs -- [ ] Performance benchmarks - -### Week 3-4 (Future) -- [ ] Demo website showing proofs -- [ ] Multi-language support -- [ ] Admin dashboard -- [ ] Metrics/analytics - -## Troubleshooting - -### Bot doesn't start - -**Error: "BOT_TOKEN environment variable not set"** -- Solution: Create `.env` file with your bot token - -**Error: "Connection refused"** -- Solution: Check internet connection -- Solution: Verify bot token is correct - -### Bot doesn't respond to commands - -**Check bot is running:** -```bash -# Should see "Bot is now running!" -``` - -**Check bot username:** -- Make sure you're messaging the correct bot -- Username must match what you set in @BotFather - -**Check permissions:** -- Bot needs to receive messages -- In groups, bot needs admin rights - -### Database errors - -**Error: "Permission denied"** -- Solution: `chmod +x db/` -- Solution: Run bot with `--allow-write` - -**Reset database:** -```bash -rm db/stamp-bot.db -# Restart bot (will recreate) -``` - -## License - -PMPL-1.0-or-later - -## Author - -Jonathan D.A. Jewell - -## Learn More - -- STAMP Protocol: https://github.com/hyperpolymath/libstamp -- Roadmap: https://github.com/hyperpolymath/libstamp/blob/main/ROADMAP.md -- Telegram Bot API: https://core.telegram.org/bots diff --git a/avow-protocol/telegram-bot/SECURITY.md b/avow-protocol/telegram-bot/SECURITY.md index 6ea98768..7e0cf11f 100644 --- a/avow-protocol/telegram-bot/SECURITY.md +++ b/avow-protocol/telegram-bot/SECURITY.md @@ -385,7 +385,7 @@ When using Standards, we recommend: |---------|---------| | **Security issues** | [Report via GitHub](https://github.com/hyperpolymath/standards/security/advisories/new) or 6759885+hyperpolymath@users.noreply.github.com | | **General questions** | [GitHub Discussions](https://github.com/hyperpolymath/standards/discussions) | -| **Other enquiries** | See [README](README.md) for contact information | +| **Other enquiries** | See [README](README.adoc) for contact information | --- diff --git a/avow-protocol/telegram-bot/avow-telegram-bot/README.md b/avow-protocol/telegram-bot/avow-telegram-bot/README.md deleted file mode 100644 index f0628935..00000000 --- a/avow-protocol/telegram-bot/avow-telegram-bot/README.md +++ /dev/null @@ -1,330 +0,0 @@ -# STAMP Telegram Bot - -A proof-of-concept Telegram bot demonstrating the STAMP (Secure Typed Announcement Messaging Protocol) verification system. - -**Status:** MVP (uses mock verification, will integrate real libstamp in Week 2) - -## Features - -- ✓ **Verified Subscriptions** - Cryptographically proven consent chains -- ✓ **Guaranteed Unsubscribe** - One-click unsubscribe with verification proof -- ✓ **Rate Limiting** - Protocol-enforced message limits -- ✓ **Proof Display** - Users can see cryptographic proofs for all actions -- ✓ **Demo Messages** - Periodic verified messages to test the system - -## Quick Start - -### 1. Prerequisites - -- Deno 1.40+ installed (https://deno.land) -- Telegram account -- 5 minutes - -### 2. Create Telegram Bot - -1. Open Telegram and search for `@BotFather` -2. Send `/newbot` -3. Choose a name (e.g., "STAMP Demo Bot") -4. Choose a username (e.g., "stamp_demo_bot") -5. Copy the bot token (looks like `1234567890:ABCdefGHIjklMNOpqrsTUVwxyz`) - -### 3. Configure Bot - -```bash -cd ~/Documents/hyperpolymath-repos/stamp-telegram-bot - -# Create .env file -cp .env.example .env - -# Edit .env and add your bot token -nano .env -# Replace 'your_bot_token_here' with your actual token -``` - -### 4. Run Bot - -```bash -# Install dependencies and run -deno task start -``` - -You should see: -``` -🤖 STAMP Telegram Bot starting... -✓ Bot initialized -✓ Database connected -✓ Demo messages scheduled (every hour) - -🚀 Bot is now running! -``` - -### 5. Test Bot - -1. Open Telegram -2. Search for your bot username (e.g., `@stamp_demo_bot`) -3. Send `/start` -4. Try the commands: - - `/verify` - See proof for last message - - `/status` - Show subscription details - - `/unsubscribe` - Unsubscribe (one-click, proven) - -## Commands - -| Command | Description | -|---------|-------------| -| `/start` | Subscribe to demo messages (creates verified consent chain) | -| `/verify` | Show cryptographic proof for last message | -| `/status` | Show subscription status and consent chain | -| `/unsubscribe` | Unsubscribe with proof of removal | -| `/help` | Show help message | - -## Development - -### Run in Development Mode (Auto-Reload) - -```bash -deno task dev -``` - -### Project Structure - -``` -stamp-telegram-bot/ -├── src/ -│ ├── bot.ts # Main bot logic -│ ├── database.ts # SQLite database layer -│ └── stamp-mock.ts # Mock STAMP verification (temporary) -├── db/ -│ └── stamp-bot.db # SQLite database (created on first run) -├── deno.json # Deno configuration -├── .env # Environment variables (not in git) -└── README.md # This file -``` - -### Mock vs. Real Verification - -**Current (Week 1):** Uses `stamp-mock.ts` -- Implements STAMP interface without dependent type proofs -- Good enough to demo UX and prove concept -- Fast to build and iterate - -**Week 2:** Will integrate real `libstamp` -- Idris2 dependent type proofs -- Zig FFI for performance -- Cryptographically signed proofs -- Just swap `stamp-mock.ts` for `stamp-ffi.ts` - -## Deployment - -### Option 1: Local (For Testing) - -```bash -# Run locally -deno task start - -# Keep running (use screen or tmux) -screen -S stamp-bot -deno task start -# Ctrl+A, D to detach -``` - -### Option 2: fly.io (Recommended) - -```bash -# Install flyctl -curl -L https://fly.io/install.sh | sh - -# Login -fly auth login - -# Create app -fly launch -# Choose name: stamp-telegram-bot -# Choose region: closest to you -# Don't deploy yet - -# Set secrets -fly secrets set BOT_TOKEN=your_bot_token_here - -# Deploy -fly deploy - -# Check status -fly status - -# View logs -fly logs -``` - -### Option 3: Docker - -```bash -# Build image -docker build -t stamp-bot . - -# Run container -docker run -d \ - --name stamp-bot \ - -e BOT_TOKEN=your_bot_token_here \ - -v $(pwd)/db:/app/db \ - stamp-bot - -# View logs -docker logs -f stamp-bot -``` - -## Testing - -### Manual Testing Checklist - -- [ ] `/start` - Subscribe successfully -- [ ] Receive demo message with proof -- [ ] `/verify` - See cryptographic proof -- [ ] `/status` - See subscription details -- [ ] `/unsubscribe` - Unsubscribe successfully -- [ ] Verify no more messages received after unsubscribe -- [ ] `/start` again - Can re-subscribe - -### Expected Behavior - -**After `/start`:** -``` -✓ Subscription Confirmed - -Consent Chain Verified: -└─ Requested: 2026-01-30T10:00:00.000Z -└─ Confirmed: /start command (explicit) -└─ Token: 1234567890_abc123... -└─ Proof: Cryptographically signed ✓ - -You will receive demo messages periodically. -Each message includes STAMP verification. -``` - -**After `/verify`:** -``` -🔒 STAMP Verification Proof - -Message: Weekly STAMP Demo Update -Sent: 2026-01-30T11:00:00.000Z - -Verification Details: -{ - "type": "unsubscribe_verification", - "data": { ... }, - "timestamp": 1706698800000, - "signature": "mock_sig_..." -} - -✓ This proof is cryptographically signed -✓ Cannot be forged or tampered with -✓ Verifiable by anyone -``` - -**After `/unsubscribe`:** -``` -✓ Unsubscribed Successfully - -Proof of Removal: -└─ Removed: 2026-01-30T11:05:00.000Z -└─ Latency: 87ms -└─ Status: Confirmed ✓ -└─ Signature: sig_1706699100_30_abc... - -You will NOT receive future messages. -(This is mathematically proven ✓) -``` - -## Demo Script (For Showing Investors/Users) - -1. **Show the problem:** - - "Current email: unsubscribe often doesn't work" - - "No proof consent was given" - - "No way to verify sender is legitimate" - -2. **Demo STAMP bot:** - - Subscribe: `/start` - - Show consent chain with proof - - Receive message - - Show verification: `/verify` - - Unsubscribe: `/unsubscribe` - - Show proof of removal - -3. **Key points:** - - "Consent is cryptographically proven" - - "Unsubscribe is tested and proven to work" - - "All actions include verifiable proofs" - - "This is just a demo - works with email, social media, etc." - -## Roadmap - -### Week 1 (Current) ✓ -- [x] Mock verification library -- [x] Telegram bot with all commands -- [x] SQLite database -- [x] Demo messages -- [x] Deployment instructions - -### Week 2 (Next) -- [ ] Integrate real libstamp (Idris2 + Zig FFI) -- [ ] Real cryptographic signatures -- [ ] Actual HTTP testing of unsubscribe URLs -- [ ] Performance benchmarks - -### Week 3-4 (Future) -- [ ] Demo website showing proofs -- [ ] Multi-language support -- [ ] Admin dashboard -- [ ] Metrics/analytics - -## Troubleshooting - -### Bot doesn't start - -**Error: "BOT_TOKEN environment variable not set"** -- Solution: Create `.env` file with your bot token - -**Error: "Connection refused"** -- Solution: Check internet connection -- Solution: Verify bot token is correct - -### Bot doesn't respond to commands - -**Check bot is running:** -```bash -# Should see "Bot is now running!" -``` - -**Check bot username:** -- Make sure you're messaging the correct bot -- Username must match what you set in @BotFather - -**Check permissions:** -- Bot needs to receive messages -- In groups, bot needs admin rights - -### Database errors - -**Error: "Permission denied"** -- Solution: `chmod +x db/` -- Solution: Run bot with `--allow-write` - -**Reset database:** -```bash -rm db/stamp-bot.db -# Restart bot (will recreate) -``` - -## License - -PMPL-1.0-or-later - -## Author - -Jonathan D.A. Jewell - -## Learn More - -- STAMP Protocol: https://github.com/hyperpolymath/libstamp -- Roadmap: https://github.com/hyperpolymath/libstamp/blob/main/ROADMAP.md -- Telegram Bot API: https://core.telegram.org/bots diff --git a/avow-protocol/telegram-bot/avow-telegram-bot/SECURITY.md b/avow-protocol/telegram-bot/avow-telegram-bot/SECURITY.md index 6ea98768..7e0cf11f 100644 --- a/avow-protocol/telegram-bot/avow-telegram-bot/SECURITY.md +++ b/avow-protocol/telegram-bot/avow-telegram-bot/SECURITY.md @@ -385,7 +385,7 @@ When using Standards, we recommend: |---------|---------| | **Security issues** | [Report via GitHub](https://github.com/hyperpolymath/standards/security/advisories/new) or 6759885+hyperpolymath@users.noreply.github.com | | **General questions** | [GitHub Discussions](https://github.com/hyperpolymath/standards/discussions) | -| **Other enquiries** | See [README](README.md) for contact information | +| **Other enquiries** | See [README](README.adoc) for contact information | --- diff --git a/consent-aware-http/CODE_OF_CONDUCT.md b/consent-aware-http/CODE_OF_CONDUCT.md index 4c75ed4a..aab1bdc6 100644 --- a/consent-aware-http/CODE_OF_CONDUCT.md +++ b/consent-aware-http/CODE_OF_CONDUCT.md @@ -63,7 +63,7 @@ Because this project centers on **consent, boundary, and ethical refusal**, we h ## Enforcement Responsibilities -Community leaders (see [MAINTAINERS.md](MAINTAINERS.md)) are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful. +Community leaders (see [MAINTAINERS.md](MAINTAINERS.adoc)) are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful. Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned with this Code of Conduct, and will communicate reasons for moderation decisions when appropriate. diff --git a/consent-aware-http/CONTRIBUTING.md b/consent-aware-http/CONTRIBUTING.md deleted file mode 100644 index 8c9d97b7..00000000 --- a/consent-aware-http/CONTRIBUTING.md +++ /dev/null @@ -1,116 +0,0 @@ -# Clone the repository -git clone https://github.com/hyperpolymath/standards.git -cd standards - -# Using Nix (recommended for reproducibility) -nix develop - -# Or using toolbox/distrobox -toolbox create standards-dev -toolbox enter standards-dev -# Install dependencies manually - -# Verify setup -just check # or: cargo check / mix compile / etc. -just test # Run test suite -``` - -### Repository Structure -``` -standards/ -├── src/ # Source code (Perimeter 1-2) -├── lib/ # Library code (Perimeter 1-2) -├── extensions/ # Extensions (Perimeter 2) -├── plugins/ # Plugins (Perimeter 2) -├── tools/ # Tooling (Perimeter 2) -├── docs/ # Documentation (Perimeter 3) -│ ├── architecture/ # ADRs, specs (Perimeter 2) -│ └── proposals/ # RFCs (Perimeter 3) -├── examples/ # Examples (Perimeter 3) -├── spec/ # Spec tests (Perimeter 3) -├── tests/ # Test suite (Perimeter 2-3) -├── .well-known/ # Protocol files (Perimeter 1-3) -├── .github/ # GitHub config (Perimeter 1) -│ ├── ISSUE_TEMPLATE/ -│ └── workflows/ -├── CHANGELOG.md -├── CODE_OF_CONDUCT.md -├── CONTRIBUTING.md # This file -├── GOVERNANCE.md -├── LICENSE -├── MAINTAINERS.md -├── README.adoc -├── SECURITY.md -├── flake.nix # Nix flake (Perimeter 1) -└── Justfile # Task runner (Perimeter 1) -``` - ---- - -## How to Contribute - -### Reporting Bugs - -**Before reporting**: -1. Search existing issues -2. Check if it's already fixed in `main` -3. Determine which perimeter the bug affects - -**When reporting**: - -Use the [bug report template](.github/ISSUE_TEMPLATE/bug_report.md) and include: - -- Clear, descriptive title -- Environment details (OS, versions, toolchain) -- Steps to reproduce -- Expected vs actual behaviour -- Logs, screenshots, or minimal reproduction - -### Suggesting Features - -**Before suggesting**: -1. Check the [roadmap](ROADMAP.md) if available -2. Search existing issues and discussions -3. Consider which perimeter the feature belongs to - -**When suggesting**: - -Use the [feature request template](.github/ISSUE_TEMPLATE/feature_request.md) and include: - -- Problem statement (what pain point does this solve?) -- Proposed solution -- Alternatives considered -- Which perimeter this affects - -### Your First Contribution - -Look for issues labelled: - -- [`good first issue`](https://github.com/hyperpolymath/standards/labels/good%20first%20issue) — Simple Perimeter 3 tasks -- [`help wanted`](https://github.com/hyperpolymath/standards/labels/help%20wanted) — Community help needed -- [`documentation`](https://github.com/hyperpolymath/standards/labels/documentation) — Docs improvements -- [`perimeter-3`](https://github.com/hyperpolymath/standards/labels/perimeter-3) — Community sandbox scope - ---- - -## Development Workflow - -### Branch Naming -``` -docs/short-description # Documentation (P3) -test/what-added # Test additions (P3) -feat/short-description # New features (P2) -fix/issue-number-description # Bug fixes (P2) -refactor/what-changed # Code improvements (P2) -security/what-fixed # Security fixes (P1-2) -``` - -### Commit Messages - -We follow [Conventional Commits](https://www.conventionalcommits.org/): -``` -(): - -[optional body] - -[optional footer] diff --git a/consent-aware-http/MAINTAINERS.adoc b/consent-aware-http/MAINTAINERS.adoc index ac120fa4..91ca219f 100644 --- a/consent-aware-http/MAINTAINERS.adoc +++ b/consent-aware-http/MAINTAINERS.adoc @@ -1,4 +1,118 @@ // SPDX-License-Identifier: PMPL-1.0-or-later + +== Maintainers + +This document lists the individuals responsible for maintaining and governing the Consent-Aware HTTP Standards project. + +=== Lead Maintainer + +*Jonathan D.A. Jewell* + +* Role: Primary Author, Protocol Designer, Ethics Convenor +* Affiliation: NEC PRC Representative, NUJ Ethics Council +* Working Group: AI & Data Working Group (Convenor) +* Contact: jonathan@metadatastician.art +* GitHub: @Hyperpolymath +* Areas: Protocol specification (HTTP 430, AIBDP), ethical framework, IETF coordination, cultural theory integration + +=== Responsibilities + +==== Lead Maintainer + +* Oversee Internet-Draft revisions and IETF submission process +* Maintain philosophical and ethical coherence across documentation +* Review and merge pull requests +* Coordinate with standards bodies (IETF, W3C) +* Engage with community (IndieWeb, Fediverse, academic researchers) +* Ensure alignment with journalism ethics and consent theory + +==== Community Maintainers (Open) + +This project welcomes co-maintainers who demonstrate: + +* Deep understanding of consent-aware protocols +* Commitment to ethical infrastructure +* Technical expertise in web standards +* Alignment with project philosophy (boundary as dignity, declarative refusal) + +To express interest in co-maintainership, please: + +[arabic] +. Make substantial contributions (3{plus} merged PRs or significant documentation) +. Demonstrate understanding of cultural/ethical framework +. Open a Discussion thread proposing your maintainership scope + +=== Governance Model + +*Benevolent Dictator Temporarily (BDT)*: Jonathan D.A. Jewell holds final decision authority on: + +* Internet-Draft content and submission +* Core protocol design +* Ethical framework integrity +* Project direction and scope + +*Community Input*: All technical decisions should involve community discussion via: + +* GitHub Issues for bugs and feature requests +* GitHub Discussions for philosophical and strategic topics +* Pull Request reviews for implementation feedback + +*Transition to Committee*: As the project matures, governance may transition to a steering committee representing: + +* Technical implementers +* Ethics/policy experts +* Federated web community representatives +* IETF working group participants + +=== Decision-Making Process + +[arabic] +. *Protocol Changes* (HTTP 430, AIBDP core spec) +* Requires lead maintainer approval +* Should align with IETF standards process +* Must preserve ethical coherence +. *Documentation Updates* +* Can be approved by any maintainer +* Should maintain philosophical consistency +* Require clear, principled language +. *Reference Implementations* +* Community-driven with maintainer review +* Must meet security and correctness standards +* Should demonstrate compliance examples +. *Outreach Materials* +* Require alignment with project values +* Should be accessible yet principled +* Community contributions strongly encouraged + +=== Contact + +* *General Inquiries*: Open a GitHub Discussion +* *Security Issues*: See link:.github/SECURITY.md[SECURITY.md] +* *Private Communications*: jonathan@metadatastician.art +* *Community Discussion*: GitHub Discussions + +=== Attribution + +This project builds on work by: + +* IndieWeb community (federated publishing) +* Journalism ethics traditions (NUJ, SPJ) +* Critical theorists (bell hooks, Virginia Woolf) +* Web standards bodies (IETF, W3C) + +''''' + +_"Boundary is where meaning begins." - bell hooks_ + +This document reflects a commitment to transparent governance and collective care for ethical infrastructure. + +//// +Appendix preserved verbatim from the legacy .adoc during the +Item 11 .md/.adoc consolidation (Day 10 lossy-tail). 49 legacy-only +content tokens were not present in the converted Markdown source; +retained here so nothing is lost. Reviewer may de-duplicate prose. +//// + = Maintainers :toc: preamble diff --git a/consent-aware-http/MAINTAINERS.md b/consent-aware-http/MAINTAINERS.md deleted file mode 100644 index cdaee06d..00000000 --- a/consent-aware-http/MAINTAINERS.md +++ /dev/null @@ -1,97 +0,0 @@ -# Maintainers - -This document lists the individuals responsible for maintaining and governing the Consent-Aware HTTP Standards project. - -## Lead Maintainer - -**Jonathan D.A. Jewell** -- Role: Primary Author, Protocol Designer, Ethics Convenor -- Affiliation: NEC PRC Representative, NUJ Ethics Council -- Working Group: AI & Data Working Group (Convenor) -- Contact: jonathan@metadatastician.art -- GitHub: @Hyperpolymath -- Areas: Protocol specification (HTTP 430, AIBDP), ethical framework, IETF coordination, cultural theory integration - -## Responsibilities - -### Lead Maintainer -- Oversee Internet-Draft revisions and IETF submission process -- Maintain philosophical and ethical coherence across documentation -- Review and merge pull requests -- Coordinate with standards bodies (IETF, W3C) -- Engage with community (IndieWeb, Fediverse, academic researchers) -- Ensure alignment with journalism ethics and consent theory - -### Community Maintainers (Open) -This project welcomes co-maintainers who demonstrate: -- Deep understanding of consent-aware protocols -- Commitment to ethical infrastructure -- Technical expertise in web standards -- Alignment with project philosophy (boundary as dignity, declarative refusal) - -To express interest in co-maintainership, please: -1. Make substantial contributions (3+ merged PRs or significant documentation) -2. Demonstrate understanding of cultural/ethical framework -3. Open a Discussion thread proposing your maintainership scope - -## Governance Model - -**Benevolent Dictator Temporarily (BDT)**: Jonathan D.A. Jewell holds final decision authority on: -- Internet-Draft content and submission -- Core protocol design -- Ethical framework integrity -- Project direction and scope - -**Community Input**: All technical decisions should involve community discussion via: -- GitHub Issues for bugs and feature requests -- GitHub Discussions for philosophical and strategic topics -- Pull Request reviews for implementation feedback - -**Transition to Committee**: As the project matures, governance may transition to a steering committee representing: -- Technical implementers -- Ethics/policy experts -- Federated web community representatives -- IETF working group participants - -## Decision-Making Process - -1. **Protocol Changes** (HTTP 430, AIBDP core spec) - - Requires lead maintainer approval - - Should align with IETF standards process - - Must preserve ethical coherence - -2. **Documentation Updates** - - Can be approved by any maintainer - - Should maintain philosophical consistency - - Require clear, principled language - -3. **Reference Implementations** - - Community-driven with maintainer review - - Must meet security and correctness standards - - Should demonstrate compliance examples - -4. **Outreach Materials** - - Require alignment with project values - - Should be accessible yet principled - - Community contributions strongly encouraged - -## Contact - -- **General Inquiries**: Open a GitHub Discussion -- **Security Issues**: See [SECURITY.md](.github/SECURITY.md) -- **Private Communications**: jonathan@metadatastician.art -- **Community Discussion**: GitHub Discussions - -## Attribution - -This project builds on work by: -- IndieWeb community (federated publishing) -- Journalism ethics traditions (NUJ, SPJ) -- Critical theorists (bell hooks, Virginia Woolf) -- Web standards bodies (IETF, W3C) - ---- - -_"Boundary is where meaning begins." - bell hooks_ - -This document reflects a commitment to transparent governance and collective care for ethical infrastructure. diff --git a/lol/CONTRIBUTING.md b/lol/CONTRIBUTING.md deleted file mode 100644 index 77b63719..00000000 --- a/lol/CONTRIBUTING.md +++ /dev/null @@ -1,116 +0,0 @@ -# Clone the repository -git clone https://github.com/hyperpolymath/lol.git -cd lol - -# Using Nix (recommended for reproducibility) -nix develop - -# Or using toolbox/distrobox -toolbox create lol-dev -toolbox enter lol-dev -# Install dependencies manually - -# Verify setup -just check # or: cargo check / mix compile / etc. -just test # Run test suite -``` - -### Repository Structure -``` -lol/ -├── src/ # Source code (Perimeter 1-2) -├── lib/ # Library code (Perimeter 1-2) -├── extensions/ # Extensions (Perimeter 2) -├── plugins/ # Plugins (Perimeter 2) -├── tools/ # Tooling (Perimeter 2) -├── docs/ # Documentation (Perimeter 3) -│ ├── architecture/ # ADRs, specs (Perimeter 2) -│ └── proposals/ # RFCs (Perimeter 3) -├── examples/ # Examples (Perimeter 3) -├── spec/ # Spec tests (Perimeter 3) -├── tests/ # Test suite (Perimeter 2-3) -├── .well-known/ # Protocol files (Perimeter 1-3) -├── .github/ # GitHub config (Perimeter 1) -│ ├── ISSUE_TEMPLATE/ -│ └── workflows/ -├── CHANGELOG.md -├── CODE_OF_CONDUCT.md -├── CONTRIBUTING.md # This file -├── GOVERNANCE.md -├── LICENSE -├── MAINTAINERS.md -├── README.adoc -├── SECURITY.md -├── flake.nix # Nix flake (Perimeter 1) -└── Justfile # Task runner (Perimeter 1) -``` - ---- - -## How to Contribute - -### Reporting Bugs - -**Before reporting**: -1. Search existing issues -2. Check if it's already fixed in `main` -3. Determine which perimeter the bug affects - -**When reporting**: - -Use the [bug report template](.github/ISSUE_TEMPLATE/bug_report.md) and include: - -- Clear, descriptive title -- Environment details (OS, versions, toolchain) -- Steps to reproduce -- Expected vs actual behaviour -- Logs, screenshots, or minimal reproduction - -### Suggesting Features - -**Before suggesting**: -1. Check the [roadmap](ROADMAP.md) if available -2. Search existing issues and discussions -3. Consider which perimeter the feature belongs to - -**When suggesting**: - -Use the [feature request template](.github/ISSUE_TEMPLATE/feature_request.md) and include: - -- Problem statement (what pain point does this solve?) -- Proposed solution -- Alternatives considered -- Which perimeter this affects - -### Your First Contribution - -Look for issues labelled: - -- [`good first issue`](https://github.com/hyperpolymath/lol/labels/good%20first%20issue) — Simple Perimeter 3 tasks -- [`help wanted`](https://github.com/hyperpolymath/lol/labels/help%20wanted) — Community help needed -- [`documentation`](https://github.com/hyperpolymath/lol/labels/documentation) — Docs improvements -- [`perimeter-3`](https://github.com/hyperpolymath/lol/labels/perimeter-3) — Community sandbox scope - ---- - -## Development Workflow - -### Branch Naming -``` -docs/short-description # Documentation (P3) -test/what-added # Test additions (P3) -feat/short-description # New features (P2) -fix/issue-number-description # Bug fixes (P2) -refactor/what-changed # Code improvements (P2) -security/what-fixed # Security fixes (P1-2) -``` - -### Commit Messages - -We follow [Conventional Commits](https://www.conventionalcommits.org/): -``` -(): - -[optional body] - -[optional footer] diff --git a/rhodium-standard-repositories/CONTRIBUTING.adoc b/rhodium-standard-repositories/CONTRIBUTING.adoc index 95cc8aab..4c1510be 100644 --- a/rhodium-standard-repositories/CONTRIBUTING.adoc +++ b/rhodium-standard-repositories/CONTRIBUTING.adoc @@ -87,7 +87,7 @@ The Rhodium Standard uses a graduated trust model. Your contribution scope depen * Contribute to DocGementer tooling *How to Become a Trusted Contributor*: -See link:MAINTAINERS.md[MAINTAINERS.md] for the progression path. Typically: +See link:MAINTAINERS.adoc[MAINTAINERS.md] for the progression path. Typically: * 20+ merged contributions OR deep expertise in specific area * 3+ months of consistent activity * Positive community interactions @@ -613,7 +613,7 @@ Or focus on areas you're comfortable with - all contributions are valuable! * **Trusted contributor** (20+ MRs, 3+ months): Listed in MAINTAINERS.md, can approve MRs in your domain * **Core maintainer** (6+ months trusted): Listed as maintainer, voting rights -See link:MAINTAINERS.md[MAINTAINERS.md] for details. +See link:MAINTAINERS.adoc[MAINTAINERS.md] for details. == Legal @@ -663,7 +663,7 @@ Violations can be reported to code-of-conduct@rhodium-standard.org * link:README.adoc[README] - Project overview * link:GOVERNANCE.adoc[GOVERNANCE] - How decisions are made * link:SECURITY.md[SECURITY] - Security policies -* link:MAINTAINERS.md[MAINTAINERS] - Team structure +* link:MAINTAINERS.adoc[MAINTAINERS] - Team structure * link:CLAUDE.md[CLAUDE.md] - AI assistant guidance * link:COMPLIANCE_CHECKLIST.md[Compliance Checklist] - RSR standards diff --git a/rhodium-standard-repositories/CONTRIBUTING.md b/rhodium-standard-repositories/CONTRIBUTING.md deleted file mode 100644 index 13766450..00000000 --- a/rhodium-standard-repositories/CONTRIBUTING.md +++ /dev/null @@ -1,116 +0,0 @@ -# Clone the repository -git clone https://github.com/hyperpolymath/rhodium-standard-repositories.git -cd rhodium-standard-repositories - -# Using Nix (recommended for reproducibility) -nix develop - -# Or using toolbox/distrobox -toolbox create rhodium-standard-repositories-dev -toolbox enter rhodium-standard-repositories-dev -# Install dependencies manually - -# Verify setup -just check # or: cargo check / mix compile / etc. -just test # Run test suite -``` - -### Repository Structure -``` -rhodium-standard-repositories/ -├── src/ # Source code (Perimeter 1-2) -├── lib/ # Library code (Perimeter 1-2) -├── extensions/ # Extensions (Perimeter 2) -├── plugins/ # Plugins (Perimeter 2) -├── tools/ # Tooling (Perimeter 2) -├── docs/ # Documentation (Perimeter 3) -│ ├── architecture/ # ADRs, specs (Perimeter 2) -│ └── proposals/ # RFCs (Perimeter 3) -├── examples/ # Examples (Perimeter 3) -├── spec/ # Spec tests (Perimeter 3) -├── tests/ # Test suite (Perimeter 2-3) -├── .well-known/ # Protocol files (Perimeter 1-3) -├── .github/ # GitHub config (Perimeter 1) -│ ├── ISSUE_TEMPLATE/ -│ └── workflows/ -├── CHANGELOG.md -├── CODE_OF_CONDUCT.md -├── CONTRIBUTING.md # This file -├── GOVERNANCE.md -├── LICENSE -├── MAINTAINERS.md -├── README.adoc -├── SECURITY.md -├── flake.nix # Nix flake (Perimeter 1) -└── Justfile # Task runner (Perimeter 1) -``` - ---- - -## How to Contribute - -### Reporting Bugs - -**Before reporting**: -1. Search existing issues -2. Check if it's already fixed in `main` -3. Determine which perimeter the bug affects - -**When reporting**: - -Use the [bug report template](.github/ISSUE_TEMPLATE/bug_report.md) and include: - -- Clear, descriptive title -- Environment details (OS, versions, toolchain) -- Steps to reproduce -- Expected vs actual behaviour -- Logs, screenshots, or minimal reproduction - -### Suggesting Features - -**Before suggesting**: -1. Check the [roadmap](ROADMAP.md) if available -2. Search existing issues and discussions -3. Consider which perimeter the feature belongs to - -**When suggesting**: - -Use the [feature request template](.github/ISSUE_TEMPLATE/feature_request.md) and include: - -- Problem statement (what pain point does this solve?) -- Proposed solution -- Alternatives considered -- Which perimeter this affects - -### Your First Contribution - -Look for issues labelled: - -- [`good first issue`](https://github.com/hyperpolymath/rhodium-standard-repositories/labels/good%20first%20issue) — Simple Perimeter 3 tasks -- [`help wanted`](https://github.com/hyperpolymath/rhodium-standard-repositories/labels/help%20wanted) — Community help needed -- [`documentation`](https://github.com/hyperpolymath/rhodium-standard-repositories/labels/documentation) — Docs improvements -- [`perimeter-3`](https://github.com/hyperpolymath/rhodium-standard-repositories/labels/perimeter-3) — Community sandbox scope - ---- - -## Development Workflow - -### Branch Naming -``` -docs/short-description # Documentation (P3) -test/what-added # Test additions (P3) -feat/short-description # New features (P2) -fix/issue-number-description # Bug fixes (P2) -refactor/what-changed # Code improvements (P2) -security/what-fixed # Security fixes (P1-2) -``` - -### Commit Messages - -We follow [Conventional Commits](https://www.conventionalcommits.org/): -``` -(): - -[optional body] - -[optional footer] diff --git a/rhodium-standard-repositories/MAINTAINERS.md b/rhodium-standard-repositories/MAINTAINERS.md deleted file mode 100644 index e1cf6b2e..00000000 --- a/rhodium-standard-repositories/MAINTAINERS.md +++ /dev/null @@ -1,256 +0,0 @@ -# MAINTAINERS.md - - - -# Project Maintainers - -This document lists the maintainers of the Rhodium Standard Repositories project, organized by the Tri-Perimeter Contribution Framework (TPCF). - -## Core Team (Perimeter 1) - -Core maintainers have write access to protected branches and make final decisions on architectural changes. - -### Project Lead - -- **@hyperpolymath** - Project Creator & Lead Architect - - Areas: Overall vision, CCCP philosophy, RSR standards - - GitLab: [@hyperpolymath](https://gitlab.com/hyperpolymath) - - PGP: `[To be added]` - - Timezone: UTC - -### Core Maintainers - -*Additional core maintainers will be added as the project grows.* - -Eligibility criteria for core maintainer status: -- 6+ months of consistent contributions -- Deep understanding of RSR philosophy and CCCP principles -- Demonstrated technical excellence and community leadership -- Nominated by existing core maintainer and approved by consensus -- Completed security and governance training - -## Trusted Contributors (Perimeter 2) - -Trusted contributors have expertise in specific areas and can approve merge requests for their domains after review. - -### Component Owners - -*To be populated as specialists emerge in the community.* - -Areas needing owners: -- Haskell Registry & Validation Service -- Nix/Nickel Infrastructure -- Documentation & DocGementer -- Security & Supply Chain -- Example Repositories & Templates -- Testing & CI/CD Infrastructure - -Eligibility criteria: -- 3+ months of contributions in specific area -- Demonstrated expertise and reliability -- Community trust and positive collaboration -- Application reviewed by core team - -## Community Contributors (Perimeter 3) - -All contributors are valued members of the community. This list represents significant ongoing contributors. - -### Active Contributors - -*Generated from git history - see GitLab contributors page:* -https://gitlab.com/hyperpolymath/rhodium-standard-repositories/-/project_members - -### Historical Contributors - -All past contributors are honored in git history and in the .well-known/humans.txt file. - -## Emeritus Maintainers - -Maintainers who have stepped down but contributed significantly: - -*None yet - project is young.* - -Emeritus maintainers retain: -- Credit in all project materials -- Advisory role (if desired) -- Community respect and acknowledgment - -## Contribution Recognition - -We recognize contributions beyond code: - -- **Documentation**: Clear writing, comprehensive guides, translations -- **Community**: Helping others, answering questions, moderating discussions -- **Testing**: Finding bugs, writing tests, QA work -- **Design**: UX/UI, graphics, branding, user research -- **DevOps**: CI/CD, infrastructure, tooling, automation -- **Advocacy**: Talks, blog posts, social media, conference presentations -- **Mentorship**: Helping new contributors, code reviews, teaching - -## Becoming a Maintainer - -### Path from Contributor to Maintainer - -1. **Community Contributor (Perimeter 3)**: Open to all - - Make your first contribution - - Engage with the community - - Read CONTRIBUTING.adoc and CODE_OF_CONDUCT.adoc - - Estimated time: Immediate - -2. **Regular Contributor**: Recognized contributor - - 5+ merged contributions - - Consistent engagement over 1+ month - - Positive community interactions - - Estimated time: 1-3 months - -3. **Trusted Contributor (Perimeter 2)**: Domain expert - - 20+ merged contributions OR deep expertise in specific area - - 3+ months of consistent activity - - Demonstrated judgment and collaboration - - Nominated by maintainer or self-nomination via issue - - Estimated time: 3-6 months - -4. **Core Maintainer (Perimeter 1)**: Project leadership - - 6+ months as trusted contributor - - Significant architectural contributions - - Deep RSR philosophy understanding - - Community leadership and mentorship - - Security and governance training completed - - Nominated by core maintainer, consensus approval - - Estimated time: 6-12 months - -### Self-Nomination Process - -Ready to level up? Open an issue using the maintainer-nomination template: - -```markdown -**Title**: [Maintainer Nomination] @username for [Trusted/Core] status - -**Nominee**: @username -**Current Level**: [Community/Regular/Trusted] -**Target Level**: [Trusted/Core] -**Nominator**: @nominator (or self-nomination) - -**Areas of Expertise**: -- [Area 1] -- [Area 2] - -**Contributions**: -- [Contribution 1 with link] -- [Contribution 2 with link] -- [Contribution 3 with link] - -**Why this promotion**: -[Explanation of readiness and plans] - -**References** (optional): -- @reference1 -- @reference2 -``` - -## Maintainer Responsibilities - -### All Maintainers - -- Follow CODE_OF_CONDUCT.adoc -- Review merge requests in your area -- Respond to issues and questions -- Participate in governance discussions -- Maintain RSR compliance in your work -- Mentor new contributors - -### Trusted Contributors (Perimeter 2) - -All of the above, plus: -- Approve MRs in your domain -- Participate in architectural discussions for your area -- Help triage issues in your domain -- Write documentation for your area - -### Core Maintainers (Perimeter 1) - -All of the above, plus: -- Make final decisions on architectural changes -- Maintain project roadmap -- Handle security issues -- Approve new trusted contributors -- Participate in consensus decision-making -- Ensure project health and sustainability - -## Maintainer Expectations - -### Time Commitment - -- **Core**: 5-10 hours/week -- **Trusted**: 2-5 hours/week -- **Regular**: As available (no minimum) - -### Communication - -- Respond to mentions within 1 week (best effort) -- Participate in monthly community calls (planned) -- Vote on governance decisions within 7 days -- Announce unavailability if away >2 weeks - -### Code of Conduct - -All maintainers must: -- Lead by example in following CODE_OF_CONDUCT.adoc -- Handle conflicts with empathy and fairness -- Step back from decisions where they have conflicts of interest -- Maintain confidentiality for security and personal issues - -## Stepping Down - -Maintainers may step down at any time, with no shame or penalty. - -Process: -1. Announce intention to step down (private or public) -2. Transition responsibilities (2 weeks ideal, but flexible) -3. Update this file and .well-known/humans.txt -4. Optionally move to emeritus status -5. Optionally remain as community contributor - -## Removal - -In rare cases, maintainer status may be revoked: - -Reasons: -- Repeated CODE_OF_CONDUCT violations -- Prolonged inactivity without communication (6+ months) -- Compromise of security credentials -- Actions harmful to project or community - -Process: -- Private discussion with maintainer -- Consensus decision by core team -- Public announcement (details determined case-by-case) -- Appeal process available (see GOVERNANCE.adoc) - -## Contact - -- **Maintainer team**: maintainers@rhodium-standard.org -- **GitLab mentions**: @rhodium-standard-maintainers (planned group) -- **Matrix**: #rhodium-standard-maintainers:matrix.org (planned, private) - -## Acknowledgments - -Special thanks to: -- All contributors listed in git history -- Community members who help others -- Organizations supporting RSR adoption -- Funders and sponsors (see FUNDING.yml) - ---- - -**Last Updated**: 2025-11-28 -**Next Review**: 2026-02-28 -**Document Version**: 1.0.0 -**Maintained by**: Core Team - -_"Leadership is not about authority—it's about service to the community."_ - -— The Rhodium Standard diff --git a/rhodium-standard-repositories/README.adoc b/rhodium-standard-repositories/README.adoc index 34748574..dd41181e 100644 --- a/rhodium-standard-repositories/README.adoc +++ b/rhodium-standard-repositories/README.adoc @@ -376,7 +376,7 @@ See link:CONTRIBUTING.adoc[CONTRIBUTING.adoc] for details. * link:docs/haskell-registry-design.md[Haskell Registry Design] - Validation service architecture * link:PROJECT-STATUS.md[Project Status] - Current development status -* link:MAINTAINERS.md[Maintainers] - Project maintainers and contributors +* link:MAINTAINERS.adoc[Maintainers] - Project maintainers and contributors == License @@ -442,7 +442,7 @@ The Rhodium Standard builds on decades of best practices from: * Erlang/OTP fault tolerance patterns * CRDTs and distributed systems research -See link:MAINTAINERS.md[MAINTAINERS.md] and link:.well-known/humans.txt[humans.txt] for contributor attribution. +See link:MAINTAINERS.adoc[MAINTAINERS.md] and link:.well-known/humans.txt[humans.txt] for contributor attribution. == Citation diff --git a/rhodium-standard-repositories/examples/README.md b/rhodium-standard-repositories/examples/README.md index 92d94456..57123875 100644 --- a/rhodium-standard-repositories/examples/README.md +++ b/rhodium-standard-repositories/examples/README.md @@ -255,7 +255,7 @@ Want to contribute a new example? - Must have .well-known/ directory - Must have SPDX headers on all source files -See [../CONTRIBUTING.md](../CONTRIBUTING.md) for details. +See [../CONTRIBUTING.md](../CONTRIBUTING.adoc) for details. --- diff --git a/rhodium-standard-repositories/satellites/cccp/CONTRIBUTING.md b/rhodium-standard-repositories/satellites/cccp/CONTRIBUTING.md deleted file mode 100644 index 8c9d97b7..00000000 --- a/rhodium-standard-repositories/satellites/cccp/CONTRIBUTING.md +++ /dev/null @@ -1,116 +0,0 @@ -# Clone the repository -git clone https://github.com/hyperpolymath/standards.git -cd standards - -# Using Nix (recommended for reproducibility) -nix develop - -# Or using toolbox/distrobox -toolbox create standards-dev -toolbox enter standards-dev -# Install dependencies manually - -# Verify setup -just check # or: cargo check / mix compile / etc. -just test # Run test suite -``` - -### Repository Structure -``` -standards/ -├── src/ # Source code (Perimeter 1-2) -├── lib/ # Library code (Perimeter 1-2) -├── extensions/ # Extensions (Perimeter 2) -├── plugins/ # Plugins (Perimeter 2) -├── tools/ # Tooling (Perimeter 2) -├── docs/ # Documentation (Perimeter 3) -│ ├── architecture/ # ADRs, specs (Perimeter 2) -│ └── proposals/ # RFCs (Perimeter 3) -├── examples/ # Examples (Perimeter 3) -├── spec/ # Spec tests (Perimeter 3) -├── tests/ # Test suite (Perimeter 2-3) -├── .well-known/ # Protocol files (Perimeter 1-3) -├── .github/ # GitHub config (Perimeter 1) -│ ├── ISSUE_TEMPLATE/ -│ └── workflows/ -├── CHANGELOG.md -├── CODE_OF_CONDUCT.md -├── CONTRIBUTING.md # This file -├── GOVERNANCE.md -├── LICENSE -├── MAINTAINERS.md -├── README.adoc -├── SECURITY.md -├── flake.nix # Nix flake (Perimeter 1) -└── Justfile # Task runner (Perimeter 1) -``` - ---- - -## How to Contribute - -### Reporting Bugs - -**Before reporting**: -1. Search existing issues -2. Check if it's already fixed in `main` -3. Determine which perimeter the bug affects - -**When reporting**: - -Use the [bug report template](.github/ISSUE_TEMPLATE/bug_report.md) and include: - -- Clear, descriptive title -- Environment details (OS, versions, toolchain) -- Steps to reproduce -- Expected vs actual behaviour -- Logs, screenshots, or minimal reproduction - -### Suggesting Features - -**Before suggesting**: -1. Check the [roadmap](ROADMAP.md) if available -2. Search existing issues and discussions -3. Consider which perimeter the feature belongs to - -**When suggesting**: - -Use the [feature request template](.github/ISSUE_TEMPLATE/feature_request.md) and include: - -- Problem statement (what pain point does this solve?) -- Proposed solution -- Alternatives considered -- Which perimeter this affects - -### Your First Contribution - -Look for issues labelled: - -- [`good first issue`](https://github.com/hyperpolymath/standards/labels/good%20first%20issue) — Simple Perimeter 3 tasks -- [`help wanted`](https://github.com/hyperpolymath/standards/labels/help%20wanted) — Community help needed -- [`documentation`](https://github.com/hyperpolymath/standards/labels/documentation) — Docs improvements -- [`perimeter-3`](https://github.com/hyperpolymath/standards/labels/perimeter-3) — Community sandbox scope - ---- - -## Development Workflow - -### Branch Naming -``` -docs/short-description # Documentation (P3) -test/what-added # Test additions (P3) -feat/short-description # New features (P2) -fix/issue-number-description # Bug fixes (P2) -refactor/what-changed # Code improvements (P2) -security/what-fixed # Security fixes (P1-2) -``` - -### Commit Messages - -We follow [Conventional Commits](https://www.conventionalcommits.org/): -``` -(): - -[optional body] - -[optional footer] diff --git a/rhodium-standard-repositories/satellites/cccp/SECURITY.md b/rhodium-standard-repositories/satellites/cccp/SECURITY.md index 6ea98768..5eff0bf6 100644 --- a/rhodium-standard-repositories/satellites/cccp/SECURITY.md +++ b/rhodium-standard-repositories/satellites/cccp/SECURITY.md @@ -373,7 +373,7 @@ When using Standards, we recommend: - [Our PGP Public Key]({{PGP_KEY_URL}}) - [Security Advisories](https://github.com/hyperpolymath/standards/security/advisories) - [Changelog](CHANGELOG.md) -- [Contributing Guidelines](CONTRIBUTING.md) +- [Contributing Guidelines](CONTRIBUTING.adoc) - [CVE Database](https://cve.mitre.org/) - [CVSS Calculator](https://www.first.org/cvss/calculator/3.1) diff --git a/rhodium-standard-repositories/satellites/state.scm/CODE_OF_CONDUCT.adoc b/rhodium-standard-repositories/satellites/state.scm/CODE_OF_CONDUCT.adoc index 6f73bdda..4547c73a 100644 --- a/rhodium-standard-repositories/satellites/state.scm/CODE_OF_CONDUCT.adoc +++ b/rhodium-standard-repositories/satellites/state.scm/CODE_OF_CONDUCT.adoc @@ -1,57 +1,130 @@ -= Contributor Covenant Code of Conduct -:toc: +== Contributor Covenant Code of Conduct -== Our Pledge +=== Our Pledge We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, -nationality, personal appearance, race, caste, color, religion, or sexual -identity and orientation. +nationality, personal appearance, race, religion, or sexual identity +and orientation. We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community. -== Our Standards +=== Our Standards -Examples of behavior that contributes to a positive environment: +Examples of behavior that contributes to a positive environment for our +community include: * Demonstrating empathy and kindness toward other people * Being respectful of differing opinions, viewpoints, and experiences * Giving and gracefully accepting constructive feedback -* Accepting responsibility and apologizing to those affected by our mistakes -* Focusing on what is best for the overall community -* Using welcoming and inclusive language +* Accepting responsibility and apologizing to those affected by our mistakes, +and learning from the experience +* Focusing on what is best not just for us as individuals, but for the +overall community -Examples of unacceptable behavior: +Examples of unacceptable behavior include: -* The use of sexualized language or imagery, and sexual attention or advances of any kind +* The use of sexualized language or imagery, and sexual attention or +advances of any kind * Trolling, insulting or derogatory comments, and personal or political attacks * Public or private harassment -* Publishing others' private information without explicit permission -* Other conduct which could reasonably be considered inappropriate in a professional setting +* Publishing others' private information, such as a physical or email +address, without their explicit permission +* Other conduct which could reasonably be considered inappropriate in a +professional setting -== Enforcement Responsibilities +=== Enforcement Responsibilities Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful. -== Scope +Community leaders have the right and responsibility to remove, edit, or reject +comments, commits, code, wiki edits, issues, and other contributions that are +not aligned to this Code of Conduct, and will communicate reasons for moderation +decisions when appropriate. + +=== Scope This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. +Examples of representing our community include using an official e-mail address, +posting via an official social media account, or acting as an appointed +representative at an online or offline event. -== Enforcement +=== Enforcement Instances of abusive, harassing, or otherwise unacceptable behavior may be -reported to the community leaders responsible for enforcement. - +reported to the community leaders responsible for enforcement at +. All complaints will be reviewed and investigated promptly and fairly. -== Attribution +All community leaders are obligated to respect the privacy and security of the +reporter of any incident. + +=== Enforcement Guidelines + +Community leaders will follow these Community Impact Guidelines in determining +the consequences for any action they deem in violation of this Code of Conduct: + +[[1-correction]] +==== 1. Correction + +*Community Impact*: Use of inappropriate language or other behavior deemed +unprofessional or unwelcome in the community. + +*Consequence*: A private, written warning from community leaders, providing +clarity around the nature of the violation and an explanation of why the +behavior was inappropriate. A public apology may be requested. + +[[2-warning]] +==== 2. Warning + +*Community Impact*: A violation through a single incident or series +of actions. + +*Consequence*: A warning with consequences for continued behavior. No +interaction with the people involved, including unsolicited interaction with +those enforcing the Code of Conduct, for a specified period of time. This +includes avoiding interactions in community spaces as well as external channels +like social media. Violating these terms may lead to a temporary or +permanent ban. + +[[3-temporary-ban]] +==== 3. Temporary Ban + +*Community Impact*: A serious violation of community standards, including +sustained inappropriate behavior. + +*Consequence*: A temporary ban from any sort of interaction or public +communication with the community for a specified period of time. No public or +private interaction with the people involved, including unsolicited interaction +with those enforcing the Code of Conduct, is allowed during this period. +Violating these terms may lead to a permanent ban. + +[[4-permanent-ban]] +==== 4. Permanent Ban + +*Community Impact*: Demonstrating a pattern of violation of community +standards, including sustained inappropriate behavior, harassment of an +individual, or aggression toward or disparagement of classes of individuals. + +*Consequence*: A permanent ban from any sort of public interaction within +the community. + +=== Attribution This Code of Conduct is adapted from the https://www.contributor-covenant.org[Contributor Covenant], -version 2.1. +version 2.0, available at +https://www.contributor-covenant.org/version/2/0/code_of_conduct.html. + +Community Impact Guidelines were inspired by https://github.com/mozilla/diversity[Mozilla's code of conduct +enforcement ladder]. + +For answers to common questions about this code of conduct, see the FAQ at +https://www.contributor-covenant.org/faq. Translations are available at +https://www.contributor-covenant.org/translations. diff --git a/rhodium-standard-repositories/satellites/state.scm/CODE_OF_CONDUCT.md b/rhodium-standard-repositories/satellites/state.scm/CODE_OF_CONDUCT.md deleted file mode 100644 index 18c91471..00000000 --- a/rhodium-standard-repositories/satellites/state.scm/CODE_OF_CONDUCT.md +++ /dev/null @@ -1,128 +0,0 @@ -# Contributor Covenant Code of Conduct - -## Our Pledge - -We as members, contributors, and leaders pledge to make participation in our -community a harassment-free experience for everyone, regardless of age, body -size, visible or invisible disability, ethnicity, sex characteristics, gender -identity and expression, level of experience, education, socio-economic status, -nationality, personal appearance, race, religion, or sexual identity -and orientation. - -We pledge to act and interact in ways that contribute to an open, welcoming, -diverse, inclusive, and healthy community. - -## Our Standards - -Examples of behavior that contributes to a positive environment for our -community include: - -* Demonstrating empathy and kindness toward other people -* Being respectful of differing opinions, viewpoints, and experiences -* Giving and gracefully accepting constructive feedback -* Accepting responsibility and apologizing to those affected by our mistakes, - and learning from the experience -* Focusing on what is best not just for us as individuals, but for the - overall community - -Examples of unacceptable behavior include: - -* The use of sexualized language or imagery, and sexual attention or - advances of any kind -* Trolling, insulting or derogatory comments, and personal or political attacks -* Public or private harassment -* Publishing others' private information, such as a physical or email - address, without their explicit permission -* Other conduct which could reasonably be considered inappropriate in a - professional setting - -## Enforcement Responsibilities - -Community leaders are responsible for clarifying and enforcing our standards of -acceptable behavior and will take appropriate and fair corrective action in -response to any behavior that they deem inappropriate, threatening, offensive, -or harmful. - -Community leaders have the right and responsibility to remove, edit, or reject -comments, commits, code, wiki edits, issues, and other contributions that are -not aligned to this Code of Conduct, and will communicate reasons for moderation -decisions when appropriate. - -## Scope - -This Code of Conduct applies within all community spaces, and also applies when -an individual is officially representing the community in public spaces. -Examples of representing our community include using an official e-mail address, -posting via an official social media account, or acting as an appointed -representative at an online or offline event. - -## Enforcement - -Instances of abusive, harassing, or otherwise unacceptable behavior may be -reported to the community leaders responsible for enforcement at -. -All complaints will be reviewed and investigated promptly and fairly. - -All community leaders are obligated to respect the privacy and security of the -reporter of any incident. - -## Enforcement Guidelines - -Community leaders will follow these Community Impact Guidelines in determining -the consequences for any action they deem in violation of this Code of Conduct: - -### 1. Correction - -**Community Impact**: Use of inappropriate language or other behavior deemed -unprofessional or unwelcome in the community. - -**Consequence**: A private, written warning from community leaders, providing -clarity around the nature of the violation and an explanation of why the -behavior was inappropriate. A public apology may be requested. - -### 2. Warning - -**Community Impact**: A violation through a single incident or series -of actions. - -**Consequence**: A warning with consequences for continued behavior. No -interaction with the people involved, including unsolicited interaction with -those enforcing the Code of Conduct, for a specified period of time. This -includes avoiding interactions in community spaces as well as external channels -like social media. Violating these terms may lead to a temporary or -permanent ban. - -### 3. Temporary Ban - -**Community Impact**: A serious violation of community standards, including -sustained inappropriate behavior. - -**Consequence**: A temporary ban from any sort of interaction or public -communication with the community for a specified period of time. No public or -private interaction with the people involved, including unsolicited interaction -with those enforcing the Code of Conduct, is allowed during this period. -Violating these terms may lead to a permanent ban. - -### 4. Permanent Ban - -**Community Impact**: Demonstrating a pattern of violation of community -standards, including sustained inappropriate behavior, harassment of an -individual, or aggression toward or disparagement of classes of individuals. - -**Consequence**: A permanent ban from any sort of public interaction within -the community. - -## Attribution - -This Code of Conduct is adapted from the [Contributor Covenant][homepage], -version 2.0, available at -https://www.contributor-covenant.org/version/2/0/code_of_conduct.html. - -Community Impact Guidelines were inspired by [Mozilla's code of conduct -enforcement ladder](https://github.com/mozilla/diversity). - -[homepage]: https://www.contributor-covenant.org - -For answers to common questions about this code of conduct, see the FAQ at -https://www.contributor-covenant.org/faq. Translations are available at -https://www.contributor-covenant.org/translations.