DEV Community

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

Posted on

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

#nostr #decentralized #foodtech #opensource

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
Enter fullscreen mode Exit fullscreen mode

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

  1. 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.
  2. 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
Enter fullscreen mode Exit fullscreen mode

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:

  1. A store encodes its location as a cellId and publishes its Nostr event tagged ["g", "<cellId>"]
  2. A customer enters their coordinates, computes the same cellId, and subscribes with {"#g": ["<cellId>"]}
  3. 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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

To run the demo:

  1. Install both apps on two devices (or two emulators)
  2. Enter the same coordinates on both — e.g. 40.71, -74.00
  3. User app: tap Observe Catalog → subscribes to that geo-cell on wss://relay.damus.io
  4. Store app: tap ⚡ Bulk Update 6k + Broadcast → randomizes all prices, encodes DIFP, publishes to Nostr
  5. 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
);
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)