Skip to content

food-messaging-roadmap.md

Latest commit

 

History

History
86 lines (60 loc) · 2.65 KB

food-messaging-roadmap.md

File metadata and controls

86 lines (60 loc) · 2.65 KB
title Food Messaging and Trust Roadmap
weight 70

This roadmap keeps food exchange simple while supporting practical trust and responses.

Product Goal

Allow members to post surplus or request listings (for example: oats, jam, produce), and let peers respond with intent ranges (for example: 1-2 jars, 5-10 jars, 15+ jars).

Suggested v1 Response Model

  1. Keep listings as they are: give or find with pickup windows and optional public contact.
  2. Add lightweight responses bound to a listing:
    • listing_id
    • responder_peer_id
    • intent (interested, can_take, can_offer)
    • quantity_band (free text like 1-2 jars)
    • note (short)
    • created_at_unix_ms
  3. Keep in-app response UX intentionally small:
    • one-tap reaction chips
    • optional quantity band input
    • optional note
  4. Route detailed conversation to external channels:
    • Matrix
    • Signal
    • SMS/phone

This avoids turning Common OS into a full chat app while still unlocking coordination.

Notification Approach

Use local-first notifications in phases:

  1. In-node activity feed for new responses.
  2. Optional push-style local notifications in the PWA/app shell.
  3. Optional bridge notifications only when the user explicitly shares Matrix/SMS contact.

Trust and Verification Model

Use QR scan verification as the first trust primitive.

  1. QR exchange establishes node identity and public key mapping.
  2. Promote trust in explicit levels (discovered -> verified -> trusted).
  3. Require trusted for posting listings.
  4. Keep responses readable to peers, but show trust badges on responders.

Longer-term, add a web-of-trust score inspired by GPG:

  • trust attestations signed by peers
  • local weighting policy (strict vs permissive)
  • no global reputation token

Why Not Full IPFS First

IPFS and broader decentralized storage can be valuable, but adds operational complexity early.

Recommended sequence:

  1. Keep SQLite local-first baseline now.
  2. Add signed export/import bundles for backup and migration.
  3. Consider optional IPFS pinning for public noticeboard snapshots later.

API Surface Proposal

Potential endpoints for v1 responses:

  • POST /api/food/listings/{id}/responses
  • GET /api/food/listings/{id}/responses

Rules:

  • only trusted peers can post listings
  • any known peer can post a response
  • contact fields remain optional and explicit

Engineering Discipline

To keep "a reason for every line of code":

  • each new API requires one integration test
  • each trust rule requires one negative test
  • each UI action requires one localized string and one error state
  • each persisted field requires a documented purpose in schema comments