NEARBuilders / NEARBuilders/everything-dev

v2-platform: 08 member subdomains — bindings, per-request composition, wildcard TLS

Open
#283 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

ready-for-agent
Dominant language
TypeScript
Stars
5
Forks
6
Avg merge
1m
Merged PRs (30d)
1

Description

Parent

#274 (v2 platform services spec)

What to build

Member subdomains: org-eligible members deploy UI-level customizations served at <user>.<city>.<domain>. The binding table gains member entries (resolved through the existing 30s-cached host resolver); the member's runtime extends the city runtime and may override UI and plugin-UI remotes ONLY — enforced server-side, so no unverified member server code ever executes in a host process. This ticket resolves the per-request composition question (wayfinder ticket 06): composed trees cached per member/tenant with invalidation on republish, or the single-tree runtime-override alternative — decided by measurement here. SSR stays per-binding gated. Wildcard TLS via DNS-only wildcard CNAME plus ACME-challenge delegation to the host's auto-issued wildcard certificate (free, any depth — no paid certificate manager). Deploy-time: the deploy service registers the member binding after the eligibility gate passes.

Acceptance criteria

  • A member deploy is served at their subdomain of the city node's domain over HTTPS within the resolver cache TTL
  • Member configs can override UI/plugin-UI remotes only; attempts to override server-side remotes are rejected
  • Per-request composition is correct under three config layers (base, tenant, member) with cached composed trees and invalidation on republish — or the measured decision record shows the single-tree alternative winning
  • Member bindings are created only for org-eligible accounts and only through the deploy service
  • Wildcard HTTPS works for any member subdomain without per-hostname certificates
  • SSR for member subdomains respects the per-binding SSR gate

Blocked by

  • #281 (all web plugins grafted — override-by-plugin is the member surface)
  • #275 (deploy service core — eligibility + binding registration)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the parent v2 platform services spec in #274, then review the blocked work in #281 and #275 and the existing host resolver, runtime composition, and deploy service entry points. Measure the cached composed-tree and single-tree alternatives, and verify binding eligibility, server-side override restrictions, wildcard TLS, and per-binding SSR against the acceptance criteria.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
backend, cloud, infrastructure, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.