Secondlife 15th anniversary and CEO's letter

[LittleMe Jewell]

30 minutes ago, Callum Meriman said:

I'd also like to think they did open the old names. Maybe start at 2007 names to protect the OhFours (and certainly never reuse neva). I know the plan was to keep old names retired, but meh, does it really matter that much?

/me again dreams of her army family of Jewell alts

[LittleMe Jewell]

33 minutes ago, Callum Meriman said:

One of the biggest reasons LL gave for removing last names was that it was just too hard thinking up new names that were 100% G rated in all languages. I am sure the community can help there, maybe the Lab could consider accepting name applications already.

One of the things noted in the previously referenced summary of the CCUG meeting was:

" To help keep the available names relatively fresh, the Lab is considering accepting suggestions from users. "

[Pussycat Catnap]

On 3/21/2018 at 10:50 AM, Parhelion Palou said:

LL has to get more revenue in other areas in order to bring down land prices.

I believe that revenue stream exists here:

https://secondlife.com/my/lindex/buy.php

Which is used to gain access to this new feature:

https://marketplace.secondlife.com/?

I'm actually serious here though... Over the last few years the "in thing" to do in SL has changed from "be a curmudgeon on your plot of 512m land with all kinds of hostile textures rezzed to chase off your neighbors and a bunch of angry breedables to take over all the land around you" over to "OMG... get me into this event so I can buy MORE MORE MORE..." followed up with "Well, I clocked 12 hours today buying mah lootz on MP... and I made a single new outfit... but I won't ever use it because tomorrow Imma going shopping againz"

SL users, in a generalized sense, have gone from 'residents' to 'shoppers'.

Bringing down land though... is not about lowering their revenue... its about getting us to SHOP more...

We don't need to really own / use this land... we just need to keep buying it... BUT... making it cheaper to own more of it... gives us more reason to shop on MP for not just clothes and mesh bodies, but furnishings and houses and so on...

 

This move is all about giving us more reasons to shop.

 

 

[Theresa Tennyson]

3 minutes ago, Pussycat Catnap said:

I believe that revenue stream exists here:

https://secondlife.com/my/lindex/buy.php

Which is used to gain access to this new feature:

https://marketplace.secondlife.com/?

I'm actually serious here though... Over the last few years the "in thing" to do in SL has changed from "be a curmudgeon on your plot of 512m land with all kinds of hostile textures rezzed to chase off your neighbors and a bunch of angry breedables to take over all the land around you" over to "OMG... get me into this event so I can buy MORE MORE MORE..." followed up with "Well, I clocked 12 hours today buying mah lootz on MP... and I made a single new outfit... but I won't ever use it because tomorrow Imma going shopping againz"

SL users, in a generalized sense, have gone from 'residents' to 'shoppers'.

Bringing down land though... is not about lowering their revenue... its about getting us to SHOP more...

We don't need to really own / use this land... we just need to keep buying it... BUT... making it cheaper to own more of it... gives us more reason to shop on MP for not just clothes and mesh bodies, but furnishings and houses and so on...

 

This move is all about giving us more reasons to shop.

 

 

Yep.

Some people even choose friends based on whether or not they can share shopping opportunities...

[Pussycat Catnap]

I'll add that... some years back when MP was kicking off I was in the panic crowd over 'this is going to kill SL land, and if there aren't stores inworld, SL will die...'

But I don't see it that way anymore...

Yes most of the SL shops died off inworld. MP ones took over, and smarter designed brands use inworld shops for branding / experience...

And that DID lead to a massive chunk of mainland being abandoned and a lot of islands closing up...

So the panic was right... but also wrong. The other notion I explored back then was that MP could fill the gap... and it seems to have done so...

 

But we do now have all this vacant mainland...

So why not turn it into residential land. That's what I think some of this is about.

 

[Alyona Su]

1 hour ago, Pussycat Catnap said:

I believe that revenue stream exists here:

https://secondlife.com/my/lindex/buy.php

Which is used to gain access to this new feature:

https://marketplace.secondlife.com/?

I'm actually serious here though... Over the last few years the "in thing" to do in SL has changed from "be a curmudgeon on your plot of 512m land with all kinds of hostile textures rezzed to chase off your neighbors and a bunch of angry breedables to take over all the land around you" over to "OMG... get me into this event so I can buy MORE MORE MORE..." followed up with "Well, I clocked 12 hours today buying mah lootz on MP... and I made a single new outfit... but I won't ever use it because tomorrow Imma going shopping againz"

SL users, in a generalized sense, have gone from 'residents' to 'shoppers'.

Bringing down land though... is not about lowering their revenue... its about getting us to SHOP more...

We don't need to really own / use this land... we just need to keep buying it... BUT... making it cheaper to own more of it... gives us more reason to shop on MP for not just clothes and mesh bodies, but furnishings and houses and so on...

 

This move is all about giving us more reasons to shop.

 

 

 

1 hour ago, Pussycat Catnap said:

I'll add that... some years back when MP was kicking off I was in the panic crowd over 'this is going to kill SL land, and if there aren't stores inworld, SL will die...'

But I don't see it that way anymore...

Yes most of the SL shops died off inworld. MP ones took over, and smarter designed brands use inworld shops for branding / experience...

And that DID lead to a massive chunk of mainland being abandoned and a lot of islands closing up...

So the panic was right... but also wrong. The other notion I explored back then was that MP could fill the gap... and it seems to have done so...

 

But we do now have all this vacant mainland...

So why not turn it into residential land. That's what I think some of this is about.

 

Now you've done it. Letting that cat out of the bag. You are not allowed to be so cognizant and intellectually smart as to use wise deductive reasoning in this way. They will be watching you.

The good news is that too many are not that bright and either will not believe you and poo-poo it or find an alternative opposite to attempt to debate you with.

//JUST
//KIDDING

You've nailed it: to keep the economy going required lotsa shopping. Right now LL's revenue is too heavily reliant on land use/sim fees. They need to diversify that, spread that butter over more bread without thinning it too much. So the trick is to spread all those sinks: increase land sales, then-then take any revenue lost from that and add it to other sinks, like MP commisions and cash-out fees, then add new sinks, for example: it will cost L$ to change your name and enough to prevent abuses (I dunno: L$500? L%1000? I can see that and I would even think that's fair).

So to do all this without these new and increase fees crushing the economy, they need to prop-up the economy to get us to spend more.

The above is just my own hypothesis to fill-in the blank mechanical part of what you said. hahaha

[Pussycat Catnap]

It is really not all that different from the strategy used by the "free to play" MMO games. SL is basically nothing more than an old Free to play Sandbox MMO. Any gamer can look here and see this is a video game in that model - and one which has a much larger cash shop than any free to play MMO could ever dream of.

I suspect that people buying $L to be able to shop already brings in more cash than land. It is likely that the point at which this happened was the point in time when they 'trigger was pulled' to start messing with prim limits and premium tier - and that this was planned out years ago. Because it makes a lot of sense.

Where a lot of Free to Play MMOs suffer is they are usually design studios of 10-40 developers, and they have tight themes to match their games. They just can't make enough cash shop items to get people to buy enough to pay their salaries... and they're often strapping this onto older models where they failed to include a good 'player housing' system so all people have left to buy is 'looks and styles for dungeon gear, vehicles/mounts, and pet followers'.

SL on the other hand starts as a sandbox with a primitive game engine. And it handed the developer tools over to the players. Those players found things they wanted... and made them...
- so SL has the best 'cash shop' in the video game industry, on an old MMO, that the players have updated the graphics for on their own effort, and all the developers need to do is keep making sure the tools we have to keep updating the game keep improving, and skim off the top of the cash shop just enough that we have to keep putting in money.

[Qie Niangao]

 

Quote

Gridwide Experiences - Currently, Creators can use the increased scripting capabilities of an Experience only in a region or parcel whose owner has explicitly enabled their Experience. One of the new Premium abilities will be an Experience that is enabled anywhere on the grid unless the landowner has blocked it.

Assuming that's available at an affordable Premium level, I'd find that very useful.

One thing I can't remember from beta testing Experiences, though, is whether a grid-scope Experience can llAttachToAvatarTemp() items that remain attached across region changes. I'd love to be able to auto-attach a "swimmer" that adds buoyancy and swimming anims in Linden water whenever an avatar wades out from one of my shorelines, but that would be a drowning trap if it all comes undone at the sim border, as do items temp-attached by land-scope Experiences.

(I'm also eager to know more about this new multi-level Premium program, like whether it's a menu of a la carte features, or a fixed sequence of tiered feature layers -- and if so, what that sequence will be.)

[Phil Deakins]

23 minutes ago, Qie Niangao said:

(I'm also eager to know more about this new multi-level Premium program, like whether it's a menu of a la carte features, or a fixed sequence of tiered feature layers -- and if so, what that sequence will be.)

I think that many of us are keen to find out more about that. A thread to speculate about it might be enjoyable. I think I'll start one

 

Edited March 24, 2018 by Phil Deakins

[Love Zhaoying]

4 minutes ago, Phil Deakins said:

I think that many of us are keen to find out more about that. I thread to speculate about it might be enjoyable. I think I'll start one

 

I missed that one. I speculate different premium levels may get different (or no) stipend.

[Phil Deakins]

Good one, Love. I started the thread. Perhaps you'd like to add that one.

[Aislin Ceawlin]

On 3/21/2018 at 10:18 PM, Claireschen Hesten said:

I'm fairly certain it was directly connected with the website of the TV show Gossipgirl 

Not sure if anyone responded to this, so many posts to go through! One of my best SL friends worked for the GossipGirl franchise and had one of the first avies with that name. Her job was to set up the GossipGirl house, which I had the fun of helping her with. So, yeah, it was connected to the television show. So, if you remember the GossipGirl house, you've seen my work (that telephone on the nightstand...all me)  lmao!

Edited March 24, 2018 by Aislin Ceawlin

[SultanSullyVonSwag]

Hi
1st I'd like to say this is awesome! I wish when I signed up there had been something saying "be careful what you choose it WILL be displayed" Now I can be happy and become "me"

I'd like to suggest a surname>   VonSwag

Also will a surname list be available (or is there one already) so those of us whose identities may be changing drastically to start to figure out who we will be?

 

Edited March 25, 2018 by Glayered

[Lyle Maeterlinck]

I wonder how this name change will affect HTTP request headers. Currently, outgoing http requests from second life using llHTTPRequest include the legacy name in the header X-SecondLife-Owner-Name. I'd be interested in knowing if whatever the person's mutable (changeable) name is will be the name sent in this header, or if it might be sent in an additional header, something like X-SecondLife-Mutable-Name.

[BobbyGeorge]

The real advantage of the names change, I think, will be the ability to start a new account with the forename and surname of your choosing. Foresee a flood of new sign-ups when that feature's launched.

[Allegory Malaprop]

I love the idea of last names returning.  I wasn't a fan of getting rid of them, and they made coming up with the name you wanted without a bundle of numbers much easier.  When I think of changing names though, I cringe.

Single names mark an era in SListory!  Once last names are back, YOU will become the special ones, you'll be Cher.  You don't NEED a last name, you are cool enough to be without one.  And you'll no longer be a "young" account, younger accounts will have last names, the oldbies with last names will become less "special."

And UUIDs are great unique identifiers for machine code.  They make awful identifiers when it comes to human readability.

Have a friend who's changed their name?  You can figure it ought, I'm sure!  Have an old friend who you haven't seen for a couple of years change their name in the interim?  ....Maybe.  Want to reconnect with an old friend you haven't seen in a while?  Are you even the same person or are you catfishing?  Will they trust you to be the same person?  Will they be able to find you if they are curious about you?  Alts are almost the same deal (ditto with all the stalking/ex situations), so no big deal.  Individual interaction might be a little rocky here and there, but it can be managed.  (My dad met my mother twice in RL, the first time he was bored and lonely and snowed in and told her his entire life story one night.  She got out of the cast, changed how she wore her hair, he met her again a few months later on the same campus where he superficially interacted with hundreds of people, he was convinced she was a witch because she knew everything about him- visual appearance is a key human identifier in face to face interaction, names are more "machine code" in that case, and harder to keep track of.  They aren't there on your screen the entire interaction to remind you.)

Dealing with massive numbers of strangers?  That gets hairier.

I'm sure you HAD to be considered this and decided that it just didn't matter, because it's obvious....but.

Like many people in SL, I make things.  I sell things.  I've had a running store in SL for a long ass time.  Human readable transactions means I can catch problems early- double charge?  Hey, here's your refund as I just noticed that!  Wait why am I seeing a number of sales from that person for only one color of that...ARGH I forgot to rename the vendors in packaging didn't I, fix that NOW so there's less problems later.  UUIDs as identifiers means I won't see those.  They are nonsense to human reading enough that I will just dismiss them as "close" numbers, not the same.

I've got more than a decade of transaction records downloaded from SL's website- transaction records that ONLY RECORD USERNAMES, no UUIDs.  Transaction records still do not record UUIDs.  I still have no easy access to what will be the only unique identifier, even for records that start NOW, never mind all the customer service I need to do for transactions from previous years (10 years?  Nah.  3 years?  Yes, on a regular basis I have people from the last few years who contact me for redeliveries or double purchases or assorted issues that require verification).  Will you be providing my entire transaction history for the entire duration of my account, with UUIDs, so I have records that actually work?  "Oh but people have vendor systems" isn't an answer- not everyone has a vendor system.  Vendor systems are prone to more points of failure for gaps in records due to issues with connections to the outside server, transaction records still serve as an important backup.

Will we be (finally) getting LlName2Key, and even more key (no pun intended), llRequestAgentKey(string name, DATA_KEY) that we've been asking for forever?  Every time I check the jira over the years, there's at least one request for it, usually with a Linden shooting it down (currently Dan Linden as of August 2017 says "We've reviewed your request and determined that it is not something we can tackle at this time.")  Many scripts use names instead of UUIDs for avatars that aren't the ones who actually are DOING the thing if they can get away with it because we have no easy access to keys from names.  The existing solution is to use messy third party hacks- w-hat hasn't been active in SL for years, but they maintain the only database of keys still in existence.  They don't cover everyone, keys have to be added (newer the account, less likely they have you, and this database hasn't been actively maintained in years), and keys could be added manually so make a typo or just add in the wrong key for fun?  Poison data.  The database could also disappear with no notice at any time- like all the other databases that also kept lists which have already disappeared.  The alternative is to use a proxy to ping SL servers (because you can't connect directly from SL to SL's website), and scrape a page that has to have the data in one place.  It's an inelegant hack, and relies on LL never changing the format of those pages- a format that isn't meant to be used that way at all.  Again, it can break with no notice at any time.  It also doesn't include everyone- not listed in search?  I can't get your key.  I can't get keys from some names IN ANY WAY, even manually.  While you're at it, throw in llRequestAgentList(key id) to get a list of ALL names ever associated with a key to make sorting through data easier.

Anything with any sort of access list may or may not have jumped through all of those hoops- and those that did may not have succeeded and held on to just username as a backup when they failed, because they would still function.

And that assumed you actually are willing to go through all the (tedious annoying and complicated) process of pinging a webpage or the dataserver.  Most merchants I know personally don't script that much- they may do the extent of what they need (a little light posing, some texture/transparency cycling, etc.), or they may rely entirely on scripting solutions for things that happen exclusively IN SL.  Transaction records don't.

Any way you slice it, it adds an extra bit of tedium to an already tedious process.  Looking things up for people isn't the most fun ever.  I don't mind it- I will chat with people some if I have the time, the vast majority of SL users are polite, patient, and quite nice to talk to (and the majority of those know that they are still some who aren't- doubly so if you are a merchant because they "want something"- customer service for those people will just be longer and more painful and give them yet more to argue and lie about).  That doesn't even get into the "oh hey, I remember you!  Oh yeah, last time you asked about x, didn't you?" that makes interaction with people just downright friendlier and more personable.  I've ended up chatting with customers about their cats, their RL families, their upcoming vacations, all sorts of things- and having a name to tie it to means I might remember next time if my chat log for that isn't on that computer, or I've backed it up and moved it as I do from time to time so it's not too huge.

Will you provide a warning to people upon changing their names that their friends may not recognize or trust them, that they can no longer expect customer service, that random content may break for them with no way to fix it?  Not that the problem children will pay attention, we've seen how well that mesh questionnaire has done with the proliferation of Disney characters and sneakers with Nike swooshes.

I'm sure there are many more instances I haven't even thought of that will cause issues.  This is how I SL, other people have other areas of interest that have their own hurdles.  I may have been entirely caught up in the nightmare of customer service and content breaking that I have missed other things that will effect me directly.

There used to be a practice of trying not to break existing content unless there was a good reason.  I don't see changing names being THAT good a reason, personally.  Security, yes?  Key and exciting new features on the grid?  Yes.  SL isn't the only service out there that won't let you change your name, it's not an uncommon practice to be stuck with one.

Sure, we'll adjust.  We have no choice.  We'll be a little bit crankier, a little shorter on time, a little less attentive.

So in short: cringe.

[LittleMe Jewell]

1 hour ago, Allegory Malaprop said:

I love the idea of last names returning.  I wasn't a fan of getting rid of them, and they made coming up with the name you wanted without a bundle of numbers much easier.  When I think of changing names though, I cringe.

[...]

So in short: cringe.

So basically at a recent inworld meeting for creators, LL said that you would be able to search a known previous name and get the current name.  We aren't sure about searching current to get previous ones, as that wasn't specifically mentioned. 

LL is encouraging scripters to change their products to use UUID rather than names.  They said that they will likely provide an API that will resolve names into the UUID.

A better summarization of the meeting as well as audio can be found here:
https://modemworld.me/2018/03/23/the-return-of-second-life-last-names-update-with-audio/

[Allegory Malaprop]

1 hour ago, LittleMe Jewell said:

So basically at a recent inworld meeting for creators, LL said that you would be able to search a known previous name and get the current name.  We aren't sure about searching current to get previous ones, as that wasn't specifically mentioned. 

LL is encouraging scripters to change their products to use UUID rather than names.  They said that they will likely provide an API that will resolve names into the UUID.

A better summarization of the meeting as well as audio can be found here:
https://modemworld.me/2018/03/23/the-return-of-second-life-last-names-update-with-audio/

As I said- we can find ways around them.  They won't be easy, they won't be automatic, they will waste time and effort and create frustration on all sides.

Encouraging scripting to use UUIDs rather than names is all well and good, except the tools to do that do not actually exist yet, and have never existed, so they haven't been done that way- and when people have done it using inelegant hacks because they were determined to just in case, it only sometimes has worked because there is literally no way to reliably do it.  Adding them "sometime" doesn't change the fact that they have never existed and that many things old, and CURRENT AS OF NOW, both scripts and records, will become some version of "broken" or at the very least "difficult."

[LittleMe Jewell]

1 hour ago, Allegory Malaprop said:

As I said- we can find ways around them.  They won't be easy, they won't be automatic, they will waste time and effort and create frustration on all sides.

Encouraging scripting to use UUIDs rather than names is all well and good, except the tools to do that do not actually exist yet, and have never existed, so they haven't been done that way- and when people have done it using inelegant hacks because they were determined to just in case, it only sometimes has worked because there is literally no way to reliably do it.  Adding them "sometime" doesn't change the fact that they have never existed and that many things old, and CURRENT AS OF NOW, both scripts and records, will become some version of "broken" or at the very least "difficult."

I am not a creator or scriptor, but I am confused on this.  I have a security orb that uses UUID values.  I also have a Rezday reminder item that also works off of UUID.  Are you saying these products are using some sort of hack that may not actually work correctly?  As of yet, the Rezday reminder has been perfect.  No way for me to tell on the security orb since it may or may not be tossing people when I'm not around.

[Chase01]

Having only one name combination makes me think of all the games I have played over the years and couldn't get the name I wanted because it was "unique" ... -sigh-

[Allegory Malaprop]

2 hours ago, LittleMe Jewell said:

I am not a creator or scriptor, but I am confused on this.  I have a security orb that uses UUID values.  I also have a Rezday reminder item that also works off of UUID.  Are you saying these products are using some sort of hack that may not actually work correctly?  As of yet, the Rezday reminder has been perfect.  No way for me to tell on the security orb since it may or may not be tossing people when I'm not around.

Currently for a user to just enter a name, and the script to do the heavy lifting to FIND the UUID (because let's face it, people want to enter names, they don't want to look up and copy over UUIDs), the script has to do a super weird workaround, yes.  Now, you have people show up and touch register themselves?  No problem, that works fine.  Get a key from just a name?  More complicated.  There are built in functions that exist to get names from keys- enter a key in some manner, the script can easily look up your name when you're in the same region, or a bit more complexly look up a name from a key when someone is in another region (it's built in, it just involves looking up the internal database instead of just hitting easily accessed local information, which makes the way it is handled a bit more complicated and slower).  For many many years scripters have been filing requests to add the reverse (even though no one likes using the latter way!), and been denied.

So instead, they devised workarounds that don't rely on LL to get what they wanted- they rely on someone else.  Relying on a third party is volatile and all sorts of over engineering was created to try to make this AS reliable as they could with the tools they were given.  You have to get the name, send the name to an external website, wait for the website to return the key value.

The "old way" was to use external databases that SL users compiled themselves.  They had aggressive sniffers, you could add people yourself when you found someone who wasn't in the database (which is good and bad- good because if they were missed, they were there!  Bad because user error, intentional or accidental), they were pretty great at keeping ALMOST comprehensive lists.  Failures were uncommon, but happened.  When there were multiple databases, you checked one, waited for a response.  If success, cool, good to go- if failure, try the next one, and the next one, and the next one.  As the databases aged, the people who maintained them stopped using SL and letting SL users eat their server traffic, and the remaining ones weren't as good at finding new people because the people who ran them simply weren't as active about looking, so failure becomes a little more common.  I can easily find a number of avatars that are not listed in the sole remaining database- it's still pretty good, but it's not infallible.  The older and more active an avatar is/was, the more likely they are to appear in the database.  Any object using this has always been prone to utter failure when this last database finally dies, but it was the only way for a long time.  The group maintaining this last database left SL years ago, and they left their database active as a service to people anyway, but there's no guarantee they will continue leaving it open, at which point adding any NEW avatars to any devices that use this service will fail completely.  (There are some other databases as well, but they aren't open to the public- and it only works when you have a LOT of varied traffic to build and store.  More data = less failure, it's just throwing numbers at it and hoping you beat the odds.)  Once it is gone, as long as you don't reset your scripts, once a person is registered, they're there, but you won't be able to change anything in the future.

The "new" way is to use a proxy of another website that then loads an SL website unique for that avatar name, and looks in the code for that page and finds one specific line that contains the UUID.  LL does not let SL objects hit their website directly- this is an annoying, but good, idea- it's relatively trivial to grief websites with massive attacks from in SL if you really want to do that, and LL's own site is the obvious choice, so you have to still rely on a completely unrelated website.  This is not the intended way to use that information on the SL website either, so LL has no reason to leave this data as it currently is formatted.  And any user who chooses to opt out of search cannot be found with this method.  When either website change format (the script already completely failed once and had to be re-written because something IN a site changed and had to be remade to function to the new format), all functionality fails- people still mostly use the old way with the sole remaining database, or also use it as a backup, just in case.  Once again, anyone currently registered in your object before the failure is fine.  But you can never add anything new, rez a new one and add people you had before, etc.

Using both of these methods, you can cover MOST of SL.  Failures are uncommon.  However, there is still no foolproof way that even now will always work, and neither system will age well- it's always been a matter of when anything that uses a key that had to actually find that key will break, not if.  As a result, when systems could use names instead of UUIDs, they would, as names were always stated as being unique- so why go through all the trouble if you didn't have to, when it would eventually break?  Could be tomorrow, could be ten years from now- no way to know.

Letting people change names doesn't make those systems any more reliable than not- but that's WHY people relied on them the absolute utter minimum.  If there was another way to do it by name instead, they certainly would.  That still holds true- this is the way you have to look up keys from names today.

(That said, that's less problematic for me personally than having to slog through multiple passes over years of records as I try to match up whatever name someone had at the time when they can't remember, or remember incorrectly- or going through the mess of converting all that data, which is in multiple formats because of the way SL has changed transactions over the years, to something that actually converts each format to include the newly uniquely relevant and never included information- or simply try to find someone without being completely reliant on copy/paste.)

[Phil Deakins]

6 hours ago, LittleMe Jewell said:

I am not a creator or scriptor, but I am confused on this.  I have a security orb that uses UUID values.  I also have a Rezday reminder item that also works off of UUID.  Are you saying these products are using some sort of hack that may not actually work correctly?  As of yet, the Rezday reminder has been perfect.  No way for me to tell on the security orb since it may or may not be tossing people when I'm not around.

In LSL you can get a name from a UUID ( llKey2Name() ) but there is no llName2Key() function. That's the difficulty. If LL adds it to LSL, then it would be the solution. It would require scripters to update their scripts, which would need a fair amount of rewriting in some cases, but it's relatively simple.

When a security device gets a list of avatars that are in range, it's a list of avatar UUIDs (keys), not names. The scripter converts them to names using llKey2Name() or another LSL method of getting an avatar's info. Adding an avatar to the device's white list by hand, means typing the name but, from that input, LSL has no means of acquiring the avatar's key. So, unless the scripter uses an external 3rd party database, which I think does or did exist, albeit very incomplete, s/he has no way of getting the avatar's key, and can't write a system that primarily relies on keys. I assume that, with your device, you can add someone by typing the name in, so your security device will at least partially break, even though it may be based on keys rather than names. They all use keys to some extent. They have to.

As things are now, such items as security devices can be written to work with either keys or names, although if keys, then names can't be entered by hand, not even in a notecard, at least not reliably. So all current security devices that allow the user to input names by hand, will become broken. llName2Key() would allow it to be fixed by the scripters.

ETA: The way that such devices will break is not that they will stop working. It's the ability to manipulate an avatar (add, remove, whatever) by typing its name in by hand, or adding its name to a notecard, that will no longer work. Just as now, the device will see each hand-entered name as unique. It has no means of relating it to the same avatar's previous or future name(s). It's the ability to enter a name just once for an avatar that won't work. When we can change names, entering a name will only cover that avatar in that name. It won't cover that avatar for its next and/or previous name(s). They will have to be added and deleted seperately as necessary. Not nice.

So it's not that existing security systems will become useless. It's that they will not work as they were written to work - they'll be at least partially broken. Some have a built-in workaround, such as getting nearby avatars, which means bringing the avatar within range, and clicking menu buttons to add or allow it. Mine does that but it's not the solution.

Edited March 26, 2018 by Phil Deakins

[Callum Meriman]

2 hours ago, Phil Deakins said:

In LSL you can get a name from a UUID ( llKey2Name() ) but there is no llName2Key() function.

That was mentioned as being possible when it goes live, wasn't it? I am sure I read that - if not in the original, then in a Linden reply.

 

Ultimately/ideally maybe, the function could work llName2Key("Fred.Resident") == UUID == llName2Key("Fred.NewSurname");

Edited March 26, 2018 by Callum Meriman

[Phil Deakins]

I haven't seen it mentioned, and I read the page with the audio clips. Unless there's a good reason not to add it that I don't know about, adding it is a no-brainer.

What has been mentioned is LL producing an API (Application Programming Interface) to get keys from names, which, at first thought, seems like something of an overkill when llName2Key() would work perfectly. That's probably what you're thinking of.

[Callum Meriman]

Just now, Phil Deakins said:

What has been mentioned is LL producing an API (Application Programming Interface) to get keys from names, which, at first thought, seems like something of an overkill when llName2Key() would work perfectly. That's probably what you're thinking of.

Could be! And all the name history will return the correct UUID. SO....

Someone blacklists Fred.Resident, and that will always work (as it's historical too) and nothing breaks as long as the "new" llName2Key(first.last); or it's equivalent is used. Doesn't matter if he sneakily changes his name... Fred.Resident still resolves.