The first Pizza4People order I cared about this week was not a real pizza order.
It was a restart test.
I sent one synthetic order into the pilot node, checked that it had been stored, stopped the process, started it again with the same database and node identity, and looked for the order.
It was still there.
The pizza was synthetic. The restart was not.
That is a small result, but it is the kind of small result Pizza4People needs now. I have already written about why a restaurant should own its menu, its customer relationship and its ability to take an order. I have already argued that the protocol matters more than another marketplace app. The next phase is less philosophical.
Does the system keep working when something stops, restarts or receives a bad request?
At the local checkpoint on 6 November 2026, the answer became slightly more concrete.
What works now
The earlier P4P proof already showed direct test ordering and registry failover. This checkpoint adds persistence and operator control.
The full local check completed 312 tests, with two intentional skips. The documented health command passed against the reference client, two registries and one node registered with both.
Then I stopped the primary registry.
The backup registry still found the same node. The menu remained available directly from the restaurant node. A valid test order could still be sent directly to it.
The controlled pilot also passed its readiness checks in both modes: first in menu_only, where customers may read the menu but cannot place orders, and then in the local software mode named live, after an explicit activation. Both checks reported 22 passes and no warnings or failures.
An order also has to survive the software stopping. The synthetic order remained after a restart because it lived in the node's SQLite database instead of only in process memory.
The node identity persisted too. When I deliberately changed its cryptographic signing identity while reusing the same node id, the registries rejected the mismatch. In practical terms, different software could not quietly present itself as the same restaurant.
That is useful failure behavior. A restarted process should not forget the order queue. A changed identity should not silently become the same restaurant.
None of this happened on the public internet. The registries were temporary local processes. There was no real restaurant, printer or customer. The test proves a local runtime path, not a live business.
The 100-pizza question
The question that keeps bothering me is also the obvious one: what stops somebody from pretending to be 100 customers and ordering 100 pizzas?
The honest answer is that no single control makes that impossible.
The current pilot instead places several boundaries before a fake order can become wasted food.
A hosted node always starts in menu_only. Moving it into the order-accepting live mode requires persistent storage, a persistent identity, a strong operator token and a completed setup receipt. New orders enter as new. Payment and print actions do not run until the restaurant operator explicitly accepts the order.
The node also limits order size, total value and queue depth. By default it allows no more than 50 active orders, 25 pending orders and three pending orders for the same customer contact. Requests are also throttled per resolved client address.
A network retry should not create a second pizza. Every submission therefore carries a stable request key called client_request_id. Repeating the same request returns the original order; reusing the key with different order data is rejected.
The operator can reject an order before cooking, return the node to menu_only, or close ordering entirely.
Because the first pilot uses pay-at-pickup, Pizza4People is not holding card details or customer money. That narrows the damage, but it does not make abuse irrelevant. A full fake queue can distract staff. A careless operator can accept a bad order. Food can still be wasted.
The practical safety model is therefore not “fraud solved”. It is smaller:
A request is not yet a pizza in the oven.
For a controlled pilot, manual acceptance and visible limits are a reasonable place to begin. They are not a reason to open 100 restaurants tomorrow.
What is still not live
Pizza4People currently has a public website and a public GitHub repository. That is not the same as public protocol infrastructure.
The intended registry and client subdomains still point at the static host, and the certificate does not cover the dynamic subdomains needed for the proof. The current local checkpoint therefore does not establish a public primary registry, a genuinely independent backup registry, valid hosted discovery or a public restaurant node.
It also does not establish the physical last meter: a screen in a pizzeria, an operator accepting an order during service, a printer producing a kitchen ticket, or a real customer collecting and paying for food.
Those missing pieces matter because a repository can be internally correct while the deployed system is unusable. A local failover test can pass while both public registries later fail together because they were placed on the same infrastructure. A software order can persist while the restaurant never notices it.
The proof has to move outward one layer at a time.
The next real step
The next P4P milestone is not 100 restaurants. It is not an app-store launch, an investor deck or a promise that the security problem has disappeared.
It is a narrow public proof:
- one real primary registry;
- one genuinely independent backup registry;
- valid DNS and TLS;
- one public node that registers with both;
- a complete hosted readback of discovery, menu and order behavior;
- then one controlled restaurant pilot with an operator who can still say no.
That is less dramatic than saying Pizza4People is live.
It is also more useful.
The project has reached the uncomfortable stage where the next important bug may not be hiding in the local code. It may be in DNS, hosting, certificates, deployment, hardware or the way a busy person reacts when an unexpected order appears.
The next problem is no longer whether I can make the order survive on my own machine.
It is whether I am willing to put the registry on the public internet and let reality answer back.
The code, proof boundaries and current technical status remain public in the Pizza4People repository. The broader argument is in How to Take Wolt's Market Without Becoming Wolt.
— Dennis Hedegreen
