NIP-24: Add User-Defined Custom Profile Fields

[alexgleason]

Ref: https://github.com/nostr-protocol/nips/pull/1590 https://github.com/nostr-protocol/nips/pull/1592 https://github.com/nostrability/nostrability/issues/132

Screenshots:

[vitorpamplona]

Looks good! I would just rename the example of avatar to picture since I don't think we actually have avatar on nostr.

[melvincarvalho]

Looks good. The only thing I'd say is that it's not future proofed, and clients should start to make it. For example for website we only have a single item allowed there, but it could be an array. So clients should parse an array with one item in it as though it was a single field. We learn this the hard way in solid. This will save a lot of headaches later on.

[melvincarvalho]

If going for a limited subset of "special" display fields, like mastodon, what about aligning the same name: "attachments"? (just thinking out loud here)

[barrydeen]

Nice work @alexgleason

[alexgleason]

@melvincarvalho I have linkified custom field values on Ditto. So although for website you have to choose one, you can add any number of additional links with custom fields.

[vitorpamplona]

@rabble are you migrating to this?

[melvincarvalho]

Is there anything about uppercase vs lowercase -- an idea might be to make it all lowercase -- as there might be typos -- I am sure there's some edge cases I havent considered tho.

[alexgleason]

I bridged it with ActivityPub in both directions: https://gitlab.com/soapbox-pub/mostr/-/merge_requests/125

[mikedilger]

I'd like an explanation of where the collision is happening, otherwise this seems like more complexity for no benefit.

[eskema]

this feels unnecessary as to me the whole object was already user defined, this adds extra complexity for no benefit whatsoever. there's already so much garbage attached to kind-0 metadata by clients that it doesn't really matter in the end..

[alexgleason]

@mikedilger This is not a replacement for protocol-level fields. This is a user-defined table with two columns: name and value. The order of fields is important, something a plain object cannot guarantee. And duplicate entries are allowed.

Each protocol-level field is a contract between the user and the client. The goal here is to have a clear contract about an arbitrary list of tuples that are displayed in a confined place in the same order they're defined

[alexgleason]

It's actually harder to implement this feature by picking out all "known" fields than to just display the list of custom fields verbatim.

Look at my screenshot. Do you really think "Soapbox" belongs as a key in the root metadata object? metadata.Soapbox...

[alexgleason]

These are name-value pairs, not key-value pairs.

[mikedilger]

I always took kind-0 metadata to be user-defined meaningless data, not protocol-level stuff. People later added meaning and expectations around nip05 and username and then lud16 fields because that was a simple (but incorrect in a strict sense) way to get what they wanted. Saying "name-value" as opposed to "key-value" is just another way to say that you think metadata fields are protocol-level not user-level things.

Yes it is unordered and no there can't be duplicates (due to the nature of JSON).

This isn't a big deal to me, but it seems like the flood of changes to nostr making it more and more complex and breaking things over and over is never going to stop and that maybe I should just rip off the damn band-aid and give up on this overly complex nightmare of a moving target protocol that can't actually fix any of it's real problems, but rapidly fixes more and more non-problems with more and more complexity. sigh

[arthurfranca]

Ack

Though a downside of not knowing the allowed fields before hand is that the client can't do i18n properly aside from dynamically translating each field name.

Maybe "pronouns" and other things that need translation may be better if inserted ~in the stringified JSON~as before (outside the "fields" key), but only the keys listed on NIP-24 would be valid.

[alexgleason]

This isn't a big deal to me, but it seems like the flood of changes to nostr making it more and more complex and breaking things over and over is never going to stop

My dude, you do not have to implement every NIP! It's in the name. Nostr Implementation Possibilities.

[mikedilger]

This isn't a big deal to me, but it seems like the flood of changes to nostr making it more and more complex and breaking things over and over is never going to stop

My dude, you do not have to implement every NIP! It's in the name. Nostr Implementation Possibilities.

I've been replying under the assumption that my custom ser/de code would break on the unexpected json array and that if I didn't implement this, more and more kind-0 events would fail in gossip. But I just looked into my code and it looks like it already can handle this case. So I don't have to implement anything.

[shawnyeager]

ACK

[1l0]

Why not using NIP-32 Labeling

[alexgleason]

I considered modifying this to add clarifications, but I think the text is clear already. There are technically two implementations (Ditto and Mostr Bridge), but they are both me. So @vitorpamplona maybe you can implement this in Amethyst if you believe it's the right way forward.

[vitorpamplona]

Yeah, I am implementing these fields as well. The only question I had was about the pronouns state.

[rabble]

@alexgleason Can we add a list of common suggested fields. Just so folks aren't mixing up 'pronouns' vs 'Pronouns' vs 'pronoun' and then all the apps know, if they want to support pronouns then then should use the one form. Personally i'd prefer we keep PR #1590 in addition to this, but it's not a hill i'd die on.