DEV Community: Djowda

Introducing a Real-Time World Food Map — here's how it works (and how to query it with Python)

Djowda — Mon, 15 Jun 2026 14:40:48 +0000

A real-time world map where anyone, anywhere on earth can list food, ask for it, or donate it — and be seen instantly, globally — with no account, no backend, and no central server.

This post covers:

What we built and why
The architecture behind it (Nostr + DIFP geo-grid)
A Python script to query any cell on the network right now
What's coming next (three-way trades + Trade on Map)

The problem we're trying to solve

The global food system is enormously centralized. Platforms extract rent from every transaction between producers and consumers. Farmers in a village can't be discovered by someone 10km away without paying a marketplace. During a disaster, there's no open channel to broadcast "I have food here" or "we need food here" without going through a gatekeeper.

We wanted to build the infrastructure layer that makes that possible. Open, permissionless, unstoppable.

The result is DIFP — the Djowda Interconnected Food Protocol. The Food Freedom Map is the first public UI on top of it.

What the map does right now

Open djowda.com/food-freedom-map, click anywhere on earth, and you can:

📦 List — add a food product with a price
🙋 Ask — broadcast that you need something
🤝 Donate — offer something for free
🗺️ Discover — browse nearby stores, farms, restaurants — see their catalog, ask list, and donations in real time
🔍 Search — jump to any location by coordinates or Cell ID

Everything happens without an account. Your identity is a secp256k1 keypair auto-generated in your browser and stored in localStorage. Your pin is a signed Nostr event broadcast to wss://relay.damus.io.

The architecture

Layer 1 — The geo-grid (MinMax99)

The earth is divided into a flat 500m × 500m grid: 82,000 columns × 42,000 rows = ~3.4 billion cells. Any lat/lng maps to exactly one cell ID:

import math

EARTH_W   = 40_075_000  # metres
EARTH_H   = 20_000_000
CELL_SIZE = 500
NUM_ROWS  = 42_000
NUM_COLS  = 82_000

def geo_to_cell(lat, lng):
    x = (lng + 180) * (EARTH_W / 360)
    y = EARTH_H / 2 - math.log(
        math.tan(math.pi / 4 + (lat * math.pi) / 360)
    ) * (EARTH_H / (2 * math.pi))

    x_cell = max(0, min(int(x / CELL_SIZE), NUM_COLS - 1))
    y_cell = max(0, min(int(y / CELL_SIZE), NUM_ROWS - 1))

    return x_cell * NUM_ROWS + y_cell

# Example: Algiers
cell = geo_to_cell(36.737, 3.086)
print(cell)  # → 1711935606

Cells are grouped into lobbies (41×41 cells ≈ 20km² each). Subscribing to a lobby ID means you get all components within that area — no bounding-box query needed, no spatial index on a server.

LOBBY_SIZE     = 41
NUM_LOBBY_ROWS = 1025  # ceil(42000 / 41)

def cell_to_lobby(cell_id):
    x_cell = cell_id // NUM_ROWS
    y_cell = cell_id % NUM_ROWS
    lx = x_cell // LOBBY_SIZE
    ly = y_cell // LOBBY_SIZE
    return lx * NUM_LOBBY_ROWS + ly

Layer 2 — Nostr (NIP-01 + NIP-33)

Every component presence is a kind:30420 replaceable event (NIP-33). One pubkey = one component. Updating your presence replaces the old event on the relay — no accumulation of stale data.

The event tags that matter:

[
  ["d",     "main"],
  ["t",     "difp"],
  ["t",     "s"],
  ["cell",  "1711935606"],
  ["lobby", "40780"],
  ["t",     "lobby-40780"],
  ["status","1"]
]

The #t: ["lobby-40780"] tag is what makes geo-discovery possible. Any client can subscribe to a lobby ID with a standard Nostr REQ — no custom relay extensions, no spatial query language. It's just tag filtering.

Layer 3 — Catalog encoding

Product listings, ask lists, and donations are separate kind:30421 events with a compact payload:

Listing:  1:29900;6:14900;21:9900    (productId:priceCents pairs)
Ask:      3;7;44                      (productIds)
Donation: 2;15;88                     (productIds)

This keeps event sizes tiny and fits thousands of products in a single Nostr event.

Query the network right now — Python script

You don't need the map UI at all. Here's a minimal Python script to query any cell and print what's there:

import json
import websocket

# ── DIFP grid constants ─────────────────────────────────────
NUM_ROWS       = 42_000
LOBBY_SIZE     = 41
NUM_LOBBY_ROWS = 1_025

def cell_to_lobby(cell_id):
    x_cell = cell_id // NUM_ROWS
    y_cell = cell_id % NUM_ROWS
    lx = x_cell // LOBBY_SIZE
    ly = y_cell // LOBBY_SIZE
    return lx * NUM_LOBBY_ROWS + ly

# ── Input ───────────────────────────────────────────────────
cell_id  = int(input("Enter DIFP Cell ID: ").strip())
lobby_id = cell_to_lobby(cell_id)

print(f"\nCell ID  : {cell_id}")
print(f"Lobby ID : {lobby_id}")
print("Connecting to relay...\n")

# ── Connect & subscribe ─────────────────────────────────────
ws = websocket.create_connection("wss://relay.damus.io")

req = ["REQ", "difp-cell-query", {
    "kinds": [30420],
    "#t":   [f"lobby-{lobby_id}"],
    "limit": 500
}]

ws.send(json.dumps(req))

# ── Read results ────────────────────────────────────────────
found = 0

while True:
    msg = json.loads(ws.recv())

    if msg[0] == "EVENT":
        event     = msg[2]
        event_cell = next(
            (tag[1] for tag in event.get("tags", []) if tag[0] == "cell"),
            None
        )

        # Filter to exact cell match
        if event_cell != str(cell_id):
            continue

        found += 1
        content = {}
        try:
            content = json.loads(event["content"])
        except Exception:
            pass

        print("=" * 60)
        print(f"COMPONENT #{found}")
        print("=" * 60)
        print(f"PubKey : {event['pubkey']}")
        print(f"Name   : {content.get('n',  'Unknown')}")
        print(f"Type   : {content.get('cT', '?')}")
        print(f"Avatar : {content.get('aI', '?')}")
        print(f"Cell   : {event_cell}")

        listings = [t[1] for t in event.get("tags", []) if t[0] == "listing"]
        catalogs = [t[1] for t in event.get("tags", []) if t[0] == "catalog"]
        print(f"Listings : {listings}")
        print(f"Catalogs : {catalogs}")
        print()

    elif msg[0] == "EOSE":
        break

ws.close()
print(f"Done. Components found in cell {cell_id}: {found}")

Install the dependency:

pip install websocket-client

Run it:

python query_cell.py
# Enter DIFP Cell ID: 1711935606

You'll see every registered component at that 500m cell — their name, type, avatar, and any catalog/listing data — pulled directly from the Nostr relay, no API key, no rate limit, no account.

Try it with Cell ID 1711935606 (Algiers) or drop your own pin on the map first, grab your Cell ID from the confirmation toast, then query it here.

Why this is interesting for AI

One of the things we're actively experimenting with: querying the DIFP network from an AI agent.

The geo-cell model maps cleanly to natural language queries:

"Find me a farm within 5km of these coordinates" → convert to cell → find nearby lobbies → subscribe → filter by type f
"What food donations are available near me right now?" → same pipeline, filter by donation events

The protocol is just Nostr tag filtering. Any model that can make a WebSocket connection and parse JSON can become a food discovery agent on the open network. No API contract. No terms of service. No SDK required.

We're planning to publish a reference agent implementation in the next sprint.

What's coming next

Three-way trades

The current version supports three independent broadcast types per component: listing (sell), ask (need), and donation (give). The next update will connect these across components — enabling matched trades:

A farmer broadcasts surplus tomatoes as a listing
A restaurant broadcasts tomatoes as an ask
The protocol surfaces the match
Both parties transact directly, peer-to-peer

No escrow platform. No commission. Just two signed events and a handshake.

Trade on Map

We're also prototyping a new concept: Trade on Map. Instead of navigating to a store profile and browsing a catalog, you see the trades themselves as map objects — color-coded by type (listing / ask / donation), filterable by product category, visible in real time as they're published to the relay.

Think of it as a live order book, but geographic. You can see at a glance where surpluses and shortfalls are clustering, and what's moving.

This is still early-stage. We're designing the UX now. If you have thoughts, we'd love to hear them.

Try it / get involved

The map is live: djowda.com/food-freedom-map

Drop your pin. Try the Python script. Share your Cell ID in the comments — we'll tell you what's in your neighborhood on the network.

We're aiming for 1,000,000 pins as a signal of demand for open food infrastructure. Not a vanity metric — a message to the food system that people are ready for something better.

The npm library if you want to build on the protocol:

npm install @djowda/difp

→ npmjs.com/package/@djowda/difp

The protocol is open. The relay is public. Build something. 🌾

Part of the Djowda open food infrastructure project.
Protocol spec: DIFP v0.4-alpha | Built on Nostr NIP-01 + NIP-33

DIFP is Now a Library. Plug Any App Into the Open Food Network in 3 Lines of Code.

Djowda — Fri, 12 Jun 2026 05:28:04 +0000

The protocol works. The POC proved it. Now we're making it dead simple for any developer — in any language — to join the network.

Two weeks ago we published a proof-of-concept: two Android apps syncing a 6,000-product food catalog over Nostr in real time, geo-filtered to a 500m cell, zero backend, zero commission.

Today we're announcing the next step.

@djowda/difp is live on npm. Alpha. Open source. Ready to use.

What just shipped

The first DIFP SDK — a lightweight TypeScript/JavaScript library that wraps the entire protocol into a handful of intuitive calls.

npm install @djowda/difp

Three lines to join the open food network:

import { createDifpClient } from '@djowda/difp';

const client = await createDifpClient();

await client.registerPresence({
  name: 'Marché El Baraka',
  lat:  36.737,
  lng:  3.086,
});

That's it. Your component is now discoverable by anyone in your geo-cell, on the open Nostr network, with no central authority, no API key, no monthly bill.

📦 npm: npmjs.com/package/@djowda/difp

🔗 Source: github.com/Djowda/difp-npm

🌐 Reference web app: github.com/Djowda/difp-reference-webApp

What the SDK does

The library exposes 9 core operations — the same API that will ship across every language binding:

Presence

// Register on the network (or let the library generate random test data)
const result = await client.registerPresence({
  name: 'Green Valley Store',
  lat:  36.737,
  lng:  3.086,
  type: 's',         // store
});
console.log(result.cellId);   // 1711935606
console.log(result.lobbyId);  // 875346

// Update your presence
await client.updatePresence({ status: false }); // mark as closed

// Or just test with zero config
await client.registerPresence('test');
// → generates a realistic random component and publishes it

Catalog management

// List a product (id=14, price=150.00 DA, available)
await client.updateItem('l', 14n, 15000n, true);

// Mark a product as something you need
await client.updateItem('a', 7n);

// Mark a product you're donating
await client.updateItem('d', 22n);

Each call re-broadcasts the full catalog payload over Nostr as a NIP-33 addressable event — always latest state, no history needed, 6,000+ products per event.

Discovery

// Find components near a cell, 5 lobby levels out (default)
const nearby = await client.getNearby(1711935606n, 5);

console.log(nearby.components);
// [{ id: '79be667...', n: 'Ferme Bouzidi', cT: 'f', cI: 1711935580n, ... }]

The library computes nearby lobby IDs from the center cell, queries Nostr with #t tag filters, and returns parsed Component objects. No backend involved.

Catalog browsing

// Browse another component's full catalog
const catalog  = await client.listCatalog('79be667ef9dc...');
const asks     = await client.listAsk('79be667ef9dc...');
const donations= await client.listDonation('79be667ef9dc...');

console.log(catalog.entries[0]);
// { productId: 14n, price: 15000n, available: true }

Status

const s = client.status();
// {
//   pubkey:       '79be667...',
//   cellId:       1711935606n,
//   lobbyId:      875346n,
//   connected:    true,
//   catalogSize:  312,
//   askCount:     7,
//   donationCount: 3
// }

Geo utilities (also exported standalone)

import { geoToCell, cellToLobby } from '@djowda/difp';

const cellId  = geoToCell(36.737, 3.086);   // 1711935606n
const lobbyId = cellToLobby(cellId);         // 875346n

How it works under the hood

Everything in the library maps to two Nostr event kinds:

Kind 30420 — Component (NIP-33 replaceable)

Your presence on the network. Contains name, type, cell ID, lobby ID, working hours, and flags for ask/donation broadcasting. Replaced silently every time you update.

Kind 30421 — Catalog (NIP-33 replaceable)

Your product data. One event per catalog type (-l, -a, -d). Content is raw DIFP compact encoding:

14:15000;1:4000;12:120000;7:8250

ID colon price-in-cents, semicolon separated. Presence means available. Absence means not. No field names. ~7,000 products per 64 KB Nostr event.

Discovery uses lobby-based #t tag filtering:

{
  "kinds": [30420],
  "#t":    ["lobby-875346", "lobby-875347", "lobby-875472"],
  "limit": 200
}

One query. Up to 200 components across a ~20 km radius. Entirely decentralized.

The PAD system — and why the next milestone matters

The library ships with a built-in demo PAD (Preloaded Asset Distribution): a CSV of product metadata that travels with the app, not over the wire. Product names, images, units, categories — bundled at install. Only price and availability travel over Nostr.

The alpha PAD has 30 demo products. The full PAD spec reserves indexes 1–1000 for strictly necessary raw foods — universal staples that exist in every food system on earth, indexed consistently across all implementations.

Indexes 1001+ are open for claim.

If you are a food company, a grocery brand, or you have products in production that belong on the global food network — you can claim a permanent index in the DIFP PAD. Indexes are limited. The global network shares one namespace.

We'll publish the claim process shortly. If you're interested, reach out now.

Multi-language SDK roadmap

The npm library is the first. The same spec — same API names, same encoding, same Nostr wire protocol — is being implemented across:

Language	Registry	Status
JS/TS	npm	✅ Live
Java/Android	Maven Central	🔨 In progress
Python	PyPI	🔨 In progress
Rust	crates.io	📋 Planned
Go	GitHub Modules	📋 Planned
C#	NuGet	📋 Planned
C/C++	GitHub + Conan	📋 Planned

Every library will expose the same 9 methods with the same semantics. A component published from a Python script is discoverable by a Rust app, by the Android prototype, by the reference web app. One protocol, any language.

Try the test mode — zero config required

You don't need a real location or product data to experience the protocol. Every method accepts 'test' as an argument:

const client = await createDifpClient();

// Generate a random realistic component and publish it
const result = await client.registerPresence('test');
console.log(result.component.n);  // e.g. "Ferme Bouzidi"
console.log(result.cellId);       // e.g. 2034871922n

// Update with a new random component
await client.updatePresence('test');

// Check nearby (uses the auto-generated cell)
const s      = client.status();
const nearby = await client.getNearby(s.cellId, 3);

The library handles keypair generation, storage, and relay connection automatically. First run: new identity. Subsequent runs: same identity loaded from ~/.difp/identity.json (Node.js) or localStorage (browser).

What we're building toward

DIFP is not trying to be a lower-fee food delivery platform. It's trying to make the fee structurally impossible.

The relay is open infrastructure. The events are signed by the publisher's key, not by us. There is no Djowda server sitting in the middle routing discovery. The protocol runs on Nostr's relay network — run by the community, for the community.

The next milestones are:

Full PAD v1 — 1,000 standardized raw food indexes, globally consistent
Open PAD claim — brands and producers can register their products permanently in the shared namespace
Android prototype public release — the reference implementation made available to test with real devices
Multi-relay support — publishing to multiple relays for resilience

We're building open food infrastructure, one protocol at a time.

Just Killed the 30% Commission. Anyone Can Now List and Buy Food, Anywhere on Earth — for Free.

Djowda — Sun, 07 Jun 2026 03:56:11 +0000

tldr; We shipped a working proof-of-concept: two Android apps syncing a 6,000-product food catalog over Nostr in real time, geo-filtered to a 500m × 500m cell. No backend. No fees. No middleman. And we're open-sourcing everything.

It started with a napkin calculation.

Every time a restaurant lists a dish on a major food delivery platform, they pay somewhere between 25% and 35% commission on every single order. Not on profit. On revenue. A store doing $10,000 in food sales hands $3,000 straight to the platform — for the privilege of being discovered.

We asked: what if discovery were free? What if listing food were a right, not a subscription?

That question became DIFP. And this week, it works.

What We Shipped

A fully working proof-of-concept built on two pillars:

DIFP (Djowda Interconnected Food Protocol) — an open protocol for syncing food catalog data compactly across distributed nodes, with geo-awareness built in from day one.

Nostr — a decentralized communication protocol where events are signed, relays are open, and no single entity controls the network.

Together: a store broadcasts its full price and availability catalog to the world. A customer anywhere subscribes to their local geo-cell. They receive only what's relevant to them. Nobody charges a commission for this. Nobody can.

The Math That Made This Work

Here's the number that changed everything.

A Nostr event holds 64 KB of content. A product catalog entry — just the fields that need to travel over the wire — can be encoded as:

500,30000

That's it. Product ID and price in cents, comma-separated. Two optimizations made this possible:

Availability by presence — if a product entry exists, it's available. If it's absent from the payload, it's not. No boolean field needed.
Position-based encoding — field names are dropped entirely. The app knows position 0 is the ID, position 1 is the price. Decoding happens on device.

The result:

~6,000 – 7,000 products per single Nostr event

An entire store's catalog. One event. One relay push.

The rest of the product data — names, images, categories, units — ships once, bundled with the app install (the PAD system: Preloaded Asset Distribution). Updates are only ever price + availability. The network payload is minimal by design.

Geo-Discovery Without a Central Server

The other hard problem: how does a customer in Austin find stores in Austin, while someone in Berlin finds theirs — without a central directory knowing where anyone is?

DIFP uses a geo-cell system called MinMax99 that partitions the world into addressable ~500m × 500m cells. Each cell maps to a long integer — the cellId.

The flow:

A store encodes its location as a cellId and publishes its Nostr event tagged ["g", "<cellId>"]
A customer enters their coordinates, computes the same cellId, and subscribes with {"#g": ["<cellId>"]}
The Nostr relay returns only events tagged for that cell

No API. No account. No server knowing where you are. Just math and an open relay.

The Architecture

STORE APP                           USER APP
──────────────────────────────────────────────────────
[CSV PAD] → Room DB                 [CSV PAD] → Room DB
     ↓                                    ↑
[Bulk randomize]                    [DIFP Decoder]
     ↓                                    ↑
[DIFP Encoder]                      [RAM Index O(1)]
     ↓                                    ↑
[NostrClient]  ──── Nostr Relay ──→ [NostrSubscriber]
  NIP-01 EVENT                        NIP-01 REQ+#g
  kind:1, #g=cellId                   filter by cellId

The user app maintains an in-memory index of product IDs for O(1) lookup. When a Nostr event arrives, it decodes the DIFP payload, applies the delta to the RAM index, and bulk-writes to Room DB. LiveData notifies the RecyclerView. The UI updates in real time.

No polling. No REST calls. No backend to go down.

Running It Yourself

The POC is open source: github.com/Djowda/difp-nostr-catalog-poc

Two apps, same CSV asset pack:

id,name,brand,description,price,is_available,category,sub_category,image,unit,score
1,Ail,DJOWDA,Ail,40.0,1,Légumes,Légumes,1.webp,KG,0

To run the demo:

Install both apps on two devices (or two emulators)
Enter the same coordinates on both — e.g. 40.71, -74.00
User app: tap Observe Catalog → subscribes to that geo-cell on wss://relay.damus.io
Store app: tap ⚡ Bulk Update 6k + Broadcast → randomizes all prices, encodes DIFP, publishes to Nostr
Watch the user app update in real time

The relay is public. No auth required. No account. No fee.

What This Actually Means

Let's be direct about what just became possible.

Any food seller, anywhere on earth, can list their catalog for free.
No platform approval. No onboarding fee. No monthly subscription. Run the app, enter your location, broadcast.

Any buyer, anywhere on earth, can discover and purchase from local sellers.
No account with a gatekeeper platform. No delivery fee routed through a VC-backed intermediary. Just open protocol.

The 30% commission is structurally impossible in this model.
There is no central entity to collect it. The relay is open infrastructure — run by the community, for the community. DIFP events are signed by the store's Nostr key, not by us.

This isn't a lower-fee platform. It's a world where the fee doesn't exist as a concept.

What's Still TODO

The POC uses a placeholder Schnorr signature. Production deployment needs real NIP-01 signing:

// build.gradle
implementation "fr.acinq.secp256k1:secp256k1-kmp-jvm:0.10.1"

// NostrClient.java
byte[] sigBytes = Secp256k1.signSchnorr(
    hexToBytes(eventIdHex),
    hexToBytes(PRIVATE_KEY_HEX),
    null
);

Beyond that, the roadmap includes:

Payment layer — Nostr Wallet Connect (NWC) for zap-based ordering with no payment processor taking a cut
Multi-cell relay mapping — larger areas subscribing to multiple geo-cells
Relay diversity — publishing to multiple relays for censorship resistance
Live throughput benchmarks — measuring real-world latency across relay infrastructure

Why Food Infrastructure

Food systems are some of the most centralized infrastructure on the planet. A handful of platforms control discovery for hundreds of thousands of local sellers. A protocol disruption that happened in music (streaming), in finance (crypto), and in social (Nostr itself) hasn't happened in food yet.

We think it should.

DIFP isn't a product. It's a protocol. Anyone can build on it. Anyone can run a relay. Anyone can publish a catalog.

The spec is at djowda.com/difp.
The code is at github.com/Djowda/difp-nostr-catalog-poc.

We're building open food infrastructure, one protocol at a time. Come build with us.

Questions? Comments? Open an issue on the repo or find us on Nostr.

DIFP Nostr: Fitting 6,000+ Products into a Single 64 KB Event

Djowda — Sat, 06 Jun 2026 03:10:09 +0000

TL;DR — The DIFP protocol was designed to be data-compact and geo-aware from day one. We recently discovered it maps almost perfectly onto the Nostr event format. Here's how, and why it matters for decentralized food infrastructure.

Background: What Is DIFP?

DIFP (Djowda Interconnected Food Protocol) is an open protocol designed to sync food product data across distributed nodes — compactly, efficiently, and with geo-location awareness built in by default.

One of its core design decisions is the PAD system (Preloaded Asset Distribution):

Apps ship with a preloaded asset pack — item metadata, compressed images, category structure — all bundled at install time.
Only price and availability need to travel over the wire during sync.

This means the data footprint per product is tiny. Very tiny.

Enter Nostr

Nostr is a simple, open protocol for decentralized communication. One of its key specs: events support up to 64 KB of content.

When we started exploring Nostr as a potential transport layer, we ran the numbers — and the fit was surprisingly clean.

The Math: Products Per Event

Baseline encoding

A product represented with three fields:

{ "id": 500, "available": true, "price": 30000 }

At this level of verbosity, a single 64 KB Nostr event can hold approximately:

~1,500 – 2,000 products

Already useful. But we can do better.

Optimized encoding

Two key optimizations:

1. Drop the availability key — If a product entry exists in the JSON, it's available. If it's absent, it's not. No boolean needed.

2. Drop the field names — Instead of {"id": 500, "price": 30000}, just store:

500,30000

Field mapping is handled at the app level, not the protocol level. The device knows position 0 is the product ID, position 1 is the price (in smallest currency unit, e.g. cents).

Result

~6,000 – 7,000 products per single Nostr event

Possibly more, depending on the price distribution and ID ranges in a given catalog.

Geo-Discovery: MinMax99 Cells

DIFP uses a geo-cell system called MinMax99 to partition the world into addressable geographic units. Each cell can correspond to a Nostr relay or event namespace.

This means:

A client subscribes to the Nostr relay(s) for its geographic cell.
It receives events containing only the product catalog relevant to that area.
Country-specific and type-specific component catalogs further narrow the data.

The result is geo-coordinated product discovery with zero central coordination.

What This Unlocks

Putting it all together:

Layer	Mechanism
Product catalog	PAD pack (shipped with app)
Price + availability sync	Nostr events (64 KB, ~6–7k products)
Geo-discovery	MinMax99 cell → Nostr relay mapping
Country/type filtering	Component catalog per region

This architecture means:

No central server required for product sync
Open network — anyone can run a relay, anyone can publish
Geo-aware by default — clients only receive what's relevant to them
Censorship-resistant — food data lives on a distributed event graph

Why This Matters

Food infrastructure is one of the most centralized, fragile systems in the world. A protocol stack that enables:

free ordering
donation coordination
availability broadcasting

...across an open, serverless, geo-aware network — without gatekeepers — is worth building.

We didn't design DIFP for Nostr. But the fit turned out to be near-perfect.

What's Next

We're moving into implementation testing — mapping live DIFP events onto Nostr relays with real product catalogs and measuring real-world throughput, latency, and relay compatibility.

We'll publish results here as we go.

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. 🌍