llRequestNameData(string name, integer data)

Web commerce systems are already burning up a lot of resources both in game and out of game to gather and store this data. There is no additional spam risk by implementing this reverse lookup function. The data is already there.

llRequestNameData(string name, integer data)

Constant: DATA_KEY
Returns: The key of the agent.

I personally would like to setup a system to sell my own products from my own website. Right now my options for in-world delivery are:

1. Have the user pre-identify themselves by going to an 'atm' device. This is inconvenient for them and forces me to store the key/name combo.

2. Have the user know their key and enter it into the website. Obviously this is not a very user friendly answer.

3. Setup scanners at every telehub (or equivalent coverage) in world. Every scanner would constantly be scanning and sending redundant data via email or xml-rpc back to my server. There, I would have to cull out redundant information and store it. This is just a massive misuse of resources. I can only guess how many of these systems are already in place.

Some enterprising individuals are already scanning and marketing reverse lookup services. But, with this one simple LSL function all of this can be resolved.

Huh. No offense, Al, but I'm not sure quite what you're getting at with a couple of your... "store features" there. Granted, I don't use Second Life for e-commerce (largely for lack of protections relating to Intellectual Property, external and internal), but as general scripting, here are some suggestions for you.

First of all, I'll agree with you on the data lookups from name to key. Something like this, or a more compact llName2Key() with 16 returns in a sim would be pretty nifty.

However, I'm afraid I don't quite understand some of your logic for your proposed system, as stated.

First off, where is there a problem in having someone predetermine their unique key (or name) in world? Since listeners, touch events, collision events, et cetera, can all fairly painlessly call an agent's key value, in slightly differing ways, it's not conceivably painful to me to have a person or system find their key value using one of your ATMs.

Second, since the reversal of your feature suggestion, llKey2Name, works - this renders the need to store name values in-world obsolete. As for storing name/key combos at the back end... well, it all depends on the way you create your system, but I don't see that as too limiting either.

Finally, I am most confused as to your want to quote, "Set up scanners at every telehub (or equivalent coverage)." Not only would this constitute a minor breach of privacy, since many of these hubs are private - if you mean doing this for purposes of product distribution or ATM service, you just don't have to:

- If you wish for ATM service that's everywhere a user goes, I suggest you create a no modify machine for their use. This carries its own risk in the form of possible permissions exploits, but at least with those the Lindens will side with you.

- llGiveInventory, what I'll assume to be the lynchpin of your business (since Linden Dollars are generally kept in reserve within the system), works cross-sim for avatars. This renders the need to have "Access Points with content" obsolete in favor of a more consolidated service. Don't hold me to this, though - I've only tested the command thusfar with passing notecards.

Anyway, that's my two cents. Good luck.

This function is proposed as an equivalent to the llRequestAgentData function which returns data globally.



As an individual merchant, selling only my own products, placing ATMs (or actually a key grabber) throughout the world doesn't make sense. If an av would take the time to go to one, they might as well go to my main store.



My point here is that with this 1 LSL function, I eliminate the need to store a database of every known key in the world. I just access the existing game database which is 100% accurate, whereas any user created database will have missing keys.



These scanning systems exist today. Their purpose is just to gather name/key combos and send them to an off world user database. This is currently the only feasible way to gather and store this information.

You may be missing a more basic concept here. What I want is for someone to be able to browse my website, click on a product they want, type in their av name, and have that product immediately delivered to them in-world (financial transactions are handled in world via a simple script). In order to do that, I have to have their key as a parameter of the llGiveInventory function. Most people aren't going to know, nor wish to type in, their key.

Fair enough. Again, I'm not directly trying to attack you or your system - merely offer some constructive criticism that might help.

However, enter my question once again. What is stopping this system from obtaining keys or data with an attachment (if I recall the syntax, attach(key attachedAgent))? The only downside I can think of there is the possibility someone breaks into your script with a permissions exploit.

Also, I do realize that, as far as your system is concerned, this proposed command will be beneficial. That's fine.

As for existing scanner systems - that doesn't surprise me, but then, that also does not mean I have to agree with the way they work. I'm merely giving my side on how I would think it would be, beneficially, done. And I'll agree with you that, no, "key grabbers" don't make a lot of sense, so if this is the conclusion you've come to to prevent that, more power to you.

I guess the only other point of clarification would be: are avatar keys static, or are they maintained much in the same way object keys are dictated? My current understanding is that they are static, and as such, would be facilitative for a database that could effectively store them (this being one of the reasons why llGetOwner() commands in state entry continue to work after an avatar logs out of the world). If, however, they are considered "moving targets" for scripted key values, then I will humbly agree with you that it would be fairly cumbersome.

Huh?




They are static.

In response to "Huh?" - attachments, I believe, retain the ability to both make XML-RPC/Email calls and can obtain an avatar's key value fairly easily through use of the attachedAgent value. Assuming this, couldn't you make your ATM script an attachment?

This evokes, however, the possibility that there may still be some lurking permissions exploits, allowing someone to "hack" your script or otherwise since they'd have limited ownership of the item in question. That would be the downside, as I see it, but Linden Labs in general takes action against said exploits fairly rapidly, if they're found.

Jeff, the whole point is that if a person is surfing my website - they should not have to have to have previously obtained or visited any in world object. Since this is not a multi-user store, but just my products, making them obtain an attachment object by visiting my store is well... pointless. If they are going to visit my store to pickup an attachment in order to shop at my online store, what is the point? You see?

Okay. That's different, then.

And, by the way... how do you intend to deduct from the avatar's account in this manner?