The JS resolver plays a patch that pins a module somebody published themselves · Issue #1 · center.for.cybernetic.beauty/atmosynth-audio-engine

A page that plays patches with this package alone — resolvePatch from src/resolve.js, then the JS engine — refuses every patch that pins a module somebody published in their own account, even one made only of node kinds the engine already plays. The person sees an error naming the block ("… this engine plays only the modules built into ATMOSYNTH.") instead of hearing the patch.

That is the one place left that refuses them:

The spec says how a community module version is read: getRecord from its author's PDS, the record key being the versionKey (atmosynth-patch-spec/SPEC.md, the section beginning "There are two kinds of module").
The Rust resolver already does this (crates/resolve/src/lib.rs:9-14), and neither engine refuses an entry that is not a built-in once it is resolved (src/audio/validate.js only reads builtin and codeBearing).
src/resolve.js:83-92 throws for any authorDid other than the platform DID, and the file header (lines 8-9) and the README ("Built-in modules only, for now") say so on purpose.

It works against the guardrail that everything published can be played by an implementation that isn't ours: this package is how another app plays a patch in a browser.

What should be true #

A patch pinning a community module version plays through resolvePatch as one pinning built-ins does: the version read from its author's account, its samples from wherever its fills and defaults say.
A version that can't be read is refused with a PatchError that names the block and says why — gone, unreachable, or not a module — rather than one message for all three.
A module that carries code (a dsp node) is resolved and marked as such in the descriptor, the way the Rust resolver's descriptor says whether a patch runs community code; whether to play it stays the caller's decision.
The header comment and the README's line are changed with the behaviour.
Resolving the same patch in JS and in Rust gives the same modules, so the two resolvers don't disagree about what a patch is made of.

Fixed in 071d59f. resolvePatch reads a community module version from its author's PDS (getRecord, with the pinned version as the record key), and its default samples from the account that holds them. A version that can't be read is refused with a PatchError that names every block using it, and its reason says which way it failed: deleted, notFound, unreachable, refused or unreadable. A code-bearing module is resolved and marked codeBearing, and runsCommunityCode says whether any non-built-in one is; whether to play it stays the caller's. The header and README are updated. crates/render/tests/js_resolver.rs resolves one patch with both resolvers against the same accounts and checks that they produce the same modules, refuse for the same reasons, and render bit for bit the same.