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
- 星标
- 29
- 派生
- 9
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 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 一周以上 新手友好度 28/100
相似的 Issue
-
documentation good first issue help wanted
难度 2/5 1-3 小时 新手友好度 75/100
维护者通常 1 天内回复
-
bug release:v5.56
难度 2/5 1-3 小时 新手友好度 75/100
Jason-Vaughan/TangleClaw#2270 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 66/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 75/100
style-dictionary/style-dictionary#1773 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
SignalK/signalk-server#3143 ·
维护者通常 1 天内回复