mirror of
https://github.com/vitorpamplona/amethyst.git
synced 2026-10-06 03:38:23 +00:00
Claude
88fddce324
The Quartz half of the current profile was ready and tested; nothing in the app layer called it. KeyPackage publishing now defaults to the current profile, which is the half that decides whether anyone running the adopted spec can invite us at all — a leaf without the 0x8009 account identity proof is simply not addable to a current-profile group. `createCurrentProfileGroup` builds the group through `CurrentProfileGroupFactory` and hands it to the manager via `adoptGroup`. Group creation is the one place a group cannot be built through the manager: a leaf's identity proof covers its OWN signature key, so the keypair has to be generated and authorized by the account signer before the leaf exists. Switching the KeyPackage path surfaced the mirror image of the bug this whole effort started from. A current-profile leaf advertised only the draft app_data_dictionary extension, and a legacy group REQUIRES 0xF2EE — so our new KeyPackages were un-addable to every group that already exists. Capabilities say "this client can handle it", not "this group uses it", so the leaf now advertises both. Advertising more than a group requires is always fine; advertising less is what gets a leaf rejected. The reference-shape test now states that rule rather than asserting byte-equality with MDK's leaf. The current-profile KeyPackage event also carries neither a `relays` nor an `encoding` tag, both per transports/nostr.md: a KeyPackage is fetched from the account's own inbox relay set, so repeating the relays would be a second drifting source of truth, and the binding forbids `encoding` outright because a receiver that switched decoders on one could be steered into a different parse of the same bytes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016kCuA6tc4JQzHPCDd39GHq