That doesn't answer my question at all.

Is the decision (regardless of who fucking decides) based on metadata attached to the key the client controls or from a breadcrumb included in the message itself?

▲

vnuge 4 days ago | parent | next [-]

We are obviously speaking from different understandings. I would say neither. I would need you to define your terms differently maybe.

In all cases the client application chooses the algorithm used when the user writes a DM. What do you mean by breadcrumb in the message. Message in what context? Message sent to the signer?

Edit: Maybe I should say the client developer? Is that the answer you're looking for? The developer _could_ give the user the option of choosing which to use, but clients generally are hard-coded to use one or the other.

▲

duskwuff 4 days ago | parent | prev [-]

I think that the (unsatisfying) answer is that there's no established standard for how protocol selection works. nip04 and nip44 are completely different types of messages, and it's up to the client how it'll use and/or respond to them.

	▲	vnuge 4 days ago \| parent \| next [-]
		I guess it's worth also saying, there is no algorithm selection. Nip04 is dead for DMs. It doesn't need to be backward compatible. A user can't know which client another user is on, nor what their capabilities are, nostr is not smart in that way. Most, if not all, operations on nostr are completely stateless. When a user decides to send a DM to another user, the client must choose the standard for encryption, and message wrapping. Then hope the other user is using a client that implements the same standard, in order to decrypt the message. Again, remember, DMs don't have a session. Every message derives a new symmetric key. The only metadata that makes a "chat" session is the timestamp, and the public keys of the users.
	▲	vnuge 4 days ago \| parent \| prev [-]
		Kind of. They are standards for encryption, not the direct message itself. You'd be speaking about nip17. Which i've been mis-speaking as nip19. https://github.com/nostr-protocol/nips/blob/master/17.md Notice that nip44 IS the standard. again, nip04 is deprecated, and should be treated by clients as such.