System Requirements Document

1. Introduction

This System Requirements Document (SRD) defines ChatLink, a modern, long-distance real-time chat web application that lets users communicate in real time using a unique username as their identity. ChatLink evolves an existing minimal Socket.IO/Express chat prototype (a public chat room keyed only by a nickname) into a full account-based social messaging product with friend relationships, real-time private messaging, presence, notifications, profiles, privacy controls, and an administrative dashboard.

The document captures the functional capabilities, personas, flows, visual direction, non-functional requirements, technology stack, and constraints required to deliver ChatLink. It is derived strictly from the uploaded source material (an HTML client, a Node.js server.js, and a package.json for a simple chat application) and the explicit project requirements stated by the project owner.

2. System Overview

ChatLink is a browser-accessed chat platform where each registered user is identified by a unique username and authenticated with a username + password credential pair. Users discover each other by username, form mutual friendships through friend requests, and then exchange real-time messages that render without a page refresh. Message history, friendships, profiles, blocks, and privacy settings are persisted in a database, and profile images are stored in object storage.

The platform is backed by managed cloud services:

• Firebase Auth for authentication.
• Firestore as the database and the real-time chat/message transport.
• Firebase Storage for profile photos.

Security is enforced with hardened password handling, database security rules, per-user data access scoping, and HTTPS for all traffic. A separate admin dashboard allows administrators to manage users and review reports. The user interface is modern, clean, fast, and professional, built around a white, light-blue, and blue palette, and is fully responsive across PC, laptop, tablet, and mobile.

The existing prototype contributes the baseline real-time delivery behavior: a static Express server, a Socket.IO channel that broadcasts a sent message to connected clients, a message input with a send button, and auto-scroll of the message list. Messages with an empty body are ignored, and messages from a user without a name are attributed to "Anonim" ("Anonymous").

3. Functional Requirements

3.1 Authentication and Account

• FR-1. As a new user, I want to register an account using a username and password, so that I can establish a persistent identity on ChatLink.
• FR-2. As a registered user, I want to log in using my username and password, so that I can access my chats and data.
• FR-3. As a registering user, I want my username to be unique across the platform, so that no two users can be confused or impersonated.
• FR-4. As a security-conscious user, I want my password stored securely with strong password handling, so that my credentials are not exposed.
• FR-5. As a user, I want the system to enforce database security rules that limit me to data I am entitled to access, so that other users can never read or modify my private data.
• FR-6. As a user, I want all traffic served over HTTPS, so that my credentials and messages are encrypted in transit.

3.2 User Discovery and Friend Requests

• FR-7. As a user, I want to search for other users by username, so that I can find people to connect with.
• FR-8. As a user, I want to send a friend request to another user, so that I can initiate a connection.
• FR-9. As a user, I want to receive and view incoming friend requests, so that I can decide how to respond.
• FR-10. As a user, I want to accept a friend request, so that we become mutually connected and can chat.
• FR-11. As a user, I want to reject a friend request, so that I can decline connections I do not want.
• FR-12. As a user, I want a friend list showing my accepted connections, so that I can quickly open a conversation with any friend.

3.3 Real-Time Messaging

• FR-13. As a user, I want to send messages to a friend, so that we can communicate directly.
• FR-14. As a user, I want to receive incoming messages in real time without refreshing the page, so that conversations feel immediate.
• FR-15. As a user, I want my chat history persisted in the database, so that I can review previous conversations at any time.
• FR-16. As a user, I want the message list to automatically scroll to the newest message, so that the latest activity is always visible (baseline behavior carried from the existing prototype).
• FR-17. As a user, I want empty messages to be ignored on send, so that the conversation is not polluted by blank entries (baseline behavior carried from the existing prototype).

3.4 Presence, Notifications, and Message Feedback

• FR-18. As a user, I want to see whether a friend is online or offline, so that I know if they are currently available.
• FR-19. As a user, I want to see a friend's last active time, so that I can gauge when they were last around.
• FR-20. As a user, I want notifications for new messages, so that I do not miss incoming conversations.
• FR-21. As a user, I want a "typing" indicator, so that I know when a friend is composing a reply.
• FR-22. As a user, I want each message to show whether it was sent, delivered, and read, so that I have confirmation of delivery status.

3.5 Profile and Privacy

• FR-23. As a user, I want a profile with a profile photo, display name, and bio, so that I can present myself to others.
• FR-24. As a user, I want to block another user, so that I can stop unwanted contact.
• FR-25. As a user, I want to configure privacy settings, so that I control who can see and reach me.

3.6 Responsiveness and Access

• FR-26. As a user, I want the interface to be responsive on PC, laptop, tablet, and mobile, so that the experience is consistent across every device I use.

3.7 Administration

• FR-27. As an administrator, I want an admin dashboard, so that I have a central place to operate the platform.
• FR-28. As an administrator, I want to manage users from the dashboard, so that I can act on accounts as needed.
• FR-29. As an administrator, I want to manage reports from the dashboard, so that I can review and resolve reported issues.

3.8 Legacy / Baseline Chat Capability (from the existing prototype)

• FR-30. As a visitor, I want to join a public chat room using only a nickname, so that I can chat without creating a full account (existing prototype behavior).
• FR-31. As a participant in the public chat room, I want my message broadcast to all connected participants in real time, so that everyone in the room sees it immediately.
• FR-32. As a public-room participant without a nickname entered, I want to be attributed as "Anonymous" ("Anonim"), so that I can still send a message (existing prototype behavior).

4. User Personas

• ChatLink User (Registered Member) — Registers and logs in with a unique username and password. Searches usernames, sends/accepts/rejects friend requests, maintains a friend list, chats in real time, reviews chat history, sees online/offline and last-active status, receives notifications, sees typing indicators and message status, maintains a profile (photo, name, bio), blocks users, and configures privacy settings.
• Administrator — Operates the admin dashboard to manage users and manage reports.
• Guest / Public-Room Visitor — Enters a public chat room with only a nickname and participates in the broadcast conversation (baseline prototype audience).
• System Actors (non-personas) — Firebase Auth (authentication), Firestore (database and real-time chat), Firebase Storage (profile photos), and the Express/Socket.IO server process (baseline real-time delivery and static asset hosting).

5. Core User Flows

5.1 Registered User — Primary End-to-End Flow (Owner-Stated Alur Utama)

1. Register — user creates an account with a unique username and a password.
2. Login — user authenticates with username + password (Firebase Auth).
3. Cari Username / Search Username — user searches for a person by username.
4. Tambah Teman / Add Friend — user sends a friend request.
5. Terima Permintaan / Accept Request — recipient accepts the friend request.
6. Mulai Chat / Start Chat — the two friends open a conversation.
7. Pesan Real-Time / Real-Time Message — messages render on both sides without a page refresh.
8. Notifikasi / Notification — the recipient is notified of the new message.
9. Riwayat Chat / Chat History — the conversation is persisted and retrievable from the database.

5.2 Registered User — Friend Request Handling

1. User searches for a username and selects the result.
2. User sends a friend request.
3. Target user opens incoming requests.
4. Target user either accepts (both become friends, chat unlocked) or rejects (request declined, no connection created).

5.3 Registered User — Active Conversation

1. User selects a friend from the friend list.
2. Conversation view loads persisted chat history.
3. Presence (online/offline, last active) is shown for the friend.
4. User types; the friend sees the typing indicator.
5. User sends a message; the friend receives it in real time and a notification is raised.
6. Message status progresses through sent → delivered → read.

5.4 Registered User — Profile, Blocking, and Privacy

1. User opens their profile and sets a profile photo (stored in Firebase Storage), display name, and bio.
2. User adjusts privacy settings to control visibility and reachability.
3. User blocks another user; that user's contact and content are suppressed.

5.5 Administrator — User and Report Management

1. Administrator accesses the admin dashboard.
2. Administrator reviews and manages user accounts.
3. Administrator reviews incoming reports and manages their resolution.

5.6 Guest — Public Room (Baseline)

1. Visitor opens the public chat page and enters a nickname (defaults to "Anonim" if left empty).
2. Visitor types a message and presses Kirim (Send); empty messages are ignored.
3. Message is broadcast to all connected participants and appended to every message list, which auto-scrolls to the newest message.

6. Visuals, Colors, and Theme

• Palette (owner-specified): white, light blue, and blue. The baseline prototype uses #f0f2f5 as the page background, white (#ffffff) surfaces, and #007bff as the primary action color; these are carried forward and formalized.
• Base/background: white and near-white neutral surfaces.
• Primary accent: blue for primary actions (e.g., the Send control).
• Secondary accent: light blue for highlights, hover states, and status surfaces.
• Typography: clean sans-serif, consistent with the baseline prototype (font-family: sans-serif).
• Surfaces: rounded corners (the prototype uses an 8px radius on the chat container and 4px on inputs/buttons), light borders, and generous padding for a clean, professional feel.
• Overall character: modern, bersih (clean), cepat (fast), and profesional, as specified by the owner.

6.1 Design Language — Layered Translucency (Creative Direction)

ChatLink's visual system is layered translucency: frosted glass panels floating over a cool paper-white ground, with luminous edges, generous radii, and gentle float. The requested white / light-blue / blue palette becomes a layered glass system rather than a flat dashboard. The generic indigo/blue-on-white SaaS template is forbidden for this project.

Light-mode tokens

• Background (ground): #F2F7FC — a cool paper-white, not stark white, so frosted panels have something to sit on.
• Surface: #FFFFFF at 70–85% opacity with a 1px rgba(27,111,184,0.14) border and a soft 24px blur (the signature material). Text-heavy surfaces (message bodies) sit on white at 85% opacity minimum for contrast.
• Text (ink): #0F2740 — near-navy ink for body and headings.
• Primary: #1B6FB8 — deep sea-blue for own-message bubbles, primary buttons, and the active nav rail; deliberately darker and more saturated than a default SaaS blue so it reads as ink, not bootstrap.
• Accent: #7DD3FC — the light blue from the brief, used for presence dots, typing-indicator pulse, unread badges, and the luminous top edge of frosted panels.
• Muted: #5B7A94 — timestamps, last-active lines, and secondary labels.
• Proportion: 60% ground and white glass, 25% primary blue, 10% accent light blue, 5% ink and muted.
• Gradients: no gradients behind text; the only permitted gradient is a slow-drifting 3-stop wash (accent → primary → transparent) inside the hero's decorative panel.

Typography

• Headings: Plus Jakarta Sans at 600–700 weight, tracking -0.02em, sentence case for product copy and small-caps only for micro-labels such as 'ONLINE' and 'TYPING'.
• Body: Manrope at 400/500, 15–16px with 1.6 line-height for messages, 13px for metadata.
• Scale: 1.25 modular — 56/44/28/20/16/13. Hero wordmark clamp(40px, 8vw, 96px); page titles 28px; panel titles 20px; message body 16px; metadata and timestamps 13px.
• Forbidden typefaces: Inter, Roboto, Poppins, and system-ui are not used for headings or body; Plus Jakarta Sans and Manrope only.

Shape language

• Frosted glass panels with 20–24px radii and 1px light borders.
• Pill buttons and pill message bubbles: own messages right-aligned, 18px radius with a flattened bottom-right corner; incoming messages left-aligned, mirrored with a flattened bottom-left corner.
• Presence dots and unread badges are perfect circles.
• The app shell is a floating three-column frame — nav rail, conversation list, chat thread — each panel separated by 12px of ground so the layers read as separate glass sheets rather than one flat dashboard.

Layout

• Desktop (1280px): a floating app shell inset 24px from the viewport edges, containing a 72px icon nav rail, a 320px conversation list panel, and a flexible chat thread panel, all as separate frosted sheets.
• Tablet (768px): nav rail collapses to a bottom bar; conversation list and thread stack with a slide-over thread.
• Mobile (375px): single-column; thread takes the full viewport, conversation list is a full-screen sheet, nav is a bottom tab bar.
• The marketing hero above the shell is a full-bleed composition: a large left-aligned headline block, and a right-side stack of three overlapping frosted chat panels at slight rotations (2°, -1.5°, 1°) that drift slowly. No centred headline + subtext + button arrangement.

Imagery

• No stock photography and no clip art. The imagery is the interface itself rendered as glass: frosted chat panels, message bubbles, presence dots, and typing indicators as the hero's visual subject.
• Avatars are generated initial-based circles on a rotating palette of accent tints; no photography of people.
• Empty states use simple geometric glass primitives — a frosted speech-bubble shape, a frosted magnifier — never illustrated characters.

Signature moves

• The app shell itself is three separate frosted glass sheets floating on a paper-white ground with 12px gaps — the nav rail, conversation list, and chat thread read as physical layers, not one flat dashboard.
• The hero's dominant element is a stack of three rotated frosted chat panels that slowly float, showing real message fragments, typing dots, and read ticks — the product's own UI is the hero image.
• Own-message bubbles are solid #1B6FB8 with a flattened bottom-right corner; incoming bubbles are white glass with a 1px accent border and a flattened bottom-left corner, so the conversation has a visible directional weave.
• The typing indicator is three #7DD3FC dots pulsing in a 1.2s stagger inside a frosted pill that fades in at the bottom of the thread, paired with a 'TYPING' micro-label in Plus Jakarta Sans small-caps.
• Presence is a breathing #7DD3FC dot with a soft outer glow that sits half-overlapping the avatar circle's lower-right edge, so online status reads as a luminous object attached to the person rather than a flat status chip.

Avoid

• No flat white dashboard with a blue sidebar — the shell must read as floating frosted layers on a cool paper ground.
• No gradient-blob hero and no centred headline + subtext + blue button arrangement.
• No default #2563EB or #4F46E5 SaaS blue; primary is the deeper #1B6FB8 and accent is the pale #7DD3FC.
• No glassmorphism used on text-heavy surfaces without a solid backing.
• No grid of identical hover-lift cards; conversation rows lift 2px and brighten their border, they do not scale or shadow-pop.
• No bouncy spring easing or cartoon illustration; motion is float, fade, and pulse.

Readable text and controls

• Readable text and controls stay whole at every viewport: headlines, wordmarks, labels, numbers, and cards' text and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element covers any part of them.
• Imagery, decoration, and motion follow the creative direction: a photograph, artwork, shape, texture, or animation may be cropped, bled off an edge, rotated, overlapped, or cut exactly as the direction asks, as long as it covers no readable text or control.
• Moving and scrollable content (marquees, tickers, carousels, horizontally scrollable rows) may cross the viewport or container edge by design: judge it by whether it actually moves or scrolls and whether every item becomes fully readable as it passes, never by the item cut at the edge in a still frame. With prefers-reduced-motion it stops and shows whole items: they wrap into rows, or sit in a horizontally scrollable row (overflow-x: auto) whose further items are reached by scrolling.
• Where a direction, requirement, brief, or finding asks readable text or a control to be cropped, clipped, covered, or run off an edge, keep it whole and carry the gesture with imagery or decoration instead; for readable text and controls this rule takes precedence.

7. Signature Design Concept

The signature concept is a single, focused conversation surface — the message stream is the hero element, occupying the primary visual weight of the screen, framed by a disciplined white-and-blue chrome rather than heavy ornamentation. The design lineage traces directly to the prototype's chat container: a large, bordered, scrollable message panel with a compact input row beneath it, where the input sits left and the blue Send action sits right. All secondary surfaces (search, friend requests, friend list, profile, privacy, admin) adopt the same restrained card language so the product reads as one continuous system rather than a set of bolted-on screens.

That conversation surface is rendered as layered translucency: the app shell is three separate frosted glass sheets — nav rail, conversation list, and chat thread — floating on the #F2F7FC paper-white ground with 12px gaps, so the product reads as physical layers rather than one flat dashboard. The hero's dominant element is a stack of three rotated frosted chat panels that slowly float, showing real message fragments, typing dots, and read ticks — the product's own UI is the hero image.

7.1 Landing Hero Motion Brief

• Motion tempo: expressive (per the creative direction's Motion Tempo: line); hero dimensionality layered_2d; hero drama bold.
• Thesis (input → transformation → outcome): a visitor arrives with no account and no context → the hero shows three real conversation fragments (a message bubble, a typing indicator, a delivery tick) drifting as frosted glass sheets → the visitor understands that ChatLink is live, human, and reachable by username alone.
• Focal subject: the stack of three overlapping frosted-white chat panels at 2°, -1.5°, and 1° rotation, each showing a real conversation fragment, stacked with 40px vertical offsets.
• Visible layers: full-bleed #F2F7FC ground; a soft accent wash drifting behind the right third; the three rotated frosted chat panels; the left-aligned headline block (oversized 'ChatLink' wordmark at clamp(40px, 8vw, 96px) in Plus Jakarta Sans 700, ink #0F2740, with a single line beneath it at 20px Manrope — 'Talk to anyone, by username alone.' — and a pill primary button #1B6FB8 with a 1px accent top edge).
• Loop: a staged opening followed by a story loop at expressive tempo — the panels settle into place, then float with a 6s ease-in-out ±4px translateY loop, staggered 400ms apart; the typing indicator pulses three #7DD3FC dots in a 1.2s stagger; presence dots breathe with a 2s opacity loop; new message fragments slide up 8px and fade in over 180ms.
• Composed first frame: the three panels already visible at their rotations with a message bubble, typing dots, and a read tick legible, the wordmark and subline fully rendered, and the primary button in its resting state — no blank or mid-animation first paint.
• Optional interaction: hovering a conversation row lifts it 2px and brightens its border to accent; the hero panels may respond to pointer proximity with a slight parallax drift.
• Responsive behavior: at 375px the panels collapse into a single upright panel below the headline, and the headline wraps to three lines without clipping; at 768px the stack reduces to two panels; at 1280px the full three-panel stack is shown.
• Reduced-motion fallback: all motion stops under prefers-reduced-motion, and the hero panel stack becomes a static column.
• Implementation: a product-specific 2D DOM/SVG/CSS composition in the direction's motion vocabulary, implemented with Motion for React (motion/react) or GSAP. No Canvas/R3F/Drei is required for this hero.

8. Interaction Model & Motion Direction

• Instant feedback loop: sending a message clears the composer immediately, and the message is reflected in the stream without a page refresh.
• Live streaming list: new messages append to the bottom of the conversation and the list auto-scrolls to keep the newest entry in view.
• Composer behavior: the send action is a single primary blue control; blank or whitespace-only messages are rejected silently.
• Availability cues: presence (online/offline and last active) and the typing indicator are surfaced as lightweight, low-distraction state changes.
• Delivery progression: message status (sent → delivered → read) advances in place rather than through disruptive modal dialogs.
• Notification direction: new messages raise unobtrusive notifications rather than blocking overlays.
• Responsive motion budget: transitions and state changes remain fast and understated to preserve the "cepat" (fast) quality across PC, laptop, tablet, and mobile.

8.1 Motion Vocabulary (Layered Translucency)

• Panel float: frosted panels float with a 6s ease-in-out ±4px translateY loop, staggered 400ms apart.
• Typing indicator: three accent dots with a 1.2s staggered pulse inside a frosted pill that fades in at the bottom of the thread, paired with a 'TYPING' micro-label in Plus Jakarta Sans small-caps.
• Message arrival: new messages slide up 8px and fade in over 180ms.
• Presence: presence dots breathe with a 2s opacity loop; the dot sits half-overlapping the avatar circle's lower-right edge with a soft outer glow.
• Row hover: hovering a conversation row lifts it 2px and brightens its border to accent — no scale or shadow-pop.
• Easing: motion is float, fade, and pulse; no bouncy spring easing.
• Reduced motion: all motion stops under prefers-reduced-motion, and the hero panel stack becomes a static column.

9. Non-Functional Requirements

• NFR-1. Security of credentials: passwords must be securely handled; plaintext or weakly protected credential storage is not acceptable.
• NFR-2. Database security rules: the database must be governed by security rules that prevent unauthorized reads and writes.
• NFR-3. Per-user data scoping: every user may access only the data to which they are entitled.
• NFR-4. Transport security: the entire system must operate over HTTPS.
• NFR-5. Real-time responsiveness: message delivery and receipt must occur without a page refresh.
• NFR-6. Persistence: chat history and account/relationship data must be durably stored in the database.
• NFR-7. Media storage: profile photos must be stored in Firebase Storage and served securely.
• NFR-8. Device responsiveness: the UI must adapt across PC, laptop, tablet, and mobile form factors.
• NFR-9. Performance and feel: the product must feel fast, clean, and professional in routine use.
• NFR-10. Portability of deployment: the Node.js server process must bind to the environment-provided port (process.env.PORT, falling back to 3000) so it can run on a cloud host.

10. Tech Stack

Frontend

• HTML, CSS, and vanilla JavaScript browser client (baseline delivery shape: a static index.html page with inline styling and script, plus the Socket.IO client script).

Backend / Baseline Runtime

• Node.js with Express (^4.19.2) serving static assets (baseline server: app.use(express.static('public'))).
• Socket.IO (^4.7.5) for the baseline real-time message channel (kirim-pesan received, pesan-baru broadcast to all connections).
• package.json application name chat-sederhana, version 1.0.0, start script node server.js.
• Runtime port resolution via process.env.PORT with fallback 3000.

Cloud Services (Owner-Specified)

• Firebase Auth — authentication for login.
• Firestore — database and real-time chat transport.
• Firebase Storage — profile photo storage.

Security

• Database security rules; per-user data access scoping; HTTPS for all traffic.

Deployment

• Cloud hosting with HTTPS; the baseline server is structured for platforms such as Render via environment-provided port assignment.

11. Assumptions and Constraints

• Project name: the project is named chatlink-chat.
• Identity model: a user's public identity is their unique username; uniqueness must be enforced at registration.
• Progressed scope: the uploaded prototype (nickname-only public room) is the baseline; the owner's requirements extend it to account-based, friend-scoped private messaging with Firebase services.
• Conflict resolution: where the prototype's open public room and the owner's account-gated features differ, the owner's stated requirements govern; prototype behaviors that do not conflict (auto-scroll, blank-message rejection, anonymous fallback nickname, real-time broadcast) are preserved.
• Service dependency: authentication, real-time chat, persistence, and media storage depend on Firebase Auth, Firestore, and Firebase Storage being provisioned and secured.
• Feature gating by friendship: real-time private chat is only meaningful between accepted friends.
• Administrative access: the admin dashboard is an operational surface for managing users and reports; it is not a general user surface.
• Compliance: HTTPS enforcement and database security rules are mandatory, not optional.
• Terminology: the source material uses Indonesian labels (e.g., Ruang Chat Publik, Kirim, Anonim); the product must remain coherent for that user base.

12. Page Content and Component Coverage

This section defines the presentation contract for each page: its purpose, the information it presents, the actions it offers, the domain and feedback states it must render, and the components that own each visual responsibility. Independent visual responsibilities are given top-level section ownership; tightly coupled visual regions are named nested subcomponents under their one mutable-state owner. This contract adds no personas, pages, routes, behaviors, integrations, or adjacent modules beyond those already defined in this SRD.

12.1 Landing

• Purpose: anonymous first impression explaining ChatLink, its audience, and real-time communication before identity establishment or protected work.
• Information set: the 'ChatLink' wordmark, the subline 'Talk to anyone, by username alone.', a short explanation of username-based real-time chat, and the primary entry actions.
• Actions: go to Sign Up; go to Login; open the Public Chat room.
• Domain states: anonymous visitor (no session).
• Feedback states: none required beyond link/button hover and focus.
• Components:
  • Landing Hero (owner of the hero's mutable motion state) — nested subcomponents: Hero Headline Block (wordmark, subline, primary pill button), Hero Panel Stack (three rotated frosted chat panels with message bubble, typing indicator, and delivery tick fragments), Hero Ground Wash (drifting accent wash behind the right third).
  • Landing Value Section — short feature summary of username discovery, friend requests, and real-time messaging.
  • Landing Entry Actions — Sign Up, Login, and Public Chat entry points.

12.2 Sign Up

• Purpose: self-service enrollment for a user who independently registers a persistent username and password account.
• Information set: username field, password field, password confirmation, uniqueness guidance, and the credential/security notice.
• Actions: submit registration; navigate to Login.
• Domain states: idle, submitting, username already taken, invalid input, registration failure.
• Feedback states: inline field validation, uniqueness error, submission progress, success confirmation.
• Components:
  • Sign Up Form (owner of form mutable state) — nested subcomponents: Username Field, Password Field, Password Confirmation Field, Submit Control.
  • Sign Up Feedback Region — validation, uniqueness, and submission messages.

12.3 Login

• Purpose: shared returning-verification surface for registered members and administrators using username and password.
• Information set: username field, password field, and the credential/security notice.
• Actions: submit login; navigate to Sign Up.
• Domain states: idle, submitting, invalid credentials, account not found, login failure.
• Feedback states: inline validation, authentication error, submission progress.
• Components:
  • Login Form (owner of form mutable state) — nested subcomponents: Username Field, Password Field, Submit Control.
  • Login Feedback Region — validation and authentication messages.

12.4 Public Chat

• Purpose: public room for nickname-based participation, anonymous fallback attribution, broadcast delivery, and auto-scrolling messages.
• Information set: the public room message list, the nickname field, the message composer, and the 'Kirim' send control.
• Actions: enter a nickname; type and send a message via Kirim; read the broadcast stream.
• Domain states: no nickname entered (attribution falls back to 'Anonim'), nickname entered, empty/whitespace-only message rejected silently, connected/disconnected broadcast channel.
• Feedback states: message appended to every participant's list, auto-scroll to the newest message, silent rejection of blank messages.
• Components:
  • Public Room Panel (owner of the room's mutable message state) — nested subcomponents: Nickname Field, Public Message List (auto-scrolling), Public Composer (input left, blue Kirim action right).

12.5 User Search

• Purpose: username discovery and friend-request initiation workspace for registered members.
• Information set: username search field, result rows (username, display name, avatar, relationship state), and the add-friend action per result.
• Actions: search by username; send a friend request; open a result's profile summary.
• Domain states: idle, searching, no results, results found, already friends, request already pending, blocked relationship.
• Feedback states: loading indicator, empty-result message, request-sent confirmation, error message.
• Components:
  • Search Workspace (owner of search query and result state) — nested subcomponents: Username Search Field, Search Result List, Result Row (avatar, username, display name, relationship badge, add-friend control).

12.6 Friend Requests

• Purpose: incoming request review with accept and reject decisions.
• Information set: incoming request rows (requester avatar, username, display name, request time) and the accept/reject controls.
• Actions: accept a request; reject a request.
• Domain states: no incoming requests, requests pending, request accepted (both become friends, chat unlocked), request rejected (request declined, no connection created).
• Feedback states: empty state, action-in-progress, accept/reject confirmation, error message.
• Components:
  • Incoming Requests Panel (owner of request list mutable state) — nested subcomponents: Request List, Request Row (requester identity, accept control, reject control).

12.7 Friends

• Purpose: revisitable overview of accepted connections and conversation entry points.
• Information set: friend rows (avatar, display name, username, presence dot, last-active line, unread badge) and the conversation entry point.
• Actions: open a conversation with a friend; filter or scan the friend list.
• Domain states: no friends yet, friends present, friend online, friend offline, unread messages present.
• Feedback states: empty state, row hover lift, unread badge count.
• Components:
  • Friend List Panel (owner of friend list mutable state) — nested subcomponents: Friend Row (avatar with presence dot, display name, username, last-active line, unread badge), Friend List Empty State (frosted speech-bubble primitive).

12.8 Chat

• Purpose: focused friend conversation surface with persisted history, real-time messages, presence, typing, notifications, and delivery status.
• Information set: the conversation thread (incoming and own message bubbles, timestamps, delivery ticks), the friend's presence and last-active line, the typing indicator, the message composer, and the send control.
• Actions: load persisted history; send a message; receive messages in real time; observe typing; observe delivery progression.
• Domain states: history loading, history loaded, empty conversation, friend online, friend offline, friend typing, message sent, message delivered, message read, blocked relationship.
• Feedback states: auto-scroll to newest message, silent rejection of blank messages, typing pill fade-in, delivery tick progression in place, unobtrusive new-message notification.
• Components:
  • Conversation Thread (owner of the thread's mutable message state) — nested subcomponents: Message List (auto-scrolling), Incoming Message Bubble (white glass, 1px accent border, flattened bottom-left corner), Own Message Bubble (solid #1B6FB8, flattened bottom-right corner), Delivery Tick, Typing Indicator Pill (three pulsing accent dots plus 'TYPING' micro-label), Thread Empty State.
  • Conversation Header — friend avatar with presence dot, display name, username, online/offline and last-active line.
  • Message Composer — input left, primary blue send action right.

12.9 Notifications

• Purpose: protected destination for new-message notification review and continuation.
• Information set: notification rows (sender avatar, sender identity, message preview, timestamp, read/unread state).
• Actions: open the related conversation; mark notifications as read.
• Domain states: no notifications, unread notifications present, all read.
• Feedback states: empty state, unread badge, read-state transition.
• Components:
  • Notification List Panel (owner of notification list mutable state) — nested subcomponents: Notification Row (sender identity, preview, timestamp, unread badge), Notification Empty State.

12.10 Profile

• Purpose: registered member workspace for profile photo, display name, and bio.
• Information set: profile photo, display name, bio, and the unique username (read-only identity).
• Actions: upload or replace the profile photo (stored in Firebase Storage); edit display name; edit bio; save changes.
• Domain states: profile loaded, editing, saving, upload in progress, upload failure, save success.
• Feedback states: upload progress, validation messages, save confirmation, error message.
• Components:
  • Profile Editor (owner of profile form mutable state) — nested subcomponents: Avatar Uploader (initial-based circle fallback), Display Name Field, Bio Field, Username Display (read-only), Save Control.
  • Profile Feedback Region — upload progress, validation, and save messages.

12.11 Privacy

• Purpose: protected controls for blocking users and configuring visibility and reachability.
• Information set: the blocked-user list (avatar, username, display name, unblock control) and the privacy setting controls governing who can see and reach the user.
• Actions: block a user; unblock a user; adjust privacy settings; save privacy settings.
• Domain states: no blocked users, blocked users present, settings default, settings modified, saving, save success, save failure.
• Feedback states: block/unblock confirmation, save confirmation, error message.
• Components:
  • Blocked Users Panel (owner of blocked-user list mutable state) — nested subcomponents: Blocked User Row (identity, unblock control), Blocked List Empty State.
  • Privacy Settings Panel (owner of privacy settings mutable state) — nested subcomponents: Visibility Controls, Reachability Controls, Save Control.

12.12 Admin Dashboard

• Purpose: administrator operational hub for platform management and report review.
• Information set: platform summary counts (users, pending reports), and entry points to the Users and Reports workspaces.
• Actions: navigate to Users; navigate to Reports.
• Domain states: administrator session active; loading; load failure.
• Feedback states: loading indicator, error message.
• Components:
  • Admin Summary Panel (owner of dashboard summary state) — nested subcomponents: User Count Tile, Pending Report Count Tile.
  • Admin Navigation — entry points to Users and Reports.

12.13 Users (Administrator)

• Purpose: administrator workspace for managing user accounts.
• Information set: user rows (avatar, username, display name, account state) and per-account management controls.
• Actions: review user accounts; act on accounts as needed.
• Domain states: loading, users present, no users, action in progress, action success, action failure.
• Feedback states: loading indicator, action confirmation, error message.
• Components:
  • User Management Table (owner of user list mutable state) — nested subcomponents: User Row (identity, account state, management controls), User Table Empty State.

12.14 Reports (Administrator)

• Purpose: administrator workspace for reviewing and resolving reports.
• Information set: report rows (reporter identity, reported subject, report reason, submission time, resolution state) and resolution controls.
• Actions: review incoming reports; manage report resolution.
• Domain states: loading, reports present, no reports, resolution in progress, resolved, resolution failure.
• Feedback states: loading indicator, resolution confirmation, error message.
• Components:
  • Report Queue Panel (owner of report list mutable state) — nested subcomponents: Report Row (reporter, subject, reason, timestamp, resolution state), Resolution Control, Report Queue Empty State.

13. Glossary

• ChatLink — the real-time chat web application defined by this SRD.
• Username — the unique identifier a user registers, logs in with, and is found by.
• Friend Request — a connection invitation sent from one user to another, which can be accepted or rejected.
• Friend List — the set of accepted connections for a user.
• Real-Time Chat — message exchange delivered and rendered without a page refresh.
• Chat History — persisted record of past messages retrievable from the database.
• Last Active — the last time a user was observed as present.
• Typing Indicator — a live cue showing that a conversation partner is composing a message.
• Message Status — the delivery progression of a message: sent, delivered, read.
• Block — a user action that suppresses contact from another user.
• Privacy Settings — user-controlled options governing visibility and reachability.
• Admin Dashboard — the administrative surface for managing users and reports.
• Report — a submitted issue for administrators to review and resolve.
• Socket.IO — the baseline real-time event library used by the uploaded prototype.
• Firebase Auth / Firestore / Firebase Storage — the owner-specified authentication, database/real-time chat, and profile-photo storage services.
• Security Rules — database-level rules restricting access to authorized users and data.
• Ruang Chat Publik — the public chat room in the baseline prototype, joined with only a nickname.
• Anonim — the default attribution ("Anonymous") used when a public-room participant sends a message without entering a nickname.
• Layered Translucency — the project's design language: frosted glass panels floating over a cool paper-white ground with luminous edges, generous radii, and gentle float.
• Landing Hero Motion Brief — the specification of the landing hero's thesis, focal subject, layers, loop, first frame, interaction, responsive behavior, and reduced-motion fallback.
• Page Content and Component Coverage — the presentation contract defining each page's purpose, information set, actions, domain and feedback states, and component ownership.