Add Kind 15 for Encrypted File message

[water783]

File Message Kind

{
  "id": "<usual hash>",
  "pubkey": "<sender-pubkey>",
  "created_at": "<current-time>",
  "kind": 15,
  "tags": [
    ["p", "<receiver-1-pubkey>", "<relay-url>"],
    ["p", "<receiver-2-pubkey>", "<relay-url>"],
    ["e", "<kind-14-id>", "<relay-url>", "reply"], // if this is a reply
    ["subject", "<conversation-title>"],
    ["file-type", "<file-mime-type>"],
    ["encryption-algorithm", "<encryption-algorithm>"],
    ["decryption-key", "<decryption-key>"],
    ["decryption-nonce", "<decryption-nonce>"]
    // rest of tags...
  ],
  "content": "<file-url>"
}

Kind 15 is used for sending encrypted file event messages:

• file-type: Specifies the MIME type of the attached file (e.g., image/jpeg, audio/mpeg, etc.).
• encryption-algorithm: Indicates the encryption algorithm used for encrypting the file. Supported algorithms may include aes-gcm, chacha20-poly1305,aes-cbc etc.
• decryption-key: The decryption key that will be used by the recipient to decrypt the file.
• decryption-nonce: The decryption nonce that will be used by the recipient to decrypt the file.
• content: The URL of the file (<file-url>).

[water783]

@vitorpamplona @staab Do you have any suggestions for this proposal? This allows us to send encrypted files in DMs

[mikedilger]

Since this is inside a seal and giftwrap, it is already encrypted. But that is OK if the content is at some URL encrypted under any other encryption algorithm. What doesn't make sense to me is base64 data in the content, since that double encryption doesn't seem necessary. Maybe just to have a different algorithm?

Also the 'p' tags can't be looked up since they are inside the encrypted giftwrapped seal. So I'm not sure what they are for.

[vitorpamplona]

So I'm not sure what they are for.

They are there to define which NIP-17 group of users this image belongs to. It's similar to how kind 14 gets is group definitions.

[water783]

Since this is inside a seal and giftwrap, it is already encrypted. But that is OK if the content is at some URL encrypted under any other encryption algorithm.

For private chats, file content encryption is essential. Otherwise, with only URL encryption, the file could still be visible to the file server, and if the URL is leaked or indexed, it could also be accessed by others.

If I remember correctly, Signal uses the AES-GCM algorithm to encrypt file content? I think @erskingardner might also be interested, especially considering NIP-104, where file encryption could be added as well?

What doesn't make sense to me is base64 data in the content, since that double encryption doesn't seem necessary. Maybe just to have a different algorithm?

Ah yes, that’s right. Base64 placed in the content is encrypted through giftwrap, so there’s no need for additional double encryption.