With this NIP a user can grant fine-grained decryption permissions to an app because this spec enables the NIP-07/46/55 signer to show a detailed permission dialog to the user such as "example.com is asking to decrypt edit keys of the spreadsheet My Clients"
A label is added when encrypting with NIP-44 to help the signer show a more detailed permission dialog to its user.
The label is a JSON with optional keys as follows:
{
isRestricted: true, // default is false
code, // A string ending with a _[^_]+ pattern, e.g. "ADMIN_KEY_107febac73685", that is defined on each NIP
kind, // The kind of the event where the ciphertext will be placed
pubkey, // The pubkey of the event where the ciphertext will be placed
// The event unique identifier (last portion of the ANIP-01 "U" tag),
// e.g. "d71238929173", from a "d" tag set to 71238929173. Adding
// a "d" or "dd" tag to the event is required
uid
}
The isRestricted
label flag when true means the signer shouldn't allow the app to access the plaintext directly,
i.e. the nip44.decrypt("...", "<ciphertext with isRestricted=true label flag>")
signer method call MUST fail.
When encrypting, the signer adds some strings to the plaintext like this:
#!N3r <plaintext>`<isRestricted ? 1 : 0>:<code, optional>:<kind, optional>:<pubkey, optional>:<uid, optional>
.
If the plaintext contains ´
chars, escape them with a preceding -
.
Example: #!N3r red-´grape´0:FRUIT_9d10d210f580d:123:abc..def:d1265721
.
Encryption example: const ciphertext = await nostr.nip44.encrypt("<peer pubkey>", "red´grape", label)
When decrypting, the client may pass events it deems useful as context for the signer to extract even more detail.
The context is an array of nostr events, e.g. [{<some nostr event>}]
Decryption example: await nostr.nip44.decrypt("<peer pubkey>", "<ciphertext>", context)
Gift-wraps and seals upon .content
decryption reveal their inner event kinds. That is, if
a decrypted data doesn't have a "#!N3r "
prefix, the signer should
fallback to JSON.parse(plaintext)
, check if it is a seal or rumor
and possibly use its kind to assist the user with a more detailed permission dialog.
Fine-grained decryption permissions for apps reduces the damage an app can do. However, chat messages have open-ended scopes.
Prefer using a trusted client that is solely a messenger or a trusted signer that has the single extra feature of also being a messenger.