Mark Iroh adapters as deferred pending fork of iroh-ts

Update peer dep from @rayhanadev/iroh to @alkdev/iroh. Document
platform strategy: Linux native + WASM fallback, Windows/macOS
deferred. Fix outdated single-import reference in iroh-transport.md
to split spoke/hub imports. Resolve binding stability and NAPI/Deno
R&D items as covered by the fork path.
This commit is contained in:
2026-05-08 03:59:35 +00:00
parent bc0c2589c7
commit e60f0a1aa0
4 changed files with 22 additions and 18 deletions

View File

@@ -6,8 +6,8 @@ last_updated: 2026-05-08
# Iroh Hub Event Target
**Import**: `@alkdev/pubsub/event-target-iroh-hub`
**Peer dep**: `@rayhanadev/iroh` (optional, NAPI-RS native addon)
**Status**: Not yet implemented. Needs R&D on binding stability, NAPI under Deno.
**Peer dep**: `@alkdev/iroh` (optional, NAPI-RS native addon — pending fork of iroh-ts)
**Status**: Deferred. Pending fork of iroh-ts with Linux + WASM platform targets.
P2P QUIC event target for the hub (server) side. The hub accepts incoming connections and bidirectional streams. Manages multiple connected spokes.
@@ -78,7 +78,7 @@ dispatchEvent(event) {
## R&D Needed
1. **Binding stability** — same as spoke adapter. `@rayhanadev/iroh` needs testing.
1. **Fork of iroh-ts** — same as spoke adapter. Pending fork as `@alkdev/iroh`.
2. **Concurrent accept** — can `endpoint.accept()` handle multiple simultaneous connections?
3. **Stream vs. Connection per spoke** — current design: one bidirectional stream per spoke on a single connection. Alternative: one connection per spoke. Need to benchmark which is better for the expected workload.
4. **iroh-gossip** — for true broadcast to many spokes, `iroh-gossip` would be more efficient than per-spoke streams. Not yet available in TS. The current subscription-tracked fan-out design works for moderate fan-out; gossip would be an optimization for very large fan-out later.

View File

@@ -6,8 +6,8 @@ last_updated: 2026-05-08
# Iroh Spoke Event Target
**Import**: `@alkdev/pubsub/event-target-iroh-spoke`
**Peer dep**: `@rayhanadev/iroh` (optional, NAPI-RS native addon)
**Status**: Not yet implemented. Needs R&D on binding stability and Deno/NAPI compatibility.
**Peer dep**: `@alkdev/iroh` (optional, NAPI-RS native addon — pending fork of iroh-ts)
**Status**: Deferred. Pending fork of iroh-ts with Linux + WASM platform targets.
P2P QUIC event target for the spoke (client) side. The spoke initiates the connection and opens the bidirectional stream.
@@ -70,9 +70,8 @@ Control events use the existing `EventEnvelope` format:
## R&D Needed
1. **Binding stability**`@rayhanadev/iroh` has one author and no tests. API surface is small (10 methods) but needs validation.
2. **NAPI under Deno** — NAPI-RS `.node` binaries need testing under Deno 2.x.
3. **Stream multiplexing** — multiple `openBi()` streams on one connection vs. single stream with multiplexed events. Single stream + JSON framing is simpler.
4. **Reconnection**`RecvStream.readExact()` throws on connection close. Need to propagate this to listeners and support reconnect.
1. **Fork of iroh-ts**`@rayhanadev/iroh` has one author and no tests. We plan to fork as `@alkdev/iroh` with Linux (NAPI-RS) + WASM platform targets. Windows and macOS native builds are deferred — cross-compilation from Linux is possible with NAPI but tricky, and macOS licensing is dubious for CI. Initial release: Linux native + WASM fallback. Adding other platforms is a future accessibility concern.
2. **Stream multiplexing** — multiple `openBi()` streams on one connection vs. single stream with multiplexed events. Single stream + JSON framing is simpler.
3. **Reconnection**`RecvStream.readExact()` throws on connection close. Need to propagate this to listeners and support reconnect.
See [../iroh-transport.md](../iroh-transport.md) for full protocol details, identity, and comparison with WebSocket.