fix: persisted user display name

[willydouhard]

No description provided.

[dokterbob]

Isn't creating a persisted user from a user the data layer's job?

In that case, I would expect this code to live in the data layer, e.g. in

chainlit/backend/chainlit/data/literalai.py

Line 225 in 970bde2

return PersistedUser(

and the likes.

Similarly, it seems to be we should want to persist it create_user().

Overall, I don't think this is part of authenticating a user.

Or do I not understand this well?

[willydouhard]

Isn't creating a persisted user from a user the data layer's job?

In that case, I would expect this code to live in the data layer, e.g. in

chainlit/backend/chainlit/data/literalai.py

Line 225 in 970bde2

return PersistedUser(

and the likes.
Similarly, it seems to be we should want to persist it create_user().

Overall, I don't think this is part of authenticating a user.

Or do I not understand this well?

The display_name should never be sent to the backend. The use case is to have unidentifiable users in the backend but on the UI the real name is displayed

[dokterbob]

The display_name should never be sent to the backend. The use case is to have unidentifiable users in the backend but on the UI the real name is displayed

This seems to me a very uncommon use case for a field called display_name. The field name is very commonly used and it usually is the username as it is rendered, like a nickname.

Literally all I could find out in the code about it is "The User class now has a display_name field. It will not be persisted by the data layer."
Which makes adding it explicitly to a PersistedUser class quite confusing (at least to me!)!

My point is that if this feature is already confusing to a fellow maintainer, devs will struggle even more using it. Getting clarity on the naming on the feature and documenting it's use and use case would resolve it.

Could you please:

1. Explain where and how this is used.
2. Refer to a PR or page in the docs where I can read about it?
3. Change the name into something with less overlap with pre-existing expectations?