The Local Agora: A Retro AI Machine for Finding Local Events

Jonathan Lee — Mon, 13 Jul 2026 04:37:45 +0000

This is a submission for the Weekend Challenge: Passion Edition.

What I Built

I built The Local Agora, a retro-inspired Android event discovery machine for finding local music, comedy, and theater performances.

The basic interaction is simple:

Choose a city or ZIP code.
Choose when you want to go.
Choose music, comedy, or theater.
Scan for current public event information.
Open the original source to verify the details.

The interface is designed like a strange monochrome civic machine: part CRT terminal and part mythological signal receiver.

Behind that visual identity is a grounded Google AI discovery system called the Keryx Engine.

Why I Built It

I am a musician and help operate a small DIY performance space. I have seen how much passion exists in local creative scenes—and how easily events disappear inside scattered social posts, flyers, venue pages, and ticket listings.

A great local show can be happening only a few miles away while the people who would love it never learn that it exists.

The Local Agora is my attempt to help those scenes become easier to discover without turning them into another social network, advertising feed, or map covered in promoted pins.

Its guiding phrase is:

Find your scene. Grow your scene.

Demo

Watch the Android video demo on YouTube

The video shows an earlier physical Android build of The Local Agora.

Since recording it, I completed several additional parts of the challenge build:

Real grounded event discovery through a protected Firebase callable
Current public source links inside event results
Improved text-only CRT results
Bottom-anchored controls and improved phone layout
A protected Add Event contribution flow
Server-side submission validation
Pending Firestore storage for community-submitted events
Deny-all direct client access to Firestore
Additional automated testing
Android and Flutter web builds

The protected contribution backend is deployed. Its final Android-to-Firestore physical verification is the next acceptance test, so I am not claiming that final device proof as completed in this submission.

During physical testing, the live discovery system successfully returned sourced events for locations including Springfield, Missouri and Mountain Home, Arkansas.

Code

View The Local Agora on GitHub

Challenge snapshot:

Repository: JonathanEdwardLee/the-local-agora
Branch: pass-03-agora-discovery-vertical-slice
Commit: 4408b9fa53a9b5648ae626a650246344c17d6d0e

The project was developed during the challenge window.

The latest build produced:

A working Android debug APK
A successful Flutter web build
131 passing Flutter tests
39 passing Firebase Functions tests
Passing Flutter analysis
Passing TypeScript compilation
Security tests confirming unauthorized Firestore reads and writes receive 403 PERMISSION_DENIED

How I Built It

Flutter and Dart Client

The application is built in Flutter and Dart so the same product can support Android, web, and a future iOS release.

Android was the primary physical test target for this weekend.

Instead of using conventional cards and map markers, I designed a text-first interface around:

A monochrome CRT display
Dial-like time and category selectors
Source actions presented as terminal text
A shared procedural Junkfeathers Tech startup animation
A portrait-oriented machine layout
Accessible controls beneath the retro presentation

The Keryx Engine

The most important technical decision was separating discovery from factual normalization.

Keryx uses a two-stage process:

Grounded discovery searches current public information using the Gemini API and Google Search grounding.
Fact-constrained normalization converts supported findings into structured event records.

The normalization stage is not allowed to freely invent missing information.

When an event time, price, age restriction, address, performer, or ticket link cannot be supported by a public source, it remains unknown.

Every displayed event preserves a path back to its original source.

This was important to me because an event finder becomes harmful very quickly if it confidently invents details.

Protected Google Cloud Architecture

The Google AI work happens on the server rather than exposing secrets inside the Flutter application.

The current stack includes:

Flutter and Dart
Firebase Cloud Functions, second generation
TypeScript
Node.js 22
Firebase App Check
Gemini API with Google Search grounding
Cloud Firestore
Server-side schema validation
Firebase Admin SDK writes

The live Keryx route has been proven end to end on a physical Android phone through:

Android app
→ Firebase App Check
→ Protected callable function
→ Gemini with Google Search grounding
→ Fact-constrained normalization
→ CRT event results
→ Original public sources

The deployed event-submission callable is:

submitEventContribution
Region: us-central1
Runtime: Node.js 22
Memory: 256 MiB

The existing keryxScanDebug and keryxStatus functions were preserved rather than modified unnecessarily.

Community Event Contributions

I also built Add Event Lite so community members can contribute a missing public event.

The form accepts only public event information:

Event name
Music, comedy, or theater
Date and start time
Venue
City and state
Public source or ticket URL
Optional short description

The application does not request a submitter name, email address, or phone number.

Submissions travel through the App Check-protected submitEventContribution callable. The server validates the information and creates a Firestore record with server-controlled values including:

status: pending
origin: community_submission
schemaVersion: 1

The Flutter client cannot approve its own submission or write directly to Firestore.

Firestore rules deny direct client reads and writes, including access to the eventSubmissions collection.

I verified those rules with unauthenticated REST read and write attempts. Both were rejected with:

403 PERMISSION_DENIED

Server-side negative tests also confirmed that the following inputs are rejected:

Invalid URLs
Invalid event types
Past event dates
Attempts to submit a client-controlled approved status

Cost and Abuse Control

A public AI event finder could become expensive if every visitor caused a new discovery request.

The production direction is therefore cache-first:

Return useful recent stored events when available.
Invoke grounded AI discovery only when information is missing or stale.
Normalize and store useful results.
Reuse those results for later visitors.
Accept missing events from the community into pending review.

The shared cache and event index are the next production milestone. I intentionally did not rush them into this weekend build.

Privacy and Source Honesty

The Local Agora does not infer or expose private venue addresses.

Supported location information can remain at levels such as:

Exact public address
Venue only
General area
City only
Ask the organizer

Unknown information stays unknown.

The app does not claim that its results are a complete list of every event. It presents sourced public signals and lets the user inspect the original source.

Building With AI Tools

I built this as a solo founder using AI tools as specialized collaborators.

Cursor was the primary repository implementation agent.
ChatGPT helped with product planning, architecture review, risk analysis, acceptance criteria, and continuity.
Google AI and Gemini power the actual event-discovery system.

I remained responsible for product direction, scope decisions, physical-device testing, privacy boundaries, source-honesty rules, and final acceptance.

One major lesson from this weekend was that AI-assisted development works best when each agent receives:

A bounded assignment
An exact starting commit
Clear acceptance tests
Protected systems it may not alter
A required technical handoff

That approach helped me make significant progress without allowing multiple AI systems to overwrite each other’s work.

Technical Progress During the Weekend

The project moved from a product blueprint to a functional Android application with:

A custom Flutter interface
Physical Android testing
Grounded current-event discovery
Supported event normalization
Working public source links
Protected Firebase communication
App Check integration
A deployed contribution function
Server-side validation
A new Firestore database
Pending community submissions
Default-deny database rules
Android and web builds
More than 170 combined passing tests

I deliberately did not add:

User accounts or public profiles
Social feeds
Embedded maps
Ticket sales
Billing
Paid placement
Nationwide background crawling
Automated flyer extraction

The goal was to build one useful and trustworthy vertical slice instead of a large collection of unfinished features.

Current Limitations and Next Steps

The Local Agora is still an early challenge build.

Current limitations include:

The newest Add Event backend still needs its final physical Android submission proof
The Flutter web build is not yet publicly deployed for production use
Pending community submissions require a future review process
The shared cache-first event index is not built yet
Flyer image extraction is intentionally deferred
Android is currently the primary tested platform

The next milestone is a shared Firestore event index that lets one grounded discovery serve many visitors.

After that, I plan to securely release the Flutter web version and continue turning The Local Agora into a useful public tool for local creative communities.

Prize Categories

Best Use of Google AI

Google AI is not a decorative chatbot inside this project. It performs the central product function.

The Gemini API with Google Search grounding discovers current public event signals. A separate fact-constrained normalization stage converts those findings into structured records while preserving original sources and refusing to invent unsupported details.

This allows The Local Agora to search the fragmented public web while remaining honest about:

What it knows
What it does not know
Where each event came from
Which details require verification

Google AI makes the product possible, while the surrounding Firebase and Flutter architecture makes that AI safer, reusable, and practical for a public application.

DEV Community: Jonathan Lee