# Tinbot Exchange — The Logistics Backbone

**Working draft for the TLIP Discord jam — "open source Amazon" riff**
**Status:** Riff / proposal seed. Not yet a Void/admin ask. Section 10 is the only formal ask, and it's flagged for when intake opens.
**Authoring context:** Written to feed straight back into the Discord. Numbered 1–10 to map 1:1 to the riff you posted.

---

## 0. North Star (one paragraph)

Tinbot takes in hardware and outputs *trusted reuse*. The waste between donor and recipient is friction, fraud, and freight. Everything below is a way to remove waste with **infrastructure that already exists** before we spend a dollar on new infrastructure. The whole design is *Little Free Library meets UberEats meets Boost Mobile* — piggyback donor-side storage, neighbor-side last-mile, and aggregator-side freight, with the same trust layer a wireless reseller rides on a phone company's network.

---

## 1. Node tiers — what counts where

Three tiers, deliberately small. Each has a job. Promotion rules are explicit so we don't blur categories mid-pilot.

| Tier | What it is | Examples | Job in the network | Trust needed |
|---|---|---|---|---|
| **T1 — Dropoff node** | A place a donor can hand a box to without meeting a person | Home porch (scheduled pickup), library drop bin, repair café counter, church office desk, laundromat counter | Receive + label + hold ≤ 14 days | Signed MoU + visible signage |
| **T2 — Cluster hub** | A room, garage, or workshop that consolidates a metro area | Host's garage, branch workshop, library back-room, makerspace | Intake wipe, intake QA, triage, light repair, prepare for onward leg | Named steward, posted hours, published checklist |
| **T3 — Freight depot** | An aggregation point that ships cross-region or accepts inbound pallets | Branch HQ warehouse, partnered co-op warehouse, library system mailroom | Palletize, LTL book, receive freight, route to another T3 or T2 | Lease/insurance/signed cargo handoff |

**Promotion rule:** a T1 earns T2 status when it has held ≥ 60 days without a single unresolved chain-of-custody gap; a T2 earns T3 when it has executed ≥ 3 cross-region legs with verified handoffs.

**Hard rules across all tiers:**
- *Tinbot accepts hardware, not data.* No tier opens a device, plugs it into anything networked, or accesses storage without a documented wipe attestation. (See §6.)
- No tier tracks people's identities beyond a pickup window. (See §7.)
- A node is not "in the network" until its written role, hours, and liability posture are on `branches.html` or a sister doc. Public visibility is the immune system.

---

## 2. Trust layer first — piggyback, don't build

In order of "highest leverage per hour of work":

1. **Little Free Libraries** — built-in donor-side drop, low ceremony, already neighborhood-legitimized. We don't put a LFL on a corner; we *register an existing one as a Tinbot drop node* if its steward opts in. Start with a 1-mile radius of every active LFL as a pickup catchment.
2. **Mutual-aid delivery routes** — TLIP adjacent meshes (food fridges, diaper banks, period supply) already have weekly circuits. We *overlay* a weekly pickup sweep on those routes rather than invent a new one. The mutual-aid partner gains a reason to keep running the route; we gain zero-cost legs.
3. **Repair cafés** — natural T2 hubs: people already bring broken stuff, repair skills are on site, and intake quality is best-in-class because volunteers can triage in person.
4. **Library systems** — T1 dropoff at the desk + back-room overflow for T2 if branch agrees. Public libraries already handle inter-library mail — they understand physical handoff paperwork better than any other civilian institution.
5. **Boost/aggregator pattern (the structural riff)** — for freight, we don't own trucks. We piggyback existing LTL carriers as the *network layer*. Tinbot's freight function is just a router that picks the cheapest existing lane + books a pickup window, same way Boost Mobile picks a Verizon or T-Mobile tower without owning a tower.
6. **What we do NOT build this year:** a custom app, a custom matching engine, a custom identity layer, or a custom backend. Use Signal/email/DM + a public ledger in §7.

If a partner org says no, log it in `tinbot/partnerships.md` and move on. Trust is built by accepting who says no.

---

## 3. Last-mile volunteer model

A volunteer carrier should commit to **a single short hop**, repeatable, not a journey. The unit of commitment is *a hop*, not *the program*.

**The hop card.** Every route has a one-page card:
- From → To (T1 / T2 / T3 tag on each)
- Window: "Tuesday 6–8pm, or push to next slot"
- Payload: 1–3 boxes, ≤ 30 lb total, pre-labeled
- Done condition: a 1-photo handoff posted to the route thread
- Soft commitment: zero follow-up if you can't make a week. No "reliability score." Volunteers are not gig workers.

**Sign-up flow (under 5 minutes):**
1. Tap the route card pinned in the relevant Discord channel.
2. Fill a 4-field form: name, contact, neighborhood, "I can do hops on [any weekday / weekend / evenings]."
3. Read the 1-page liability note (§8) and acknowledge.
4. They get added to the route thread. That is the entire onboarding.

**Why this works:**
- It costs $0 in new software (Discord/email/Signal group).
- The low ceiling (a hop) and the low floor (no penalties for skipping) compound. People who *can* reliably carry will quietly become the de facto regulars; people who carry once a year still do.
- It models the "Boost reuses towers" pattern: we reuse *people's existing rhythms* (school pickup + box in the trunk, library visit + box in the bag) rather than invent new ones.

---

## 4. Freight pooling math (working numbers)

Goal: compare three strategies for moving 1 unit (a desktop/laptop + adapter) over a 500-mile leg, all-in (label + freight + claims buffer).

| Strategy | Per-unit cost (today) | Per-unit cost (at scale) | Notes |
|---|---|---|---|
| **Individual shipping** (USPS Priority, 5 lb, 500 mi) | ~$22–30 | floor ~$15 | Donor/recipient pays; poor for >1 device, fragile boxes stack |
| **LTL pallet pooled** (1 of 200 devices on a monthly pallet, 500 mi) | ~$6–10 + share of pallet prep $1.50 | ~$5–7 at 1 leg/mo, **~$3.50–4.50 at 4 legs/mo** | Minimize per-mile cost; the catch is pallet threshold |
| **Peer round-trip carry** (driver already crossing) | $3–5 (fuel + stipend) | floor $2–3 | Fast, low ceremony, no freight insurance; liability posture must be explicit (§8) |

**Break-even rule of thumb (donor-side economics):**
- **Below ~30 devices/month per region:** individual shipping is fine; do not over-engineer. Use peer carries where they exist.
- **~30–80 devices/month:** begin consolidating to a single bi-weekly pallet per region. Reserve a small line item for pallet materials (~$50–80/leg).
- **Above ~80 devices/month:** monthly LTL pallet + parallel peer route for urgent/oversize items.

**Yearly program budget (working draft — subject to §10):**

| Line item | Range | Notes |
|---|---|---|
| Pallet prep materials (shrink, label, blanket wrap) | $300–600/yr at 1 leg/mo, scales linearly | |
| 1× LTL lane, 1 region, 12 legs/yr | $700–1,400/yr | Each leg averages $60–120 for ~$6–10/unit × 12 devices consolidated |
| Hop stipends (separate from freight) | $0–1,200/yr | Honor system — only when a volunteer self-identifies a need for fuel/time |
| Insurance rider on host-org policy | $0–500/yr | Often covered for free as a "volunteer logistics" rider; verify before adding |
| Handoff signage + tote bins × 6 sites | $300–500 one-time | |
| Petty claims budget (lost/damaged box) | $200–400/yr | Reserve fund; paid out per published rule |
| **Total year-one floor** | **~$1,500** | Peer-driven, 1 region |
| **Total year-one realistic** | **~$3,000–4,000** | If we add stipends + insurance + signage |
| **Total year-one with second region** | **~$6,000–8,500** | Two LTL lanes, roughly 2× the per-leg line |

These are crude working numbers, **not** the formal ask. §10 is where the budget becomes a real number.

---

## 5. Hub-and-spoke routing — when something earns a long leg

Default posture: **gear stays local. Most of the time, it shouldn't move.**

A long leg is earned when *one or more* of these is true:

1. **Local demand is met and local supply isn't.** A cluster has zero working Chromebooks in inventory and three unfixed laptops on the bench.
2. **Scarcity lift.** A specific SKU is rare enough that local repair produces less value than region-wide pooling. (Think specific ThinkPad models, working NAS boards, replacement LCDs.)
3. **Donor concentration spike.** A school district donates 60 working laptops at once; the home cluster can't absorb 60.
4. **Geographically orphaned nodes.** A drop node has no T2 within 30 mi — escalate to T2 search before escalation to T3 freight.
5. **Specialty repair routing.** Some repair (board-level, data-grade screen) only happens at one hub in a region.

**Routing rules (operational):**
- *Try before you ship.* Before booking freight, post the item to the next-tier regional channel with a 48-hour "local first" window. If no local match, ship.
- *Cluster-aware batching.* Don't ship 1 device. Hold to the next pallet unless it's the kind of urgency in §5(1)–(2) above.
- *Always return-route.* If a device moves up a spoke and can't be re-homed, it goes back down rather than piling up at a T3. Nothing rots in the depot.
- *Sunset clause on pallets.* Anything held at a T3 > 60 days reverts to the originator's region (return leg at freight direction's expense).

This is the rule that prevents "garage in Wisconsin hoarding Kentucky laptops."

---

## 6. Intake data rule, in writing

**Tinbot accepts hardware, not people's data. This is rule one, in plain language, on the front page of the intake form and on every tote.**

Operational rules — non-negotiable from day one:

1. **No reading of user storage, ever, by anyone, anywhere in the chain.** Not "we wiped it." Not "we backed up your photos." Not "we extracted your contacts to migrate." None.
2. **Wipe-before-label.** A device does not get its intake label (and therefore its slot in inventory) until a documented wipe is completed. The wipe is the entry to the system, not an afterthought.
3. **Wipe attestation is a 4-field form**, attached to the device's tag: device class (laptop/desktop/router/...), wipe method (DBAN / nwipe / vendor secure-erase / manual proof), operator initials, timestamp.
4. **Drive-out decision is donor-driven, not Tinbot-driven.** If a donor wants their drive returned separately, that's a separate handoff in a separately-labeled bag, not blocked (we don't destroy donor property) but never touched on our network.
5. **Network segregation during triage.** Repair benches use a clean network or air-gap. No donor device is the first thing on a home Wi-Fi.

**The line, in user-facing copy:**
> *"We accept hardware, not data. We wipe the storage before it enters our system. We do not open, copy, or migrate anything from your device at any step."*

That sentence gets the same prominence as donor hours. Maybe more.

---

## 7. Chain-of-custody — lightweight, no surveillance

Goal: at any moment, "where is device X" is answerable by anyone with read access to a public ledger. Goal is *not* to know who is carrying what.

**Ledger model.** A single append-only ledger (`tinbot/ledger.csv` mirrored in a Discord channel):
```
timestamp, device_tag, from_node, to_node, hop_kind, carrier (initials or "LTL")
```
That's the whole schema. No device value. No donor name. No recipient identifier. No GPS. No carrier home address.

**Device tag.** A physical label with a 6-char alphanumeric ID. Sticker goes on the box *and* on the device, with the same ID. Peel-resistant marker on the device. Sticker falls off? Re-tag at the next node and note the relabel in the ledger.

**Where it gets coarse on purpose:**
- The hop *window* (e.g. "Tue 6–8pm") is more visible than the carrier's identity.
- "Arrived" without naming the volunteer is fine for T1 hops; naming is optional and never required for record.
- Anomalies (skip in ledger, duplicate arrival, lost tag) are recovered by a human, not by a sensor.

**Why no app yet:** A custom chain-of-custody app would normalize *identity* in a way we don't want. The ledger is hostile to identity by construction.

---

## 8. Liability + handoff norms (the part nobody writes down)

A volunteer should be able to carry a Tinbot box without reading an insurance policy first. Concise, plain-language norm:

**A carrier is responsible for:**
- Keeping the box sealed and dry.
- Not opening, plugging in, or attaching donor storage to a personal device.
- Posting the 1-photo handoff into the route thread when delivered.
- Reporting damage on arrival with the photo, no cover-up.

**A carrier is NOT responsible for:**
- The donor's pre-existing data, regardless of wipe status.
- Damage present at pickup (visible or not) — node labeled "received as-is."
- Loss or theft beyond their reasonable control during the hop.
- Outcome of subsequent repair at a T2/T3.

**Tinbot (the network) is responsible for:**
- Publishing what was on the box at handoff ("received as-is" + a wipe attestation).
- Maintaining the public ledger so the carrier's run is provable.
- A petty claims budget (§4) to make whole without litigation when it's the right thing to do.

**The handoff norm:**
- Pickup photo: sealed box + node label.
- Transit: closed bag or box, no stickers removed.
- Dropoff photo: sealed box + next node's label visible.
- A dispute starts with a photo, not a story.

The whole goal is to make the box boring. Boring boxes get carried.

---

## 9. Pilot geography — *one* small cluster, real run, no perfect plan

**Pilot recommendation: Corinth / Walton County, Florida, anchored on the existing schoolhouse host site.**

Why:
- Already has on-ground infrastructure (the schoolhouse easement project → repair bench space, gathering room, and a planted relationship with the community).
- Branch interest in Florida is already public on `branches.html`; we don't have to invent the foothold.
- Mixes rural + small-town routes (forces real last-mile design instead of city-only optimization).
- Property and host context already documented, so a Solar Link pilot stacks cleanly under §1 (the school's workshop can be a real T2 from week one).
- If we get it wrong here, the failure is bounded; if we get it right here, it ports to TX/WI/NY branch interest later.

**Pilot scope (90 days):**
- ≥ 2 T1 dropoff nodes (library + faith partner or community fridge).
- 1 T2 hub (the schoolhouse workshop).
- 1 outbound freight leg, only if local demand is met.
- 1 ledger, 1 set of tote labels, 1 volunteer cohort under 12 people.
- 1 public write-up at the end — what worked, what didn't, the actual cost.

**What we are explicitly NOT doing in the pilot:**
- No cross-state freight other than the planned single leg.
- No custom software. Discord + ledger sheet.
- No donor data collection beyond handoff window and box count.
- No expansion past the cluster until the write-up exists.

**Stop conditions (the pilot fails forward if…):**
- 1 missing box becomes a forensic problem instead of a write-off: we re-design.
- 1 donor asks "what about my data?" and we don't have §6's sentence ready: we re-design.
- 1 volunteer drops out and we blame them: we re-design.
- After 90 days, *no pallet* is justified — that's a success, not a failure.

---

## 10. Decision asks for Void / admins (when intake opens)

These are the items that are **not** the author's call. They are flagged and ready.

1. **Year-one budget commitment.** Floor ~$1,500 / realistic ~$3,000–4,000 / two-region ~$6,000–8,500 — see §4. Confirm the chosen tier or specify a different one.
2. **Insurance posture.** Confirm whether the existing umbrella policy covers a "volunteer logistics" rider, or whether we need a line item for it.
3. **TLIP-published liability note.** A 1-page plain-language version of §8 needs Void approval before it goes on `branches.html` or partner-facing materials.
4. **Wipe-at-intake checklist.** The §6 / 4-field form needs to be blessed by the branch with repair authority (someone who knows DBAN/nwipe/vendor tools) before it goes live.
5. **Public ledger governance.** Who can read, who can append, retention, mirror cadence. The structure in §7 is the proposal; the rule is the ask.
6. **Cross-org partnerships.** Each formal partnership (library system, mutual-aid collective, repair café) needs a single named TLIP contact. Not all at once — just enough to staff the pilot.
7. **End-of-pilot evaluation.** Who reads the 90-day write-up and decides whether §9 expands to a second region.

> Note from author (transportation, not decision): §10 is intentionally routed around the pilot for obvious reasons. If §4's "realistic" number isn't available, the pilot collapses to "peer-only, no freight, see you in 90 days" — and that's a valid mode too.

---

## 11. What to put in Discord tonight (concrete next steps)

- [ ] Pin §6 ("We accept hardware, not data") as the channel topic in `#tinbot-intake`.
- [ ] Open a thread `#fl-pilot` for Florida-cluster logistics talk.
- [ ] Open a thread `#freight` for the LTL/peer-routing math in §4 and §5.
- [ ] Open `#ledger` to start the append-only log.
- [ ] Drop the 10-item riff into `#tinbot-jam` with a link back to this doc, marked "riff v0.1, edit freely."

---

*End of proposal v0.1. Every section is meant to be challenged. The author hands it back to the jam.*