FIPS concepts for AppWeaver

FIPS (Free Internetworking Peering System) is an identity-addressed encrypted mesh. A public key names a node independently of its current IP address. Discovery and transports must still provide a usable path to that node: knowing a public key alone does not create connectivity.

Protocol layers

AppWeaver app payload / ping
  -> FSP service datagrams (end-to-end Noise XK)
  -> FMP links and routing (hop-by-hop Noise IK)
  -> UDP socket, or configured FIPS WebSocket carrier

FMP authenticates adjacent nodes and protects each link. FSP authenticates the application endpoints and encrypts their session independently of intermediate forwarders. A transit node can forward traffic without reading its application payload. This does not imply traffic-analysis anonymity.

An adjacent network peer and a trusted application collaborator are different concepts. An app must enforce project membership and domain permissions even when a packet arrived over an authenticated FIPS session.

Discovery and NAT traversal

The Rust implementation describes signed kind 37195 endpoint adverts and gift-wrapped kind 21059 traversal offers/answers over ordinary Nostr relays. For NAT traversal, each attempt keeps one UDP socket open through STUN, candidate exchange, probing, and the eventual FMP handshake. Changing the socket can invalidate the NAT mapping learned through STUN.

STUN discovers a mapping; it does not guarantee that a peer can use it. UDP filtering, endpoint-dependent NAT mappings, and stale candidates can prevent a direct path. A reachable forwarding mesh can provide another path, where a compatible transport and routing implementation are available.

Which implementation AppWeaver uses

The plugin embeds a pinned TypeScript protocol implementation from mmalmi/fips-ts. It adds a local Bun/Node UDP transport in udp-nostr-transport.ts, inspired by the Rust discovery/traversal design. It does not run the Rust daemon, install a TUN interface, configure .fips DNS, or expose an OS-level VPN.

The browser-oriented TypeScript upstream also contains WebRTC transport code. Vendoring that package does not enable it in AppWeaver: the current runtime uses UDP and optionally WebSocket seeds, with no WebRTC runtime dependency.

The Rust project and TypeScript project's current interoperability targets can differ. Similar event kinds and Noise patterns are not proof of wire compatibility. The custom transport has only been exercised locally with an in-memory signaling relay substitute and real loopback UDP; cross-network NAT, real-relay delivery, and Rust interoperability remain unverified.

See AppWeaver architecture for the local flow and relay selection for current relay behavior.