Request a Key from a worn Key

[emmamei]

Might be nice to allow the general public to get a Key from a worn Key - using a menu button.

[emmamei]

The most obvious way to do this leads to putting a Key within a Key - which, when carried through, means an infinitely recursive set up is required - obviously not workable.

Can't request a copy of the actually worn key as far as I know - would have to be pointers to where the Key could be gotten from.

Could also be a part of a special Key - that is, the Key given out does not support this function. Thus the recursion value becomes 1.

[silkymesmeriser]

Having the ones that are given out lacking the feature would remove one significant advantage of having the feature in the first place, namely the viral distribution mechanism there is a way to achieve this which actually would provide an even more useful side benefit.

Essentially the key to getting this working is not to actually have the key give out the copy at all, instead you have it send an llHTTPRequest to a prim server somewhere on the grid which has a copy/trans version of the key in it's inventory the HTTP request includes the UUID of the requesting avatar and then the server does an llGiveInventory call to send a copy to the requesting avatar.

There is one large downside to this method due to SL technical issues namely prim URL's are dynamic so in order to be able to code the server URL in a way that would be accessible to the keys it would need at least one static reference URL to point it in the right direction (Essentially acting like a dynamic DNS server but for the whole URL instead) there are two such services publicly available and I could fairly easily whack one up for us too.

Downsides aside the positives of this method would be: Firstly it would work for a truly viral distribution as it would really be the same key being copied each time unlike the recursive method.

The second point here is that once you have such a server operating in SL you could also have the key's post it's version string to said server prim during on_rez so long as say 86400 second have passed since last doing so, if the version number is less than the one the server has in inventory send the newer copy or an updater of some kind to the owner of the posting key.

[emmamei]

I figured something like this would be necessary - though handing out a complete Key would be different than updating the currently worn Key I would say. At least, I'd be thinking about a process whereby the Key would copy in new scripts into itself, thus updating itself rather than getting a whole new Key.

[silkymesmeriser]

True but the same system could be used to distribute both updater and keys

[silkymesmeriser]

I just committed a couple of sample files related to this issue in the /server directory.

[emmamei]

So we have this implemented in the key - that a key can be requested as an object by anyone looking at the key?

[silkymesmeriser]

Yep it's in the help and support menu of the key itself with the real request handled by OnlineServices.

Associate Parts:

• http://api.silkytech.com/objdns translates the names to prim server URL's the same as for update checks.
• The prim servers themselves that handle getting, publishing and refreshing URL's as well as providing the vital llGiveInventory call itself.

Advantages of course this method works recursively as all keys are really served from a central server a given key is no different to an original key and can recursively give out more keys though as many levels are needed.

The one question and it's more a polish thing but should we relocate the option somewhere more visible like main menu?

[emmamei]

This seems to be done.