Then nip-39 should have extended or deprecated nip-05, which is not the case. It is a simple birds of a feather issue. We are talking about nip-05 and the associated design, nip-39 is a different design not even mentioning nip-05 or referencing it as a use case. Nip-05 should be extended to include this, nip-39 is not suitable as it adds unnecessary complexity to a simple task. The only reason to suggest it is to push off an idea that might have consequences to your personal take.

Replies (2)

It is responses like these that make me want to offer a discount to any user migrating from nostr.land, vs having an ecosystem where each registrar would have purpose and many would be adopted for users to use for their use cases. Your obvious conflict of interest is not seeing that it is better to not fight for users, but offer unique value to them to attract their business across offerings. It is better to embrace the logical and optional addition to nip-05 and let users have more flexibility in the setup of providers. I do not want to approach it in a hostile way, I want synergy. But without the synergy, it is clear who the competition is and easy to identify the actors preventing the synergy.
NIP-39 did not deprecate NIP-05 because NIP-05 is a way of having Nostr identifiers while NIP-39 is a way of *listing* identifiers. If you view using a tag which is standard convention to list NIP-05 IDs as “unnecessary complexity” and prefer a JSON field (the usage of which is being phased out) then I don’t know what to say.