FrogNet is running. It is not finished.
The Guild is for the people who want to argue with the architecture, reproduce the measurements, attack an open problem, or build something nobody has tried yet.
You do not have to agree with FrogNet to belong in that conversation. Counterexamples, failed experiments and better designs all move the work forward.
The interesting parts are not all settled.
FrogNet was built from one perspective. Some decisions will survive hard use. Some will not. The way to find out is to put them under load, break links, change hardware, challenge assumptions, and bring back evidence.
Argue with it
Read the architecture and the evidence. If a claim is wrong, identify the assumption, construct the counterexample, and show it.
Reproduce it
Run the benchmarks and demonstrations on different machines and paths. Reference measurements are not portable limits; more measurements make the map better.
Extend it
Use the programming surface somewhere it has not been used yet. The point of the project is not to preserve the current inventory. It is to find out what else becomes possible.
About fifty-six nodes should not be the pond limit.
The current tunnel allocator spends a scarce carrier resource per tunnel. In a full mesh, tunnel count grows quadratically with node count, so the allocator reaches its edge at roughly fifty-six nodes. That is an implementation problem, not a claimed architectural limit.
The replacement design moves allocation from per tunnel to per node. That changes the resource growth from quadratic to linear and moves the projected ceiling to the addressing plan itself, roughly 59,500 nodes. The replacement is in development; it has not landed.
The useful question
How should permitted address ranges, carrier identity and broker namespace change when many peers share the same WireGuard interface without introducing ambiguous return paths?
The useful test
Build a topology that fails under the current allocator and passes under the replacement. Routing correctness and resource consumption are measurable. The proposal has to survive the test.
The allocator is only the easiest open problem to point at.
FrogNet crosses routing, distributed state, semantic wire protocols, radios, media, shared RAM, Redis compatibility, distributed training, residency, simulation and application design. Each area has seams where another engineer can attack the current answer or try a different one.
Network
Routing, discovery, broker behavior, split/heal behavior, radios, addressing and scale.
Living Network →Programming model
Memory addressing, held reads, Regions, participants, residency and application structure.
Memory and Ribbit →Qualification
Redis, PyTorch, Communicator, semantic transport, failure injection and benchmarks.
Evidence →Bring an argument that can be tested, along with code or measurements when you have them.
Start wherever you have something useful to test.
FrogNet is GPLv2-only. You can inspect it, run it, modify it and test it under that license. If you find a defect, a counterexample, a better mechanism, or a new use, that is exactly the kind of result the Guild exists to surface.