Revival

Throwing away old and broken tech is in the past. Connect with other people to turn the old and useless into new and helpful.

Comment

Inspiration

A broken screen should not mean throwing away an entire laptop. Someone else might have the part it needs, but those two people may never find each other.

I wanted to build around that gap. We can reach people across the world in seconds, yet useful materials still become waste because we cannot connect the person who needs something with the person who already has it. Wasting usable parts for that reason should be a thing of the past.

Revival starts with electronics. The idea is to make offering a spare part or asking for a repair as easy as sending a message.

What it does

Revival is a community repair network. You can add a broken device or donor device on the website, then text a one-use LINK command to the project's Photon iMessage line to continue that same intake from your phone.

Take a picture of the device or its model label and send it in the conversation. Gemini extracts visible details and reported symptoms, and the device updates on the website. You can also start directly in iMessage. STATUS returns your device's details, NEW starts another intake, and DONATE lets you offer a donor device and its parts.

The resurrection map shows real submissions and potential connections between devices with the same reported model and overlapping part needs. Every candidate still needs someone to check the exact part number, connector, condition, and suitability before a repair.

The theme

I used Frutiger Aero's bright blues, glass panels, water, greenery, and glossy buttons to give Revival an optimistic view of technology. That visual style fits the project's purpose: a connected world where people help each other keep useful things in circulation.

The interface starts with an empty network. The people using it create the connections, and their devices become the story on the screen.

How I built it

I built the frontend with React, TypeScript, and Vite, with an Express backend. Photon receives iMessage text and image attachments. Gemini reads intake descriptions and images into structured fields. Tiger Data stores device inventory and conversation state, while Timescale hypertables preserve message and event history. SQL finds candidate part connections and groups recent message activity into hourly buckets.

OpenAI Codex helped me build, revise, debug, and test the app. I kept API keys and database credentials on the server in an ignored environment file. The current version runs locally, and the source is on GitHub.

How the tracks connect

Frutiger Aero: The blue sky and water palette, translucent panels, greenery, and glossy controls connect the event's visual theme to the project's optimism about technology and reuse.

Community: Revival helps people offer donor devices and find parts for broken electronics. It creates a shared inventory of what people need and what others can contribute.

Gemini: The app uses Gemini's multimodal API to extract device details from text and photos, including photos received through iMessage.

Photon: iMessage is part of the product flow. A website intake can move into a phone conversation, where photos and follow-up messages update the same device.

Tiger Data: The app uses a live Tiger Data database for actual inventory and conversation state, SQL candidate matching, Timescale message and event hypertables, and hourly activity queries with time_bucket.

These are the integrations implemented in this version. Track selection and eligibility still depend on the event's form and rules.

Challenges I ran into

The biggest challenge was moving from a convincing mockup to a real intake flow. Website submissions, phone photos, and follow-up messages needed to refer to the same device. I added one-use link codes, conversation-specific state, and duplicate-message checks.

Gemini also returned temporary high-demand errors during testing. I added a retry and made sure an unavailable model would not erase someone's submission. Another challenge was keeping the matching honest: a photo can help identify a device, but it cannot prove that an internal part works or that two components fit.

Accomplishments I'm proud of

I replaced the fictional demo inventory with real submissions, connected Photon and Gemini, and verified the live Tiger Data connection and Timescale hypertables. The build and six automated tests passed. I also tested photo upload, image serving, and intake persistence in an isolated environment so test records would not clutter the live network.

What I learned

The difficult part of a repair network is keeping the device, its owner, its messages, and its possible parts connected as information arrives. A message interface makes intake easier, but the data behind it still needs clear ownership and reliable persistence.

I also learned to separate AI extraction from hardware verification. Revival can organize an offer; a person still needs to check the part.

What's next for Revival

Next I want to add verified part numbers, repair volunteers, reservations, and scheduling. After that, I want to record completed repairs and measure the devices and materials kept in use. Those features are future work; this version handles intake, conversation continuity, and candidate discovery.

Built With

Share this project:

Updates

Submission history