NeighborNet: The Hyperlocal Tool Library That Never Was

Imagine a web app where your neighborhood becomes a decentralized lending library. You log in (no password, just a simple token via email or SMS using free services like Twilio's free trial or even just local storage with a pseudonym). You list your spare drill, your pressure washer, your newfound sourdough starter. You request a leaf blower from the Smiths two blocks away. The app uses a mesh of proximity and trust: items are visible only within a 2-mile radius, based on IP geolocation or optional GPS. No database of users beyond what's needed for transactions; we use a free tier of Supabase or even a JSON file on GitHub as a "database" with Netlify Functions handling the API. The whole thing is a progressive web app so it works offline: you can browse listings cached from your last sync, and when you go online, you trade messages via a simple pub/sub system (maybe using a free MQTT broker or WebRTC via a signaling server on a free Heroku dyno that sleeps). The ambition is to prove that a functional, safe, and useful community platform can run on zero dollars, relying on users' goodwill and minimal infrastructure. But we never built it because of concerns about liability (what if someone's tool breaks?) and the challenge of getting critical mass in a single neighborhood without marketing budget. Still, the plan was solid.

In many neighborhoods, people own tools they use once a year, and others need them briefly but can't afford to buy. Existing platforms like Nextdoor are cluttered with spam, Facebook Marketplace is full of scams, and tool libraries require physical storefronts and staff. There's no simple, free, peer-to-peer system that works on a small scale.

• Enable a user to list an item with a photo, description, and availability within minutes.
• Allow browsing items within 2-mile radius without creating an account.
• Provide a simple reputation system based on completed swaps (no ratings, just "successful swaps" count).
• Work fully offline for browsing, and sync when online.
• Run entirely on free tier services: Netlify for hosting, Supabase free tier for DB, Mapbox free tier for geocoding, etc.

• No payment processing or money exchange.
• No insurance or liability coverage.
• No user verification beyond optional email.
• No mobile app (PWA only).
• No social media integration.

• Frontend: Vanilla JavaScript with Svelte (or Preact) for simplicity, using a static site generator (like Eleventy) to pre-render pages.
• Backend: Netlify Functions (free tier) for API endpoints, Supabase (free tier) as the database and real-time subscriptions.
• Geolocation: OpenStreetMap Nominatim for reverse geocoding (free), Mapbox GL JS for maps (free tier limited).
• Offline: Service workers with Workbox, IndexedDB for local caching using Dexie.js.
• Communication: Simple messaging via Supabase Realtime (free tier includes real-time).
• Authentication: Magic link via Supabase Auth (free tier).
• All open source, hosted on GitHub Pages via Netlify.

The app is a single-page application (SPA) with offline capability. The core data model: items (title, description, image URL, owner ID, location lat/lng), users (pseudonym, verification token, reputation score), and transactions (item ID, requester ID, status: requested/borrowed/returned). The frontend fetches items within a bounding box from the user's approximate location (derived from IP or browser geolocation). Real-time subscriptions update the listings when items are added or status changes. Offline, the app shows previously cached items and allows the user to create requests that are queued locally and synced later. Security is minimal: CORS, HTTPS, and simple rate limiting on Netlify Functions. The architecture is stateless on the server, with the database as the single source of truth.

• Legal liability if a borrowed tool causes injury or damage.
• Users may not self-police; fake listings or no-shows degrade trust.
• Free tier limits may be hit if usage grows (e.g., Supabase row limits).
• Geolocation accuracy may be poor, leading to irrelevant listings.
• Offline sync conflicts could cause data loss.

• How to handle disputes? Perhaps a simple "dispute" flag that notifies both parties via email, but no resolution mechanism.
• Should we allow anonymous browsing or require a pseudonym? Pseudonym reduces spam but adds friction.
• How to seed the first neighborhood? Maybe create a "demo" neighborhood with fake items.

Life got busy with day jobs, and the liability concerns were never fully resolved. Also, we realized that without a budget for marketing, it would be impossible to reach the critical mass needed for even one neighborhood to be useful. The idea remains a beautiful what-if.

This plan was drafted over a weekend hackathon but never started. The code repo is still empty except for the README.