• The Constraint: Private Nodes
• The Change in 0.3.0
• UDP Rendezvous
• Nostr: Coordination Layer Only
• A Proposal: Peer-Assisted Onboarding
• Limitations
• Why It Matters
• Result

The Internet isn’t what it was.

What was once a relatively neutral transport layer is now dominated by platforms, intermediaries, and infrastructure that quietly turns communication into dependency.

FIPS pushes in the opposite direction: direct, permissionless communication between nodes, without relying on centralised services to carry the conversation.

At its core, FIPS is a mesh network. Nodes connect directly where possible and route through peers when needed. There is no central server dependency. The network adapts as nodes join, leave, move, or change transports.

FIPS is also transport-agnostic. It can operate over UDP, TCP, Ethernet/Wi-Fi, Tor, Bluetooth, and other mediums. In the current master branch (0.3.0-dev), Nostr becomes part of the discovery and rendezvous story too, not as the data path, but as a coordination layer.

§The Constraint: Private Nodes

Most modern devices are not publicly reachable.

They sit behind:

• Home-router NAT
• Carrier-grade NAT
• Mobile networks
• Firewalls
• Restricted Wi-Fi and enterprise networks

These devices can usually initiate outbound connections, but they cannot reliably accept inbound ones.

Traditional FIPS bootstrapping assumes at least one known public peer: an IP address and port that a new node can dial. This works for servers, VPS instances, and deliberately configured home routers.

It excludes a lot of real-world devices from acting as useful entry points.

A laptop, phone, or Raspberry Pi may be perfectly capable of participating in the mesh, but still unable to expose a stable public endpoint.

§The Change in 0.3.0

The current master branch (0.3.0-dev, not yet released) adds the pieces needed for private nodes to find and connect to each other more easily:

• Nostr-mediated discovery and signalling
• Signed overlay adverts
• STUN-assisted UDP NAT traversal
• udp:nat endpoints
• via_nostr fallback discovery for configured peers

The key principle is simple:

Use public infrastructure for coordination only, not for transport.

STUN servers and Nostr relays help peers meet. They do not become the FIPS network (unless you want it to, @SatsAndSports).

§UDP Rendezvous

The mechanism is UDP hole punching.

A simplified flow looks like this:

1. Each node queries a STUN server to learn its reflexive UDP endpoint.
2. The nodes exchange endpoint information using encrypted Nostr messages.
3. Both peers send outbound UDP packets to each other at roughly the same time.
4. Their NAT devices associate the inbound packets with existing outbound mappings.
5. A direct UDP path is established.

Once that path exists, FIPS runs its normal encrypted transport and mesh logic over it.

The useful properties are:

• No manual port forwarding
• No permanent public listener
• No relay in the data plane
• No special FIPS bootstrap server

The public services only coordinate the rendezvous. The resulting connection is peer-to-peer.

§Nostr: Coordination Layer Only

Nostr is used for:

• Signed FIPS overlay adverts
• Endpoint discovery
• Encrypted rendezvous signalling

It is not used as the persistent transport for FIPS traffic.

That separation matters:

• STUN discovers how a node appears from the outside.
• Nostr coordinates discovery and rendezvous messages.
• FIPS carries the actual encrypted mesh traffic.

Nostr relays remain replaceable and application-unaware. They may store and forward small coordination events, but they are not trusted with FIPS payload data and they are not on the long-lived data path.

§A Proposal: Peer-Assisted Onboarding

The same model points toward peer-assisted onboarding.

Once a node is connected, it can help expand the reachable surface of the mesh. Alice joins. Alice helps Bob. Bob helps Colin. Colin can then help Dave.

This creates a recursive onboarding surface:

• Less reliance on fixed public endpoints
• More useful private nodes
• More possible paths into the mesh
• Better growth across constrained environments

The important shift is that private nodes stop being mere clients at the edge. They can participate in growing the network.

§Limitations

NAT traversal is not magic.

Some networks still make direct UDP difficult or impossible:

• Symmetric NATs
• UDP-blocking firewalls
• Strict enterprise networks
• Mobile networks with aggressive filtering
• Short or unpredictable NAT mapping lifetimes

Fallbacks remain necessary. Public peers, Tor, TCP, explicit port forwarding, or future relayed paths may still be the right answer in some environments.

But the default answer no longer has to be: “open a port on your router.”

§Why It Matters

Traditional Internet topology tends to enforce a hierarchy:

• Public servers at the core
• Private devices at the edge

FIPS tries to flatten that.

Ordinary devices should be able to act as peers. A node should not need a static IP address, a VPS, or router admin access just to participate meaningfully.

With 0.3.0-dev, public services become coordination tools rather than infrastructure dependencies. STUN and Nostr help nodes discover each other, but they do not own the network and they do not carry the mesh.

That makes FIPS easier to run from the places people actually are: homes, mobile networks, small boards, laptops, and temporary networks.

§Result

Private nodes become more useful.

Mesh growth becomes less dependent on public servers.

Network resilience improves because there are more possible peers and paths.

Operational overhead drops because fewer users need to configure routers, static IPs, or hosted bootstrap machines.

The Internet remains a transport layer, but no longer the control plane.

That is Private FIPS.