E-food delivery is a trillion-dollar market.

And most of that trillion is not going to farmers, store owners, or the people who actually move food around. It's going to the infrastructure layer sitting between them — the platform tax, the per-order cut, the SaaS subscription that charges you to exist inside someone else's garden.

The walled garden isn't accidental. It's the product.

What if food delivery was a protocol, not a platform?

Not an app. Not a marketplace. A protocol — like HTTP, like SMTP — that any node can speak, that no single company owns, and that costs near zero to run.

That's what DIFP is. The Djowda Interconnected Food Protocol. An open wire format for connecting food ecosystem participants — farms, stores, restaurants, wholesalers, delivery nodes, end users — directly to each other, without a platform in the middle extracting rent at every step.

The spec covers:

• Presence & discovery — participants announce themselves to their spatial cell, others find them by location
• Orders, asks, and donations — not just commerce, but demand signals and surplus distribution in the same protocol
• Spatial routing — the MinMax99 grid maps the entire planet into ~500m cells; every message knows where it's going
• Decentralized registry — nodes find each other through a federated lobby system, no central server required

Version 0.4 of the spec dropped a few weeks ago. Today we're publishing the first working implementation.

The gRPC preview — what we built

DIFP-gRPC is a skull implementation of the full protocol stack over gRPC. Thin, end-to-end, every domain wired — nothing production-hardened yet, everything clearly marked for what it is.

What's inside

difp.proto — the entire DIFP v0.4 spec as a single protobuf file. Two services, 30+ message types, the full DifpEnvelope wrapper with a oneof payload that covers every domain:

message DifpEnvelope {
  string id      = 1;
  string type    = 2;   // "trade.ask" | "presence.announce" | "node.ping" | …
  string version = 3;

  MessageSender from   = 4;
  MessageTarget target = 5;
  MessageMode   mode   = 6;

  oneof payload {
    PresenceAnnouncePayload presence_announce = 20;
    TradeAskPayload         trade_ask         = 30;
    QueryCellPayload        query_cell        = 40;
    NodePingPayload         node_ping         = 52;
    RegistryAnnouncePayload registry_announce = 60;
    // … 25+ more
  }
}

DifpNodeServer.java — a Java gRPC node that implements the §18 processing pipeline:

1. Structural validation
2. Semantic validation (TTL, nonce)
3. Cryptographic check ← TODO: Ed25519 — placeholder for now
4. Payload validation
5. Handler dispatch
6. Propagation ← TODO: federation — placeholder for now

Every database interaction is an isolated, clearly named placeholder function. You replace them one at a time:

db_queryPresenceByCell()   // → your PostGIS / Firebase spatial query
db_createTrade()           // → your §9.1 atomic fan-out write
db_registerComponent()     // → your auth provider + persistent store

MainActivity.java — an Android test client with 6 flows you can run against a live node:

Running it

# Build and start the node
cd server\java\examples
.\gradlew.bat installDist
.\build\install\examples\bin\Difp-Node-Server
# INFO: Server started, listening on 50051

Open examples\android\ in Android Studio, forward the port, run a flow:

adb reverse tcp:50051 tcp:50051

That's it. The protocol is on the wire.

A note on what this actually is

This is not a product launch. It's a proof that the architecture works — that a food coordination protocol can run on commodity hardware over a standard transport, without a platform in the loop.

The "skull" framing is intentional. A skull is the minimum structure that proves the shape of the thing. Every component is present, nothing is missing, nothing is over-built. The placeholders are not laziness — they're the seams where your storage, your auth, your network plugs in.

What this means in practice

In the nearest future, a single node on a Raspberry Pi will be able to coordinate thousands of components — farms, stores, restaurants, delivery agents — for a local food network. No cloud bill. No per-transaction cut. No permission required from a platform to exist.

And because DIFP is just a protocol, the client can be anything. We wrote an Android app. But the wire format doesn't care. You could write a Python script. A web dashboard. A terminal client.

Yes, you could order groceries from your CLI. We're not stopping you.

What about donations and asks?

This is the part that doesn't exist in any commercial delivery platform, and it matters.

DIFP has three trade types — not one:

• Order — standard purchase
• Ask — a demand signal, broadcast to the network: "I need tomatoes, who has them?"
• Donation — surplus distribution: "I have 40kg of unsold bread, who needs it?"

All three travel on the same wire, through the same nodes, with the same routing. Food security and commerce aren't separate systems in DIFP. They're the same protocol.

Next on the roadmap

The skull proves the shape. The next iterations fill it in:

1. Stream broadcasting — push events to all subscribers in a cell (the missing piece that makes it feel live)
2. Real storage — swap the placeholder functions for your backend of choice
3. Ed25519 signing — message integrity per §15.3 of the spec
4. Federation — nodes announcing themselves to peer registries on startup
5. PAD catalog distribution — /.well-known/difp/pad/latest for the product database

Links

• 📄 DIFP Spec v0.4 — djowda.com/difp
• 💻 DIFP-gRPC repo — github.com/Djowda/DIFP-gRPC
• 🏗 Djowda on GitHub — github.com/Djowda

The repo is CC-BY 4.0. Fork it, implement it, build on it. If you're working on food infrastructure — especially in regions where the platform tax hits hardest — we'd love to hear what you're building.

Issues, PRs, and hard questions about the architecture are all welcome.

DIFP is an open protocol. No one owns the food network.