Co-create architecture and development plan
PROPOSAL FOR REVIEW · 13 October 2026 · Not an implemented or approved release specification
Build Porto as an open audio-upload and streaming app with voice and text editing. Anyone with an account can upload audio, add a title and artwork, and publish it to their profile or keep it private. Listeners discover uploaded originals and, where permitted, describe a change, receive a playable variation, and name, save and share it. Each variation preserves its source, parent and permission history. Eligible paid listening feeds the Porto Ledger and settlement on Aptos.
Open uploading is founder direction, 13 October 2026. Uploading does not require an artist partnership, manually selected catalogue or payout wallet. Accounts remain subject to upload limits and content rules. Public listening, other-user AI remixing, downloads and monetization have separate permissions; an uploaded file is not automatically cleared for all four.
The founder's current instruction is one shared audio model, conditioned on the original recording and the requested change. No artist-specific models, adapters, fine-tuning programme or training catalogue is required. This instruction supersedes the bespoke-model assumption in the website and deck for this development proposal. Artist permission still governs which tracks and edits are available.
ACE-Step 1.5 is the selected shared music model. Its exact checkpoint and inference settings will be pinned after testing uploaded-audio editing quality, latency and cost.
The smallest useful architecture is a frontend, one modular Porto backend, a durable job queue, an audio worker, one shared audio-generation model, PostgreSQL for product metadata, private S3 storage with CloudFront delivery, and an adapter to the existing Aptos Move contracts. Speech recognition and a small text-planning model translate the user's request into a validated edit plan. The music model produces music, rather than spoken narration.
Open the interactive architecture. The diagram shows the principal service relationships; the detailed request and playback paths are in Architecture.
| Read next | What it answers |
|---|---|
| Architecture | Components, request flow, storage, finance boundary and deployment |
| Audio model research | The selected ACE-Step model, checkpoint tests and exact versus generative edits |
| Data, APIs and reliability | Track lineage, jobs, endpoints, permissions and failure handling |
| Development plan | Work packages, estimates, ownership, dependencies and acceptance gates |
| Decisions and evidence | What is agreed, proposed, unverified or inconsistent with older sources |
What exists and what must be built
The current prototype demonstrates a persistent player, speech/text input, browser audio effects, local drafts, naming, genealogy, creator feeds, following, search, comments, a listening-budget walkthrough and illustrative royalties. These flows provide the product reference. Browser-local state, fictional accounts and displayed demo money must be replaced with authenticated server state and verified financial records.
The website's example, “Remove the guitar. Slow it down. Make it dreamy.” requires several capabilities. Tempo change is a precise processing operation. Removing an instrument is reliable when the artist supplies its stem; separation from a mixed master is approximate. Mood or arrangement change uses the shared audio model. One coordinated job can combine these operations.
Treat the existing Aptos payment contracts as an integration dependency supplied by the founder. This research reads the current Move specification, not contract implementation. Deployment, ABI compatibility, security and support for the October commercial rules must be verified before claiming that the integration is ready.
Recommended first release
Start with self-service account creation and audio uploads, processing/status feedback, public/private tracks, creator profiles, web playback, voice/text commands, deterministic edits, one benchmarked generative transformation, private drafts, lineage, explicit sharing, reporting and simple discovery. Use a permission-cleared sample set to test transformations, rather than restricting the product catalogue to manually onboarded artists. Add testnet accounting, then real paid listening after tariff, budget-cap funding, rights and payment gates pass. The full plan includes the remaining prototype flows without delaying the first working upload-to-audio loop.
The initial managed S3/CDN delivery proposal is a scoped change from the older independent-node pilot. It does not claim to implement node-to-node distribution. Older PRT, app-chain, subscription and operator-pool mechanics remain separately documented; they do not become requirements through this proposal.
Graph checked: 5 matches; source state: current; read cited sources before answering.
The graph check above records the initial research retrieval. Later direct source review and publication checks are recorded separately; a graph check does not prove a running system.