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.
Links
- 🔗 DIFP Protocol spec: djowda.com/difp
- 🔗 Nostr protocol: nostr.com
Follow the Djowda journey — we're building open food infrastructure, one protocol at a time.
Top comments (0)