Expand description
The module boundary (first-party registry track §3.4): a plain C ABI, no
wasm-bindgen, so the build is one .wasm file and no glue.
alloc(len) -> ptr reserve `len` bytes of linear memory
dealloc(ptr, len) release a buffer from `alloc` or a result
admit(ptr, len, exp_ptr, exp_len) -> u64
call(ptr, len) -> u64 a JSON request in, a JSON result outadmit takes the upload archive at ptr..ptr+len and, optionally, the
expected package as JSON at exp_ptr..exp_ptr+exp_len ({"name":"o/p", "version":"1.0.0"}; zero length means none). It returns ptr << 32 | len
of a UTF-8 JSON result in linear memory, which the caller reads and then
frees with dealloc:
{"ok":{"name","version","checksum","deps":[{"package","range"}],
"npm":[…],"archive":"<standard base64>"}}
{"error":{"code","message"}}call (first-party registry R2, #2336, decision B) takes a JSON request
{"op": …, …} and returns a JSON result the same way, so the hosted
registry signs exactly the bytes clients verify:
{"op":"line_payload","line":{name,version,checksum,deps,npm,toolchain},"registry":"<id>"}
-> {"ok":{"payload":"<base64>"}} the canonical bytes a line's signature covers
{"op":"line_render","line":{…,"yanked":bool,"withdrawn"?:"<reason>","sig":"<base64>"}}
-> {"ok":{"text":"<one index line>"}}
{"op":"signer_info","config":"<config.json text>","key":"ed25519:…"}
-> {"ok":{"id","chain_key","delegated","delegation_payload","delegation_sig","revoked"}}signer_info does no cryptography: it reports the newest chain key, the
delegation of key (its payload and signature) and whether a revocation
names key, for the caller to verify with its own crypto.
admit_json is the whole of it as a safe function, so the native build
and the wasm module produce the very same bytes for the very same input.
Functions§
- admit_
json - Admit
uploadagainst theexpectedJSON (empty for none) and render the result as the boundary’s JSON. - call_
json - Answer one JSON request (
call); see the module docs.