Allegory Malaprop
-
Posts
6 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Allegory Malaprop
-
-
10 hours ago, Qie Niangao said:
Right now we're focusing on what happens with scripts, but there's a host of other complications. Take, for example, this very forum we're using now. What's supposed to happen to existing posts when an avatar takes on a new name? If somebody references my current name in the text of a post, will that still be recognizable if my forums username updates to my new choice of name? How's all that gonna work?
Scripting is my LEAST concern over the name change. It's going to break things for people, but no one was using names in scripts because they WANTED to, they've never been a good choice. I brought it up because it's just another thing that will break, and it's just another way in which people will be inconvenienced- another way end users, who don't even know all the stuff going on behind the scenes, are going to have problems. (And because they have outright told people not to use names in scripting anymore, but to use UUIDs instead, while official necessary functions do not currently, and have never existed- people haven't been not doing it because they are lazy or bad coders.)
Names have been human readable unique persistent ID- in other words, I see your name, I know who you are. UUIDs are machine ID, nobody will remember that, use that, identify that, we aren't wired that way. I can barely remember a phone number- UUIDs are longer, have more variables, and less reason to enter in manually over and over and over and over until it gets ground into your memory.
As I mentioned before- I make things. I sell things. I have years and years of records with history of what I've sold, to who, provided by LL themselves. Entirely by name and not UUID. THAT is my number 1 primary "I will have to go through at least one extremely inconvenient way of fixing this" problem. "This will still cause me headaches for forever" problem. I will need to fix years of transaction records into a format that lets me actually access any relevant data, that I straight up need to access on a regular basis.
Additionally, human readable unique ID (names, the entire reason they have always used names) means I can see things. I can identify what is actually going on in my transaction records significantly easier at a glance, instead of having to compare long string of nonsense code to long string of nonsense code.
-
55 minutes ago, Qie Niangao said:
I'll pretty much bet that llKey2Name() will continue to fetch-up the legacy name, which is the same name it has returned since before there were display names, and that name changes will never affect those legacy names. If they do, then it would be time to worry because a whole lot of content will break.
So, you're suggesting that they will add a fifth avatar id type? UUID, Firstname Lastname, firstname.lastname, DisplayName, and Newname Newname? That would prevent script breakage- but considering they've been advocating already switching to using data to identify OTHER than Firstname Lastname even though the tools to get the UUID do not even officially exist yet and it significantly more robust all around in what you can currently do than with firstname.lastname, I have not gotten that impression.
(I don't use Name2Key for any "security" that involves people ever being present. I need to send things to people not present on the same sim, who I have never met, and have only been given names of, on a semi regular basis- so I use the hacks, and it tells me when it fails and I need to fix the significantly smaller number by hand. It is a very small number, but it's also all around not something I really trust at all.)
-
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.)
-
1
-
1
-
-
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."
-
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.
Facebook
Instagram
Twitter
YouTube
Flickr
Secondlife 15th anniversary and CEO's letter
in General Discussion Forum
Posted
The land impact and tier bonuses we've already been getting have been welcome, and lovely. Baked on mesh is amazing and incredible and makes me so happy I can't even articulate. Appliers and layers are an awful messy resource intensive hack. They aren't particularly user friendly, and they are horribly creator unfriendly. A lot of the other stuff is nice (we're going to hope in execution as well as theory!), but that one is a thing of absolute beauty that will improve experiences all over.