3 Word Pseudonym Alternative

Idea name:

3 Word Pseudonym Alternative

Description:

Functionality that creates a human language agnostic alternative to the 3 word pseudonym derived from the user’s public chat key.

Use case:

As a user, I want to have an alternative to the use of English word usernames so that I don’t feel alienated by a language that I don’t understand or like.

Target user:

Users that are not familiar with English or users that would prefer not to be force to use English identifiers.

Why this is important:

Marketing have reported that users from South American countries are put off with English words.

Any other comments:

Emojis

One possibility is to use emojis

The list of all emojis is 1809, if we discount all flags (I’d presume flag emojis could be problematic if language choice is alienating) we have 1540 emojis.

Using a 3 emoji pseudonym we get 1540 ^ 3 = 3,652,264,000 combinations of emojis
Using a 4 emoji pseudonym we get 1540 ^ 4 = 5,624,486,560,000 combinations of emojis

Examples:

  • :crossed_swords::tv::star_and_crescent::currency_exchange:
  • :scroll::woman_teacher::video_game::dolls:
  • :dark_sunglasses::sob::ambulance::no_mouth:

Procedurally generated names

Another alternative would be to use “human” names

Products like https://blog.reedsy.com/character-name-generator/fantasy/human/ allow users to create random names. The names can be generated using a deterministic process of word generation using the linguistic patterns common for names of a particular culture.

Examples:

  • Parth Alathic Aldwulf
  • Yel Favian Cog
  • Quella Olaka Rylla

Combinations

We could also make combination names, from the above suggestions and maybe include numbers.

  • :no_mouth: Quella 1337
  • :dog: Aldwulf 1999
  • :alien: Cecimeric :metal:

Emoji usernames are a clever, space-saving workaround, but I don’t think they get at the core problem. The core problem is users remembering who they are chatting with.

Being able to select a single-word username should be a default convention, with the option to use randomly generated symbols/words/emoji/whatever for users interested in a more private experience. Localized language options should be supported by phone defaults to give the user the choice.

In the sign up screen instead of asking which username they want, just ask, what username do you want? And give them no choices unless they select something already taken. Maybe even give them status.eth names by default.

3 Likes

Hey @andyboyan, thanks for your feedback.

Add Local Contact Names should address this problem, allowing users to give any contact a custom name locally on their device.

The problem with your suggestion is that usernames currently are algorithmically determined from the public chat key. So if you know the public chat key you can create the pseudonym.

But if the user wants to create a username that is permanently associated with their public chat key, we need a decentralised method of propagating that information through the network. So, as you suggest, status.eth usernames are the best solution, but this would mean that the user needs to pay Ether gas and some SNT which isn’t the best on boarding experience.

I’d suggest we could pay the gas and SNT for the user, but this would mean that we need some mechanism to determine legitimate usage vs spam. It’s a hard problem.

I had this idea initially also, but the above problem of deterministically generating the name from the public chat key means that the pseudonym would appear differently depending on the local language. Which may not be a bad thing. I think input from others on this point would be helpful.

Thanks for sharing the ideas :raised_hands:. I agree with Andy on most of his feedback,

Add Local Contact Names should address this problem, allowing users to give any contact a custom name locally on their device.

I don’t really think they will, or not as widely as we’d like to think as managing contacts this way is a manual hassle.
If I were to point towards an underlying problem I’d say It’s about giving people the agency to construct an identity themselves, how they choose to be perceived by others online.
I don’t expect us to jump to any conclusions here yet, but would rather ask to maybe reserve some research time and see if there’s an alternative of having chat usernames / profile pics that can run on protocol / waku.

I’m also not fond of the emoji approach, the advantage to having text only names is they are relatively unobtrusive in a chat setting, you can filter them out. Having those colourful emojis everywhere would drown out all of the chat signal in noise. If anything, I’d rather consider them as an alternative to identicons.

4 Likes

Hey @maciej I’m really grateful for your insights on this feature.

This is a fair point. I was just throwing out ideas that could give a language agnostic solution and on reflection you make a good point. Chat’s could become a hideous migraine of emojis.

Ok. The solutions to this problem as far as I can see are:

  • Register a name of the user on the blockchain linking the chat key to a name chosen by the user.
    • This does not need to be ENS, it can be a custom smart contract for this purpose.
    • Con : The user will need Ether to register their key
    • Con : May undermine SNT utility
  • Attach a username to the message metadata
    • This will mean that messages will have an author name, but if the user changes their username this will not affect previous messages.
    • Con : May undermine SNT utility
  • Special profile data message
    • Con : May undermine SNT utility
    • This would require a new hidden message type but could work as follows:

Process flow:

  • User sets username and profile picture in local app
  • User joins a chat
  • App publishes hidden profile data message (pdm) to chat
  • All devices connected to this chat read the pdm and store this data as a hidden contact.
    • This will associated the joining user chat key with the user’s selected username
  • If a device joins a chat and finds a message from a chat key that hasn’t sent a pdm the device sends a pdm request message (pdmr) including all the chat keys that the device does not have pdms for.
  • The other devices will receive the pdmr and may choose to reissue the pdm for this request
    • Some limiting would need to be placed on this functionality as spammers could force devices to send pdm responses 100s of times a second. That’s why the choice of sending the pdm is up to the recipient device.
  • All devices update their hidden contact info as per the new pdm.

@cammellos may I ask you if this pdm process flow seems logical and doesn’t have any particular issues?

1 Like

Some historical context, we used to have something very similar to what you proposed before.
It worked as follow:

  1. User would set up a name and picture on onboarding
  2. User would share username/picture on contact requests, and send a contact update each time it changes (the current protocol still support this use case).

We talked about sharing it publicly (similarly to what you described) but there was push back on the ground of privacy and selectively sharing your identity to people, so we never pulled the trigger.
Things might be different now though, so we might reconsider, myself I am not too concerned about the privacy aspects as I don’t think a few random keystroke really reveal much about you.

Generally, the issue with this approach is:

  1. Phishing. When we had this feature, it was trivial to impersonate someone, so a user-set name or ENS as well, should always be accompanied by the 3 random words name for security reason.
  2. Data inconsistencies. User have multiple devices, with the same public key, there’s no central place for storage so there’s no a single authoritative place where to store this information.

I think a mobile style approach (I set your name, a la whatsapp) is much more suited for our current technology, but clearly UX is not as good.

That’s not to say that we can’t make this work.

Of the solutions you proposed, I think a mix of the 2 is probably best, to minimize traffic.

When you say:

but if the user changes their username this will not affect previous messages.

I take you mean:

“If a user changes their username and does not send a new message in a public chat, other users will not be able to see the new username” .
As if he does send a message we can update information about the user, and so previous messages will also show the new username.

So the pdm approach would solve this use case, but the cost is fairly high, that’s something we noticed with the previous approach as well, where you would have to update each contact.

Here if you changed your username, you would have to send at least n messages, where n is the number of public chats joined, and it would only update public chats and not one-to-one or group chats.
One-to-one and group chats can be updated using your bundle information, so that should be relatively cheap, as anyone who has a chat open with you, listens to your private topic in order to receive new bundles, so username can be attached to it. That’s a single message to update anyone who has an open 1-to-1 chat/ group chat with you.

So the overall cost is n public chats + 1

So the algorithm would be something like:

  1. User join a public chat (no pdm is necessary on joining, one for privacy reason, two as if it’s a new chat, no messages from the user should be there, although there’s one edge case, join->publish-message->leave->join again, but I think we can live with that).

  2. Each message has attached to it the username metadata

  3. If a username changes, a hidden pdm is sent in any public chat and published on the bundle (n + 1 messages)

That way you drop some of the other technical aspecs, for example there’s no need to send pdm requests/replies:

If a device joins a chat and finds a message from a chat key that hasn’t sent a pdm the device sends a pdm request message (pdmr) including all the chat keys that the device does not have pdms for.

That’s not necessary anymore, as either the user pulls a message with a username, or it finds a pdm for a given user as the last message. (The assumption is that we don’t have gaps in the history, meaning, if I join a chat I pull from now to yesterday, not from yesterday to two days ago, which is the actual behavior).

Another issue is how to deal with multiple devices which set a different username, but that’s a minor concern.

Something like that I’d say, whether is worth the complexity I don’t know, but given we want to implement something like this, that’s what I would go for instinctively.

1 Like

Oh Add Local Contact Names I see you proposed both options, well done! :slight_smile:

Yes, that one obviously fits more our technology world (mobile phone contact book vs central authority usernames), and that’s the one I’d start with, although less ux friendly

+1 for the local names alternative.

It’s a secure concept that allows us to support pseudonymity moving forward. Also, secure identity centric projects take that approach, so lets make sure to pave the way for future integrations with decentralized identity.

Some references for a local names pipeline on a DNS level:

https://gnunet.org/en/gns.html

1 Like