System Requirements Document for anonymous-messaging-inbox

1. Introduction

anonymous-messaging-inbox is a production-ready mobile anonymous-messaging application for Android and iOS. It enables a person to create a profile, receive anonymous messages through a unique personal link, manage received messages in a private inbox, and share their link through supported social channels.

The product is inspired by the familiar anonymous social-message experience and interaction patterns of the current NGL app, while using original code, original app branding, and original visual assets. It must not copy NGL’s logos, wordmark, copyrighted assets, or exact proprietary visual artwork.

The audience includes people who want to invite anonymous messages through a shareable link, people who wish to send an anonymous message without creating an account, and authorized administrators who moderate abuse and manage reported content.

2. System Overview

The system consists of:

• A React Native + Expo mobile application for Android and iOS.
• Public anonymous-message surfaces available through a recipient’s unique URL, such as https://myapp.com/u/username.
• Authenticated recipient experiences for onboarding, inbox management, profile management, settings, and message actions.
• A separate, role-restricted administrative dashboard for moderation and user management.
• Backend services for authentication, secure data storage, message delivery, notification delivery, abuse controls, and moderation.
• Push notifications that notify recipients when a message arrives.

Recipients create an account and profile, choose a username, generate a personal anonymous-message link, and share it through Instagram, WhatsApp, Snapchat, copy-link actions, or the device system share sheet. Anonymous senders can open a public recipient link and submit an anonymous message without creating an account when anonymous submissions are enabled.

Received messages are stored in the intended recipient’s private inbox. Recipients can read, reply to, share, delete, report, block, and view permitted sender details for messages. Administrators can review reported messages, remove abusive content, ban accounts, manage users, access authorized technical metadata, and manage moderation settings.

2a. Product Interpretation and Delivery Boundary

The mobile product must be real and functional rather than a prototype, mockup, or collection of fake controls. Every major button and flow must perform its intended function.

The application owns recipient authentication, onboarding, private inboxes, profile management, settings, public message-link delivery, message storage, moderation workflows, and administrative access. Social applications and the device share sheet are external destinations used to distribute a recipient’s personal link.

Anonymous message senders do not need an account when anonymous submissions are enabled. A sender’s real-world identity must never be claimed, inferred, or exposed merely because they sent a message. Sender details are limited to information that is legitimately collected, authorized for display, and permitted by applicable law.

The current scope includes Android and iOS delivery, account creation and login, anonymous message submission, private inbox management, push notifications, abuse controls, and administration. It excludes copying NGL proprietary branding, logos, assets, or exact visual artwork.

2c. Page Content and Component Coverage

Landing

• Information and state: Public introduction to anonymous-messaging-inbox; original product messaging; entry choices for sending a message through a supplied public link or accessing recipient authentication.
• Primary actions: Continue to Login; open a valid shared personal message URL.
• Supporting actions: View the public-facing anonymous-message concept.
• Components: Full-bleed colour-blocked product introduction, original masquerade-mask illustration, primary CTA, secondary access link.
• States and recovery: Loading state while resolving deep-link routing; invalid or unavailable public-link routing informs the visitor and permits return to Landing.

Login

• Information and state: Recipient email/password signup, login, forgot-password recovery, and secure-session entry.
• Primary actions: Sign up; log in; request password recovery.
• Supporting actions: Return to Landing.
• Components: Email field, password field, signup/login controls, password-recovery control, validation messaging.
• States and recovery: Show authentication progress; identify invalid credentials or unavailable service without exposing sensitive account information; allow retry; establish a secure session before protected recipient access.

Welcome screen

• Information and state: First protected onboarding screen for a newly authenticated recipient.
• Primary actions: Continue to Create username.
• Supporting actions: Review onboarding introduction.
• Components: Original visual welcome poster, onboarding prompt, Continue button.
• States and recovery: Resume onboarding for an authenticated recipient whose onboarding is incomplete.

Admin Login

• Information and state: Separate administrator and moderator access boundary.
• Primary actions: Authenticate to access Admin dashboard.
• Supporting actions: Return to Landing.
• Components: Administrator credentials, secure-session controls, access-denied messaging.
• States and recovery: Reject non-administrator sessions; allow authorized administrator retry; do not reveal administrative data before authorization succeeds.

Create username

• Information and state: Username selection for the recipient’s profile and unique public-link identity.
• Primary actions: Enter and continue with an available username.
• Supporting actions: Revise an invalid or unavailable username.
• Components: Username input, availability validation, Continue button.
• States and recovery: Validate format and uniqueness; retain the entered value when correction is required.

Profile setup

• Information and state: Recipient profile setup, including short profile description/bio.
• Primary actions: Save profile information and continue.
• Supporting actions: Edit entered profile information.
• Components: Profile description input and Continue button.
• States and recovery: Validate input; preserve entered content when saving fails; permit retry.

Profile picture

• Information and state: Recipient profile-picture selection.
• Primary actions: Add or update the profile picture and continue.
• Supporting actions: Continue with the accepted onboarding progression after picture handling.
• Components: Image selection/upload control, preview, Continue button.
• States and recovery: Show upload progress and failure; allow image re-selection or retry.

Notification permission

• Information and state: Push-notification permission request during onboarding.
• Primary actions: Request notification permission; continue after the device response.
• Supporting actions: Continue if permission is declined.
• Components: Permission explanation, system permission trigger, Continue button.
• States and recovery: Record the device permission result; recipient can later manage notification preference in Settings.

Generate personal message link

• Information and state: Unique personal anonymous-message link generation, such as https://myapp.com/u/username.
• Primary actions: Generate and confirm the personal link.
• Supporting actions: Continue to Share link.
• Components: Generated URL display, link-generation status, Continue button.
• States and recovery: Handle uniqueness or backend failures without completing onboarding until a valid link is generated; allow retry.

Share link

• Information and state: Onboarding share prompt showing the generated personal link.
• Primary actions: Share through Instagram, WhatsApp, Snapchat, Copy link, or the system share sheet.
• Supporting actions: Continue to Home / Inbox.
• Components: Link preview, social-share tiles, Copy link control, system-share trigger.
• States and recovery: Confirm copied or handed-off share action; if a target application is unavailable, retain alternative sharing methods.

Home / Inbox

• Information and state: Authenticated recipient’s private message inbox, notification badge, read/unread state, message date/time, and message cards.
• Primary actions: Open a message; pull to refresh.
• Supporting actions: Search or filter messages where appropriate; navigate through the floating Inbox, Share, and Profile navigation.
• Components: Message-card list, unread badge, loading skeletons, pull-to-refresh control, search/filter control where used, empty-inbox state.
• States and recovery: Load skeletons while fetching; empty state when no messages exist; refresh failure with retry; private access enforcement prevents access to another recipient’s inbox.

Message Details

• Information and state: Focused view of one message’s text, date/time, read/unread state, and available actions.
• Primary actions: Reply, Share, Delete, Report, Block, and View Details.
• Supporting actions: Return to Home / Inbox.
• Components: Message content, timestamp, sender-identity sticker, action controls, destructive-action confirmation where necessary.
• States and recovery: Mark a message read when opened; report action confirms submission; delete removes the message from the recipient inbox after confirmation; block updates the recipient’s blocked-user state; failures provide retry or cancellation.

Reply

• Information and state: Response/post composition using the received message as the source context.
• Primary actions: Create the response/post.
• Supporting actions: Return to Message Details without posting.
• Components: Received-message reference, response/post composition control, publish action.
• States and recovery: Preserve draft input if creation fails; confirm successful response/post creation; return to the message context.

Sender Details

• Information and state: Permitted sender information for the selected message.
• Primary actions: Review Account information and Technical information.
• Supporting actions: Return to Message Details.
• Components: Split details presentation:
  • Account information: Registered sender username, account ID, profile information, message ID, date, and time when legitimately available.
  • Technical information: Device type, browser/app version, operating system, approximate region when legally permitted, and available timestamps.
  • Anonymous disclosure: “Anonymous — identity not revealed.”
• States and recovery: Display exactly Information unavailable. for unavailable information. Never claim that an anonymous sender’s real identity was discovered. Do not expose private personal information.

Share screen

• Information and state: Recipient’s personal link and encouragement to distribute it.
• Primary actions: Share through Instagram, WhatsApp, Snapchat, Copy link, and the system share sheet.
• Supporting actions: Return to Home / Inbox or Profile.
• Components: Personal-link display, giant share marquee, share-target tile grid, copied-link confirmation.
• States and recovery: Indicate successful copying or external handoff; retain alternate actions if a social target is unavailable.

Profile

• Information and state: Recipient profile picture, username, personal anonymous link, and message count.
• Primary actions: Copy link, Share link, Edit profile, open Settings.
• Supporting actions: Navigate through Inbox, Share, and Profile.
• Components: Profile header, link display, message count, copy/share controls, Edit profile entry, Settings entry.
• States and recovery: Refresh profile state after edits; communicate load or save failure without losing prior valid profile data.

Edit Profile

• Information and state: Editable recipient profile information and profile picture.
• Primary actions: Save profile updates.
• Supporting actions: Cancel and return to Profile.
• Components: Username, profile-picture, and profile-information editing controls.
• States and recovery: Validate username uniqueness and input; preserve entered values on failure; update Profile after successful save.

Settings

• Information and state: Recipient account and application preferences.
• Primary actions: Manage account settings, username, profile picture, password, notifications, privacy, blocked users, report history, delete account, and logout.
• Supporting actions: Return to Profile.
• Components: Grouped settings controls, notification toggle, privacy controls, blocked-users list, report-history list, password controls, delete-account control, logout control.
• States and recovery: Confirm destructive actions; persist changed preferences; permit retry when updates fail; terminate secure session on logout.

Anonymous Message Page

• Information and state: Public recipient page at a unique URL such as /u/rohit, available without sender authentication when anonymous submissions are enabled.
• Primary actions: Enter and send an anonymous message.
• Supporting actions: Review recipient picture, username, and short profile description.
• Components: Profile picture, username, short bio, anonymous message input, character counter, Send button, confirmation choreography.
• States and recovery: Validate input; apply spam protection, rate limiting, CAPTCHA where appropriate, and moderation checks; show sending status; show confirmation animation after successful storage; explain and allow correction/retry when sending fails.

Admin dashboard

• Information and state: Role-restricted moderation workspace.
• Primary actions: View reported messages, remove abusive messages, ban accounts, review reports, manage users, view authorized technical metadata, and manage moderation settings.
• Supporting actions: Review moderation outcomes and continue moderation work.
• Components: Reported-message queue, report-review controls, content-removal action, account-ban action, user-management controls, authorized metadata view, moderation-settings controls.
• States and recovery: Show load, empty, success, error, and retry states; retain administrative information behind administrator authorization; prevent normal-user access.

3. Functional Requirements

FR-01 — Mobile Delivery

As a Recipient (App User), Anonymous Sender, or Administrator / Moderator, I should use anonymous-messaging-inbox on Android and iOS so that the system is available as a real mobile application.

• Provenance: explicit.
• The application shall use React Native + Expo where feasible.
• The interface shall respond to different phone screen sizes.
• The application shall provide smooth animations and transitions.
• The application shall not be a mockup, prototype, or non-functional demonstration.

FR-02 — Recipient Authentication

As a Recipient (App User), I should sign up, log in, log out, and recover a forgotten password so that my inbox and profile remain bound to a secure session.

• Provenance: explicit; first-use and returning access mechanics are required_inference.
• The system shall support email/password signup, login, logout, forgot-password recovery, and secure sessions.
• Signup and login shall occur on Login before protected recipient destinations are available.
• Logout shall terminate the recipient session and return the recipient to an anonymous access boundary.
• Authentication failures shall provide a recoverable error state without exposing account-sensitive information.

FR-03 — Onboarding and Profile Creation

As a Recipient (App User), I should complete Welcome screen, Create username, Profile setup, Profile picture, Notification permission, Generate personal message link, and Share link steps so that I can create and distribute a functioning anonymous-message profile.

• Provenance: explicit.
• Onboarding shall include a Continue button where progression is required.
• The system shall validate username availability and profile input.
• The recipient shall be able to establish a profile picture and short profile description.
• The system shall request notification permission during onboarding.
• The system shall generate the recipient’s unique personal message link before sharing.
• The recipient shall be able to share the generated link or continue to the inbox.

FR-04 — Personal Link Generation and Sharing

As a Recipient (App User), I should receive and share my personal anonymous-message link so that others can send me anonymous messages.

• Provenance: explicit.
• The system shall automatically generate a unique link such as https://myapp.com/u/username.
• Sharing shall support Instagram, WhatsApp, Snapchat, Copy link, and the device system share sheet.
• The Share screen and Share link onboarding page shall encourage link sharing.
• If an external social application is unavailable, the system shall keep other share options available.

FR-05 — Public Anonymous Message Submission

As an Anonymous Sender, I should open a recipient’s public link and send an anonymous message without creating an account when anonymous submissions are enabled.

• Provenance: explicit; account-free enabled submission is required_inference.
• Anonymous Message Page shall show the recipient profile picture, username, short profile description, anonymous message input, character counter, and Send button.
• The system shall validate the message before submission.
• The system shall store a valid message for the addressed recipient.
• After successful sending, the sender shall see a confirmation screen or animation.
• Failure caused by validation, spam controls, rate limits, CAPTCHA where appropriate, moderation, or unavailable service shall be communicated with a correction or retry path.

FR-06 — Private Inbox

As a Recipient (App User), I should view my received anonymous messages in a private card-based inbox so that I can manage incoming messages.

• Provenance: explicit.
• Every inbox message card shall show message text, date/time, and read/unread status.
• The inbox shall provide pull to refresh, loading skeletons, an empty inbox state, and a notification badge.
• The inbox shall support search/filter messages if appropriate to the delivered interface.
• Opening a message shall make its read state observable.
• Database security rules and authorization shall prevent one recipient from accessing another recipient’s private inbox.

FR-07 — Message Actions

As a Recipient (App User), I should reply to, share, delete, report, block, and view details for a received message so that I can respond to and control my inbox.

• Provenance: explicit.
• Each received message shall provide Reply, Share, Delete, Report, Block, and Sender Details/View Details actions.
• Reply shall allow the recipient to create a response/post using the received message.
• Delete shall remove the message from the recipient’s inbox after confirmation.
• Report shall create a moderation report for the message.
• Block shall update the recipient’s blocked-user state where a blockable sender relationship exists.
• Share shall hand off the selected content using the available sharing mechanism.
• Action errors shall not falsely report success and shall permit retry or cancellation.

FR-08 — Sender Details and Privacy

As a Recipient (App User), I should view only authorized sender details so that I can understand a message without falsely exposing anonymous identity.

• Provenance: explicit.
• Sender Details shall clearly distinguish Account information from Technical information.
• For registered senders, Account information may include username, account ID, profile information, message ID, date, and time when legitimately available and permitted.
• Technical information may include device type, browser/app version, operating system, timestamps, and approximate region only when legitimately collected and legally permitted.
• The system shall display Information unavailable. when requested information is unavailable.
• The system shall not claim that an anonymous sender’s real identity has been discovered.
• The system shall not expose private personal information merely because someone sent a message.

FR-09 — Profile Management

As a Recipient (App User), I should view and edit my profile so that my public message page and personal link remain accurate.

• Provenance: explicit; focused editing destination is required_inference.
• Profile shall display profile picture, username, personal anonymous link, copy-link action, share-link action, message count, and Settings entry.
• Edit Profile shall support updating profile information and profile picture.
• Username changes shall preserve uniqueness requirements and update link-related state only after a valid save.
• The system shall confirm successful profile updates and preserve entered values when a save fails.

FR-10 — Settings and Account Controls

As a Recipient (App User), I should manage account settings, username, profile picture, password, notifications, privacy, blocked users, report history, account deletion, and logout so that I can control my account and experience.

• Provenance: explicit.
• Settings shall provide access to every named setting area.
• Recipients shall be able to disable notifications.
• Blocked users and report history shall be visible to the relevant recipient.
• Password controls shall use secure authentication mechanisms.
• Delete account shall require a confirmation step and complete only when the backend confirms it.
• Logout shall be functional and end the secure session.

FR-11 — Push Notifications

As a Recipient (App User), I should receive a push notification when somebody sends me a message so that I know to check my inbox.

• Provenance: explicit.
• On successful message delivery, the system shall send the recipient the notification text: Someone sent you an anonymous message 👀.
• Notification delivery shall honor the recipient’s notification permission and notification settings.
• The recipient shall be able to disable notifications.
• Notification failures shall be logged and recoverable by backend delivery processing without exposing service secrets to the mobile application.

FR-12 — Data Model and Storage

As the system, I should securely store users, messages, sender metadata, blocked users, reports, and notifications so that accepted product workflows have durable state.

• Provenance: explicit.
• The implementation shall use Supabase/PostgreSQL or Firebase.
• Users shall support: id, username, email, password/auth reference, profile picture, bio, and created_at.
• Messages shall support: id, recipient_id, sender_id if available, message_text, anonymous_status, created_at, read_status, and reported_status.
• Sender metadata shall support: message_id, device information, app/browser information, approximate location where legitimately available, and timestamps.
• The implementation shall store blocked users, reports, and notifications.
• Proper database security rules shall prevent unauthorized inbox and administrative-data access.

FR-13 — Abuse Prevention and Security

As a Recipient (App User), Anonymous Sender, and Administrator / Moderator, I should use a protected messaging service so that abuse and unauthorized access are reduced.

• Provenance: explicit.
• The system shall implement rate limiting, spam protection, CAPTCHA where appropriate, input validation, XSS protection, SQL injection protection, authentication security, authorization, secure database rules, abuse reporting, blocking, and message moderation.
• Server secrets and database credentials shall never be exposed in the mobile application.
• Public message submission shall be protected without requiring anonymous senders to create accounts when anonymous submissions are enabled.
• Authorization shall restrict recipients to their own private data and administrators to authorized administration functions.

FR-14 — Administration and Moderation

As an Administrator / Moderator, I should use a separate protected dashboard to moderate reported content and manage abuse so that harmful content and accounts can be handled.

• Provenance: explicit; administrator identity establishment is required_inference.
• The dashboard shall be separate from normal recipient destinations.
• Authorized administrators shall be able to view reported messages, remove abusive messages, ban accounts, review reports, manage users, view legitimately authorized technical metadata, and manage moderation settings.
• Normal users shall not access administrative information or dashboard functions.
• Administrative actions shall expose their observable moderation outcome and recover from failed requests without claiming completion prematurely.

FR-15 — Production Readiness and Verification

As a project owner, I should receive a tested production-ready application and Android build instructions so that the application can be delivered reliably.

• Provenance: explicit.
• Major user flows shall be tested.
• Navigation, authentication, database, message delivery, and notification problems shall be fixed before delivery.
• Testing shall verify private inbox isolation and anonymous messaging.
• Testing shall verify Android functionality.
• The delivered project shall include instructions for generating an APK/AAB.

4. User Personas

Recipient (App User)

Product context: The recipient creates an authenticated profile, receives anonymous messages through a personal public link, and manages their private inbox.

Primary goal: Establish a shareable anonymous-message link and reliably receive and manage messages that arrive through it.

Distinct responsibilities:

• Sign up, log in, recover a password, and log out through secure sessions.
• Complete onboarding by creating a username, profile information, profile picture, notification preference, and personal link.
• Share the personal link through supported social destinations or the system share sheet.
• Review received messages, distinguish unread from read messages, refresh the inbox, and search/filter where appropriate.
• Reply to a message through a response/post, share a message, delete it, report it, block it, and inspect permitted sender details.
• Edit profile information and manage account, privacy, notification, blocked-user, report-history, password, account-deletion, and logout settings.

Relevant decisions and inputs: Email/password credentials, username, profile description, profile picture, notification permission, sharing target, message action selection, settings preferences, reporting and blocking decisions.

Interaction with other participants: The recipient’s link is used by Anonymous Senders. Recipient reports and moderation-relevant actions are available to the Administrator / Moderator through the protected moderation workflow.

Observable success: The recipient has a functioning unique personal link, can share it, receives messages in an inbox that only they can access, and can safely manage received content.

Provenance: required_inference from accepted account, profile, inbox, sharing, and message-management requirements.

Anonymous Sender

Product context: The anonymous sender opens a recipient’s public URL and submits a message without needing an account when anonymous submissions are enabled.

Primary goal: Send an anonymous message to the recipient through the public link.

Distinct responsibilities:

• Open the recipient’s public Anonymous Message Page.
• Review the recipient’s picture, username, and short profile description.
• Enter a message while observing the character counter.
• Submit the message through the Send button.
• Respond to validation, CAPTCHA where appropriate, rate limit, spam-protection, or moderation failure conditions.
• Observe successful send confirmation.

Relevant decisions and inputs: Anonymous message text and any required anti-abuse interaction.

Interaction with other participants: The sender’s successful message creates a new message for the Recipient (App User). The sender is not promised identification disclosure. Any technical data shown later is limited to legitimately collected and authorized information.

Observable success: The message is accepted, stored for the intended recipient, and the sender sees a confirmation animation without account creation or identity exposure.

Provenance: required_inference from accepted public anonymous submission requirements.

Administrator / Moderator

Product context: The administrator or moderator operates a separate role-restricted dashboard for content safety, reports, users, and moderation settings.

Primary goal: Review and resolve abuse while keeping moderation and technical information inaccessible to normal users.

Distinct responsibilities:

• Authenticate through the separate Admin Login surface.
• Review reports and reported messages.
• Remove abusive messages.
• Ban accounts.
• Manage users.
• View technical metadata only where legitimate and authorized.
• Manage moderation settings.

Relevant decisions and inputs: Report-review decision, content-removal decision, account-ban decision, user-management decision, and moderation-setting updates.

Interaction with other participants: The administrator acts on reports originating from recipient message-management workflows and on content produced through anonymous message submission.

Observable success: Reported content is reviewed and handled, administrative actions are confirmed, and normal users remain unable to access administrative information.

Provenance: explicit.

5. Core User Flows

Recipient Account Signup, Login, and Recovery

1. The Recipient (App User) starts at Landing or is directed to Login.
2. On Login, the recipient chooses signup, login, or forgot-password recovery.
3. For signup, the recipient enters email and password; the system validates the input and establishes a secure authenticated session on success.
4. For login, the recipient enters valid credentials; the system verifies them and resumes the recipient’s secure session.
5. For forgot password, the recipient requests recovery through the supported authentication service and follows the recovery process.
6. Authentication failure is shown as a recoverable error; the recipient can correct inputs, retry, or use password recovery.
7. A newly authenticated recipient continues to Welcome screen. A returning recipient with completed onboarding continues to Home / Inbox.

Recipient Onboarding and Personal Link Setup

1. The authenticated recipient opens Welcome screen and selects Continue.
2. On Create username, the recipient enters a username; the system validates format and uniqueness.
3. If unavailable or invalid, the system explains the issue and preserves the input for correction.
4. On Profile setup, the recipient provides profile information including a short profile description and selects Continue.
5. On Profile picture, the recipient selects or uploads a profile picture and continues after successful handling.
6. On Notification permission, the recipient requests device notification permission or continues after declining it.
7. On Generate personal message link, the system generates and displays a unique URL such as https://myapp.com/u/username.
8. If generation fails, the system does not falsely complete onboarding and allows retry.
9. On Share link, the recipient shares through Instagram, WhatsApp, Snapchat, Copy link, or the system share sheet, or continues to Home / Inbox.

Recipient Inbox Review and Message Action

1. The authenticated recipient opens Home / Inbox.
2. The inbox loads message cards with text, date/time, and read/unread state; skeletons appear while data loads.
3. If no messages exist, the recipient sees the empty inbox state