Avatar name changes re: scripted objects

[Sasun Steinbeck]

Just wondering if any detailed information exists yet on LSL API changes related to the upcoming avatar name changes. If not, where and when can we expect some details? I'm really hoping there are no breaking changes, but I need to know what is going to happen specifically to the APIs and any changed assumptions about avatar names before any changes roll out so I can get any necessary updates to my products out there.

[Chic Aeon]

Ebbe has mentioned a few times that coding with NAMES will not work after the change (or perhaps not work as well). He cautioned and advised folks to start using KEY of the avatar.  So yes, it appears that there will be some major changes and some adjusting of older products.   Hopefully someone else has more info for you. 

[Rachel1206]

1 hour ago, Chic Aeon said:

He cautioned and advised folks to start using KEY of the avatar

This should be written in stone!

Always use UUID and key values. Repeat - always use UUID and key values.

To the user you show say the avatars display name, the script engine behind based on the UUID.

The new script functions llName2Key and llRequestUserKey are your friends there.

Edited July 19, 2018 by Rachel1206

[Sasun Steinbeck]

When you say "always use UUID values", yeah that's true when storing a list of avatars in some way. A database of legacy or account names only is indeed useless which I think is what you are getting at. For most APIs you need UUIDs so that's nothing new. For messages and whatnot to end-users, obvious I need to use something friendlier than a UUID,  display names are useless as they can change on a whim, so I need to understand the details behind legacy names (and accout names, if they are changing too?)

As a scripter I'll definitely need more specifics than general guidelines. Exactly how will the APIs change? Exactly how will llKey2Name() change? Under what conditions does it return a different name for the same UUID? What about llGetObjectDetails? What about llGetUsername? Will user names remain the same and never change or will they follow legacy name changes? Will legacy names still be called legacy names or will there be new terminology? llRequestAgentData? What about llDetectedName()? What about names passed into listen events? llSensor()? AGENT_BY_LEGACY_NAME? What about the q parameter for search.secondlife.com/web/search/? What about the q parameter for search.secondlife.com/client_search.php?s=people ? How will the results returned by those URLs change? What about the names shown for an avatar's web profile i.e. http://world.secondlife.com/resident/c3cf4c84-c31b-47ac-855c-3858375e0360 ? Do I need to store multiple names for every avatar UUID now? Will there be an API to get all (current + historical) legacy names from an avatar UUID? Or will all APIs like llKey2Name and llRequestAgentData only return one legacy name, the latest one? Can I look up a UUID from an old legacy name after it has been replaced?

As you can see there are a lot of details that need to be known for scripters to fully understand what to do. I'm looking forward to the gory details.

Edited July 19, 2018 by Sasun Steinbeck

[Callum Meriman]

6 minutes ago, Sasun Steinbeck said:

I'm looking forward to the gory details.

We all are. We need to wait until they do it.

I get a feeling in my tail-bones it won't be this year.

[Wulfie Reanimator]

Legacy name is a username is an account name.

"Legacy name" is defined as the avatar's full name, with the Resident part if they have no other last name. 

The functios mentioned will not change in how they work, just the value they return will be based on the avatars current full non-display-name. 

I can't comment on the web querys though.

Edited July 19, 2018 by Wulfie Reanimator

[Callum Meriman]

I really do hope we get a function:

list all_names = llGetAllNames(key UUID);

 

[Love Zhaoying]

51 minutes ago, Callum Meriman said:

I really do hope we get a function:

list all_names = llGetAllNames(key UUID);

 

But then you could "dead name" someone..which is not a nice thing to do.

[Wulfie Reanimator]

37 minutes ago, Love Zhaoying said:

But then you could "dead name" someone..which is not a nice thing to do.

Last I heard, old names will stay reserved to an account and LL is considering allowing people to switch back to them. 

Edited July 19, 2018 by Wulfie Reanimator

[Love Zhaoying]

1 hour ago, Wulfie Reanimator said:

Last I heard, old names will stay reserved to an account and LL is considering allowing people to switch back to them. 

That's fine, I was referring to allowing a function that lets someone "get all of another avatar's previous names", which would be a privacy issue.

[Wulfie Reanimator]

36 minutes ago, Love Zhaoying said:

That's fine, I was referring to allowing a function that lets someone "get all of another avatar's previous names", which would be a privacy issue.

At the risk of going way off-topic: Would it though?

Edited July 19, 2018 by Wulfie Reanimator

[Love Zhaoying]

2 minutes ago, Wulfie Reanimator said:

Ag the risk of going way off-topic: Would it though?

Here's the scenario: User "Sam Smith" has a disastisfying Second Life and decides to start anew. But not with an Alt, with a Name Change "Fred Jones".  

Unfortunately "Sam Smith" made a lot of enemies.  They are able to determine that "Fred Jones" was previously "Sam Smith" and so pre-emptively Ban / Shame him.

Poor "Fred Jones" never had a chance to make a new Second Life because he did not get a chance at privacy by hiding his old identify.

However, if his GUID never changes, people can just use that (if they kept track of "Sam Smith's" GUID) and will know from the GUID that this "new" character "Fred Jones" is really none other than the feared, hated, reviled "Sam Smith"! Cue the crowds with pitchforks.

[Wulfie Reanimator]

1 minute ago, Love Zhaoying said:

Here's the scenario: User "Sam Smith" has a disastisfying Second Life and decides to start anew. But not with an Alt, with a Name Change "Fred Jones".  

Unfortunately "Sam Smith" made a lot of enemies.  They are able to determine that "Fred Jones" was previously "Sam Smith" and so pre-emptively Ban / Shame him.

Poor "Fred Jones" never had a chance to make a new Second Life because he did not get a chance at privacy by hiding his old identify.

However, if his GUID never changes, people can just use that (if they kept track of "Sam Smith's" GUID) and will know from the GUID that this "new" character "Fred Jones" is really none other than the feared, hated, reviled "Sam Smith"! Cue the crowds with pitchforks.

Like you said, the UUID can be used instead, and it's shown in the profile in most TPVs.

Pre-emptive ban wouldn't come up either because the person changing their name doesn't unban them. Chat logs don't go away, avatars made by a person is usually somewhat recognizable, etc.

Social interactions/engineering is a privacy issue that even crosses the gap of alts or entire platforms, so I do not think being able to check the reserved names would be a big issue. 

[Ruthven Ravenhurst]

from what i understood, llRequestUserKey will return the users key with any user name they've used for that account. so llRequestUserKey("Fred Jones"); will continue to return the same key as llRequestUserKey("Sam Smith"); no matter which one they are using, as long as the user names were linked to the same UUID at some point

Edited July 19, 2018 by Ruthven Willenov

[Sasun Steinbeck]

1 hour ago, Ruthven Willenov said:

from what i understood, llRequestUserKey will return the users key with any user name they've used for that account. so llRequestUserKey("Fred Jones"); will continue to return the same key as llRequestUserKey("Sam Smith"); no matter which one they are using, as long as the user names were linked to the same UUID at some point

This would be critical functionality to impement. They HAVE to do this. Up until this minute legacy names were guaranteed to never change and always be unique. So let's say you have a list of subscribers to a list. Instead of exporting a list of UUIDs, you could export a list of legacy (or account!) names and be safe in the assumption that those were always useable, meaning, you could re-import them and in some way or another convert them to unique UUIDs.

Now if that assumption is broken that is really going to screw up a lot of people that happen to have lists of avatars for whatever reason (sales logs, committee memebers, whatever) that are now broken. If you re-import them and half of them are completely unknown because the avatar changed their name... what a mess. Big problem.

The only reasonable thing to do and not break a zillion tools and external lists that make those (previously perfectly safe) assumptions that legacy names will always be tied 1-to-1 to a UUID is to make ALL names, historical + current, be searchable/convertable to a unique UUID. Anything less will really screw over a lot of people.

[Innula Zenovka]

The new functions are documented in the wiki:

http://wiki.secondlife.com/wiki/LlName2Key

http://wiki.secondlife.com/wiki/LlRequestUserKey

13 hours ago, Sasun Steinbeck said:

The only reasonable thing to do and not break a zillion tools and external lists that make those (previously perfectly safe) assumptions that legacy names will always be tied 1-to-1 to a UUID is to make ALL names, historical + current, be searchable/convertable to a unique UUID. Anything less will really screw over a lot of people.

That's exactly what the wiki says llRequestUserKey does:

Quote

Requests the Agent ID for the agent identified by name from the dataserver. The name given may be either the current name of an avatar or a historical name that has been used in the past. If no agent can be found with the supplied name this function returns the value NULL_KEY.

Returns a handle (a key) that can be used to identify the request when the dataserver event is raised.

The agent being searched for with this function does not need to be signed on to Second Life.

 

[Ruthven Ravenhurst]

Thank you Innula, I knew I read it somewhere, don't know why I didn't think to check the wiki

[Sasun Steinbeck]

Yeah thanks!

BTW for those interested I found this very helpful to understand the confusing name situation on various SL properties: http://wiki.secondlife.com/wiki/Category:LSL_Avatar/Name

[Sasun Steinbeck]

OK I think I have a good handle on how this affects me and my various systems and scripts. But I have one super vital question: will search in the viewer work with retired (historical) names? Will it find the correct avatar, even with their old names?

Same question for https://search.secondlife.com/ but that is much less important to me.

[Kyrah Abattoir]

On 7/19/2018 at 4:00 PM, Love Zhaoying said:

Here's the scenario: User "Sam Smith" has a disastisfying Second Life and decides to start anew. But not with an Alt, with a Name Change "Fred Jones".  

Unfortunately "Sam Smith" made a lot of enemies.  They are able to determine that "Fred Jones" was previously "Sam Smith" and so pre-emptively Ban / Shame him.

Poor "Fred Jones" never had a chance to make a new Second Life because he did not get a chance at privacy by hiding his old identify.

However, if his GUID never changes, people can just use that (if they kept track of "Sam Smith's" GUID) and will know from the GUID that this "new" character "Fred Jones" is really none other than the feared, hated, reviled "Sam Smith"! Cue the crowds with pitchforks.

That's beyond the scope of the name change feature. UUIDs are unique and immutable.