RXN - Reaction Capture App

Overview

RXN is a concept for a mobile application that captures someone's reaction at the moment they open content you sent them. You send a message, a photo, or a video, and what comes back is how they actually responded to it.

It never got past concept and system design. What follows is the architecture such an application would need, and the privacy questions it would have to answer first.

The concept

Core interaction

1. The sender creates the content: a message, an image, or a video.
2. The receiver opens it on their device.
3. The front camera records their reaction as the content appears.
4. The reaction media goes through processing.
5. The reaction is delivered back to the sender.

Everything hangs on step three. The value is the unfiltered moment, before someone has had time to compose a response.

Features

On paper the feature set is small. You send messages, photos, or videos to a recipient, their front camera records automatically when they open one, and the sender gets that recording back. Around all of it sits the part that is not small: consent, retention limits, abuse prevention, and a media pipeline that can move reaction video around efficiently.

Technical considerations

Client architecture

The mobile clients handle:

• Content display and reaction triggering
• Front camera capture with quality optimization
• Local processing before upload
• Offline queueing for poor connectivity

The capture has to be invisible. Any delay, or any visible indication that recording is happening, ruins the thing being recorded.

Media pipeline

Reaction video is expensive to store and serve, so the architecture has to trade quality against cost somewhere. Uploads need to be chunked or resumable to survive a bad connection. Transcoding on the way in keeps playback consistent. Storage sits behind a CDN so the sender gets the reaction quickly, and a retention policy clears it out automatically instead of leaving it there forever.

Privacy architecture

Consent comes first. The recipient has to agree to reaction capture, has to be able to see what is recorded and when, and has to be able to opt out without social pressure.

Data handling follows from that: minimal retention periods, user control over their own reaction data, and a clear deletion process.

Abuse prevention is its own layer. Rate limiting on how much content an account can send, reporting mechanisms for misuse, age verification and safety features.

Privacy isn't an afterthought. It's architectural.

System architecture

graph TB
    subgraph clients [Clients]
        Sender[Sender App]
        Receiver[Receiver App]
    end
    
    subgraph api [API Layer]
        ContentAPI[Content API]
        ReactionAPI[Reaction API]
        NotificationSvc[Notification Service]
    end
    
    subgraph media [Media Pipeline]
        Upload[Upload Service]
        Processing[Processing Pipeline]
        Storage[Media Storage]
        CDN[CDN Delivery]
    end
    
    subgraph data [Data Layer]
        UserDB[User Database]
        ContentDB[Content Metadata]
        ConsentDB[Consent Records]
    end
    
    Sender --> ContentAPI --> Storage
    ContentAPI --> NotificationSvc --> Receiver
    Receiver --> ReactionAPI --> Upload --> Processing --> Storage
    Storage --> CDN --> Sender
    ContentAPI --> ContentDB
    ReactionAPI --> UserDB
    ReactionAPI --> ConsentDB

Design decisions

Capture timing

Capturing on open is the most authentic option, and potentially the most invasive. Delaying the capture is more comfortable and less authentic. Letting the recipient trigger it themselves is not authentic at all.

The value proposition depends on authenticity, but that tension with privacy has to be resolved thoughtfully.

Retention policy

How long a reaction exists is as much a product decision as a storage one:

• Ephemeral: auto-delete after viewing, the Snapchat model
• Time-limited: delete after a fixed period
• Sender-controlled: the sender decides how long it lives
• Recipient-controlled: the recipient can delete their own reactions

The right answer depends on the use case and on user expectations.

Notification design

Notifying someone without spoiling the moment is its own problem. The notification says that content is available, not what it is, and nothing indicates that a reaction will be captured. Surprise and informed consent are hard to balance here too.

Challenges

Technical challenges

On the technical side: camera access and capture have to be instant, video processing at scale is expensive, battery and mobile data take a hit, and behavior has to stay consistent across platforms.

Product challenges

On the product side: explaining the concept without killing the authenticity that makes it work, building trust around privacy, handling the "creepy" factor, and finding the use cases where anyone actually wants this.

Ethical considerations

Then there are the ethics. Informed consent versus authentic reactions. The potential for harassment or misuse. The impact on genuine human interaction, and the data retention and surveillance concerns.

Lessons from the concept

Designing RXN taught me four things. Privacy is architectural: you can't add it to a system that was designed without it. Media pipelines are complex, and video at scale takes serious infrastructure thinking. Product ethics matter, because technical possibility doesn't mean product viability. Consent models are hard, because balancing user experience against informed choice is nuanced.

Status

RXN is still a concept and a system design exercise. The architecture thinking and the privacy considerations apply to plenty of media-heavy applications, implemented or not.