# Dewemoji Community Plan (Private‑First → Public Consensus)

This plan matches the core purpose: **help people find emojis with their own words, in any language**, and let the community optionally promote keywords into global search.

## Core principles

- **Private first:** users can store any keyword for their own use.
- **Public by choice:** users can propose a keyword to the public pool.
- **Consensus‑based:** public keywords only become searchable after votes.
- **Language‑friendly:** keywords can be in any language/script (not only Latin).
- **Safety‑aware:** moderation applies only to public proposals (not private).

## Current language reality

- Today the dataset only includes **EN + ID** keywords for all emojis.
- Community should be designed to add **other languages** over time.

## Two‑layer keyword model

### 1) Private keywords (personal)
- Stored per user (or device if not logged in).
- Any term is allowed, even if not “correct.”
- Used only for that user’s search + recall.
- No moderation needed.
- Created and managed in the **user dashboard** (not on emoji detail pages).
- Must be **used locally first** before being eligible for public proposal.

### 2) Public keywords (community)
- Users can propose **one of their own private keywords** to be public **from the dashboard**.
- Emoji detail pages only **display and vote** on public proposals; no direct proposal UI there.
- Once the proposal passes the threshold, it becomes globally searchable.

## Public keyword lifecycle

```
private → public_pending → public
```

Suggested rules:
- **public_pending** shown publicly with vote controls.
- **public** if it reaches **≥ 5 upvotes** (your rule).
- Optional future: auto‑reject with heavy downvotes or time decay.

## Voting model

- 1 vote per user per keyword.
- Score = upvotes − downvotes.
- Promotion rule: **>= 5 upvotes** (simple and clear).
- Optional future: trust‑weighted votes.

## Moderation model

- Moderation applies only to **public proposals**.
- Private keywords are always allowed.
- Blocking rules:
  - disallowed words
  - mismatched emoji meaning
  - language mismatch (optional)

## UX flow (simple)

1) User adds private keyword.
2) User uses it locally (personal search/recall).
3) User clicks “Make Public” from the dashboard.
4) Keyword appears on emoji detail page as pending.
4) Community votes.
5) Reaches 5 upvotes → becomes public search term.

## API endpoints (clean, minimal set)

Auth:
- `POST /v1/contrib/auth/request`
- `POST /v1/contrib/auth/verify`

Keyword actions:
- `POST /v1/contrib/suggest`
- `POST /v1/contrib/make-public`
- `POST /v1/contrib/vote`
- `GET /v1/contrib/list?emoji=...`
- `GET /v1/contrib/search?q=...`

Moderation:
- `GET /v1/keywords/pending` (admin/moderation)

## Data model (minimum)

- `emoji_keywords` (keyword, lang, status, visibility, owner_user_id)
- `keyword_votes` (keyword_id, user_id, vote)
- `moderation_events`
- `users` / `magic_links`

## Optional recommendations (future‑safe)

### A) Multilingual expansion
- Encourage new languages by highlighting “empty language slots.”
- Allow region variants (e.g., `en-US` vs `en-GB`).

### B) Personal dictionary export
- Export private keywords per user.

### C) Trust tiers
- Contributors with good history can fast‑track proposals.

### D) Admin review console
- Moderators can approve/reject quickly.

### E) Abuse prevention
- Rate limit public proposals + voting.
- Use Turnstile only for public actions.

### F) Search blending
- Private keywords weighted highest for the owner.
- Public keywords weighted lower but global.

### G) “My Words” UI
- Show user’s private keywords in the **dashboard**.
- One‑tap “Make Public” in the dashboard (not on detail page).

## Recommended rollout

1) Private keywords (local only).
2) Public proposals + votes (no AI).
3) Basic moderation + rate limits.
4) AI guard + trust tiers.