SeedPass/docs/nostr_comms_reference_and_future_capability_2026-03-05.md

Nostr Communications Reference and Future Capability (2026-03-05)

Status: Research / Future Addition
Branch target: beta
Depends on:

• docs/dev_control_center.md
• docs/index0_atlas_execution_plan_2026-03-05.md
• docs/atlas_search_graph_integration_plan_2026-03-05.md

1) Goal

Capture the Nostr protocol references most relevant to a future SeedPass communications layer, then define how a managed-identity communication system could fit the current SeedPass architecture.

This document is for future implementation planning, not a statement of current shipped functionality.

2) Current SeedPass Baseline

SeedPass already has enough Nostr groundwork to make this future capability realistic:

1. deterministic Nostr key generation and storage as entry kind nostr
2. relay configuration and relay maintenance flows
3. active profile npub utilities
4. a current Nostr client used for SeedPass vault sync
5. index0 atlas foundations for future communication metadata and navigation

What SeedPass does not currently have:

1. DM inbox/outbox/thread models
2. community or group chat clients
3. canonical message/conversation entry types
4. communication indexing into atlas/search
5. policy-aware communication access controls in the UI/service layer

3) Protocol References

Use these NIPs as the canonical starting points.

3.1 Private messaging

1. NIP-04 Encrypted Direct Message

   • legacy kind:4 DM scheme
   • explicitly marked as deprecated in favor of NIP-17
   • uses ECDH-derived shared secret plus AES-256-CBC payload format
   • carries significant metadata leakage warnings
   • reference:
     • https://github.com/nostr-protocol/nips/blob/master/04.md

2. NIP-44 Encrypted Payloads (Versioned)

   • encryption format, not a messaging standard by itself
   • versioned payload format intended for signed-event contexts
   • should not be treated as a direct drop-in replacement for NIP-04
   • reference:
     • https://github.com/nostr-protocol/nips/blob/master/44.md

3. NIP-59 Gift Wrap

   • metadata-obscuring event encapsulation layer
   • introduces rumors, seals, and gift wraps
   • depends on NIP-44
   • does not itself define the messaging UX/protocol
   • reference:
     • https://github.com/nostr-protocol/nips/blob/master/59.md

4. NIP-17 Private Direct Messages

   • newer encrypted chat approach
   • uses NIP-44 encryption and NIP-59 seals/gift wraps
   • defines the direction SeedPass should prefer for future private DM support
   • reference:
     • https://github.com/nostr-protocol/nips/blob/master/17.md

3.2 Group and community chat

1. NIP-28 Public Chat

   • public channel model
   • reserves event kinds 40-44 for channel create/metadata/message and basic moderation
   • useful as a baseline for open team channels or public-facing communities
   • reference:
     • https://github.com/nostr-protocol/nips/blob/master/28.md

2. NIP-29 Relay-based Groups

   • closed-writer group model with relay-enforced rules
   • groups can be public or private for reading
   • strong candidate for institution/team chat semantics where relay policy matters
   • reference:
     • https://github.com/nostr-protocol/nips/blob/master/29.md

3. NIP-72 Moderated Communities (Reddit Style)

   • public community model
   • defines kind:34550 community definition and kind:4550 approval events
   • likely more relevant for public communities than for private institutional chat
   • reference:
     • https://github.com/nostr-protocol/nips/blob/master/72.md

4) SeedPass-Oriented Interpretation

For SeedPass, the most relevant practical stack is:

1. private managed DMs:
   • NIP-17 + NIP-44 + NIP-59
2. public/open channels:
   • NIP-28
3. controlled team/group chat:
   • NIP-29
4. public community publishing/moderation:
   • NIP-72

This means:

1. do not build new private DM support on top of NIP-04 unless compatibility mode is required
2. treat NIP-04 as legacy interop
3. prefer NIP-17 for future direct-message architecture
4. evaluate NIP-29 as the strongest candidate for managed institutional group chat

5) Managed Identity Model

SeedPass has a unique advantage here because it can deterministically derive managed child identities.

If a Nostr identity is a managed deterministic child account:

1. the child user can operate that identity normally
2. an authorized higher-level SeedPass holder can derive the same child identity again
3. that higher-level holder can regenerate the same Nostr private key
4. supervisory recovery/access follows from key custody, not from a separate escrow system

This implies two communication classes should exist in the future:

1. personal identities
   • user-owned
   • not intended for management derivation/access
2. managed institutional identities
   • org-controlled
   • derivable by authorized higher-level key holders
   • eligible for institutional indexing, search, and oversight

6) How This Fits index0

index0 should not store full communication bodies inline.

Recommended split:

1. canonical message or conversation content:
   • future entry kinds or encrypted conversation/message payloads
2. index0 atlas metadata:
   • account created
   • conversation created
   • participants
   • channel/community membership metadata
   • last activity
   • message counts
   • linked documents/artifacts
   • policy/classification/visibility metadata
3. local semantic layer:
   • derived search over message bodies and linked content

That preserves the atlas role:

Index0 is the map, not the message store.

7) Recommended Future Capability Scope

Phase A: Managed Nostr account workspace

1. load a SeedPass Nostr entry into an active comms session
2. show identity metadata, relay state, and conversation summaries
3. expose public posting and account-session controls

Phase B: DM dashboard

1. inbox
2. conversation list
3. thread view
4. send/receive support for managed identities
5. atlas metadata indexing for conversations and message activity

Preferred protocol direction:

1. NIP-17
2. NIP-44
3. NIP-59
4. optional NIP-04 compatibility only if needed

Phase C: Institutional team chat

1. managed group/channel model
2. likely protocol evaluation centered on NIP-29
3. optional public/open channel support using NIP-28
4. public community support later via NIP-72 if needed

Phase D: Knowledge integration

1. link conversations to docs, secrets, tasks, and artifacts
2. surface chat activity in index0
3. unify search across notes, docs, links, and comms
4. support scoped agent context loading from conversations plus linked artifacts

8) Access Control Direction

Future communication access should remain policy-driven and consistent with SeedPass hierarchy.

Recommended rules:

1. managed institutional identities are readable by authorized higher-level key holders who can derive the same child identity
2. personal identities are not treated as institutionally recoverable by default
3. UI and service layers should make identity class explicit
4. search, export, summaries, and agent access must respect classification and partition policies
5. message excerpts shown in search/atlas should be safe by default, especially for high-risk scopes

9) Open Design Questions

Resolve these before implementation:

1. should full message bodies be stored as dedicated entry kinds, chunked conversation documents, or both?
2. should SeedPass mirror only managed-identity communications into canonical vault storage, or also index external/public references?
3. how should relay/group policy state be represented for NIP-29 groups?
4. what is the minimum safe atlas metadata for private institutional conversations?
5. what should agent access look like for communication content versus conversation summaries?

10) Practical Recommendation

The best future direction appears to be:

1. NIP-17 private DMs for managed identities
2. NIP-29 for controlled team/group chat
3. NIP-28 and NIP-72 as optional public/community layers
4. index0 for metadata, navigation, and oversight
5. separate canonical storage for actual message content

11) Source Links

Primary sources used for this reference:

1. NIP-04:
   • https://github.com/nostr-protocol/nips/blob/master/04.md
2. NIP-17:
   • https://github.com/nostr-protocol/nips/blob/master/17.md
3. NIP-28:
   • https://github.com/nostr-protocol/nips/blob/master/28.md
4. NIP-29:
   • https://github.com/nostr-protocol/nips/blob/master/29.md
5. NIP-44:
   • https://github.com/nostr-protocol/nips/blob/master/44.md
6. NIP-59:
   • https://github.com/nostr-protocol/nips/blob/master/59.md
7. NIP-72:
   • https://github.com/nostr-protocol/nips/blob/master/72.md