The first profile of the Traceable Collaboration Core (companion document). It fills the Core’s three open slots for audio: asset metadata, the DAWproject composition format, and the Web Audio Modules transform runtime.

NAPI — Audio Profile of the Traceable Collaboration Core

The first profile of the Traceable Collaboration Core (companion document). It fills the Core’s three open slots for audio: asset metadata, the DAWproject composition format, and the Web Audio Modules transform runtime.

Contributors & disclaimer

npub1gek0f5s300jzqg4av4e7l4hfejrrkhzf8km2pkuquhfmja6gwdcqw4qqp7 — originator and lead. The concept and all the directional calls: the song-tree model, the fork / pull / merge flags, studio-over-protocol, the “traceable collaboration framework, audio as a profile” reframe, and the two-document split.
Claude (Anthropic — Claude Opus 4.8) — research and technical drafting under that direction: Nostr and audio-ecosystem research, the schema and tag proposals, and the editing of the final document.

This is an AI-assisted working draft, shared for discussion — exploratory, not authoritative. Kind numbers are provisional and unregistered; external standards and NIP references should be verified independently; nothing here is legal advice. (Fittingly for a spec about traceable provenance, it declares its own.)

Status: working draft · v0.3 · all kind numbers are provisional · builds on: Traceable Collaboration Core v0.1

Abstract

NAPI makes music projects portable and forkable across apps — the “GitHub-of-music” idea — as a thin audio profile over the Core. It inherits the Core’s Asset, Transform, Node, derivation tree (the “song tree”), growth flags, contributions, and graceful-degradation, and adds only what is audio-specific. A song grows as a public tree of signed, content-addressed Nodes; any app can resolve, rebuild, and re-render any node, and every fork’s authorship and lineage are verifiable. This document defines the three audio fillings; for everything else, see the Core.

Locked decisions (audio profile):

Genre-neutral. Serves loop/beat producers, full-song bands, and film/TV/game post. Roles are an open string; the timeline carries both musical time and an optional timecode anchor (§3).
Instrument tracks travel as editable MIDI + a device reference — not printed audio — with a mandatory frozen-audio fallback per instrument track (§3, §6).
(Async / immutable snapshots are inherited from Core §1.5, not redefined here.)

0. What this profile fills

Mapping the Core’s three slots (Core §3) onto audio:

|Core slot |Audio filling |Section| |------------------|-------------------------------------------------------------|-------| |Asset metadata |sample rate, bit depth, channels, BPM, key, LUFS, loop points|§1 | |Composition format|DAWproject session, content-addressed references |§3, §4 | |Transform runtime |Web Audio Modules (WAM v2) |§5 |

Everything else — Node, lineage/tree, flags (fork/pull/merge), Contribution/Status, Render — is used exactly as the Core defines it. NAPI does not redefine those.

1. Audio Asset (fills the Asset-metadata slot)

A Core Asset (NIP-94 profile, kind 1063) with required audio fields. Keyed by blob hash.

Required (in addition to Core url / x / m / size):

["duration", "<seconds>"]
["sample_rate", "48000"]
["bit_depth", "24"]
["channels", "2"]

Recommended:

["bpm", "120"], ["key", "A min"], ["bars", "4"]
["loop", "true"], ["loop_points", "<start_sample>", "<end_sample>"]
["lufs_i", "-14.0"] (integrated loudness, EBU R128)
["fingerprint", "<chromaprint or similar>"] — identity across re-encodes

2. Stem (addressable)

A musically meaningful artifact: a loop, a one-shot, or a small multitrack loop pack. References one or more Assets.

["d", "<stem-id>"], ["title", "..."]
["role", "<free string>"] — open vocabulary. Music: drums, bass, vocal, melody, fx, fullmix. Post: dialogue, foley, ambience, score, sfx. Suggest, never restrict.
["a", "1063:<pubkey>:..."] per Asset (a pack may bundle several)
mirrored bpm / key / bars for queryability
["license", "<spdx-or-cc-id>"] — machine-readable usage terms
["t", "<genre/tag>"] for discovery

3. Session (fills the Composition-format slot)

A Node’s composition reference (Core §4.3) points to a DAWproject session blob with format-id = dawproject. The session MUST express:

Time model (dual). Musical time is canonical: PPQ ticks over a tempo map (BPM + time-signature changes); absolute seconds derive from it. An optional timecode anchor — {smpte, frame_rate, anchor_tick} — pins the timeline to wall-clock for post-production sync. Both axes coexist: musical for producers, timecode for post.
Tracks: id, name, role (open string), type (audio | instrument), output/bus routing.
Audio clips (audio tracks): asset hash, source_in/source_out, timeline_in/timeline_out, gain, fades.
Note clips (instrument tracks): note events {pitch, velocity, start_tick, duration_tick, channel} + controller/automation lanes. MIDI carried as structured notes, not opaque SMF, so a fork is diffable and rebuildable (see §7).
Instrument device (instrument tracks): a requires_transform reference. The instrument renders notes → audio.
Insert chains: ordered Transform references with preset/parameter state.
Automation: parameter target + breakpoints (tick, value, curve).
Buses / sends and the master chain.
Frozen audio: a rendered blob hash of a track’s output — REQUIRED for every instrument track; SHOULD be present for heavily-processed audio tracks.

Per Core §1.2, all media and device references are content/identity addresses, never local paths.

4. Wrap DAWproject (this profile’s instance of Core §5)

Decision: wrap DAWproject (open, XML, music-DAW-native: tracks, devices, note clips, tempo map, automation). The Core’s two locked decisions force it:

Editable MIDI + instrument tracks → DAWproject natively models note clips, instrument devices, and automation. OpenTimelineIO does not (editorial audio/video clips only, no instrument concept), so OTIO is out despite nicer time math.
Async / immutable (Core §1.5) → a hashed XML blob is exactly right; no CRDT-native format needed.

For the genre-neutral / post case, layer the timecode anchor (§3) over stock DAWproject. Otherwise apply the Core’s two-step reference rewrite (Core §5): media → Blossom hashes, devices → {transform, version, bundle-hash} triples.

5. Plugin runtime (fills the Transform-runtime slot)

Audio Transforms are Web Audio Modules (WAM v2) — the open standard for browser audio plugins (instruments + effects with a host/plugin contract and parameter automation). A NAPI plugin is a Core Transform with:

["api", "wam2"]
["transform_type", "instrument" | "effect" | "preset"]
["bundle", "<sha256>", "<url>"] — the WAM bundle
["param_schema", ...] per Core §4.2

A plugin “store” is a relay query over Transform kinds filtered by transform_type / t. Hosts load the bundle from Blossom, validate against param_schema, and apply preset state from the session.

6. Reproducibility (audio specifics; extends Core §6)

Frozen instrument tracks are mandatory. Because instrument playback depends on the synth being resolvable, every instrument track MUST carry a pre-rendered output blob. An app without the synth still plays, slices, and arranges the frozen audio — editable-first, frozen-fallback. This is what stops a missing plugin from breaking a fork.
Latency metadata. Insert chains SHOULD declare reported plugin latency so a faithful rebuild can compensate (PDC) and line up with the published Render.

7. Open questions (audio profile)

Note-level session diffing. The audio leaf of Core §8.1: a useful “what changed in this fork” has to reason about note and clip changes, not just files.
Instrument substitution. When a forker swaps synth B for the original’s synth A, how do presets/params map? Likely they don’t auto-map — the forker re-voices and re-freezes — but a param-aliasing convention could help. Open.
MIDI carriage. Leaning structured note list (diffable) over embedded SMF (opaque); needs a final schema plus lossless SMF import/export for MIDI-file tooling.

8. NIP split (audio profile)

Builds on Core-1 (Asset/Transform/Node) and Core-2 (tree/flags/contributions):

NIP-Audio-1 — Audio Asset & Stem. §1–2. Standalone value for sample/loop sharing; seeds the content the rest depends on.
NIP-Audio-2 — Session. §3–4. DAWproject + content-addressed references + the dual time model.
NIP-Audio-3 — Plugins & presets. §5. The WAM-based developer market.

Ship NIP-Audio-1 first.