Clarification for the new "Usernames" object

[Reluctant-Dentist]

I've read the official documentation/comments here, I have looked through old github issues and I have run the new TdLib to see some examples of Usernames objects, but I still have multiple questions:

• According to the above documentation, active_usernames[0] is the main username, which implies it is the equivalent of the username field in older tdlib versions' Users/SuperGroups objects. However, here, @levlam suggests editable_username is the only username?
  • Is there a difference between editable_username and active_usernames[0]? In my tests, they're always the same
• What even are disabled_usernames? I haven't seen an example where this array has an entry.
  • And what's the purpose of disabling a username?
• After checking old github issues such as this, I realised that some of the usernames are NFTs. It seems like they're just unique strings attached to the account/group and isn't actually used for queries like the traditional username. Is this correct?
• How do we tell which of these usernames are NFTs or not? This comment implies all disabled_usernames and active_usernames are always NFT names. However, during my tests, I always noticed editable_username == active_usernames[0], and I know this is the "real" username since they were the same value as 1.8.0's username field when I tested that. So is active_usernames[0] both the traditional username AND an NFT?
  • If it is both and its in the "active" list, does this mean you can change it and disable your "real" username?
• In my opinion, the official documentation needs to be updated. Initially, I was very confused how there are multiple kinds of usernames, until I found that comment about NFTs. And it doesn't explain which usernames can be used for queries or not.
  • If you want I can make a small PR addressing this once I understand how these usernames work.

[levlam]

First of all, all usernames except the editable_username are NFTs and can be linked (or unlinked) with a user only on the Fragment platform.

Is there a difference between editable_username and active_usernames[0]?

They aren't related to each other. active_usernames[0] is the primary username, which is the equivalent of the username field in older TDLib versions. editable_username is the only non-NFT username, which can be changed through Telegram Apps, for example, completely removed.

What even are disabled_usernames?

disabled_usernames are NFT-usernames that were linked to the account, but are not enabled and not visible to other users.

It seems like they're just unique strings attached to the account/group and isn't actually used for queries like the traditional username.

All active usernames can be used interchangeably. They point to the same user.

[Reluctant-Dentist]

Ok, I understand this better now.

They aren't related to each other. active_usernames[0] is the primary username, which is the equivalent of the username field in older TDLib versions. editable_username is the only non-NFT username, which can be changed through Telegram Apps, for example, completely removed.

I guess this leads me to a new question. Since active_usernames[0] is the primary/"old-td-lib" username, what exactly is the editable_username? I know the TdApi commands I would need for updating this value, but I'm struggling to figure out what this does for a normal Telegram user. Eg on https://web.telegram.org/a I can and edit my username, but doing so changes both active_usernames[0] and editable_username (FYI: I haven't bought any usernames, I only have the old/free one). And from my tests, every usernames field is either null, or this

{
   "activeUsernames":["example"],
   "disabledUsernames":[],
   "editableUsername":"example"
}

So as a normal user, can you ever make active_usernames[0] != editable_username, and what does this look like in the UI?

disabled_usernames are NFT-usernames that were linked to the account, but are not enabled and not visible to other users.

Huh, strange. I presume you mean these usernames aren't visible on any of the official apps, but the API does still return them? Also, what is the purpose of disabling a username?

All active usernames can be used interchangeably. They point to the same user.

Good to know. Thank you.

[levlam]

Order of active usernames doesn't change when editable_username is changed. If it was the first active username, then it will be the first active username after the change. If a user has no NFT usernames, then everything works in exactly the same way as previously for the user, which can have up to 1 always active editable username.

the API does still return them?

The API returns them only for the user in question/supergroup owner.

[Reluctant-Dentist]

I think you mis-interpretted what I meant. In all my tests, I always see active_usernames[0] == editable_username, but is this always true? Is it possible for editable_username to be completely different from any of the active_usernames? And if so, how/why?

The API returns them only for the user in question/supergroup owner.

Interesting, to be clear do you mean it only appears if we try to get the user object for our own logged-in account as well as any supergroup owner?

[levlam]

I always see active_usernames[0] == editable_username, but is this always true?

I said at the very beginning that active_usernames[0] and editable_username are unrelated to each other, and explained a few times, what exactly they mean.

Is it possible for editable_username to be completely different from any of the active_usernames?

Yes, it can be empty.

[Reluctant-Dentist]

I understand what you're saying, that active_usernames[0] and editable_username are supposed to be unrelated to each other, however in all my tests they are always the same, I have never seen !active_usernames.contains(editable_username). So at the moment, I can't clearly define how they are different.

Yes, it can be empty.

Which value can be empty? Could you provide an example Usernames object so I can see?

[levlam]

I described a few times, what the fields mean, including the ability to have "up to 1 always active editable username". You can search on Telegram for users with NFT usernames and you can definitely find all possible cases in accordance with my description.

[Reluctant-Dentist]

You can search on Telegram for users with NFT usernames and you can definitely find all possible cases in accordance with my description.

The problem is I tried that. I went to 2 NFT servers and tried using a bunch of usernames, however all of them either had Usernames == null or active_usernames[0] == editable_username.

After your most recent comment, I decided to expand my search. I have now checked 9 big NFT servers and checked over 100 users in each server. But I still couldn't find one.

I then decided to try random "popular" phrases. Eg "instagram", "apple" and "jack". Finally, I started encountering what I was looking for. Eg. "instagram" returns

{
    "activeUsernames":["creators","instagram","growth"],
    "disabledUsernames":[],
    "editableUsername":""
}

And for anyone else following along, now or in the future, this is what the group's profile looks like on the web UI, it shows the extra active_usernames there:

I did find a few other ones like twitter and apple that had a single active_username, but also had editable_username as an empty string. And jack had many active_usernames as well as a editable_name (Where it was equal to fragmentdiscuss which is the same as active_usernames[1]). So it seems either I was very unlucky in my initial search, or extra NFT usernames are just not common.

editable_username still doesn't seem to mean anything. I don't see that particular name rendered anywhere special on the UI. I did notice that the channels like instagram and twitter seems to have empty editable_usernames, whereas groups like jack have it populated. But I've seen channels with editable_username, so that was probably a coincidence. Either way, it seems editable_username is always either empty or equal to one of the active_usernames (Kind of like a nullable index for active_usernames) so that knowledge is good enough for me.