Version 1.1 · August 08, 2026 · Beta system description

Litterbug is a mobile application that promotes decentralized litter collection efforts. It combines camera-assisted litter logging, human review of machine-vision output, community building, and optional person-to-person incentives including tipping and litter collection bounties. Its purpose is to socially normalize litter collection and create a new form of environmentalism through micro-gig-ecology and economy.

Scope note. This paper describes the current beta architecture. The product is not yet publicly released on the App Store.

Contents

1. Guiding vision
2. Problem and design principles
3. Application tabs
4. Vision and recognition pipeline
5. Human review and model training
6. Data model and security
7. Community, sharing, and map workflows
8. Tips, bounties, and payouts
9. Limitations and roadmap
10. Privacy and responsible operation
11. AI development statement

1. Guiding vision

Litterbug aspires to create a new culture and economy around ecology, specific micro-gig-ecology. Gigification of the workforce currently is focused on tasks that take considerable time to complete and are broad in scope, such as rideshare services. While having positive ecological impacts, these gigs do not have explicit environmental benefits woven into them. Litterbug seeks to promote a new form of environmentalism, micro-gig-ecology, which are short duration, economically incentivized tasks, that have environmental benefits.

Beta phase Litterbug seeks to incentivize litter collection through tipping and the setting and collection of bounties. These tools are currently sandboxed, meaning the service is functional for testing only, with no exchange of user funds. The goal of Litterbug is to build on this incentive foundation, including organizing Litterbug as a cooperative, where platform earnings are distributed among members based on effort.

Potential future income sources for Litterbug users include app sales and annual membership fees, advertising within the platform from major brands collected and seeking to demonstrate their commitment to the environment, and merchandise sales for litter collection equipment and swag. Versions of Litterbug will be available to business and government agencies, allowing for direct payments to Litterbugs through bounties that benefit communities. Litterbug will further incentivize use through tipping users and subsidizing bounties through state and federal grants.

2. Problem and design principles

Litter collection benefits people through improving our local environment, enhances human health via time spent outdoors and reductions in pollution (e.g., microplastics), and promotes community cohesion by encouraging positive interactions between people within neighborhoods. Litter is a tragedy of the commons, where the responsibility for litter collection is assumed by the government and contractors through tax dollars. While these efforts are substantial, they cannot address the continuous flow of litter into the environment, nor do they promote a society that feels responsbile for pollution or incentivized to enhance the environment they reside within. Litterbug addresses these problems by decentralizing, democratizing, and incentivizing litter collection.

• Shared stewardship is primary. Litterbug is designed to make local environmental care socially normalized.
• Technology supports society. The app helps people document what they collect.
• Community efforts are visible. Sessions, public posts, map spots, and leaderboards help neighbors, government, and industry support local litter collection.
• Incentives support action. Optional tips and bounties give communities tools to support litter collection with more incentives planned.

3. Application tabs

Scan

The Scan tab is the field workflow. A physical device camera feeds a frame processor; detections are tracked across frames before an item is promoted to a count. The scanner can attach a short-lived foreground location lookup, haptic feedback, a review image, and later OCR-derived brand information. The current native camera/model path is intentionally unavailable in iOS Simulator because it depends on native TensorFlow Lite components.

Train

The Train tab is the session and review workspace. It lists current-session items, summarizes container and brand counts, and presents an observation-review queue. A participant can correct container type, brand text, OCR text, bounding box, or resolution state; tag observations; and remove mistaken review records. Reviewed items award in-app training XP and contribute to badges and the Litterbug progression state.

Share

Share has Community and Leaderboard subtabs. Community supports posts, optional images, hashtags, reactions, session shares, cleanup-completion content, and weekly summaries. Session sharing can build a visual card with selected cleanup totals, route-style map context, and a location granularity selected by the user. Session cards can be exported for off-application sharing including social media and text messages. Leaderboard rankings are derived from public aggregate cleanup totals; the interface can offer optional tips to eligible users.

Map

The Map tab uses foreground location and native maps to show community cleanup spots. A user may create a spot with a title, description, optional image, and location; another user can claim it, submit a completion, and move it through open, claimed, awaiting-validation, and done states. A poster may fund a bounty for a spot. Bounty release is triggered by a user claiming and completing the cleanup spot, followed by the poster validating the cleanup effort. Spots without bounties do not require validation because there is no monetary exchange.

Profile

Profile provides personal totals, cleanup history, badge and progression information, feedback, account controls, and payout controls. People receiving funds complete Stripe Connect onboarding in a browser-hosted Stripe flow. The screen can show available and pending balances, payout readiness, external-account status, payout schedule, and standard or instant cash-out options where Stripe and the account allow them.

4. Vision and recognition pipeline

Definition. Hereafter the “client” is the Litterbug mobile application running on a participant’s device.

The live detector is litterbug_v1, a TensorFlow Lite object-detection model with a 320 × 320 input and 18 upstream class indices. Nine usable litter labels are mapped to product-facing container types: cardboard; clear plastic bottle; crisp packet/wrapper; disposable plastic cup; drink can; glass bottle; paper cup; plastic straw; and polystyrene. Six malformed upstream labels and bottle-cap subparts are deliberately suppressed. The client also recognizes a broader correction taxonomy such as bags, cigarette litter, film, cutlery, foil, gloves, masks, fragments, and other.

Raw detections are not immediately logged. The scanner applies a confidence threshold, dimensional sanity checks, and candidate limits; then links boxes over time using overlap, center distance, size, shape, and appearance continuity. An object must persist across multiple observations and a short dwell window before it counts. This lowers duplicate counts when a camera remains over one item, while special handling accommodates small or elongated objects such as straws. The scanner retains only a bounded number of active tracks and applies a cooldown/handoff policy before recognizing a new object.

Brand recognition is a separate, asynchronous path. A cropped region around an active object is sent to native OCR; text may update a recently logged item only inside a short attachment window. The app normalizes known aliases against a large brand lexicon. It also includes an experimental on-device TinyBERT-style named-entity-recognition model: 64-token BERT inputs (input_ids, attention_mask, token_type_ids) produce [1,64,3] logits for O, B-BRAND, and I-BRAND. This model is a developing enhancement, not a substitute for review. Table 1 summarizes the mobile-client and on-device-vision layers that support this pipeline.

5. Human review and model training

For each scanned item, the review system can preserve a snapshot, detector summary, OCR text, scan context, corrected brand and container type, semantic bounding-box data, tags, and a resolution status. Deferred processing keeps intensive image and model work off the live scanning path and supports retrying interrupted uploads or review synchronization.

The scan and train structure provide complementary functions, the event record from the field and the richer evidence record used to assess and improve model recognition in future builds. Corrections are exported daily from the client to Cloudflare storage, which is offloaded weekly to cold storage using an automation. These images will be curated into training datasets. Client training, however, does not dynamically update Litterbug’s live counting model, which is a static build. The system’s gamification—XP, stages, collectible Litterbugs, and badges—rewards review participation. The backend and media layers supporting this workflow are summarized in Table 1.

6. Data model and security

Supabase Auth maintains account sessions. Profile data includes a username, aggregate item total, account timestamps, and limited Stripe identifiers/status fields. Core tables include authoritative litter items; sessions; reviewed observations; community posts, comments, and reactions; cleanup spots, claims, and completions; badge-related records; and payment/payout ledgers. Location, time, container type, confidence, and a nullable brand can be associated with a litter item.

The mobile client treats litter_items as the runtime source of truth. Richer images, OCR, corrections, and diagnostic artifacts are stored in a separate review path so the core session, profile, and leaderboard views do not depend on a slow model-processing job.

Postgres row-level security constrains user-owned reads and writes. Sensitive counters and payment fields are not client-writable. Payment operations use authenticated Edge Functions and Stripe secret keys held server-side; client code receives only the data needed to present a payment sheet or reflect status. Realtime subscriptions keep selected app views current without requiring a polling loop. Table 1 identifies the backend technologies that implement these controls.

7. Community, sharing, and map workflows

Community content has explicit source types—ordinary user post, session share, cleanup spot, spot completion, or weekly summary—and can carry public media, hashtags, reactions, and moderation visibility. The map is designed for coordination rather than surveillance: foreground location is used when permission is granted, and a participant chooses what location precision to expose in a share. A map spot is public by design and should never be created for a sensitive location.

Badges recognize cumulative cleanup, training, and community milestones. They are a motivational layer and gamification component. Leaderboard and weekly-summary data are aggregation views over cleanup activity; they do not independently verify disposal, location ownership, or the environmental condition of a place. The mobile client, backend, media, and device-service layers involved in these workflows are listed in Table 1.

8. Tips, bounties, and payouts

The beta test payment system is fully sandboxed, meaning the user can demo payments, but payments from client-owned bank accounts or credit cards are disabled. This means the user can trial the payments system without transferring any of their own money.

Litterbug supports optional USD tips and cleanup-spot bounties. The current beta permits values from $1.00 to $500.00 per payment. A payment starts in an in-app Stripe PaymentSheet with card support and, where configured, Apple Pay or Google Pay. Users cannot tip themselves. Stripe customer, card, bank, identity-verification, and destination-account details are handled by Stripe rather than stored as raw payment data by Litterbug.

The current fee calculation is transparent but estimated at checkout: the intended recipient amount, a 1% Litterbug platform fee to support project development, and an estimated domestic-card processing charge (2.9% plus $0.30, grossed up) form the displayed total. Stripe’s actual fee is reconciled afterward in the server ledger. Payment records retain kind, amount, total, platform fee, estimated and actual processor fee, PaymentIntent/charge/transfer identifiers, timestamps, and state such as requires-payment, processing, succeeded, released, refunded, or failed.

Funds for eligible recipients move through Stripe Connect. A recipient must complete Stripe onboarding and have required charges/payout capabilities enabled before funds can be released or withdrawn. The app exposes balance and payout health, while Stripe determines availability, account requirements, schedules, and whether instant payout is offered. A bounty is associated with a map spot and its completion/validation workflow; validation must be completed by the spot creator before bounties are released to the claimant. In beta, payment systems may operate in Stripe test/sandbox mode. Table 1 summarizes the payment and backend layers that support these flows.

9. Limitations and roadmap

Vision models can fail because of occlusion, poor lighting, motion, crushed containers, unfamiliar packaging, object overlap, and domain shift. OCR may miss, misread, or over-read text. A detection or brand match should be understood as a suggestion with a confidence score, not proof. Human review, spatial/temporal tracking, and conservative count promotion mitigate errors but do not eliminate them.

Current work includes improving custom litter detection and brand extraction, strengthening correction-data provenance, refining community moderation and validation, and testing financial workflows before a public release.

10. Privacy and responsible operation

Litterbug can process profile information, camera frames, optional review images, foreground location, public community content, diagnostic data, and payment metadata. Public surfaces may show usernames, aggregate totals, posts, map pins, and media chosen for public sharing. Exact locations and images can be sensitive even when a cleanup is well-intentioned. Users should take care when posting personal information including location data, as the client may unintentionally reveal sensitive data, such as the location of their home or place of work.

The system uses Supabase for auth and backend data, Cloudflare R2 for object media, Stripe for financial activity, device platform services for camera/location/diagnostics, and an anonymity password checking plugin during signup. Litterbug does not sell personal information and does not use third-party advertising or cross-app tracking. For the full disclosures, rights, and retention terms, read the Privacy Policy.

11. AI development statement

Litterbug was developed through a human-led, LLM-assisted engineering process. The project’s creator (Elias H. Bloom) directs the product purpose, feature priorities, architecture choices, policy language, financial model, and release decisions. Bloom conducts device and field testing, inspects implementation changes, diagnoses observed failures, and decides whether a proposed change is accepted, revised, deferred, or removed.

Large language models, including Codex, have been used as collaborative development tools: to discuss designs, draft and revise code and documentation, propose debugging hypotheses, organize implementation tasks, and translate human test feedback into candidate changes. Those suggestions are not treated as authoritative. Those LLM suggestions are implemented and tested through human feedback, limiting the LLMs’ agency within the project space. In other words, the LLM does not work independently of human feedback on any given task during the beta build process.

Litterbug does not use a generative LLM within the beta application itself. An earlier LLM-based OCR-cleanup experiment was deliberately deferred after device testing found the available local runtimes unreliable; its outputs were removed from the active review flow. Human correction remains the mechanism for resolving uncertain observations.

As with any LLM-assisted software project, generated code can have unknown vulnerabilities. Technical claims in this paper describe the implemented beta at the time of publication generated by the LLM and proofed by Bloom. If a future release adds a cloud or generative-AI service to a user-facing workflow, Litterbug will document the change and update its privacy disclosures before release.