Skip to content

Conversation

@mfw78
Copy link
Member

@mfw78 mfw78 commented Dec 8, 2025

Summary

  • Define storage-aware metadata schema for Nexum identities
  • Protocol Buffers schema with Version Manifest as root
  • Storage unit separation by update frequency (identity metadata, accounts, preferences, contacts)
  • Account registry with native/provider discriminator using oneof for extensibility
  • Identity metadata, preferences, and contact management structures
  • Per-account signature audit trails for O(1) lookup/append operations

Context

NXP-3 defines the data structures for identity metadata. It's designed with storage efficiency in mind, separating data by update frequency so that frequently-changing data doesn't require re-uploading static data.

Key design decisions:

  • Uses oneof with messages for account type discrimination (NativeAccount vs ProviderAccount)
  • Provider accounts integrate provider_type and config directly in the message
  • Swarm references used for images (64 bytes encrypted refs)
  • No explicit size limits (implied by storage layer)

Closes nxm-rs/nexum#88
Related to nxm-rs/pm#3 (EPIC 0.0)

Test plan

  • Verify Zola builds successfully
  • Review Protocol Buffers definitions for correctness
  • Confirm storage unit separation makes sense
  • Verify oneof usage for account types

Define storage-aware metadata schema for Nexum identities:
- Protocol Buffers schema with Version Manifest as root
- Storage unit separation by update frequency
- Account registry with native/provider discriminator using oneof
- Identity metadata, preferences, and contact management
- Per-account signature audit trails for O(1) lookup

Closes nxm-rs/nexum#88
Related to nxm-rs/pm#3 (EPIC 0.0)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

docs: design metadata schema

2 participants