Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

add nip-24: extra metadata fields #794

Merged
merged 2 commits into from
Sep 26, 2023
Merged

add nip-24: extra metadata fields #794

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
09c0c4d
add nip-24: extra metadata fields.
fiatjaf Sep 24, 2023
e798e0a
`banner` and deprecated names.
fiatjaf Sep 24, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
32 changes: 32 additions & 0 deletions 24.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
NIP-24
======

Extra metadata fields and tags
------------------------------

`draft` `optional` `author:fiatjaf`

This NIP defines extra optional fields added to events.

kind 0
======

These are extra fields not specified in NIP-01 that may be present in the stringified JSON of metadata events:

- `display_name`: a bigger name with richer characters than `name`. Implementations should fallback to `name` when this is not available.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, why does display_name exist? This is the definition for name. NIP-01 is wrong.

name is not a username. It's a display name. Nostr inherently does not have usernames. The thing that makes a username a username is that it's globally unique. The closest thing we have to real usernames is nip05.

There's no reason the name shouldn't have special characters, and there's no reason to support display_name and then fall back on it.

The reason for the discrepancy is because of nostr.rocks, when the concept of NIP-05 didn't exist and people were LARPing with usernames. But that was an imaginary, pretend experiment. Now we have something resembling actual usernames with NIP-05. We only need one name field.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, I don't see the point of having display_name, but it is better to have just display_name than to have display_name, displayName, username, userName, handle and what other absurdities people are doing out there.

Many clients are treating name as a unique identifier, prepending it with a @ to feel like Twitter and all that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It makes way more sense to use @{nip05} fallback to @{nip19}. To use @{name} practically guarantees that Nostr won't be understood. It's a bad UX that shouldn't be enshrined in a NIP.

I would add a "deprecated fields" section of this document and list the ones found in the wild, with a recommendation about which fields to use instead. Eg:

Deprecated fields

The following fields have been in use by clients in the past, but considered deprecated and should be avoided.

  • display_name, displayName, username, userName, handle, etc. - use name instead. For human-readable usernames, see NIP-05.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

display_name exists because, in the early days, many clients (including Damus/Amethyst/Snort,Astral) didn't support @ with a space in the name.

These days we might not need it anymore. So, I would be okay with calling it deprecated and using just name instead.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a strong case for having two short text fields to express identity in different ways that don't have the constraints of a nip05. Many clients have opted for this. It would be great if a consistent standard was adopted.

type 1: how a user would like to be addressed eg Will in spite of potential identity collisions.
type 2: an identifier with a smaller chance of identity collisions such as '[firstname] [lastname]' or a username used on other platforms eg jb55.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EDIT: @jb55 pointed out that I got his use the wrong way round. The two types of use cases were there but the field choices have been inconstant. I should have left it unpublished as I was crafting a narrative without verifying the facts. I should be a politician.

Here is a short extract from a draft unpublished essay I wrote many months ago on identity expression and the potential for social verification on nostr:

display_name

This has come to be used to display a user's handle: A string of characters that is short, memorable and relatively unique (traditionally they had to be unique on a given platform, but not the case on nostr) used across many online platforms. It almost always contains only letters and numbers with the occasional @ prefix such as @waxwing or @yegorpetrov).

Sometimes it incorporates the user's first or second name, aspirations, or identity such as cultural references they resonate with such as heros. It therefore is often a creative expression of identity.

It is occasionally omitted all together. This may become more commonplace through the adoption curve as users join who are not part of username driven online communities.

name

A more personal but less unique expression of the identity than display_name.

  • Often the "[firstname] [lastname]" eg "Lyn Alden"
  • Sometimes "[firstname]" eg "Will"
  • Sometimes its the user's handle with spaces and capitalisation. Sometimes its identical to the users handle.
  • Occasionally "[lastname]" eg "Caremen"
  • Occasionally omitted

Feels like a closer and more direct human connection than a handle. It is much more likely to collide with other identities, much less of a creative expression of identity and personality.

- `website`: a web URL related in any way to the event author.
- `banner`: an URL to a wide (~1024x768) picture to be optionally displayed in the background of a profile screen.

### Deprecated fields

These are fields that should be ignored or removed when found in the wild:

- `displayName`: use `display_name` instead.
- `username`: use `name` instead.

tags
====

These tags may be present in multiple event kinds. Whenever a different meaning is not specified by some more specific NIP, they have the following meanings:

- `r`: a web URL the event is referring to in some way