Build the friend request, friendship, and blocking lifecycle
@coder13 がすでに取り組んでいます。
2021年1月1日 から。
評価
この issue はまだ評価されていません。
説明
Goal
Create the durable, server-authorized relationship model that every Friend System surface can depend on.
Product contract
Authenticated users can:
- send a friend request;
- cancel their own outgoing request;
- accept or decline an incoming request;
- list accepted friends and incoming/outgoing requests;
- unfriend someone;
- block or unblock another user.
State transitions must be idempotent. A crossed request may become an accepted friendship instead of creating two requests. Self-requests, duplicate relationships, blocked pairs, and unauthorized transitions are rejected consistently.
Blocking is directional and overrides friendship state:
- blocking removes any accepted friendship between the pair;
- pending friend requests and room invitations between the pair become non-actionable;
- the blocked user cannot send new requests or invitations;
- APIs do not reveal whether a block exists.
Data and API design
- Store one canonical relationship per unordered user pair using a normalized pair key and a unique index.
- Keep directional blocks separate from the symmetric friendship so future policy stays understandable.
- MongoDB remains the source of truth; add backward-compatible Prisma models and non-blocking PostgreSQL mirrors from the first enabled write.
- Notifications reference relationship/request resources but are not the relationship source of truth.
- Use authenticated REST operations for durable state changes; Socket.IO may announce changes to the affected users but must not own them.
- Return explicit public user projections. Never use, return, search, log, or retain email; #191 is a prerequisite.
Acceptance criteria
- Document the relationship state machine, invariants, conflict responses, and any resend cooldown.
- Add MongoDB schemas/indexes and corresponding backward-compatible PostgreSQL migrations/mirrors.
- Implement authenticated list/create/cancel/accept/decline/unfriend/block/unblock operations.
- Enforce server-side authorization, per-user/per-pair limits, idempotency, and concurrency-safe unique-pair behavior.
- Emit typed realtime invalidation/update events to both users' existing per-user rooms.
- Reconcile state from REST after reconnect so missed realtime events do not corrupt the UI.
- Add tests for crossed requests, duplicate/replayed actions, concurrent accepts, self-actions, blocking, unblocking, unfriending, ID tampering, and disabled PostgreSQL.
- Add privacy-safe metrics for request/accept/decline/block outcomes without recording graph edges or identity.
Dependencies
- #191 stop retaining WCA email addresses
Launch gate
- #188 hardening must pass before broad enablement; it does not block building this foundation.
Non-goals
- Direct messages (#189).
- Stranger recommendations or matching (#190).
- Browser push notifications.
- Room invitations (#187), which consume this relationship API.
- 主要言語
- JavaScript
- スター
- 30
- フォーク
- 9
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
coder13/LetsCube のほかの issue
-
難易度 3/5 1〜2日 初心者へのやさしさ 65/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 55/100
-
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
-
area: data area: platform enhancement priority: P1
難易度 5/5 1週間以上 初心者へのやさしさ 28/100
coder13/LetsCube の issue をすべて見る
似ている issue
-
[Feature]:オープンenhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
Uuriko/project-room#1554 ·
メンテナーはふだん 1 日以内に返信
-
automated issue report
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
lirantal/discoprint#36 ·
メンテナーはふだん 1 日以内に返信
-
accepting PR Content:HTML
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
mdn/content#45988 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信