Allow users to update/'patch' scripts?

Okay, I'm making some items with pretty complex scripts. Now I'm taking every precaution and testing every eventuality I can think of, but just like in real-life there are circumstances I may not have considered, and it may require me to distribute an updated script.

The question though is, how in the hell would I do that?

My thought is that users could go to the store and pick up a free updater object for their product. Once they've done this they place it near the appropriate item(s) which will have some system of listens designed for facilitating this update.

I'm assuming that the llRemoteLoadScriptPin() function is what I'm after?
But does this allow a no-copy, no-modify script to be transferred (the script doing the sending and the script being sent would both have the same owner)?
If not, then is there a way to keep the script from being pirated rather than used for its intended purpose?

These are complicated scripts so I don't want them leaked, but at the same time I'd like to make updating as easy possible. These aren't items that can be easily carried to the store, they're things for shops and homes, they'd have to be taken from the building and rezzed on my land before the update could begin. Which isn't the best solution.

Have the object email a server every time it is rezzed. Have the email send the version number and owner key. If it does not match the most up to date number then giveinventory them a new version. Goes without saying you would want to add some encryption as well.

Hmm, GiveInventory works from anywhere? That's handy thanks! So if I give the script to this object, what state will the new script be in, does it reset or receive a changed() event or such?

Also, when then is the easiest way to read the e-mail from PHP? I'm fine with PHP for everything, but have never dabbled in receiving e-mails through it.

The problem is that that technique will only work if you are sending no-transfer objects, or at least objects you don't care about people giving away. Unless, of course, the object would refuse to work after detecting that it's an old version.

Actually, just handing the object a new script won't work, because scripts sent through llGiveInventory arrive not running, and for some reason cannot be set running through llSetScriptState. I think they're suggesting giving the person a whole new copy of the object.

Hmm, what about like:
- Object v1.0 request update, e-mail is sent
- Updater receives data from server
- Object v1.1 is given to Object v1.0 which rezzes it at it's location
- Object v1.0 transfers it's contents to Object v1.1 (in case it's a vendor or such so has textures etc inside, and settings file information)
- Object v1.1 deletes itself

Would that be better, or is it just asking for trouble?
Since the new object would be no copy, it can still be rezzed (but would be removed from inventory). The same would be true of items dropped into the object I suppose? Then it's just a matter of making sure the settings files don't get out of date, but that's not a huge concern I think.

I hope you mean 1.0 deletes itself. That would be a nasty update otherwise...

The old object would have no way of knowing that the new object arrived in the user's inventory, and objects that are not currently rezzed cannot run scripts. In the case that your server was not running correctly for some reason, or the sim the avatar was in was lagging, the old object could end up deleting itself and a new object might not be forthcoming. This would lead to one pissed off customer.

-edit: Objects can also NOT give their inventory to other objects.

Doesn't llAllowedDrop() allow an object to drop inventory into another object? If that were the case then once Object v1.0 sends the request, it switches Allowed Drop to TRUE and waits for an inventory change, when one comes it knows the object has arrived and can rez it, if it rezzes then it gets a key back so it can confirm the new object is there and delete itself.

And erm...yeah Keiki that's a typo! Wouldn't want to go to all this effort just to do that!

When the user comes into the shop for the update, they rez the object to update and click on the updater. The updater calls llSay(magic_number, "challenge,"+llDetectedKey(0));. The script to be updated checks the challenge and the owner key to make sure it's owned by the right guy responds with llSay(magic_number, "response,"+llGetKey()+","+random_pin); and deletes itself. The updater then calls llRemoteLoadScriptPin() to load the new script into the temporarily unscripted object.

So there's no way to do this from a longer range or anything, has to be same sim? That means an awful lot of rezzing things on my land, I don't have many prims lefts over =(

Seems to be loads of inflexibility in scripting that really shouldn't be there. Like my other thought was to have the updater allow drops onto it, if you drop an item with an update available then it checks the item (matches UUID, scans contents) and then gives the updated item.
But there's no way to fetch an inventory object's owner (unless I'm missing something) and no way to check an inventory item's contents.

I think I'm going to send a proposal for unlimited range on llRemoteLoadScriptPin(). That combined with the server e-mail relay would allow for actual item updating. Because a lot of these work-arounds seem a bit too much hassle for what they're worth. I'll put the functionality there anyway, just in case.

On which, being able to IM an object would be bloody handy. I don't see why this isn't in already as well! All the hassle of e-mailing and stuff really seems very roundabout!

That's the object's key, the UUID is what you get in inventory. Unless it's different for objects than for textures.

patchwork of ideas

take the userkey name and product and send it to email (backlogs)
when the new one comes out make a distro box to send inventory to all the listed users
place the updater on the old version.
then replace objects and dialog the user to confirm deletion of version 1.0

Going from memory here, but I remember this being discussed in an earlier thread. This is roughly the strategy I remember thatw as proposed:

* Have your object email a well-known off-world address. Doing it on rez would be a little heavy, maybe on rez if it detects that today is a different day from the last time it was rezzed, so it send at most one email a day. In the email put the owner, object name, object version, whatever.

* Use a simple email forwarder on your ISP/webhost/whatever to send this email to a "server" object in SL. Using an external email address means that if you re-rez your server and it changes its key, you just need to change the auto forwarder, all the objects you've sold will still work because they use the off-world address.

* The server receives this email, and checks the object/owner/version to see if an update is needed (is there a new version, have I already sent this guy a new version, and so on). If the update is needed, give the owner a new object. If not, do nothing.

You could also do the DB lookup on your webhost, and send an email to an in-world 'updater' object if an update needs to be sent out, saying send X version of Y object to Z avatar.

What you won't get with this is an update that maintains the state of the original object. So if it's a vendor, the customer will need to transfer inventory from the old vendor to the new. Data saved in scripts etc. will be lost/reset. I'm not sure there's any easy way to do an update that retains state.

One could build some sort of system to transfer required memory between the old script and new script.

What I've done so far is set-up my script to e-mail an outer address, sending it's owner ID (so they can be messaged) and the version number as well as couple other bits and pieces.
It also gives itself a script load PIN number and opens a remote channel, this means my options are open on how to administer an update.

Fortunately settings shouldn't be a problem as these can be transfered from the original object (it could send it's settings to the new object automatically I think, llGiveInventory() works for objects if they're in the same sim, right?
Dunno about vendor contents, it might be able to do the same for that as well, since any no-copy items will be transferred, rendering the original useless (but that doesn't matter anyway).
Unless of course all I do is give the owner an updater item, they place this near the object they are updating and it replaces the main script, this way all settings and inventory remain intact.

Updates are only performed if the owner chooses to in the options dialogue (or before switching the object on). I think I'll probably have my shop keep track of which object's people buy, so I can IM them when an update is available (but not for any other reason, that would be spam!).
In fact I could put that on a server which would avoid the silly problems with lists overflowing memory.

yes. yes they can. In most glorious and destructive ways.

Why don't you just give them an "updater". It'd be no mod no copy, and when it's run it does the update (or fails) and derezzes itself. Or even *not* derez itself, since every updated object has to have the old script in it already, there's no reason not to let the guy run an update party in a sandbox, or pass it on to someone else who needs to update their item.

I've planned on using an "update pyramid" that can be passed out. Rez one near the object-to-be-updated and it does a secure handshake with the unit, then proceeds to install new scripts/items as needed. It can then self-destruct. I would make them copy-ok so multiple units can be updated with a single inventory item.

The "secure handshake" I leave as an exercise for the reader. I'd rather keep my algorithms private for that sort of thing.

Can you give me some rough idea on the "secure" handshake thing? My thought was to have the e-mail send the object ID and script PIN number to an e-mail address and my server then takes a note of these. Once the updater is given then it would send out a request to the script which triggers a reply (it doesn't matter what the request or reply is, just as long as there is one). It can then use any replies to work out which object is nearest to it, it then sends a request to the server for the object's PIN number.
Once it has this it can remote load the new script into the object, and any other valid objects within range that have been asked to update themselves (ie that have PINs on my server).

The thing is though, if the script to be remotely loaded is no-copy, can it be remotely loaded into multiple objects, or just one (in which case I give out multiple updaters as required)?

Anyway, does that sound about right, or is there a better way to do this? I'll take the extra step and encrypt the e-mail data, especially with the central 'server' object in the store (I'm designing myself a nice fancy rack-server to sit in the house part of my store ^_^)

[edit]
In fact, I probably wouldn't even bother with sending a chat message to objects, I'd just use a sensor for things created by me and check them all.

That almost excites me as much as it frightens me.

I would use negative-channel chat to do the handshake. The typical method would be a challenge-response system where the updater will send out a challenge request, the updatee would send out its own challenge in return. Once the updater has satisfied the challenge with the correct answer, the updatee answers the first challenge.

How secure you want to make the handshake with determine how complex the challenges are. Obvious elements to combine are time, ownership, creatorship, version numbers, "magic" numbers, and math formulas. Even though the chat could possibly be snooped, variables in the challenges would make each unique rendering the usefulness of snooping nill.

Updater Challenge: 18A43EE58AFF232834-299C-473D-BE45D2
Vendor Challenge: 98323BED3D7761384-3345-9FE3-DE4D53A1
Updater Answer: 45BD3EF284889A45-04Df-30B4-C0C57182
Vendor Answer: F75C04089127A4B6-3372-C304-5957D3EB

Both are now satisfied each is what it says it is. Script pins can now be agreed upon and updating can commence.


(If you want an overly simple example...)

Updater Challenge: "what is the current hour multiplied by 73?"
Vendor Challenge: "what is the first 4 characters of your key, divided by 18?"
Updater Answer: 253
Vendor Answer: 511


If all you are doing is a script update, with no inventory transfers, you don't even need the handshake. Just a "prepare to be updated" which signals them both to generate a script pin based on various factors including the time. Then the updater attempts to do the update with that pin. If they didn't both have the same formula, then the update will fail.

Hi, I ran across this thread and thought I'd add my .22 peso's. First, let me see if I understand this all correctly, are we talking about having an object auto-update itself, or would the update be given to an owner and then they update it? Either way, am I understanding this correctly in that an object can dynamically load script?

Second, for secure handshakes, stay with standardized norms, people who don't share their algorithms are typically using silly xor ciphers that are easily broken the minute a spot of zero's is hit, in the industry we tend to call this type of stuff 'encraption'. You should look at how this is done 'in real life', namely look at public key encryption, challenge response or even symmetric encryption.

Silly things like negative channels are easily brute forced, (for (i = (2^31-1)*-1; i < (2^31-1); i++) { llSay(i, "abracadabra"; }, and you shouldn't depend on those types of things for security.

Like I said, stick with publicly known standards, and if your security depends on no one knowing how it operates, you're not secure. Bruce Scheiner has a bunch of source code for various crypto implementations on his website, use that as a reference to code a known algorithm.

Even using a symmetric cipher would probably be sufficiently strong, I'd probably update the keys on each update and provide a means for you to override and upload a new key if anything goes wrong.

Does this depend on the original script being configured for being updated? I have problems that I find I may need to update something that doesn't have any functionality within the original script for being updated.