Jump to content
Sasun Steinbeck

Avatar name changes re: scripted objects

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites
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 by Rachel1206
  • Thanks 1

Share this post


Link to post
Share on other sites

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 by Sasun Steinbeck

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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 by Wulfie Reanimator
  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 by Wulfie Reanimator

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 by Wulfie Reanimator

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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. 

  • Like 2

Share this post


Link to post
Share on other sites

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 by Ruthven Willenov
  • Like 2

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

 

  • Thanks 3

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...