add nip05 and lud16 as optional metadata fields.

[unclebob]

These seem to be the names of the damus fields. I use them in more-speech and they seem to cooperate with damus.

[fiatjaf]

The nip05 field is specified on NIP-05, lud16 and lud06 are specified on NIP-57, but there are many other fields people have been using, like display_name, website. I don't think we should shove them all into NIP-01.

[Egge21M]

The nip05 field is specified on NIP-05, lud16 and lud06 are specified on NIP-57, but there are many other fields people have been using, like display_name, website. I don't think we should shove them all into NIP-01.

While I agree that kind-0 metadata fields can and should be extended arbitrary by clients if they see fit, it definitely makes sense to have a list of most adopted key-value pairs as best practices. It would make implementation easier for new clients (when we started out we were sifting through events to get them right). This could be a separate NIP though.

Edit: We could even defined rules around this e.g., "have to be implemented by at least X clients to become part of the list". Although that seems overkill for a non-breaking thing

[alexgleason]

This is all NIP-57 says regarding the lud06 and lud16 profile fields, so it would be good to add more information to NIP-57:

[fiatjaf]

I think the best approach is probably to create a NIP listing all possible fields that may go on a kind:0 event aside from the three that are specified in NIP-01.

On the other hand, I think we shouldn't encourage people to add more fields there for more specific use cases, it is better to create new event kinds only for these use cases. The Bitcoin stuff, for example, would better live on a specific kind that only Bitcoin-enabled clients would fetch and others would never touch.