A concrete open problem
About fifty-six nodes was the pond limit. What is the region’s?
The fifty-six-node allocator belonged to the broker, removed on 12 October 2026. The region that replaced it allocates per member; its allocator figure is known and its measured ceiling is not. That is the open problem now.
The broker spent a scarce carrier resource per tunnel. In a full mesh, tunnel count grows quadratically with node count, so the allocator reached its edge at roughly fifty-six nodes. That was an implementation problem, not an architectural limit.
The region moved allocation from per tunnel to per member: fdf-invite NAME gives each admitted member one edge address, the first free 10.253.X.Y, 64,008 per region, and each member keeps one tunnel, to the hub (opt/fdf/bin/fdf-invite, fdf-hub). The growth is linear. What nobody has measured is where a region actually stops: one host forwards every cross-site byte and holds one session per member, and the development network has a handful of machines.
Specification: §17 Known limits · §5 Addressing and routing
The useful question
With every member a peer of one WireGuard interface on one host, what gives out first — the hub’s forwarding, the RAM manager’s sessions, or the event rate each reconcile has to keep up with — and at how many members?
The useful test
Build a region with more members than anyone has run (the simulator or containers will do) and find the number. Routing correctness and resource consumption are measurable. A claimed ceiling has to survive the test.