Transfer of Savedata - Possible solutions

[ValKalAstra]

So this is something that came up in my everlasting effort to feature creep the hell out of my project. It's a product that among other things, is meant to offer the ability to save data and to transfer it to other users. Basically "oh yeah, how about you try this! *throws over savefile*". The basic functionality works via a type-casted list with an added SSH hash. Saving and loading works without effort, all that needs to happen is that the resulting string moves from A to B.

Transfer solution A:

Export into chat using llOwnerSay. Have user copy and paste the Savedata into a notecard. Loading is simple - drag the notecard onto the HUD, done. Uses a rudimentary function to clean up chat names, timestamps etc. Sharing possible via the exchange of notecards. Pro: About as simple as it comes. KISS and all that. Done already. Can't be used to grief. Con: Prone to user error.

Transfer solution B:

Use a Savestick. An Attachment that is sent the data upon button press and which then stores it in the item description of the attachment. Sharing possible via the exchange of the savestick. Loading would be - attach, then click button. Pro: No fussing around with chat export. Cons: Safety. In theory someone could make a pretend attachment, pass it around as genuine and do harm that way. I thought about adding a function to shout warnings if the savestick was tempered with or I'm not it's creator but by then the damage would be done already.

Transfer solution C :

Do it file swap style. If both recipient and sender are in the same Sim, theoretically nothing I know of stops me from just sending it over a mutually agreed chat channel. Pro: No fuss with any notecards or prims. Cons: I think it only really works if both are in the same Sim? Would limit it to online only, same Sim and also would need a whole three way handshake system.

Transfer solution xyz:

???

---

Honestly, I'm not sure which way makes sense. I'm probably overthinking it. Still, I figured I'd poke in and see if I'm missing an obvious or more elegant solution than just having the user hand-copy a random gibberish looking string or opening a potential security risk vector on them. So, if I just need a good smack and just KISS - I happily take it. If solution B makes the most sense, it can be done. If there's a solution that makes a lot more sense - then I don't know it and could use a pointer towards it.

Thanks in advance.

[Quistess Alpha]

KVP would be decent for this, but the 2 parties would both need to be on land with the experience enabled.

Also, for grid wide, you could send the data over an http connection (or Email, but in this scenario that gets all the downsides and none of the benefits between the two) rather than a chat channel: person A clicks their thing's button and it requests a URL, and says it to person A. person B puts that URL into their thing somehow. person B's thing http requests the URL. person A's thing HTTP responses the data.

Also FWIW attachments are not "safe" for storing data if the user is jumping between sims a lot. I worked on a system ~9 months ago that stored data in a HUD, and there have been complaints that crashing on region crossings caused people to lose some or all of the data stored in the HUD. You'll probably want some way to store backup in some object or system that is not attached.

[Jenna Huntsman]

Without knowing exactly what you're doing (I'll work on the assumption that you want to transfer data from avatar A to avatar Z), I'd personally go for option C, as that allows you to make 100% sure when sending data that it goes to the right person, and cannot be intercepted and tampered with (namely, using llRegionSayTo() ).

You'd need a system to generate a random (but predictable given the right information) channel to transfer data on, then you can decide what model you'd like to use to transfer data (the 2 methods I use are either a compressed data-dump or a question > response style interaction).

[ValKalAstra]

31 minutes ago, Quistess Alpha said:

KVP would be decent for this, but the 2 parties would both need to be on land with the experience enabled.

Also, for grid wide, you could send the data over an http connection (or Email, but in this scenario that gets all the downsides and none of the benefits between the two) rather than a chat channel: person A clicks their thing's button and it requests a URL, and says it to person A. person B puts that URL into their thing somehow. person B's thing http requests the URL. person A's thing HTTP responses the data.

Also FWIW attachments are not "safe" for storing data if the user is jumping between sims a lot. I worked on a system ~9 months ago that stored data in a HUD, and there have been complaints that crashing on region crossings caused people to lose some or all of the data stored in the HUD. You'll probably want some way to store backup in some object or system that is not attached.

Interesting. The HTML or E-Mail thing I would rule out as I want the system to be independent of external services. So there can't be any surprises with servers going down. Thank you for the suggestion though and I'll clarify in the opening post.

The lost save data is interesting as well. My idea was to store it in the object description, thinking that would persist: https://wiki.secondlife.com/wiki/LlSetObjectDesc. But thank you for the warning, much appreciated.

19 minutes ago, Jenna Huntsman said:

Without knowing exactly what you're doing (I'll work on the assumption that you want to transfer data from avatar A to avatar Z), I'd personally go for option C, as that allows you to make 100% sure when sending data that it goes to the right person, and cannot be intercepted and tampered with (namely, using llRegionSayTo() ).

You'd need a system to generate a random (but predictable given the right information) channel to transfer data on, then you can decide what model you'd like to use to transfer data (the 2 methods I use are either a compressed data-dump or a question > response style interaction).

Aye. To clarify:

1. User 1 saves Data.
2. User 1 gives User 2 the data in some way (notecard, prim, etc)
3. User 2 loads Data.

And yup, that was roughly how I imagined option C to go. You'd basically click transfer, select the user you want to transfer it too, the script would negotiate a negative comm channel and transfer the data, sending back a confirmation when received.

 

[Quistess Alpha]

1 minute ago, ValKalAstra said:

Interesting. The HTML or E-Mail thing I would rule out as I want the system to be independent of external services. So there can't be any surprises with servers going down. Thank you for the suggestion though and I'll clarify in the opening post.

HTTP and lsl Email are SL internal services. see llEmail and llRequestURL.

[ValKalAstra]

Oh? *blinks* That I would not have expected, always glancing over these because I thought they were meant to interact with external services. Well, then I've got a lead, it seems. Thank you!

[Quistess Alpha]

8 minutes ago, ValKalAstra said:

Oh? *blinks* That I would not have expected, always glancing over these because I thought they were meant to interact with external services. Well, then I've got a lead, it seems. Thank you!

Yeah, they ~can be used to communicate with external things, but they're quite useful on their own. Not to distract form your main discussion, but some use cases:

• In-world server: If you have land you can permanently place a prim on, you can emulate external-database solutions using only in-world tools, although obviously not 100% as robust. Email is used to send low-volume or moderately important info to the server-prim, and to update the client object with its current HTTP address. HTTP is then used for fast and higher volume data transmission. The server can be on an experience enabled parcel, and always have access to KVP for long-term data storage.
• data-out: This is a bit subtle, but sending data over http is actually quite useful for giving users binary data *hint hint*. if you can nudge someone to open your prim's obtained URL in an external web-browser, they can save whatever page you send them to their harddrive. Getting the data back into SL isn't 100% user friendly. if you don't trust people to know how to copy and paste. . . create a new script -> edit it -> file -> load from file (choose file saved to) -> ctrl-a ctrl-c open a new notecard, edit it, ctrl-v. I could have sworn it was also possible to load a notecard from disk

[Mollymews]

On 6/24/2022 at 4:41 AM, Quistess Alpha said:

Also FWIW attachments are not "safe" for storing data if the user is jumping between sims a lot. I worked on a system ~9 months ago that stored data in a HUD, and there have been complaints that crashing on region crossings caused people to lose some or all of the data stored in the HUD. You'll probably want some way to store backup in some object or system that is not attached.

picking up on attachments

the issue is that changes to attachment properties are only safely saved in all cases when the attachment is detached. So if the updated property data is critical to the app then is best (at this time) to prompt the user to detach and reattach the object after the data update

one day maybe Linden will fix this so that all attachment property changes are persistent and can survive crashes and borked region crossings

[Quistess Alpha]

13 minutes ago, Mollymews said:

prompt the user to detach and reattach the object after the data update

Yeah, would be better to automatically force a detach and reattach rather than a strong suggestion. detaching is easy enough, and re-attaching is easy wit RLV (detaching with llDetachFromAvatar while @detach=n is restricted would probably fulfill the inventory reset) but for things where you can't reasonably expect people to have RLV on, . . . I've never gotten secondlife:///app/inventory/<id>/select to do anything. 

[Mollymews]

On 6/24/2022 at 2:36 AM, ValKalAstra said:

Transfer solution B:

Use a Savestick. An Attachment that is sent the data upon button press and which then stores it in the item description of the attachment. Sharing possible via the exchange of the savestick. Loading would be - attach, then click button. Pro: No fussing around with chat export. Cons: Safety. In theory someone could make a pretend attachment, pass it around as genuine and do harm that way. I thought about adding a function to shout warnings if the savestick was tempered with or I'm not it's creator but by then the damage would be done already.

if this a universal data transfer system (applicable to a wide variety of uses) then I think attachment savesticks are the way to go

in application, a savestick is no different to any other kind of HUD attachment that communicates with a data receiver object. The data receiver script validates the sender before it uses the data. When the receiver doesn't recognise the sender (savestick in this case) then it ignores the sender/sender messages. Validating  a sender is a fairly well-documented procedure

users also understand how attachments work. They also understand how attachment delivery works as well.  Receive it into their Inventory, find it, wear it, and done

[Mollymews]

1 minute ago, Quistess Alpha said:

Yeah, would be better to automatically force a detach and reattach rather than a strong suggestion. detaching is easy enough, and re-attaching is easy wit RLV (detaching with llDetachFromAvatar while @detach=n is restricted would probably fulfill the inventory reset) but for things where you can't reasonably expect people to have RLV on, . . . I've never gotten secondlife:///app/inventory/<id>/select to do anything. 

i would like a llReattach function as well. Which combines detach and attach into one call (Not sureif this is even possible tho for the general case, where an item could be anywhere in the user's inventory) Might be able to be done in some way with My Outfits links? not sure exactly how tho

[Gayngel]

I have to recommend using Google App Script to a spreadsheet or doc as an external service because I've had virtually no downtime in the last 10 years using the service.