nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr why this?

Nostr has no usernames, and no rules for the name field.

Reply to this note

Please Login to reply.

Discussion

nostrudel has rules, what is the big deal

An existing user coming from another client cannot update his profile, for example.

Interoperability is the Nostr super power, with such arbitrary rules you are going to kill it.

being more strict is always better so it's other apps that should enforce these same rules

Sorry but this doesn't make much sense to me. It's a name, you cannot enforce it in arbitrary ways.

Yeah, I have had this issue too with my account (nostr.land).

Many clients use it for the display name in @ as well, which makes it worse

I suppose for aesthetics. I'm with him

I can't understand, we're talking about having a rule in the names by aesthetics, in a decentralized, uncensored network, really? πŸ˜…

I think there was restrictions in nip-01 at first. But it probably doesn't make sense anymore

If the username doesn't have restrictions then should we remove the display name?

I don't remember any restriction in NIP-01, so I would safely remove it.

Display name has always been controversial, actually it does not make much sense, in fact I didn't include it in Nstart.

A lot of clients also started to deprecate/remove it.

NIP-01 suggests kind 0 for metadata. Do whatever you want to do, but for social media clients it’s stringified JSON with some conventions.

I am always in favor of removing stuff β€” not that I have a say

what is display name?

It's definitively an error without much sense.

lol makes sense

Check the protocol.

NIP-01 (the core and mandatory part of Nostr) prescribes usernames (the "name" tag), but allows for additional metadata fields, which are described in NIP-24. Among them, the "display name" (the "display_name" tag). The "name" tag should be present even when the "display_name" is not, but not the other way around (although I think if only the display name is set for a user clients should display it).

Personally, I don't think they were a mistake. I think there are arguments against it, but also that they do have some use. Essentially they serve the same purpose as usernames, but may have a different style.

The presence of both the "username" (which, unlike on other platforms, is not identifying and not unique) and the display name doesn't make a lot of sense, indeed, and I don't know why it was ever a thing.

However, you are free to set one and not the other (I think a client should display whichever one you di did set) or set both to the same value (which I see many people do).

I think it makes some sense to have both fields, although it may be confusing, because people can set them to different values: a short, one-word original nickname as a "username" and a longer, possibly less original, name as a "display name", which may be your real name (if you are not anonymous). I believe there's something similar on IRC.

Clients can display one or the other as the primary name for a user, depending on the style they want to have: you want a HackerNews feel? Show usernames. You want a Facebook feel? Show display names.

For example, my username is "Apsie96", but by display name is "Valentino Giudice", my real name. There is no rule to follow and I could even have swapped them, but I think it's better this way.

While I might have opposed the double field, for essentially the same meaning, I'm actually not against the presence of display names for this reason.

Nice, but I suggest to use the "name" label for the field, "username" is midleading since Nostr has not usernames in the usual meaning of centralized platforms.

In Nstart I use "(nick)name", I think it is a good way to concisely explain this.

I would also add a contextual help explaining the matter, this is the introductory text in Nstart: "The name is not a unique username, we can have as many Jacks we want! Feel free to use your real name or a nickname; you can always change it later. But remember: online privacy matters, don't share sensitive data."