"Linkset Data" is coming.

[Jym Nova]

11 minutes ago, Fenix Eldritch said:

If I didn't want end users resetting the data store, I'd make the object no-modify.

I agree with this 100%, however; let's say I want an object to be modify for something like resizing "without" a resizer script or resizer functions plugged in to the existing script. 

Why should "my" script suffer at the expense of someone experimenting with scripts and wiping protected data "my" script needs to effectively operate in the object?

I'd have no objections to including a standalone script in the same package as the product to use something like: "llLinksetDataResetProtected(string pass);" (if its implemented) if the end-user decides they don't want my script in it, so they can recover the full 64KiB of LSD.

I'd also have no objections to including a copy that doesn't have a script in it all, depending on what it is.

Edited October 15, 2022 by Jym Nova

[Lucia Nightfire]

1 hour ago, Jym Nova said:

I agree with this 100%, however; let's say I want an object to be modify for something like resizing "without" a resizer script or resizer functions plugged in to the existing script. 

Why should "my" script suffer at the expense of someone experimenting with scripts and wiping protected data "my" script needs to effectively operate in the object?

I'd have no objections to including a standalone script in the same package as the product to use something like: "llLinksetDataResetProtected(string pass);" (if its implemented) if the end-user decides they don't want my script in it, so they can recover the full 64KiB of LSD.

I'd also have no objections to including a copy that doesn't have a script in it all, depending on what it is.

I'm sorry Jym, but llLinksetDataReset() is intentionally designed to remove all data, protected or not.

It was decided that in a modify environment, the end-user will always have the right to remove all data if they wish and not be burdened with the will/control of the previous owner.

I can only suggest that you use no-mod permissions to prevent this.

[Fenix Eldritch]

I get what you're saying, and the example of modify-enabled to avoid resizing scripts is indeed very valid.

But at the same time... isn't that kinda the nature of the beast with modify-enabled objects in general? Once they get into the hands of the next owner, all kinds of hijinks could occur. And while some things can be defensively programmed for, not everything can be warded against to keep the script going. It feels reminiscent of a script depending on specific prims being at specific link numbers and/or having specific names/descriptions. If the user (or a new user added script) goes and alters the linkset drastically to the point of changing all that and the script breaks, in my mind I'm thinking "well yeah, what did you expect?"

I had added a last minute thought to my previous post (now on the last page) which I think is the essence of my issue. Reposting it here:

I think my main concern here is the prospect of a datastore getting filled with obsolete junk entries from previous owners over time. Because if we can't remove them when they are genuinely no longer need, the store will be rendered unusable for that item.

26 minutes ago, Jym Nova said:

I'd have no objections to including a standalone script in the same package as the product to use something like: "llLinksetDataResetProtected(string pass);" (if its implemented) if the end-user decides they don't want my script in it, so they can recover the full 64KiB of LSD.

Now that's an interesting thought. Though what if we approached it from the opposite direction? What if the creator provided a standalone script to repopulate the necessary kvp entries the main script needed in the event they were removed? That way, the user has a means to recover the item to its initial state.

[Jym Nova]

48 minutes ago, Fenix Eldritch said:

Now that's an interesting thought. Though what if we approached it from the opposite direction? What if the creator provided a standalone script to repopulate the necessary kvp entries the main script needed in the event they were removed? That way, the user has a means to recover the item to its initial state.

I love this idea!

OK, I will gladly stand down from my suggestion to negate Protected Data from llLinksetDataReset.

I didn't even think to do it in reverse. I could definitely include a script to re-add the linkset data for recovery purposes.

Edited October 15, 2022 by Jym Nova

[sirhc DeSantis]

Been a fascinating read. All I can add is that some sort of data storage I would have loved some, oh times go by.. close on 16 years ago. Yes I do have access to 3 'experience' wossnames but the only thing that caught my attention was this ability. This ranks up with Slice being added to lsl. So however it goes, I have a happy

[Quistess Alpha]

3 hours ago, sirhc DeSantis said:

Slice being added to lsl.

*raises hand* Uhm, what's "slice"?

[Kadah Coba]

11 hours ago, Jenna Felton said:

Thank you Rider, having protected keys is cool, but I'd like to have a way to get access to protected keys to some degree without having a password. Because there are applications extensible via plugins, be it scripts installed into the application or (never seen but possible) linked to core prim. The core script and the plugin script can be by different creators.

Now the core script may want to maintain some keywords while plugin scripts would have only read access to them unless the developer or the core script made the write or deletion password known to the plugin script.

I would suggest to create protected key like this:

llLinksetDataCreateProtected(string name, string pass, integer level);

while level defines if the key is read protected, write protected, delete protected.

• Write protection inherits read protection (read protected key needs password to be changed)
• Delete protection inherits read and write protection.
• Write protected keys can be read without password but not changed
• Delete protected keys can be read and changed without password but not deleted.

Edit

Better to separate creation of the key and actual writing because this will avoid to change the protection level every time you change the content. After the key is created it can be changed via llLinksetDataWriteProtected as defined.

 

 

 

Much of this would possibly be better implemented as a custom link_message API instead.

Read-only keys could be handy though. More so if we get remote access from other objects (unless that is purely read-only).

8 hours ago, Jym Nova said:

This is great to an extent, I was going to say, I read through the first 4-5 pages and didn't see my concern(s).
Of course I'm not seeing the details of the 3 new added functions either.

I strongly disagree with "Protected keys are removed by a call to llLinksetDataReset."
Maybe negate protected keys & values by adding: llLinksetDataResetProtected(string pass);

#1 is Security, should I decide to distribute a "modifiable" object, anyone can read the data.
`llLinksetDataRead` which appears you have managed a solution: `llLinksetDataReadProtected`
What about: llLinksetDataListKeys? are protected keys negated or still fed in to the list?
> Not good if the data is meant to be private.
(I foresee this being great for HUD's though, since they will almost always be no modify)
(I don't care if they want to count how many keys I have or know how much data is available)

#2 is Persistence, should I decide to distribute a "modifiable" object, anyone can wipe the data.
> Not good for modifiable objects if you want persistent data.
`llLinksetDataReset` currently would wipe all data, even the protected keys.

If a resident has mod on something they own, they have the right to break it. We kinda don't need more slam bits.

[KT Kingsley]

10 hours ago, Quistess Alpha said:

*raises hand* Uhm, what's "slice"?

It's one of the deformations you can apply to some prims: it trims off its ends on the Z axis so, for example, you can make a cube paper thin. This once had to be done using an exploit: making a sphere, giving it a dimple, and changing it to a box. 

Edited October 16, 2022 by KT Kingsley

[Jenna Felton]

19 hours ago, Kadah Coba said:

Much of this would possibly be better implemented as a custom link_message API instead.

Read-only keys could be handy though. More so if we get remote access from other objects (unless that is purely read-only).

If a resident has mod on something they own, they have the right to break it. We kinda don't need more slam bits.

I think most of what was asked here can be done by using a script in the linkset and using it as an API: Chat messages for access the store from outside and link messages to access from within the link set (when the keys are protected). The script would respect the access level of the keys and allow or block the operation request.

Only when we want to avoid extra script in every linkset using a LSD store, or the overhead of messages between scripts when the scripts could read and write to the store directly, then we need the inter-object access, access levels and pins.

I think by now all of the applications using LSD store will have a script in them and so the current definition is sufficient. But I have a strong feeling requests about opening access from the viewer UI or from other objects will remain and follow and with it the access pins and levels. Because this will save the extra scripts and messages and allow interesting use cases.

And because of that, I want throw something else into the round, but related. When the LSD store is only under control of one installed script, then this script can define the names of the keys fully as it wants. But when we want to give access to different scripts, made by different creators, or to let viewer access the store, than we need to invent a simple semantics. This way you can also link LSD stores and the keys will mostly not interfere.

I suggest to build key names from hierarchical prefixes. connected by a dot. The first (main) prefix will identify the instance that (mainly) uses the key. For example I made a HUD and I'd like it to remember the position on screen, for every HUD slot. The script is the 'core' script, so I call the keys "core.pos.ltop", "core.pos.center", and so on. A plugin script for this HUD that is meant to style my attachments would use the main prefix "style" and the keywords would be e.g. "style.color.theme" or alike.

When I want to allow others to write plugin scripts for my HUD, I'd have to define a system that allows the creators to name the keys so that they not clash. The simplest and safest way might be to use their avatar key or login name as main prefix. I would then define such system in the user manual for my HUD or give it with the dev kit I release.

However, I'd also suggest to reserve the names of each TPV from the TPV list as prefix to avoid. And the prefix "viewer" as a common prefix to use by all viewers. The keys with them as main prefix will be used by the viewer when the viewer would get the direct or indirect access one day. When by then there will be objects on the market using the prefixes, then the viewer could have damaged the objects.

As for viewer access applications. For example the viewer could store the last region and last position under keys "viewer.last.region", "viewer.last.position". Then not only firestorm will be able to rez the object at the position it was picked up and even then when the object was picked up with an other viewer or by someone else (when the keys remain stored.) Also, every TPV could then store the own information into the LSD store of a linkset under their own main prefix.

Edited October 17, 2022 by Jenna Felton
typonese

[Kadah Coba]

9 hours ago, Jenna Felton said:

I think most of what was asked here can be done by using a script in the linkset and using it as an API: Chat messages for access the store from outside and link messages to access from within the link set (when the keys are protected). The script would respect the access level of the keys and allow or block the operation request.

Except chat messages aren't fully reliable.

9 hours ago, Jenna Felton said:

As for viewer access applications. For example the viewer could store the last region and last position under keys "viewer.last.region", "viewer.last.position". Then not only firestorm will be able to rez the object at the position it was picked up and even then when the object was picked up with an other viewer or by someone else (when the keys remain stored.) Also, every TPV could then store the own information into the LSD store of a linkset under their own main prefix.

Pretty sure that's gonna earn a special meeting if a TPV releases such and not cleared with LL first. :p

[Jym Nova]

Pretty sure my concerns have been addressed one way or another. I just want it live on Agni now. LoL

[Kadah Coba]

10 hours ago, Jym Nova said:

Pretty sure my concerns have been addressed one way or another. I just want it live on Agni now. LoL

Except that whole "crashes the region on key doesn't exist" thing.

[Kyrah Abattoir]

On 10/15/2022 at 1:38 AM, Rider Linden said:

Documentation for the LSL functions is up on the wiki but not yet linked to the main functions page. You can find it here:

https://wiki.secondlife.com/wiki/Category:LSL_LinksetData

On this roll I've added three new functions

llLinksetDataWriteProtected(string name, string value, string pass);
llLinksetDataReadProtected(string name, string pass);
llLinksetDataDeleteProtected(string name, string pass);

These functions create "protected" keys in the datastore. In order to update, read or delete a protected key/value pair you must provide the same pass string that you supplied when it was originally created. Protecting a key incurs a 32byte overhead in addition to the value and key length. 

Writing to a protected key without the correct pass string will fail and return LINKSETDATA_EPROTECT.  Reading a protected key without the pass string returns an empty string, and attempting to delete one fails silently. 

In the linkset_data event when writing a protected key, the value parameter will always be an empty string. 

Protected keys are removed by a call to llLinksetDataReset.

Why would you prevent the user from deleting keys and recover storage on objects they own?

[Zi Ree]

23 minutes ago, Kyrah Abattoir said:

Why would you prevent the user from deleting keys and recover storage on objects they own?

llLinksetDataReset() helps here.

[Lucia Nightfire]

2 hours ago, Kadah Coba said:

Except that whole "crashes the region on key doesn't exist" thing.

That "should" have been fixed Sunday.

I wasn't able to crash Mauve again with my testing.

I encourage everyone to try, though, heh.

Edited October 17, 2022 by Lucia Nightfire

[Kadah Coba]

1 hour ago, Zi Ree said:

llLinksetDataReset() helps here.

Someone(s) was requesting that llLinksetDataReset() doesn't reset locked keys.

I disagree with that as well. If its mod and I now it, I should be able to break it.

Edited October 18, 2022 by Kadah Coba
Spellerizing

[Rider Linden]

Yes, the roll on Sunday should have fixed the empty key crash.

Today's roll is hopefully the last before RC. 

[Jym Nova]

2 hours ago, Rider Linden said:

Yes, the roll on Sunday should have fixed the empty key crash.

Today's roll is hopefully the last before RC. 

Does that mean Agni? or all regions on Aditi?

[Rider Linden]

2 hours ago, Jym Nova said:

Does that mean Agni? or all regions on Aditi?

The RC channels on Agni. But I need to convince QA first. 😉 

[Kadah Coba]

29 minutes ago, Rider Linden said:

The RC channels on Agni. But I need to convince QA first. 😉 

Tell them they can either QA this or PBR this week. :v

[Coffee Pancake]

1 hour ago, Rider Linden said:

But I need to convince QA first. 😉 

Bribe them with a very large smoothie.

[Kyrah Abattoir]

16 hours ago, Zi Ree said:

llLinksetDataReset() helps here.

Then what's the point of a protected delete function?

Edited October 18, 2022 by Kyrah Abattoir

[Wulfie Reanimator]

48 minutes ago, Kyrah Abattoir said:

Then what's the point of a protected delete function?

It wouldn't be ideal for scripts to be able to hog the entire data store, either maliciously or by accident (such as changing and/or forgetting what password you used, or accidentally creating protected keys and forgetting to remove them). The protected keys shouldn't be permanent, so a function like llLinksetDataReset should be able to get rid of all data.

The protected write/delete functions have their use for managing individual keys. 🙂

It should also be noted that making a new copy doesn't get rid of any keys, those get copied too.

Edited October 18, 2022 by Wulfie Reanimator

[Lucia Nightfire]

1 hour ago, Kyrah Abattoir said:

Then what's the point of a protected delete function?

This allows a mod product's end-user to add their own links/scripts/functionality with their own storage with their own passwords and keep existing scripts "happy" while also preventing existing scripts from accidentally/intentionally breaking things without having to go "all-in" and reset data.

Granted, an application's protocol could have still been set up to wipe all data naturally/occasionally and without being nefarious or to satisfy a previous owner's control.

It's like multiple people living in a dorm, respecting each other's space and property and not kicking each other or their property out. Coexistence.

It's also like the "Good fences make good neighbors." proverb.

Edited October 18, 2022 by Lucia Nightfire

[Jenna Felton]

When you not want that your neighbor eats your yogurt from the commonly used fridge, do not let them live with you. But when they move out and left back their pudding, you want to be able to clean the fridge despite there are yogurts and pudding with other's people names on them. Something like that

Means do not install scripts that call llLinksetDataReset despite being plugins but the main script must be able to clean the database this way after the plugin scripts left protected keys after de-installation.

Edited October 18, 2022 by Jenna Felton