Skip to content

BACKLOG.md

Latest commit

 

History

History
158 lines (126 loc) · 12.4 KB

BACKLOG.md

File metadata and controls

158 lines (126 loc) · 12.4 KB
Raw

Backlog (Post-MVP)

Last updated: 2026-09-28

This is the canonical post-MVP backlog.

Use this file only for deferred or future work. Anything still in open-beta scope belongs in docs/PLAN.md and its linked canonical docs instead.

Near-Term Product UX

  1. Invoices + Clients Search and Filtering
    • Add list search on both /invoices and /clients (number/name/email/status query support as appropriate).
    • Add lightweight filters (status + date ranges on invoices; active/archived signal on clients if still relevant after soft-delete views).
    • Keep query params shareable/bookmarkable, and persist filter state across pagination.
    • Add feature coverage for query/filter combinations and ownership boundaries.

Infrastructure & Payments

  1. Self-Hosted Bitcoin Node + Watcher

    • Deploy bitcoind + Electrum indexer or mempool.space instance.
    • Replace third-party payment detection with our own RPC/WS hooks.
    • Automate failover/monitoring for mempool + confirmation events.

  2. Multisig / Advanced Wallet Support

    • Support xpub/zpub from multi-sig wallets (BIP48 or custom policies).
    • Allow per-invoice address derivation from multiple co-signers.
    • Note: small-balance resolution (manual credit to close dust residuals) is now defined in the active product spec and partial-payments spec.

Email & Notifications

Carry-forward guardrail from active roadmap scope: suppress duplicate sends for the same invoice and notice class inside a configurable cooldown window unless an explicit follow-up class is selected.

  1. Receipt PDFs for Paid Invoices

    • Once payments auto-mark invoices as paid, generate immutable PDF receipts (rate + tx snapshot).
    • Email customers/owners with attachments + status history.
    • Extend the current InvoiceReadyMail and InvoicePaidReceipt flows so invoice_deliveries rows capture PDF metadata + sent status in one place.

  2. Delivery log as full outgoing mail record

    • Evolve invoice_deliveries into a full record of outgoing email that issuers can browse and open from the invoice screen and from the client screen.
    • Each row should surface the mail type, recipient, send time, and status in a readable list; ideally show a preview or summary of what was sent.
    • Client screen view would show all mail sent to that client across all their invoices in one place.
    • Build on the existing InvoiceDelivery model and typeLabel()/statusLabel() methods already in place.

  3. Notification Hub

    • Slack/webhook integrations for payment events, delivery failures, etc.
    • Reuse InvoicePaid events and delivery log updates to emit notifications without polling.
    • M23 may select developer payment-event webhooks for M22 API consumers. If selected, define signed event truth, endpoint management, retry/replay behavior, and failure visibility in an approved spec; selection depends on consumer evidence.

  4. Notification Preference Expansion

    • Consider allowing issuers to configure alert thresholds per profile instead of keeping the open-beta-wide default threshold.

  5. Configurable Past-Due Reminder Cadence

    • Expose the hardcoded day-offset schedule (day 1, 7, 14 past due) as issuer-configurable notification settings.
    • The open beta ships a sane fixed default; this item adds issuer control post-open-beta.

  6. Custom Outbound Mail Logo Uploads

    • Allow issuers to upload a custom logo for outbound mail instead of only showing or hiding the default CryptoZing logo.
    • Include storage, validation, replacement/removal, and email-client-safe fallback behavior.
    • Keep this separate from the open-beta KISS mail-branding controls, which are limited to brand-shell text fields plus a default-logo on/off toggle.

  7. DMARC enforcement on the sending subdomain

  • Move _dmarc.mailer.cryptozing.app from p=none to p=quarantine once user traffic has produced a clean aggregate-report history (rua collectors: Mailgun DMARC monitor + OnDMARC; sources should show only Mailgun IPs, all passing aligned).
  • DNS-only change; verify a delivered message still shows dmarc=pass afterward. Context: #161/#166 — alignment already passes strictly, only enforcement is deferred.

Support & Admin Roles

  1. Support agent / maintainer role separation
  • For the open beta, the support agent role doubles as the operational maintainer: one email allowlist, one dashboard, full visibility into both issuer grants and service health monitoring.
  • Post-MVP, split these into distinct roles if the team grows:
    • A maintainer role that has access to the monitoring panel (queue depth, delivery failures, watcher health) but not to issuer grant browsing.
    • A support agent role that has access to issuer grant browsing but not to the monitoring panel, if a dedicated support function separate from engineering is needed.
  • Current SUPPORT_AGENT_EMAILS allowlist covers both concerns until separation is warranted.

Observability & Ops

  1. Structured Logging & Alerting

    • Centralized log ingestion (ELK/Loki) for rate fetches, payment events, mail sends.
    • Alerts when blockchain watcher or mail queue falls behind.

  2. Automated Deployments

  • Terraform/Ansible for infrastructure, CI/CD pipeline for staging/prod.

Integrations

  1. Accounting Export
  • CSV/JSON exports for accounting packages (QuickBooks, Xero).
  • API hooks so agencies can pull invoice/payment data programmatically.
  1. Fiat On-Ramp / Volatility Tools
  • Optional integration with OTC partners or conversion APIs for users who want instant conversion.
  1. Additional Cryptocurrencies
  • Track alternate chain addresses per invoice and support derivation/sending for other cryptocurrencies once Bitcoin MVP stabilizes.
  1. Advanced payment-ledger admin tooling
  • This is not the existing issuer-facing manual adjustment flow that already closes small balances or records credit/debit adjustments on an invoice.
  • This is post-MVP operator tooling to edit or annotate logged payment records themselves: fix tx metadata, override imported amounts in exceptional cases, reconcile disputes, or correct ledger history without relying solely on automated watcher flows.
  • Build atop the invoice_payments ledger + issuer notes so changes stay auditable and raw tx history is preserved rather than silently overwritten.

Content & SEO

  1. CMS-style Help Center (public)
  • Move /help content out of Blade into editable entries (prefer Markdown) with safe rendering and stable section slugs/anchors.
  • Add an internal editor UI with preview, draft/publish, and basic revision history so non-devs can update copy without deployments.
  • Store per-wallet “find your extended public key” guides as data so tabs are config-driven (easy to add/remove wallets).
  • Keep SEO hygiene: canonical URLs, meta descriptions/OG, and avoid indexing duplicate ?from= variants.

Product UX

  1. Multi-wallet selection + additional wallets UI
  • Core wallet-key lineage and cursor safety is now tracked in active open-beta roadmap scope; this post-MVP item builds on that foundation.
  • Re-enable the Additional wallets UI in /wallet/settings once multi-wallet selection is in scope.
  • Add an invoice-level wallet selector and migration guidance for existing invoices.
  1. Quotes + quote-to-invoice conversion
  • Treat quotes as proposal documents and invoices as billing documents; do not collapse both concepts into one shared lifecycle.
  • Keep quote status and invoice status as separate fields so proposal progress and billing/payment progress are modeled independently.
  • Initial direction: quote lifecycle draft, sent, accepted, declined, expired; invoice lifecycle keeps its own unsent, sent, pending, partial, paid, void states.
  • Converting an accepted quote into an invoice should create a linked billing record whose invoice lifecycle starts at unsent.
  • During future spec work, decide whether quotes and invoices share physical storage or use separate tables, but preserve clear quote/invoice identity and relationship history either way.
  1. Client balance tracking + credits
  • Track per-client credit balances that can be issued manually (refunds, overpayments, goodwill adjustments) and applied to future invoices.
  • Show each client’s net outstanding balance as: total open invoice balances minus unspent credit balance.
  • Surface an issuer-facing ledger so credit issuance, application, reversal, and remaining credit are auditable over time.
  1. Spending-only companion wallet ecosystem idea
  • Separate product idea, not open-beta scope for CryptoZing itself.
  • Explore a companion wallet app that can spend/send but does not receive, and only shares public derivation material with CryptoZing.
  • Goal: reduce accidental outside receive activity on the same account namespace while keeping CryptoZing watch-only.
  • Future direction to evaluate later: whether a tighter CryptoZing + companion-wallet pairing should be encouraged or even required in a future product generation.
  1. Wallet balance display (settings + beyond)
  • Show the connected account's on-chain balance on the wallet settings page, derived from the watched xpub.
  • Evaluate other surfaces where the balance is worth showing (dashboard, elsewhere) — keep the watch-only framing clear wherever it appears.
  • At implementation, decide where/whether to place a pointer to the /help#gap-limit note near balance displays — a balance readout is where gap-limit confusion becomes visible.

Authentication & Security

  1. Passkey (WebAuthn) authentication
  • Add passkey / WebAuthn (FIDO2) support: platform authenticators (Touch ID, Windows Hello, Android) and roaming security keys (e.g. YubiKey). Phishing-resistant, unlike the TOTP and emailed codes shipped in MS19 Phase 9.
  • First pass is a second factor in the shared login challenge alongside the authenticator-app and email methods; extend method precedence and the "one primary at a time" switch to include passkeys.
  • Reuse the emailed-code fallback as the recovery path (no separate recovery codes), and extend the wallet-xpub step-up re-verification to accept a passkey assertion.
  • Server side via a maintained PHP/Laravel WebAuthn library; store credential id, public key, signature counter, and transports per user (new one-to-many table). Needs a stable Relying Party ID + HTTPS; include signature-counter clone detection.
  • Later track: passwordless login (passkey as primary factor) once second-factor passkeys ship.
  1. Mandatory 2FA after open beta
  • Once out of open beta, 2FA stops being opt-in: no account reaches the app without a second factor enrolled.
  • New accounts enroll during signup; existing accounts hit a forced enrollment gate at next login until they finish.
  • Any enabled method satisfies the requirement — emailed codes are the floor, TOTP (and later passkeys, item 26) the stronger options. Disable becomes a method switch rather than an off switch.
  • Retire the MS19 Phase 9 dashboard recommendation banner — nothing left to nudge.

Legal & Policy

  1. Post-beta ToS/Privacy framing removal (#120)
  • Once out of beta: drop the beta framing (beta-software labels, low-stakes recommended-use language) from the ToS and Privacy Policy; retain the operator disclaimers.
  • Same pass: align the ToS preamble's recommended-use phrasing with the signup disclaimer wording (per note on #120), keeping the ToS the fuller of the two.

Monetization

  1. Fiat donations
  • Add a fiat path to the donation page (MS19 Phase 8 ships BTC-only; see docs/strategies/x19.8_MICRO_MONETIZE.md).
  • Requires a payment processor and business banking to land/convert funds.
  • Revisit once donation-page traffic or user requests suggest demand; fiat in scope likely means its own milestone.
  1. Per-transaction fee vs. published fee criticism (content promise 1.1)
  • Before shipping any per-transaction fee: revisit the criticism of processors "taking a cut they expect you to absorb" in learn/accepting-bitcoin-payments-freelancer-small-business.md:17 in n8bar/cryptozing-site — see CONTENT_PROMISES.md Major 1.
  • Options, decided at that time: make the fee structurally different (customer-visible or non-per-transaction, e.g. subscription/freemium); narrow the criticism in the article; or retire the article and publish an updated replacement as part of the monetization effort.