Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Build the friend request, friendship, and blocking lifecycle

Abierto
  • ¿Algo no está bien?
#75 0 comentarios 0 reacciones 1 asignado Ver en GitHub

@coder13 ya está trabajando en esto.

Desde el 1/1/2021.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

area: auth area: data area: social enhancement priority: P1

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.
Lenguaje dominante
JavaScript
Estrellas
30
Forks
9
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de coder13/LetsCube

Todos los issues de coder13/LetsCube

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.