Files
amethyst/commons
Vitor PamplonaandClaude Opus 5 94bc8864d6 feat: render shards, the objects hidden at a place (kind 3330)
DECK-0003 §3.2 is two containers for one format, not two formats, so a
shard reads through the same parser and draws through the same card as a
standalone object. SnoShardEvent adds the container and the C-tag
coordinate claim and delegates every rule to SnoParser.

What is not implemented is opening a bag. A shard published today is an
item inside a kind 33330 bag whose payload is AES-256-GCM ciphertext
keyed to a cyberspace region, so reading one means §2 coordinates, §7.2
key derivation and §7.4 discovery scanning — the protocol, not a
renderer. §7.6 is explicit that a failed decryption is not an error in
the bag.

A reader for the pre-deck tag form was written and then removed. Every
3330 publicly reachable on a relay predates the deck: 21 events, one
pubkey, all inside one minute on 2025-01-16, empty content, geometry in
vertices/colors/indices tags. Rendering the corpus showed what the
decoder bought — one black triangle and one black dot, two shapes across
21 events, every colour 0,0,0 — against the cyberspace readme saying v1
drafts "are not a valid basis for new implementations". Reverse-
engineering a deprecated encoding no current spec describes was not worth
that, so it went.

The consequence, stated rather than discovered later: no publicly
reachable 3330 renders today. The current ones are sealed in bags and the
old ones are v1.

Note the two unrelated version numbers. The payload's own `v: 1`
(DECK-0003 §2) stays supported because the deck requires it — "a reader
MUST support both" — and is the SNO format's version, not Cyberspace v1.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JwXApJjoZYtkD3sPRWbPNa
2026-09-22 00:09:34 +00:00
..