Keysat
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.4 KiB
TypeScript
14 lines
1.4 KiB
TypeScript
import { VersionInfo } from '@start9labs/start-sdk'
|
|
|
|
export const v_0_2_124 = VersionInfo.of({
|
|
version: '0.2.124:0',
|
|
releaseNotes: {
|
|
en_US:
|
|
"Frontend half of the pipelined-analyze work that ships in relay v0.2.89. Browser handler for transcript_ready no longer wipes state.chunks unless the videoId changed — this preserves partial sections that arrived earlier via sections_partial in pipelined mode. The relay-mode branch in server/index.js now emits transcript_ready EARLY (from the first onWindowComplete or from onTranscribeComplete, whichever fires first) so the browser flips from loading view to results view in time to render the streaming partial sections. SDK provider/relay.js forwards a new `windowEntries` field on the window_complete callback — in pipelined mode each window arrives with its own bracketed entries embedded; sequential mode keeps falling back to the global streamedRelayEntries cache. Net effect: when summarizing a 94-min video through a v0.2.89+ relay, the first topics now render at T~80s instead of T~160s — the loading-screen → results-view transition + first chunks landing happen DURING transcribe instead of after it. Older relays keep working — pipelined fields are absent and the existing sequential code path takes over.",
|
|
},
|
|
migrations: {
|
|
up: async ({ effects }) => {},
|
|
down: async ({ effects }) => {},
|
|
},
|
|
})
|