0ae59f3550
Introduces RECAP_MODE=multi alongside single-mode self-host: - Tenant auth + accounts (magic-link via System SMTP), per-tenant credit pool, anonymous trial minting with per-IP/-64 caps - Self-serve Pro/Max purchase: inline Lightning (BTCPay) + card (Zaprite), prepaid 30-day periods, expiry-reminder emails - Core-decoupling: relay owns cloud tier/expiry keyed by Recaps user-id - SQLite (better-sqlite3) schema for multi-mode; filesystem unchanged for single - StartOS actions/versions through 0.2.155
14 lines
1.3 KiB
TypeScript
14 lines
1.3 KiB
TypeScript
import { VersionInfo } from '@start9labs/start-sdk'
|
|
|
|
export const v_0_2_72 = VersionInfo.of({
|
|
version: '0.2.72:0',
|
|
releaseNotes: {
|
|
en_US:
|
|
'Server-side defensive title sanitization at the /api/process boundary. v0.2.71 fixed the title flow by changing the BROWSER code to send empty string when itemTitle is empty (instead of the "Untitled" sentinel). But a stale browser cache — or a future client variant — might still submit the literal string "Untitled" as the title, which would defeat the whole title-resolution chain (relay\'s yt-dlp fallback gate is `if (!title && audio.title)` which treats "Untitled" as truthy). Now: the moment `req.body.title` arrives at the Recap server, we trim whitespace and strip the value to empty if it equals "" OR (case-insensitively) "untitled". All downstream code (titleSurrogate, titleHintRaw passed to the relay, the saveToHistory fallback) can rely on "itemTitle is either a real title or empty" without checking for sentinel values. Net effect: even a browser running outdated SPA code submits "Untitled" → the server normalizes it to "" → the relay receives no title field → yt-dlp fallback fires → library entry gets the real title. Belt-and-suspenders for the existing v0.2.71 + relay 0.2.57 fix.',
|
|
},
|
|
migrations: {
|
|
up: async ({ effects }) => {},
|
|
down: async ({ effects }) => {},
|
|
},
|
|
})
|