Extract P2P Components to Standalone Repositories

[amitu]

Summary

Extract fastn-context, fastn-p2p, and fastn-net from the fastn monorepo into standalone repositories for external adoption. We will migrate fastn-id52 later.

Motivation

Our monorepo signals "internal development" while these components are production-ready and useful beyond fastn. Separate repositories signal "stable, public APIs" and enable external adoption.

Detailed Design

Repository Structure

New repos:

• fastn-stack/context - async context management (separate for now)
• fastn-stack/p2p - consolidated P2P library with examples

Existing repos maintained:

• fastn-stack/observer - observability (potential future merger with context)

P2P Consolidation

Merge related crates to reduce complexity:

• fastn-net → fastn-p2p::net module

Repository Structure

fastn-stack/p2p/
├── fastn-p2p/          # Core library with consolidated APIs
└── examples/           # Self-contained examples per use case
    ├── echo/           # Basic request/response (current sender/receiver)
    ├── remote_shell/   # SSH-like command execution
    ├── tcp_proxy/      # TCP tunneling example
    └── media_stream/   # Audio/video streaming example

Examples will help identify common patterns to abstract into the core library.

Implementation Plan

1. fastn-context - Extract first (simplest, no dependencies)
2. P2P ecosystem - Consolidate, then extract with specialized crates
3. fastn integration - Update to use published crates

Benefits

• External adoption - Clear, stable APIs for public use
• API quality - External pressure improves design
• Simplified dependencies - One P2P crate instead of ecosystem
• Community growth - External contributors and examples

Alternatives Considered

• Keep everything in monorepo - loses external adoption opportunity
• Extract without consolidation - too many small crates to maintain
• Multiple specialized crates - premature, examples should drive abstractions

Unresolved Questions

• Repository naming: p2p vs fastn-p2p?
• Migration timeline for fastn internal usage?
• fastn-context/fastn-observer merger - future consideration when bandwidth allows?

Notes

• fastn-observer: Existing separate repo with history, potential future integration with context
• Bandwidth constraints: Focus on P2P extraction first, context/observer integration later
• Pragmatic approach: Work with existing structure rather than over-reorganizing

[amitu]

We have extracted fastn-context into its own repo and published it to crates.io.

• Created https://github.com/fastn-stack/context
• Published fastn-context v0.1.1 and fastn-context-macros v0.1.1 to crates.io
• Removed the local fastn-context directories from the fastn repo
• Created PR feat: migrate to published fastn-context from crates.io #2212 to switch fastn to use the published version