Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

feat(payments): subscription data model and plan settings

Fermée
#848 0 commentaires 0 réactions 1 personne assignée Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@Priyanshubhartistm y travaille déjà.

Depuis le 16/10/2026.

  • #849 par @Priyanshubhartistm — ouverte

Évaluation

Cette issue n'a pas encore été évaluée.

Description

enhancement

Is your feature request related to a problem? Please describe.
Admission is a one-time boolean (users.is_admitted). There is nowhere to record a paid period, a plan, or when access ends, so recurring billing and tiered access (#673) cannot be built. This is the first, behaviour-neutral step.

Describe the solution you'd like

  • A user_subscriptions table (pubkey, plan id, status, period start/end, grace end, cancel-at-period-end) and the invoices columns plan_id, period_start, period_end, via a migration. A subscription is keyed by pubkey, so no separate subscription id is needed.
  • payments.subscriptionPlans[] in settings (id, price, interval, grace period, per-plan limits), with types, defaults (empty list), validation in validateSettings, and CONFIGURATION.md docs.
  • IUserSubscriptionRepository (find by pubkey, upsert, list due for renewal/expiry) and the invoice repository/Invoice type changes, with unit tests.
  • The migration grandfathers every existing is_admitted user onto a non-expiring plan so enabling plans later never locks anyone out.
  • No change to runtime behaviour: with no plans configured the relay behaves exactly as today.

Additional context

  • Design: #673. Earlier groundwork for the same layer.
Langage dominant
TypeScript
Étoiles
829
Forks
234
Merge moyen
18 h 43 min
PR mergées (30 j)
67

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de cameri/nostream

Toutes les issues de cameri/nostream

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.