DEV Community: Djowda

The First Break on the Walled Garden — Rethinking e-Food Delivery as an Open Protocol

Djowda — Sat, 30 May 2026 03:20:36 +0000

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:

Structural validation
Semantic validation (TTL, nonce)
Cryptographic check ← TODO: Ed25519 — placeholder for now
Payload validation
Handler dispatch
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:

Flow	What it does
`computeCell`	Client-side MinMax99 — validates §3.3 reference vectors
`register`	Unary RPC — registers a component, receives a DID back
`queryCell`	Discovers nearby participants in a spatial cell
`ping`	Bidirectional stream — `node.ping` → `node.pong` + RTT
`tradeAsk`	Full `trade.ask` envelope broadcast via stream
`registryQuery`	Lobby → node lookup

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:

Stream broadcasting — push events to all subscribers in a cell (the missing piece that makes it feel live)
Real storage — swap the placeholder functions for your backend of choice
Ed25519 signing — message integrity per §15.3 of the spec
Federation — nodes announcing themselves to peer registries on startup
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.

We Open Sourced the Djowda Platform — Here Are 6 Challenges for the Community

Djowda — Mon, 20 Apr 2026 23:07:54 +0000

The WFP just released Hunger Map Live — a real-time global food insecurity dashboard. The timing felt right to contribute back.

Today we're open sourcing the Djowda platform architecture: a miniature reference implementation of one food ecosystem component, built on top of the DIFP protocol concept.

👉 github.com/Moses-Code-Dev/FoodSecurity-DIFP-Android-Playground

A note on what this is

The production codebase is going through a sanitization process — a single production component sits at ~250k lines of code. This release is intentionally simplified so that developers and AI tools can ingest the core architecture without noise.

The full codebase will be released gradually at github.com/Djowda over the coming months, component by component.

What you can build on top of this

🌍 Next-gen food coordination infrastructure
The DIFP protocol is designed for internationally interoperable food coordination. The repo is a working starting point. A Tunisian cooperative and an Indian marketplace speaking the same protocol, with zero custom integration — that's what this is pointing toward.

📍 Geo-targeted food discovery on live maps
The MinMax99 spatial grid bakes location into every message. Hyper-local, cell-based food visibility — collaborative, affordable, or free for producers who need reach without a marketing budget.

🎮 Interactive map engine for games
The MinMax99 grid is essentially a ready-made spatial coordinate system. Lords of Mobile-style interactive maps, powered by native in-device Android code, are a natural derivation. The IP is there if you want to use it.

6 Challenges for the community

These are genuine open problems. If you work on any of them, open an issue or share what you find.

Challenge 1 — Web version across 6 components
Build a web implementation covering at least 6 different food ecosystem component types (farmer, store, wholesaler, restaurant, delivery, user) that all speak the same DIFP protocol without breaking interoperability. Bonus: make them federate across two independent nodes.

Challenge 2 — Jetpack Compose port
Rewrite the existing component in Jetpack Compose. A good test of how well the architecture holds up across UI paradigms — and a useful contribution if you get it right.

Challenge 3 — Android Gemini fused response renderer
This one is genuinely unsolved and widely needed: build an Android library for rendering mixed UI from a single AI response message — text, chart, grid of items, and action buttons all in one response surface. The current Gemini SDK on Android doesn't handle this cleanly. If you solve it, it's useful well beyond this repo.

Challenge 4 — MinMax99 map overlay
Overlay the MinMax99 grid as a layer on top of existing map engines — Google Maps, OpenStreetMap, Mapbox. Build a layer switcher. Visualize cell boundaries, cell IDs, and participant density per cell. This would be a powerful tool for anyone using the protocol.

Challenge 5 — Stress test at scale
Simulate millions of concurrent users on the coordination layer. Document what breaks first. We have assumptions about Firebase fan-out performance at scale that have not been tested under real load. If you run this, share the numbers.

Challenge 6 — AI coding benchmark
Can your AI coding tool produce a production-ready DIFP component from the spec alone?

Test it. Take the DIFP v0.2 specification, give it to Claude, Gemini, Copilot, or whatever tool you use, and ask it to build a conformant node component. Document what it gets right, what it misses, and where the spec needs to be clearer. This is useful both as a benchmark and as protocol feedback.

Repo details

License:   AGPL-3.0
Protocol:  DIFP v0.2 (message envelope + spatial grid)
Platform:  Android (Java)
Status:    Miniature reference — full releases at github.com/Djowda

⚠️ Before publishing any derivative app: rename the package identifier to avoid Play Store conflicts. The Djowda name and logo are trademarks — see the README for full notices.

We Open-Sourced a Protocol to Fix How the Food Supply Chain Talks to Itself

Djowda — Wed, 11 Mar 2026 02:21:29 +0000

Almost one billion people face food insecurity every year — not because the world doesn't produce enough food, but because the coordination infrastructure between producers and consumers is broken.

Farmers don't know who needs what. Stores don't know what's available 2km away. Surplus rots while scarcity persists — sometimes in the same city block.

We spent years building a prototype to solve this. Today we're publishing the protocol that powers it.

👉 djowda.com/difp — DIFP v0.1, Provisional Specification · CC-BY 4.0 · Free to implement

What DIFP actually is

DIFP (Djowda Interconnected Food Protocol) is a lightweight, open, spatial food coordination protocol. It defines:

Participant identity — how food ecosystem actors identify themselves globally without a central registry
Spatial addressing — how Earth's surface is divided into ~500m × 500m cells, each acting as a coordination zone
Presence & discovery — how participants announce and find each other within and across cells
The trade message format — a universal structure for orders, asks, and donations between any two participants
Protocol federation — how independent DIFP nodes interoperate without a central broker

It is transport-agnostic. The reference implementation uses Firebase Realtime Database. Conformant implementations may use REST, WebSockets, MQTT, or anything equivalent.

The problem it solves for developers

Right now if you're building a grocery delivery app, a farm management tool, a restaurant POS, or a truck routing system — you're building in isolation.

There's no shared layer. No common identity. No standard way to say "I'm a farmer at this location with these items available." Every integration is custom. Every partnership is a new API contract.

DIFP proposes a fix: one protocol, one grid, one trade message format.

Any two systems that implement DIFP can discover each other, exchange availability data, and complete trades — with zero custom integration work.

The spatial grid — the core innovation

The foundational piece of DIFP is a deterministic global grid called MinMax99.

The entire surface of Earth is divided into ~3.44 billion cells, each 500×500 meters. Every participant gets a cell ID derived from their GPS coordinates using a single pure-math function:

public static long geoToCellNumber(double latitude, double longitude) {

    // Longitude → x in meters (linear)
    double x = (longitude + 180.0) * (EARTH_WIDTH_METERS / 360.0);

    // Latitude → y in meters (Mercator, origin at top)
    double y = (EARTH_HEIGHT_METERS / 2.0)
             - Math.log(Math.tan(Math.PI / 4.0 + Math.toRadians(latitude) / 2.0))
               * (EARTH_HEIGHT_METERS / (2.0 * Math.PI));

    // Meters → cell indices
    int xCell = (int) Math.floor(x / CELL_SIZE_METERS);  // CELL_SIZE_METERS = 500
    int yCell = (int) Math.floor(y / CELL_SIZE_METERS);

    // Clamp + encode
    xCell = Math.max(0, Math.min(xCell, NUM_COLUMNS - 1));  // NUM_COLUMNS = 82,000
    yCell = Math.max(0, Math.min(yCell, NUM_ROWS    - 1));  // NUM_ROWS    = 42,000

    return (long) xCell * NUM_ROWS + yCell;
}

Grid constants (all conformant implementations MUST use these exactly):

EARTH_WIDTH_METERS  = 40,075,000
EARTH_HEIGHT_METERS = 20,000,000
CELL_SIZE_METERS    = 500
NUM_COLUMNS         = 82,000
NUM_ROWS            = 42,000
TOTAL_CELLS         ≈ 3.44 billion

Reference test vectors to validate your port:

Location	lat, lng	Cell ID
Algiers, Algeria	36.7372, 3.0868	3440210
Paris, France	48.8566, 2.3522	3467891
Tokyo, Japan	35.6762, 139.6503	6543210
New York, USA	40.7128, -74.0060	1823445

Why a grid instead of geo-queries?

Discovery is O(1). To find all stores near a farmer, query the farmer's cell + immediate neighbors. No radius search. No expensive geo API call.
Cells are lobbies. All components in the same cell share context — they can discover each other without knowing each other in advance.
Works offline. Cell IDs are computed client-side from GPS. No server round-trip needed to know your own address.
Cheap at scale. A Firebase equalTo(cellId) query is fast and inexpensive. No PostGIS, no Elasticsearch geo-shape queries.

Neighbor resolution

def get_nearby_cells(center_cell_id, radius):
    xC, yC = cell_number_to_xy(center_cell_id)
    result = []
    for dx in range(-radius, radius + 1):
        for dy in range(-radius, radius + 1):
            x = clamp(xC + dx, 0, NUM_COLUMNS - 1)
            y = clamp(yC + dy, 0, NUM_ROWS - 1)
            result.append(x * NUM_ROWS + y)
    return result

Radius	Grid	Cells	Coverage
0	1×1	1	~0.25 km²
1	3×3	9	~2.25 km²
2	5×5	25	~6.25 km²
5	11×11	121	~30 km²

Participant identity — DIDs without a blockchain

DIFP uses a Decentralized Identifier (DID) scheme that requires no central authority and works offline:

difp://{cellId}/{typeCode}/{componentId}

# Examples
difp://3440210/f/ali-farm-01       # Farmer in cell 3,440,210 (Algiers)
difp://3440210/s/safeway-dz-042    # Store in same cell
difp://1820044/fa/cevital-plant-1  # Factory in cell 1,820,044

Ten canonical component types:

Code	Actor
`sp`	Seed Provider
`f`	Farmer
`fa`	Factory
`w`	Wholesaler
`s`	Store
`r`	Restaurant
`u`	User / Consumer
`t`	Transport
`d`	Delivery
`a`	Admin

The trade message — one format for everything

All exchanges in the food ecosystem — commercial orders, donation offers, resource requests — are modeled as Trades between exactly two participants.

Three trade types:

Code	Type	Description
`o`	Order	Purchase request with items, quantities, prices
`a`	Ask	Demand signal — "I need this, who has it?"
`d`	Donation	Surplus signal — "I have this, who needs it?"

The Ask and Donation types are first-class citizens of the protocol, not afterthoughts. They're how DIFP addresses food insecurity directly — signaling surplus and scarcity without requiring a commercial transaction.

Trade message schema

{
  "sId": "difp://3440210/f/ali-farm-01",
  "sT":  "f",
  "sC":  "3440210",
  "rId": "difp://3440210/s/safeway-dz-042",
  "rT":  "s",
  "rC":  "3440210",
  "ty":  "o",
  "st":  "p",
  "items": {
    "difp:item:dz:vegetables:tomato_kg:v1": { "q": 50, "p": 80, "u": "kg" }
  },
  "total":     4000,
  "listSize":  1,
  "createdAt": 1710000000000,
  "info": { "phone": "+213...", "address": "...", "comment": "" }
}

Status lifecycle

PENDING (p)
    │
    ├── receiver accepts ──► ACCEPTED (a)
    │                              │
    │                              └──► PROCESSING (pr) ──► COMPLETED (c) ✓
    │
    ├── receiver denies ──► DENIED (dn) ✗
    │
    └── sender cancels  ──► CANCELLED (x) ✗

The four-node atomic write pattern (fan-out)

Every trade touches four Firebase nodes in a single atomic updateChildren() call. No partial writes. No race conditions.

TD/{tradeId}                                    ← canonical full record
T/{senderType}/{senderId}/o/{tradeId}           ← sender outbox summary
T/{receiverType}/{receiverId}/i/{tradeId}       ← receiver inbox summary
TA/{tradeId}                                    ← analytics (no PII)

Map<String, Object> updates = new HashMap<>();
updates.put("TD/" + tradeId, tradeData);
updates.put("T/" + senderType + "/" + senderId + "/o/" + tradeId, senderSummary);
updates.put("T/" + receiverType + "/" + receiverId + "/i/" + tradeId, receiverSummary);
updates.put("TA/" + tradeId + "/createdAt", timestamp);
updates.put("TA/" + tradeId + "/senderCell", senderCell);
updates.put("TA/" + tradeId + "/receiverCell", receiverCell);

db.updateChildren(updates); // atomic

The TA (analytics) node tracks timing and cell pairs for map-route animation — and must never contain PII (no phone numbers, no addresses, no item details).

The catalog system — PAD + live sync

DIFP separates item metadata (static) from availability and pricing (live).

PAD (Pre-loaded Application Data): ~6,000 items per country per component type, distributed as a compressed package with the app. Contains item names (multilingual), categories, units, thumbnail references. Never changes at runtime.
Live sync: Only price and available travel over the wire during normal usage.

This means a farmer's app works in a village with 2G. The catalog is already on-device. Only the delta syncs.

Item identity is globally namespaced:

difp:item:{countryCode}:{category}:{itemSlug}:{version}

# Examples
difp:item:dz:vegetables:tomato_kg:v1
difp:item:in:grains:basmati_rice_kg:v2
difp:item:fr:dairy:camembert_250g:v1

Protocol federation

DIFP is designed for independent operators — NGOs, national food agencies, regional cooperatives — to run their own nodes and interoperate.

Every conformant node exposes:

GET https://{host}/.well-known/difp/info
# Returns: protocol version, nodeId, cell coverage, federated peers

GET https://{host}/.well-known/difp/cell/{cellId}
# Returns: all PresenceRecords in that cell

POST https://{host}/.well-known/difp/trade/incoming
# Accepts: signed TradeMessage from another DIFP node

A Tunisian cooperative and an Indian marketplace running separate DIFP nodes can discover each other's participants and complete cross-node trades with zero custom integration — because they speak the same protocol.

How to implement (minimum viable node)

Step 1 — Port the grid algorithm. Validate against the reference test vectors above. This is the only piece that MUST be bit-for-bit identical across all implementations.

Step 2 — Stand up a presence store. Any backend (Firebase, PostgreSQL + PostGIS, DynamoDB). Index by cell_id + component_type. Expose the /.well-known/difp/ endpoints.

Step 3 — Implement the trade engine. Four-node write pattern. Role-based status transitions. Atomic writes.

That's a working DIFP node. Steps 4 (catalog) and 5 (federation) can be added incrementally.

A working node with 10 participants is more valuable than a perfect spec with zero.

What this means for AI + food

One thing we didn't anticipate when designing this: DIFP makes food data natively queryable by AI systems.

Because every participant has a DID, a cell ID, a typed presence record, and a live catalog — any AI assistant with access to a DIFP node can answer questions like:

"Which farmers within 3km have tomatoes available right now?"
"What's the current wholesale price of potatoes in this region?"
"Which stores near me are broadcasting a donation?"

No scraping. No stale listings. Live, structured, geographic data — in a format any system can query.

Current status & what's next (v0.2 targets)

ID	Topic
A	Ed25519 message signing for trustless cross-node verification
B	Supply & Demand Radar — Ask/Donation signals aggregate into cell-level heat maps
C	Map route animation from TA cell pairs
D	MQTT profile for IoT farm sensors
E	USSD/SMS fallback for participants with no smartphone
I	Conformance test suite

Read the spec. Build on it. Break it.

Full specification: djowda.com/difp

Download: DIFP-v0.1-Provisional.docx

Contact: sales@djowda.com

License: CC-BY 4.0 — free to implement, fork, extend, and commercialize. Credit required.

The food system doesn't need another closed platform. It needs a shared language.

We just published ours. 🌍