Fun Chat

1Summary

What the product is and where it stands today.

Fun Chat is a real-time messaging product: one-to-one and group conversations, media, read receipts, and the group-management controls people expect once a chat has more than a handful of participants. It ships as a native Android app, a native iOS app, and two web clients that share one codebase — a phone layout and a three-pane desktop layout — plus a separate console for moderation.

The server is a single Go binary exposing 93 HTTP routes and one WebSocket endpoint. Every client speaks the same API; the web clients are served from the same origin as the API they call, so no client needs cross-origin permission to work.

2Test environments & accounts

Where to test, what is signed in already, and what a restart takes away.

2.1 Environments

Two deployments run the same build. The first is the one to use; the second answers on its own address and is how to tell a server fault apart from something the CDN in front of the first one did.

2.2 Standing accounts

Three member accounts are recreated automatically after every server start. The password for all three is FunChat2026.

The seeded group is 产品设计组 (“Product Design”) — all three accounts, an announcement set, three messages. Registration is open, so more accounts can be created freely; nothing has to be requested.

Console credentials are deliberately not printed in this document. They live in the environment file on the server; ask whoever owns the deployment.

2.3 The Android build

The release APK is signed and minified and refuses cleartext HTTP, so it will only talk to an HTTPS host. Installing it needs “install unknown apps” granted to whichever browser downloads it. It is not a debug build: stack traces come back obfuscated, so record the steps rather than relying on the trace.

3Platform scope

Where each capability is available. The two web clients share one implementation.

● available   — not applicable to that surface

4Functional requirements

Grouped by area. Status reflects verified behaviour on the current build, not intent.

4.1 Accounts & identity

4.2 Contacts & safety

4.3 Conversations & groups

4.4 Messaging

4.5 Media

4.6 Real-time delivery & notifications

4.7 Moderation console

5Limits, timings & error codes

The boundary values worth testing at. Every figure here is read out of the shipped source, not out of an intention.

5.1 Input limits

Uploads are accepted only for these extensions, and the bytes have to match the type the name claims:

.aac .bin .doc .docx .gif .jpeg .jpg .m4a .mov .mp3 .mp4 .ogg .pdf .png .ppt .pptx .txt .wav .webm .webp .xls .xlsx .zip

5.2 Rate limits

A sliding one-minute window per client IP address, not per account — so a whole test team behind one office address shares every bucket below. Worth knowing before reporting a mysterious 429.

Exceeding one returns 429 and too many requests. Separately, five failed sign-ins lock an account for fifteen minutes; that lock is on the account, so it follows the person to another device.

5.3 Timings

5.4 Responses

Every endpoint answers in the same envelope. code is 0 on success and 1 on failure; err and msg repeat code and message for an older client generation. The HTTP status carries the class of failure:

6Non-functional requirements

Constraints the implementation has to satisfy regardless of feature.

6.1 Security

6.2 Reliability & performance

6.3 Compatibility

7Known defects — do not re-report

Every one of these is already logged. Reproducing one is not a finding — please skip past them and spend the time on what is not listed here. Ordered by what would block a public launch.

8What is already covered automatically

Ground that machine checks hold, so manual effort can go elsewhere. None of it runs on every change yet — that is OI-5.

8.1 Server tests

117 Go test functions. The largest groups are the HTTP layer (43), storage (32) and the console (14). Within storage, 61 of those cases are a single behavioural suite run against both storage implementations — the in-memory one these deployments use and the database-backed one — so the two cannot quietly disagree. Writing that suite is what turned up the blocking, session-revocation and form-decoding defects already fixed in this build.

8.2 End-to-end and browser checks

Roughly 263 assertions, run by hand against a live deployment:

8.3 Where manual testing pays

• iOS. No automated coverage at all. Everything there is unverified until a person runs it.
• Android on real hardware. The unit tests never touch the interface, and nothing exercises notifications, backgrounding, or losing the network mid-send.
• Two devices at once. Read receipts, unread counts and live delivery only mean anything with two sessions open, which no harness arranges.
• Media that is awkward rather than invalid. A 49 MB file; a file whose extension lies about its contents; a photo straight off a phone camera at full resolution.
• Anything visual. Layout, truncation, long display names, right-to-left text, dark mode.

9Goals & non-goals

What this release is trying to be — and what it deliberately is not.

Goals

• One conversation, every device. Unread state, read receipts and history stay consistent whether a person opens the phone app or a browser.
• Messages arrive now, not on refresh. A persistent socket with automatic reconnection; push notification when the socket is gone.
• Groups people can actually run. Announcements, admins, mutes, invitations and removals — not just a shared thread.
• An operator can answer for the platform. Every moderation action is attributable, reversible where it should be, and written to an audit log.
• Safe by default. No built-in credential, no fallback token, nothing that only works because a setting was forgotten.

Non-goals for this release

• Voice and video calling.
• End-to-end encryption. Transport is TLS; the server can read message content, which is what the moderation console depends on.
• Federation or self-hosting by third parties.
• Threads, reactions, scheduled messages, message editing.
• Desktop applications. The desktop experience is the web client.

10Users

Three audiences, three different jobs.

11Architecture

One backend, five front ends, two interchangeable storage backends.

Both storage backends implement one repository interface of 92 methods and are held to a single shared behavioural test suite, so a change verified against the in-memory implementation cannot silently diverge in the one production runs.

12Deployment

How the current environment is arranged.

Of these, youxin.chat and api.youxin.chat resolve today; the three client hostnames do not yet, which is why §2 gives the path form instead.

Each hostname is proxied to the same backend, so every web client is same-origin with the API it calls and no cross-origin permission is required. The API binds to the loopback interface only; the reverse proxy is the sole public listener, which is what makes trusting its forwarded client address safe.

13Deferred

Considered and consciously postponed.

• Schema migrations. Tables are created inline at start-up. Workable now; unworkable once the schema evolves across running instances.
• Field-name consistency. Several endpoints accept two names for the same field, kept for the previous client generation. Harmless but a reliable source of integration mistakes — a reference table should ship with the API documentation.
• Registration control. Anyone can create an account. An invitation code or approval step is needed before an environment holds real users.
• Web unit tests. The pure functions in the web client — row grouping, highlight escaping, URL scheme checks — are testable in isolation and currently covered only end to end.

14Appendix

14.1 API surface

14.2 Terms