noitu/plans/reports/researcher-260921-0016-noitu-landscape-and-improvement-inputs.md

# Research: noitu landscape scan — competitors, dictionary disputes, small-scale server practice

Prior reports (`research-260904-1058-noi-tu-game.md`, `research-2609{07,08,10}-*`) already cover
rules engine, bot AI, Vietnamese normalization, and an exhaustive dictionary-source comparison
(Wiktionary/undertheseanlp/Hoàng Phê). This report does not repeat those; it adds competitor
feature/complaint evidence, dispute-handling patterns, small-scale server practice, and ecosystem
notes.

## Summary

- Direct web competitors exist: `noitu.fun` and `wordfight.online` — both have ranked/Elo modes,
  neither has noitu's spectator-on-elimination or bot-difficulty design.
- The #1 recurring complaint across mobile nối từ apps is dictionary coverage ("từ điển quá ít"),
  not rules or UX — validates prior dictionary-focused work as the highest-leverage area.
- Every competitor with a fixed wordlist ships a manual "report word" channel; none of the ones
  found do live player voting mid-game. One Discord bot layers a separate community-wordlist repo
  on top of a base corpus — closest precedent to an allowlist overlay.
- Ranked/Elo matchmaking with wait-time-based window widening is the standard pattern for small
  pools (chess.com/lichess-style); directly applicable to a 2-4 player room-code game with low CCU.
- SQLite-as-embedded-store (not just read-only dictionary) is a well-documented pattern for adding
  room/stat persistence without a DB service — fits the existing `modernc.org/sqlite` dependency.
- `protovalidate` (Apache-2.0, Go+JS via `protovalidate-es`) is a concrete, license-compatible fit
  for schema-level proto validation, complementing (not replacing) noitu's Vietnamese-specific
  sanitization.
- Card-mechanic "Extended Mode" (skip/reverse/swap turn) and Elo ranked ladders are the clearest
  "features players expect but noitu lacks" signal found.
- Casual house-rule turn timers run 5-10s vs noitu's 30s default — worth noting as a design choice,
  not a defect.
- No changes found to Svelte 5/adapter-static or buf/protobuf-es that are breaking or urgent for
  noitu's current setup.

## 1. Competing implementations — rules, features, complaints

### Direct web competitors
- **noitu.fun** — solo vs AI, "Ranked" mode with a leaderboard, and group/room-code mode (closest
  analog to noitu's own room model). Also ships non-chain minigames under one brand: "Extended
  Mode" adds card mechanics (reverse turn, assign-next-responder, swap opponent's word, skip turn),
  plus a trivia-style "Character Arena" and a Wheel-of-Fortune-style "Letter Assembly" mode. Rules
  text explicitly bans slang/shorthand and misspelled tone marks. [noitu.fun]
- **wordfight.online** — 3 modes: English word chain (shows IPA + Vietnamese gloss per word),
  Vietnamese word chain (2-syllable, same rule as noitu), and a separate "King of Vietnamese"
  word-puzzle mode. Turn timer 10-30s. **Elo-based leaderboard with skill-matched opponents**,
  progressive difficulty across up to 999 levels, 3-star mastery rating per level, replay-resistant
  randomized word lists, private shareable room links. [wordfight.online]
- Neither site documents spectator viewing of eliminated players, reconnect grace windows, or
  per-seat colored room chat — these look like noitu differentiators, not table stakes to add.

### Discord bots (adjacent platform, same game)
- **minhqnd/Noi-Tu-Discord** ("Moi Nối Từ") — bot-vs-player and PvP-with-bot-as-referee modes, DM
  play, `/leaderboard` and `/stats` (streak, personal record, wins), `/tratu` dictionary lookup
  backed by 357k+ definitions via `dict.minhqnd.com`, emoji-reaction feedback per submission
  (✅ correct / ❌ can't chain / 🔴 duplicate / ⚠️ format error). [github.com/minhqnd/Noi-Tu-Discord]
- **lvdat/bot-noi-tu** ("RaHub") — dictionary sourced from `undertheseanlp/dictionary` plus a
  **separate community-contribution repo** (`phobo-contribute-words`) merged in at build/runtime.
  This is the clearest real-world precedent for a base-corpus + community-overlay split (see §2).
  [github.com/lvdat/bot-noi-tu]

### Mobile apps — features and complaints
- Galaxy Team "Nối từ - Word Chain": Survival / Time-Limited(3min) / Level-Challenge-vs-AI modes.
  [play.google.com/.../com.galaxteam.wordchain]
- "Nối từ tiếng Việt" (iOS, MWM/id6449588406): 3 modes — Challenge (timed rounds + score
  threshold), Duel (2p turn-based), Arena (4p elimination — same shape as noitu's 2-4 elimination
  room), Game Center leaderboard integration, scoring by chain-word character count. **Rating 1.2/5
  (19 reviews)**, dominant complaint is a too-small dictionary ("từ điển quá ít") rejecting valid
  words and occasionally accepting non-Vietnamese junk; developer response cites Vietnamese's
  richness as an excuse rather than fixing it. [apps.apple.com/vn/.../id6449588406]
- Cross-app pattern found via search: apps expose an in-app "Report Error" / "báo lỗi" flow for a
  rejected word rather than any live dispute; devs publicly acknowledge coverage gaps as
  unavoidable rather than committing to fixes. [search results, ktcc.blog context]

### Rule-variant survey (Vietnamese how-to-play content)
- Casual/offline house rules commonly run **5-10s per turn** (ktcc.blog), notably faster than
  noitu's 30s default — a deliberate design choice for noitu given typed Vietnamese input
  (Telex/VNI composition), not evidence of a gap.
- "Từ hiểm" (dead-end/trap words — syllables that start almost nothing) is a named, well-understood
  strategic concept across the community, not something apps hide. This affirms noitu's design of
  showing the leftover words in a dead-end position rather than treating it as a bug.
- Recurring dispute across communities: "từ ghép" (compound) vs "từ đơn" (single-syllable) and
  which authority resolves disputes; common advice is to pre-agree a single reference dictionary
  (often citing the Institute of Linguistics / Hoàng Phê) as sole arbiter — already covered in
  `research-260910-0939-hoang-phe-in-noitu.md`.

### Implications for noitu
- Dictionary coverage is the make-or-break axis for player satisfaction industry-wide; any
  roadmap item competing for effort against dictionary work should clear a high bar.
- A lightweight "report this rejection" action (word + turn context) is standard and cheap; noitu
  has no such flow today per the README. Low-risk, high-precedent addition.
- Elo/ranked ladder and light "chaos" mechanics (skip/reverse/swap) are the two concrete feature
  gaps versus the nearest web competitors, if PvP breadth is a goal.

## 2. Dictionary disputes — patterns beyond corpus choice

(Corpus/source comparison already exhaustively covered in prior reports; this is new: process
patterns for *handling disputes at runtime*, and licensing-separation precedent.)

- **Static base + community overlay repo** (lvdat/bot-noi-tu + phobo-contribute-words): base
  dictionary from a versioned upstream corpus, disputed/missing words tracked in a *separate*
  repository merged at build or load time. Mirrors an allowlist-overlay design: keeps the
  overlay's provenance and license distinct from the base corpus, which matters for noitu's
  Apache-2.0-code / CC BY-SA-4.0-data split — an overlay of player-submitted words would need its
  own license decision (CC BY-SA if derived/mixed with Wiktionary text, or a fresh license if pure
  word-list-no-definition additions, which are likely uncopyrightable facts). [github.com/lvdat]
- **Scrabble's live challenge**: any player may challenge a just-played word before the next turn;
  in double-challenge scoring the *loser* of the challenge (wrong challenger or wrong player) loses
  their turn — a real cost that discourages frivolous challenges. [en.wikipedia.org/Challenge_(Scrabble)]
- **Words With Friends' approach**: no live human challenge at all — the client just keeps
  resubmitting until the server's own dictionary accepts something; the dictionary itself (Zynga's
  ENABLE-derived ~173k word list, deliberately different from tournament Scrabble lists) is the
  sole and silent arbiter. [wordfinder.yourdictionary.com; word.tips]
- No evidence found of any nối từ implementation running **live in-match player voting** on a
  disputed word (i.e., other seated players vote accept/reject before the turn resolves). The
  Scrabble-style post-hoc challenge with a real cost, or WWF's silent-server-arbiter, are the two
  patterns actually used in the wild — an async "report → maintainer/community review → next
  dictionary build" queue (closer to WWF, deferred) is simpler to implement correctly than a live
  vote and has no real-time consistency/latency problem to solve.

### Implications for noitu
- If a self-serve "report word" pipeline is ever built, model it as WWF/lvdat's deferred pattern
  (report now, reviewed and merged into a future `noitu.db` build) rather than live voting — no
  new consensus/anti-brigading problem, and it fits the existing single-file, rebuilt-not-mutated
  dictionary architecture.
- Any player-submitted word overlay must get its own explicit license decision before merging with
  the CC BY-SA data tree; do not assume submitted words inherit Wiktionary's license by default —
  bare word forms without wiktionary-derived definitions are likely factual/uncopyrightable, but a
  submission that carries a definition text is a new derivative work needing its own care.

## 3. Small-scale realtime game server practice

- **Matchmaking for small pools**: standard pattern (chess.com/lichess-style, per Awesomenauts
  postmortem) is `window = base_window + widen_rate × seconds_waited`, anchored on whichever queued
  player has waited longest, capped at a max window — trades match quality for queue time as the
  pool thins out. Directly portable to a "quick match" queue for noitu's current room-code-only
  online mode. [joostdevblog.blogspot.com; medium.com/@deephavendatalabs]
- Batch pooling ("gather for ~1-2 min then match everyone at once") is the standard fallback for
  genuinely tiny regional pools, cited as improving match quality up to ~300 concurrent queuers —
  likely overkill for noitu's expected scale, worth knowing only if online play grows.
- **Persistence without a DB service**: SQLite is a well-documented fit for exactly this
  ("zero-configuration... ideal for small to medium services," pure-Go `modernc.org/sqlite` needs
  no CGO, single static binary). Patterns seen: JSON-blob-per-row for full game/room state
  (simplest, fine at noitu's scale), or row-per-update table if write volume grows. A SQLite
  changelog-table + trigger + Go worker pattern exists for push-driven updates but is unnecessary
  complexity for a single authoritative in-process game engine like noitu's. noitu already
  depends on `modernc.org/sqlite` for the dictionary — reusing it (a second read-write DB file, or
  a second schema in-process) for room/series-stat persistence across restarts costs no new
  dependency. [oneuptime.com/.../sqlite-go; gist.github.com/rusco]
- **Rate limiting / abuse**: `golang.org/x/time/rate`'s token-bucket `Limiter` (Allow/Wait/Reserve)
  is the standing idiomatic choice for per-connection message throttling in a Go WebSocket server;
  described as covering "90% of cases" without needing Redis-backed distributed limiting, which is
  irrelevant to a single-binary deployment. Combine with a concurrent-connection cap per IP.
  [dev.to/lovestaco; oneuptime.com/.../websocket-rate-limiting]
- **Anonymous vs identity**: industry best practice (PlayFab, AWS Games Industry Lens) is
  zero-friction anonymous login by default, with an *optional* upgrade path to a recoverable
  identity later — matches noitu's current no-account, nickname-only model; nothing here argues
  for forcing accounts. Reconnect best practice: identity (not the transient socket/session token)
  is the thing that says two connections are the same player, and the server-issued session token
  should stay stable across a reconnect within the grace window — consistent with noitu's existing
  disconnect-grace-window design per its README. [learn.microsoft.com/playfab; docs.aws.amazon.com]
- **Observability**: not surfaced as a distinct concern in results beyond generic Prometheus/metrics
  advice seen in one unrelated Go arena-server repo (`nguyenbatam/arena_game_server`, Redis-backed,
  10k-CCU target) — that project's scale and dependency footprint (Redis, k8s) is not a fit for
  noitu's single-binary constraint; flagging only because Prometheus text-format `/metrics` next to
  the existing `/healthz` endpoint is a low-cost, dependency-light addition if observability becomes
  a goal.

### Implications for noitu
- A quick-match queue (as opposed to room-code-only) is implementable with the widen-by-wait-time
  formula and no new infrastructure; it's a pure in-memory queue in the existing Go process.
- Room/series persistence across restarts (currently implied in-memory, since README describes
  rooms closing after 10 idle minutes with no persistence mention) could reuse the SQLite
  dependency already in the binary rather than adding Redis/Postgres.
- `x/time/rate` per-connection + a connection-count cap per IP is the standard, low-effort answer
  to WS abuse; no evidence any competitor does more than this at this scale.

## 4. Ecosystem notes (brief)

- **SvelteKit/Svelte 5 + adapter-static**: no breaking change found for 2026. One caution
  surfaced repeatedly in 2026 guides: module-scope runes and `$derived` wrapping a store's `$`
  auto-subscription can break specifically under prerendering/hydration; recommended fix is
  keeping runes component-local and bridging global stores explicitly via `$effect`. Only relevant
  if noitu's frontend uses module-level `$state`/`$derived` for anything beyond the documented
  client-owned state (theme, personal best, input box) — worth a quick grep, not a redesign.
  [svelte.dev/docs/kit/adapter-static; khromov.se]
- **buf/protobuf-es**: `protovalidate` (Apache-2.0) plus `protovalidate-es` gives schema-level
  field constraints (e.g. string length/pattern) enforced identically from the same `.proto` file
  on both the Go and JS generated types — same "one wire contract" philosophy noitu already uses
  for message shape. Could formalize bounds already enforced by hand (e.g. nickname length) as
  proto annotations instead of duplicated Go+JS logic — but noitu's nickname sanitization (control
  chars, whitespace collapse, combining-mark cap) is Vietnamese-text-specific logic CEL/protovalidate
  doesn't replace; treat it as a complement for simple bounds, not a replacement for sanitization.
  [github.com/bufbuild/protovalidate]
- No 2026 buf CLI or `protoc-gen-es`/`@bufbuild/protobuf` breaking-change advisory found that
  affects noitu's current generation setup.

## Unresolved questions

- Does noitu currently persist rooms/series scores across a server restart at all, or is
  everything in-memory? README doesn't say; determines whether §3's SQLite-persistence point is
  a new feature or filling a known gap.
- Would a "report rejected word" flow be worth the review-queue maintenance cost given the project
  has one apparent maintainer, versus just improving corpus coverage directly (already the subject
  of 5 prior reports)?
- Is competitive/ranked PvP actually a goal for noitu, or is vs-bot + casual room-code play the
  intended scope? The Elo/quick-match findings only pay off if ranked play is in scope.
- Could not verify `phobo-contribute-words`' actual review/merge workflow or license (GitHub
  fetch returned only nav chrome, no README text) — the "allowlist overlay" characterization is
  inferred from the bot's own README description, not confirmed from that repo directly.

Status: DONE
Summary: Competitor scan of noitu.fun, wordfight.online, and 4 Discord/mobile nối từ implementations plus small-scale server-practice research (matchmaking, SQLite persistence, rate limiting) written to the report; dictionary coverage confirmed as the industry's #1 complaint, and a base+overlay community-wordlist precedent and protovalidate found as new, concrete inputs.
Concerns: none blocking; one item (phobo-contribute-words internals) unverified due to GitHub README not rendering through WebFetch — noted in Unresolved questions.