This NIP builds on the encryption from NIP-44, the gift-wrap of NIP-59 and the distributed chat channel management of NIP-28. It is similar to NIP-38, with the exception that gift-wrap is used on every message, and issues like metadata leakage and optional forward secrecy are addressed.
In the channel creation `content` field, Client SHOULD include basic channel metadata (`name`, `about` and `picture`).
This is akin to NIP-28, kind 40 but using gift-wrap encryption.
On creating a channel, the creator MUST also generate a unique/new private-public key pair which will serve as the `shared-secret` for a given channel.
The wrapped INNER event id for the channel creation should be saved. This is the event id that will be used in all future INNER references to the channel creation.
Channel creation events MUST be sent to the "destination pubkey" of the channel itself, not to any specific user.
As a rule, this "destination pubkey" of the channel MUST used as the sole identifier and external filter that clients use to retrieve events for the channel.
There are no other public tags or metadata, all other kinds and tags are "inner" (inside the wrapped message).
## Wrapped Kind 401: Invitation to Encrypted Channel
Invitations are sent directly to the participants of the channel.
When wrapping invitation messages, the destination pubkey is the user being invited, not the pubkey of the channel. The relay used should be one of that user's well-known relays.
More than one relay can be recommended in the "e" tag.
## Wrapped Kind 402: Change channel metadata
Update an encrypted channel's public metadata.
Clients and SHOULD handle wrapped-kind 402 events similar to kind 33 `replaceable` events. Relays cannot distinguish this from other kind 1059 events.
Clients SHOULD ignore kind wrapped-402 from pubkeys other than the current owner.
The current owner of a channel is the pubkey that created the given channel using the corresponding wrapped-kind 400 event, or the current owner based on the 405-406 channel ownership delegation flow.
In other words, only the owner of a channel can *effectively* send kind wrapped-402 events; kind 402 for any channel sent by other people, even participants of that channel, are ignored.
Clients SHOULD support basic metadata fields:
-`name` - string - Channel name
-`about` - string - Channel description
-`picture` - string - URL of channel picture
Clients MAY add additional metadata fields.
Clients MUST specify an "e" tag to identify the channel id.
Clients SHOULD ignore wrapped-kind 404 messages from anyone but the current owner of a group.
Clients SHOULD ignore messages to the previous group that occur after their receive the first kind 404. In addition there is no longer a need to subscribe to the public keys of prior groups.
Clients use kind 404 to find out which was the precursor channel(s) to this new channel, and should attempt to display all old and new channels in a chain seamlessly to the user as a unified channel history.
Clients SHOULD consider the new channel metadata as authoritative.
Clients MAY discard previous channel information, since it will no longer be used.
Clients SHOULD ignore wrapped-kind 406 messages unless they are signed by the delegate in the associated 405 message
Clients SHOULD treat accepted delegates as the new owner of the group for all 404 and 405 messages.
## NIP-10 relay recommendations
For [NIP-10](10.md) relay recommendations on replies and on channel creation info, clients generally SHOULD use the relay URL where the event was first seen, if known.
This is the easiest way to allow the use of group events with select group of people, while hiding metadata, and preserving nostr's censorship resistence.
Claims of "forward" secrecy in mobile applications can be disingenuous. Many mobile applications allow users to purchase a new phone and restore their account with historic messages intact - therefore this is not forward secrecy.
True forward secrecy relies on servers reliably discarding the intermediate data - in addition to frequent key rotations, or prev-key ratcheting. A trusted server, for example, can be requested to discard old messages, by adding an optional NIP-40 expiration.
### OPTIONAL forward secrecy extension
The owner of a channel can add a "expiration" tag to the channel creation message.
The owner of a channel who adds a "expiration" tag SHOULD issue a 404 message before the expiration.
All members of a channel SHOULD also add a NIP-40 "expiration" tag to all messages sent to the channel using the duration (`expiration - created_at`) of the wrapped-400 create.
Members of a channel MUST NOT send new messages if a 404 message has not been received before expiration.
Servers SHOULD obey NIP-40 expiration tags.
Provided that servers obey NIP-40 expiration tags, this will prevent an attacker from reading old group messages before the expiration.
Drawbacks
---------
Any member of the group can, implicitly, invite new members to the group, since they have the private key. Any member of a group can "dox" other members by publishing their wrapped messages.
Any member of the group can spam the group, or otherwise DOS the group.
If any single participant of the group chat leaks the shared secret ( whether intentionally or by accident), all the messages can then be decrypted by others until the next 400 and 404 rotation events.
