Some historical context, we used to have something very similar to what you proposed before.
It worked as follow:
- User would set up a name and picture on onboarding
- 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:
- 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.
- 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:
-
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).
-
Each message has attached to it the username metadata
-
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.
Quella 1337
Aldwulf 1999
Cecimeric 
. I agree with Andy on most of his feedback,