martbost e95f9df13a Approved exceptions: people you have okayed to hold more than one account
Marty approves specific people for multiple accounts (partners, staff, a spouse on a
shared machine) and needed a way to say so without the guard fighting him.

Admin > Members > Duplicate signals now carries an "Approved exceptions" list: add an
email with a note, see who is on it and when, remove one. It sits directly under the
signals so the two are read together.

An exception can be added against the address they ALREADY have, not just the new one.
That matters because the usual case is approving a person before their second address
exists, and at sign-up time the new address is unknown to us. checkSignup now tracks
every account the sign-up collided with, and clears the block if either side is approved.

Clearing the HARD flags matters as much as clearing the block. Those flags are what
silently drop an account off the leaderboard and bar it from adopting out of the holding
tank, so an approved person would have been "allowed" in name only. They now keep both.
The account is tagged 'allowlisted' instead, so the admin sees why it went through, and
the server logs the exception by name.

Suspension still wins. An exception is permission to hold several accounts, not immunity
from being suspended for something else.

qa/fraud-allow.mjs (12 assertions) boots its own server and walks the real flow: first
account created, second blocked with the Qualified Start redirect, exception added,
second account now created, no hard flag left on it, exception visible in the admin
report, removing it blocks again, malformed address refused, endpoint admin-only.
qa/sponsor-note.mjs 5, qa/run.sh member 0 bugs.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-17 10:42:31 -05:00
2026-09-14 05:40:26 -05:00
2026-09-14 05:40:26 -05:00

InstantAdPay — site

Membership advertising with immutable on-chain settlement. Zero-dependency Node server (RM Circle pattern): static pages + JSON API + SSE ledger.

Architecture

  • server.js — http server: pages, /api/*, /join/<id> sponsor links, SSE feed
  • chain.js — contract reader + persistent event indexer (free public RPCs)
  • auth.js — SIWE wallet sign-in (EIP-4361), sessions in the volume
  • accounts.js — site-side records only (free members, last-touch sponsor attribution, handles). The CHAIN is the source of truth for money/credits.
  • public/ — landing, live ledger, member area; no client libraries

Chain flip (rehearsal → mainnet)

Everything chain-specific lives in data/config.json (volume): {contract, chainId, chainName, explorer, rpcs, deployBlock}. Defaults point at the Amoy rehearsal deployment. Launch = deploy the mainnet contract, wipe accounts.json/sessions.json/chain-index.json, PATCH /api/admin/chain with the mainnet values, set rehearsal:false via /api/admin/site. Same code, different config.

Run

PORT=3100 node server.js       # DATA_DIR defaults to ./data

Admin API auth: Authorization: Bearer $ADMIN_PASSWORD.

Spec: ../CONTRACT-SPEC.md (v1.0.3-frozen). Contracts: ../contracts/.

Chatbot knowledge is part of every change

chatbot.js answers members two ways: CANNED regex answers and systemPrompt() for the AI. Any change that a member could ask about (a new pane, a rule, a price, a limit, a fix they noticed) is not done until both are updated in the same commit, and KNOWLEDGE_DATE in chatbot.js is bumped. The QA runner (bash qa/run.sh public) fails when a release note on the live site is newer than that date.

S
Description
InstantAdPay membership advertising site
Readme 39 MiB
Languages
JavaScript 78.6%
HTML 17.1%
CSS 4.2%
Shell 0.1%