P4P Pizza4People

Public protocol / controlled live pilot

A pizza shop should be able to keep its menu and take orders direct.

Pizza4People is a public proof of one small thing: the customer can discover a restaurant through a public registry, but the menu and the order go straight to the shop. The first live shape is intentionally narrow: direct pickup orders and simple pay-at-pickup before anything broader.

Public proof now Pickup-first pilot next Not a marketplace app
If you run a pizzeria See the proof Code / protocol

More routes: 60-second version / Proof note / Broader vision / Press kit DK / Press kit EN

Diagram showing client discovery through registries and direct menu/order flow to the restaurant node.
Discovery can go through registries. Menu and orders go directly to the restaurant node.

Status: public protocol proof with a controlled live-pilot path, not broad production infrastructure. Just Eat Takeaway.com announced 30 April 2026 as the date its Danish operations would conclude. Source.

If You Run A Pizzeria

This is the simple version.

Pizza4People is trying to keep the basic digital connection in the restaurant's hands. The first live shape is intentionally small: controlled pickup orders, direct menu control, and simple payment at pickup before anything broader.

You keep your own menu

Names, prices, categories, and active items stay with the restaurant node instead of living only inside a marketplace listing.

Orders go directly to the shop

The customer can discover through a registry, but the menu and order request go straight to the restaurant node.

Start with pickup and simple payment

The first live shape is intentionally small: controlled pickup ordering, with pay-at-pickup as the simple starting point.

Add tools without giving away ownership

Kitchen screen, print, notifications, stock checks, and later trust or payment modules can be added without turning the registry into the middleman.

How The Pieces Fit

Start with what matters to the shop, then open the details only if needed.

The list below is intentionally written for first understanding, not for manifest reading. Each box opens into the technical links only when you need them.

Payment stays narrow on purpose. P4P does not hold funds, process payments, store payment credentials, settle money, or act as merchant of record.

If modules make no sense yet, start with the simple guide inside the module pages.

If you want the full public reading path for the module layer, open the dedicated module pages.

The current public catalog points to 1 readable provider identity page as a separate human layer: open provider catalog.

What the customer sees

These are the public surfaces a customer can actually open during discovery and ordering.

Customer side

Simple online menu

A customer opens a normal menu list and sends the order directly to the restaurant.

Shown in proof Click for details

For a pizzeria: You keep the menu basics on your own node instead of relying on a marketplace-owned list.

Touches
Active items, prices, descriptions, and categories.
Does not own
It does not own payment, stock, or staff workflow.
Current state
available as the pilot-node customer menu list route when enabled
Technical id
p4p.menu.list

More info: Open full module page / Open provider page / Open manifest

Customer side

Clickable photo-style menu

A customer taps a paper-menu style surface instead of a plain item list.

Shown in proof Click for details

For a pizzeria: Useful if you want the customer surface to feel closer to a printed flyer or visual takeaway menu.

Touches
Active items, prices, descriptions, and categories.
Does not own
It does not own OCR, payment, stock, or operator workflow.
Current state
available as the pilot-node photo map menu route when enabled
Technical id
p4p.menu.photo-map

More info: Open full module page / Open provider page / Open manifest

Customer side

Order status page

A customer can check whether the order was accepted, rejected, or is ready for pickup.

Shown in proof Click for details

For a pizzeria: Reduces the need for status phone calls when the restaurant updates the order state.

Touches
Order status, estimated ready time, fulfillment type, and payment mode.
Does not own
It does not expose operator notes, customer contact data, or the full event log.
Current state
available in the pilot-node public order-status route when enabled
Technical id
p4p.customer.status

More info: Open full module page / Open provider page / Open manifest

What the shop uses behind the counter

These are the restaurant-side tools for menu control, kitchen flow, stock, printing, and fallback alerts.

Owner / operator side

Edit menu and prices

The restaurant can change names, prices, categories, and whether an item is active.

Operator-side prototype Click for details

For a pizzeria: This is the control surface that lets the shop own its own menu instead of waiting for a platform back office.

Touches
Item ids, names, descriptions, prices, categories, and active/inactive state.
Does not own
It is not a customer-facing menu page.
Current state
available in the pilot-node operator dashboard when enabled
Technical id
p4p.catalog.editor

More info: Open full module page / Open provider page / Open manifest

Owner / operator side

Scan a paper menu

The restaurant can scan a paper menu into draft catalog rows before a human review.

Operator-side prototype Click for details

For a pizzeria: Useful when a shop starts from a printed takeaway card instead of rebuilding the whole menu by hand.

Touches
Draft OCR item names, prices, categories, and source lines before catalog save.
Does not own
It does not become catalog truth by itself and it is not a customer-facing menu.
Current state
available in the pilot-node operator dashboard when enabled alongside the catalog editor
Technical id
p4p.catalog.import.ocr

More info: Open full module page / Open provider page / Open manifest

Owner / operator side

Kitchen order queue

Staff can see incoming orders and move them through kitchen states.

Operator-side prototype Click for details

For a pizzeria: Lets the restaurant turn direct orders into an actual working queue behind the counter.

Touches
Order items, note, customer contact, fulfillment type, and order status.
Does not own
It is not public discovery and it does not own payment.
Current state
available in the pilot-node operator dashboard when enabled
Technical id
p4p.kitchen.screen

More info: Open full module page / Open provider page / Open manifest

Owner / operator side

Final stock check

The system can do one last local stock check before the next order step continues.

Operator-side prototype Click for details

For a pizzeria: Helps stop the flow before the kitchen commits to something the shop no longer has.

Touches
Order items and local stock state.
Does not own
It does not replace the menu or the kitchen workflow.
Current state
available in the pilot node when enabled
Technical id
p4p.stock.basic

More info: Open full module page / Open provider page / Open manifest

Owner / operator side

Print to kitchen or POS

Accepted orders can later be printed or forwarded to a restaurant-owned printer or POS surface.

Planned next Click for details

For a pizzeria: This is the bridge from a direct online order to a paper ticket or POS flow inside the shop.

Touches
Order items, note, contact, and fulfillment type.
Does not own
It does not replace payment or public discovery.
Current state
not enabled
Technical id
p4p.order.print

More info: Open full module page / Open provider page / Open manifest

Counter / hardware side

Backup printer path

If the first printer path fails, the order can be rerouted to a second print target or local spool.

Operator-side prototype Click for details

For a pizzeria: Useful when a shop wants hardware redundancy before trusting direct orders during busy service.

Touches
Order items, note, customer contact, fulfillment type, and backup printer target.
Does not own
It is fallback routing, not the main customer or kitchen workflow.
Current state
builtin operator self-test lane when enabled and configured
Technical id
p4p.order.print.backup

More info: Open full module page / Open provider page / Open manifest

Owner / operator side

Operator email alert

The system can send an email when an order needs attention or a printer flow fails.

Planned next Click for details

For a pizzeria: Useful as a fallback alert so the shop is not blind if another operator-side step fails.

Touches
Order summary and the operator destination address.
Does not own
It is a fallback notification, not the main order surface.
Current state
not enabled
Technical id
p4p.notify.email

More info: Open full module page / Open provider page / Open manifest

Owner / operator side

Operator SMS alert

The system can send a short phone alert when an order or printer problem needs fast attention.

Planned next Click for details

For a pizzeria: Useful if the test hardware is noisy or partially unattended and the operator still needs a direct phone fallback.

Touches
Order summary and the operator phone destination.
Does not own
It is a fallback notification, not the main order surface.
Current state
not enabled; candidate phone fallback lane for a five-place hardware trial
Technical id
p4p.notify.sms

More info: Open full module page / Open provider page / Open manifest

Counter / hardware side

Bell or light alert

A local box can ring, beep, or flash when a new order or hardware problem needs attention.

Operator-side prototype Click for details

For a pizzeria: Lets the hardware give an audible or visible cue without turning the alert layer into the actual order queue.

Touches
Order summary, configured alert target, and urgency state.
Does not own
It does not accept orders, replace the kitchen queue, or settle payment.
Current state
builtin operator self-test lane when enabled and configured
Technical id
p4p.order.alert.basic

More info: Open full module page / Open provider page / Open manifest

Counter / pickup side

Ready-for-pickup board

A simple local screen can show which direct orders are accepted or ready at the counter.

Operator-side prototype Click for details

For a pizzeria: Gives the shop a cheap customer-facing pickup signal without exposing the full operator dashboard.

Touches
Order summary, public order status, estimated ready time, payment mode, and board target.
Does not own
It does not take new orders or replace the kitchen queue.
Current state
builtin local counter surface when enabled and configured
Technical id
p4p.pickup.board.basic

More info: Open full module page / Open provider page / Open manifest

Payment and business trust

This is where payment stays intentionally simple and where identity or business verification can later become reviewable.

Customer + operator side

Pay at pickup / cash

The restaurant can keep payment simple by taking cash or direct in-person payment outside the protocol.

Shown in proof Click for details

For a pizzeria: This is the easiest first live shape: order online, pay when the customer arrives.

Touches
Order total and fulfillment type only.
Does not own
It does not hold card data, wallets, settlement, or merchant-of-record responsibility.
Current state
enabled in the demo node and executable in the pilot node when enabled
Technical id
p4p.payment.cash

More info: Open full module page / Open provider page / Open manifest

Customer + operator side

External MobilePay adapter

A future external adapter can expose a familiar MobilePay-style pay-at-pickup instruction without making P4P the payment processor.

Planned next Click for details

For a pizzeria: Lets pilot restaurants say whether an external MobilePay-style adapter is worth adding after cash-first feedback.

Touches
Order total, fulfillment type, and operator payment destination.
Does not own
It does not make P4P hold funds, process cards, or become merchant of record.
Current state
not enabled; external-developer invitation only after cash-first pilot feedback
Technical id
p4p.payment.mobilepay

More info: Open full module page / Open provider page / Open manifest

Trust layer

Business identity check

A later trust layer can connect a node identity claim to a Danish CVR lookup or trust claim.

Trust direction Click for details

For a pizzeria: This is meant to make a restaurant identity more reviewable later without turning the registry into the authority.

Touches
Declared CVR identifiers and public node identity data.
Does not own
It is not part of the live ordering loop today.
Current state
not enabled
Technical id
p4p.trust.cvr-basic

More info: Open full module page / Open provider page / Open manifest

Internal tests and future extras

These modules are not the live restaurant offer today. They are internal test scaffolding or planned next-step pieces.

Internal debug

Fake payment tester

An internal mock can randomly accept or reject a test payment during local debugging.

Internal test only Click for details

For a pizzeria: Not something a restaurant should read as a live offer. It exists to test ugly edge cases before any real payment direction exists.

Touches
Order total only.
Does not own
It is not real money, not real settlement, and not a real provider.
Current state
executable in pilot-node when explicitly selected
Technical id
p4p.payment.godpay-mock

More info: Open full module page / Open provider page / Open manifest

Internal debug

Ugly-case payment tester

An internal mock for timeouts, wrong amounts, duplicate callbacks, and other payment chaos scenarios.

Internal test only Click for details

For a pizzeria: This exists to break things safely in local testing before any broader payment layer is discussed.

Touches
Order total and order state.
Does not own
It is not real money, not real settlement, and not a live customer payment option.
Current state
declared only; scenario executor intentionally not enabled yet
Technical id
p4p.payment.chaospay-mock

More info: Open full module page / Open provider page / Open manifest

For journalists

The story is ready to discuss. The live restaurant pilot is still being prepared.

Pizza4People can be covered now as a public protocol proof responding to a real market exit. The careful wording is important: this is not a finished replacement for Just Eat, not a delivery company, and not a production restaurant network yet.

What is public now

Public main repo, public proof note, readable protocol/spec docs, schemas, reference code, and an independent node interop kit.

What is being tested next

Several independent people can build their own nodes and check whether they interoperate before the first real pickup-order pilot goes live.

What changed in the module layer

The public repo now includes replaceable customer menu modules, internal mock payment modules, operator workflow modules, and a money contract where prices are integer minor units with an explicit node currency.

What the first pilot means

One restaurant-owned node, one primary registry, one backup registry, and explicit operator approval before live pickup orders.

Where to verify

The public repo is the conservative story branch. The proof site and the broader protocol-family framing remain the narrowest public places to verify what exists now.

Press kit

Open the press kit in Danish or English. PDF exports remain artifacts; the HTML kits are the maintained source.

The story

Start with the restaurant, not the marketplace.

The point is not to launch another giant food app. The point is to let a pizzeria keep the basic connection: its own menu, its own direct order endpoint, and a small pickup-first flow it can actually control. This public proof is the first step toward that.

In one sentence

The customer finds the shop through a public directory, but the menu and order go straight to the shop.

What you can see already

Four visible things, no protocol knowledge required.

1

Find a pizzeria

The client asks a registry for nearby restaurant nodes and can discover a public proof node now.

2

Open the menu

The menu is fetched from the restaurant node, either as structured items or through a photo-map view of a paper menu fixture.

3

Send a test order

The order goes directly to the node. In the public proof this is a test order; in the pilot it becomes explicit restaurant-approved pickup ordering.

4

Break the primary registry

Discovery still works through a backup registry because the node announced itself to both.

Problem

A market exit exposes who owns the basic connection.

Closed marketplaces can be useful, but they also concentrate discovery, customer access, order intake, and commercial terms in one place. When a platform leaves, restaurants and customers should not have to rebuild the basic contact layer from zero.

For a journalist, the story is not "new pizza app". The story is whether basic local commerce should depend on one private discovery and ordering silo at a time.

Proof

The public proof demonstrates one narrow loop.

01

Discover

A client asks a registry for nearby pizza nodes. This is the phone book part.

02

Fetch menu

The client requests the menu directly from the selected node. The registry is not the menu owner.

03

Send direct order

The client sends the order directly to the node. Public proof orders remain test orders until a restaurant operator explicitly enables live mode.

04

Fail over

If the primary registry disappears, discovery can still work through a backup registry.

Press takeaway

This is not a replacement for Just Eat today. It is a working argument for an open base layer.

A company can still build delivery, payments, support, loyalty, analytics, or hosting on top. The point is that no single company should have to own discovery, identity, and the first restaurant-customer contact for the system to work.

What this proves

  • Public discovery can be separated from order handling.
  • Menu and test order requests can go directly to the node.
  • A node can sign announcements with its own key.
  • A registry can record public identity events without holding node private keys.
  • Menu prices can carry explicit currency and integer minor-unit amounts without P4P doing currency conversion.

What this does not prove

  • No production security claim.
  • No broad production restaurant network yet.
  • No real payment processing, delivery, CVR verification, or certification yet.
  • No claim that registries automatically synchronize.

Trust direction

Identity belongs with the node.

The current P4P direction is node-owned identity. A node signs its own announcement. A registry verifies the node signature, records an identity event, and can later publish signed snapshots. The registry does not need the restaurant's private key.

node signs registry verifies event is logged snapshot can be signed client can verify

Proof gate

Selective outreach can point to the public repo. Broad launch still waits for the live-pilot dry run.

Roadmap

From public protocol proof to controlled live pilot.

  1. Public protocol. Clean GitHub repository, readable proof note, spec, schemas, reference implementation, and a short GitHub reading path.
  2. Controlled restaurant pilot. One real restaurant node, primary registry, backup registry, and explicit operator approval before live orders.
  3. Module manifests. Provider declarations with data-access boundaries, including menu, order, status, kitchen, stock, print, and internal mock payment modules.
  4. Trust and federation. CVR binding, signed snapshots, scoped registries, and reviewable trust claims.

Next gate

These surfaces are real and already built, but they belong to the pilot-node path after the current public proof. They are not the narrow v0.1 proof loop itself.

Curated tablet plate of the P4P operations room showing kitchen flow, order status, and local node state.
Pilot-node / next gate Local operations room

What the restaurant will control locally when the controlled pilot opens.

/operator
Curated tablet plate of the P4P catalog room showing local menu items and editing controls.
Pilot-node / next gate Catalog and menu

Menu editing belongs to the shop, not to the discovery layer.

/operator/catalog
Curated tablet plate of the P4P modules room showing current modules, desired modules, and restart-required truth.
Pilot-node / next gate Modules on the node

The pilot node shows clearly when the running module set and the desired module set differ.

/operator/modules

Contact

This is a public protocol proof and controlled pilot path, not a commercial marketplace launch.

For technical review, protocol questions, or press context: hedegreen.research@gmail.com.

Source and protocol work: https://github.com/DennisHedegreen/p4p.

Broader protocol-family direction: https://protocols4people.com/.

Pizza4People is the concrete restaurant-ordering proof. Protocols4People is the broader protocol-family direction.