Update 7/26/2025
I’ve shifted directions on this project. Originally, the concept was focused on NFC-based anonymous group chat, but after exploring the user flow and technical constraints, I decided to drop NFC entirely and move to a QR-based invite system. It’s faster, more flexible, and easier to scale beyond close-range use cases.
The broader idea is evolving into something more focused: lightweight, private communication without accounts or stored identities. Anyone in a stream can now generate a one-time-use QR code to invite others. I’m working toward an invite system that uses Firebase to validate and expire these codes after use, making the experience feel ephemeral and self-contained.
This is helping me think more critically about access models, onboarding flows, and how trust can be designed into a system without logins or profiles. Still early, but this shift unlocked a much more usable concept.
The broader idea is evolving into something more focused: lightweight, private communication without accounts or stored identities. Anyone in a stream can now generate a one-time-use QR code to invite others. I’m working toward an invite system that uses Firebase to validate and expire these codes after use, making the experience feel ephemeral and self-contained.
This is helping me think more critically about access models, onboarding flows, and how trust can be designed into a system without logins or profiles. Still early, but this shift unlocked a much more usable concept.
Update 7/23/2025
The app is now fully running in Android Studio with Firebase Realtime Database handling temporary session and stream data. Core functionality is working on multiple devices.
The concept is taking shape: a tap-to-join group chat with no user accounts, no names, no data sent to the server — just presence.
The concept is taking shape: a tap-to-join group chat with no user accounts, no names, no data sent to the server — just presence.
When the creator clicks "Nuke Stream," the creator and anyone in the session are sent back to the Start Screen.
a. The Session ID, Device ID, and all messages are deleted from that session.
b. If the original creator creates a new session/stream, the app will assign a new Session ID and not reuse the old one.
c. Those who have joined a stream can choose to leave it and must tap to join again. Leaving sends them to the Start Screen.
a. The Session ID, Device ID, and all messages are deleted from that session.
b. If the original creator creates a new session/stream, the app will assign a new Session ID and not reuse the old one.
c. Those who have joined a stream can choose to leave it and must tap to join again. Leaving sends them to the Start Screen.
If the creator is the only one in the stream, they must still "Nuke the Stream" to leave. That session is wiped.
Update 7/19/2025
This is still in the early design ideation phase. I will update as things progress.
V2 7/23/2025
V1 logo
V1 7/19/2025
Phase 1 – Core Prototype (Complete)
Built and tested a fully functional Android prototype.
Uses Firebase Realtime Database to store ephemeral stream and session data.
Multi-device chat working with presence tracking and auto cleanup when the stream is empty.
Mobile-first design with a 4-column layout grid.
No login, no usernames, no data sent to the server, only stream activity is stored.
Uses Firebase Realtime Database to store ephemeral stream and session data.
Multi-device chat working with presence tracking and auto cleanup when the stream is empty.
Mobile-first design with a 4-column layout grid.
No login, no usernames, no data sent to the server, only stream activity is stored.
Phase 2 – NFC-Based Access (In Progress)
Only way to join a stream is by tapping phones with a current member.
Stream IDs are not publicly listed or typed, shared only through NFC.
No global user identities or discoverability.
Exploring debug option to manually join with a stream ID during development.
Stream IDs are not publicly listed or typed, shared only through NFC.
No global user identities or discoverability.
Exploring debug option to manually join with a stream ID during development.
Phase 3 – Optional Lightweight Moderation & Anonymity Upgrades (Planned)
Basic client-side sanitation:
– Normalize contractions (can't → cannot).
– Strip obvious personal data (dates, floor numbers, email addresses).
Optional “Feels suspicious” button to flag a user anonymously.
Possible challenge system for vetting or soft moderation.
– Normalize contractions (can't → cannot).
– Strip obvious personal data (dates, floor numbers, email addresses).
Optional “Feels suspicious” button to flag a user anonymously.
Possible challenge system for vetting or soft moderation.
Phase 4 – Optional AI Style Layer (Future / Experimental)
Client-side or lightweight rewriter that adjusts message tone
Stream creator can pick a style:
– Corporate formal
– Shakespearean
– Pirate
– Passive-aggressive Wisconsin mom
Style setting would apply to all messages in a stream.
Toggleable or upgradeable as a premium feature.
Stream creator can pick a style:
– Corporate formal
– Shakespearean
– Pirate
– Passive-aggressive Wisconsin mom
Style setting would apply to all messages in a stream.
Toggleable or upgradeable as a premium feature.
Bonus / Long-Term Ideas
Stream self-destruct timer (e.g. 2-hour rooms).
Vetting rules: require approval from existing members to join.
“Toss back to the lake” – kick/ban user from rejoining.
FireChat-style mesh/local mode with no server.
Vetting rules: require approval from existing members to join.
“Toss back to the lake” – kick/ban user from rejoining.
FireChat-style mesh/local mode with no server.