Skip to content
This repository has been archived by the owner on Feb 28, 2024. It is now read-only.

[BUG-139168] Feature Request - Mod Keys. An environment where secure, remote no-mod object manipulation can be achieved. #2388

Open
4 tasks
sl-service-account opened this issue Oct 3, 2017 · 24 comments

Comments

@sl-service-account
Copy link

sl-service-account commented Oct 3, 2017

Please do not triage until November 1st or later.

Dear LL, You will NOT have time to tackle this feature at this time, but it is a major feature that I hope can be discussed at next feature summit for consideration into possible implementation in 2018.

Problem

  • Creators of have long needed a means to allow accessorizing/outfitting of their products via linking of their no-mod accessories/goods to their base no-mod creations.

  • Current break and create link functions cannot work in a no mod environment.

  • Link change permissions are not third party product friendly, efficient and/or feasible.

    The advent of Animesh further exemplifies the need for a new remote and secure means of no-mod object manipulation.

    Solution

    This feature request is for a new "Modify Key" object parameter and new functions to work with said parameter. Mod keys are not exposed to the viewer, nor can they be read by script.

    llSetModifyKey(key mod_key)

    Applies modify key to every link of the object the script is in.
    Applying a null key removes the mod key from every link of the object the script is in.
    Mod keys survive taking into inventory and rerez.
    Mod keys do not allow users to modify no-mod objects through the viewer, only through the new functions that require correct mod key inputs.

    llBreakObjectLinks(key mod_key, key id, list link_nums, list handling)

    This function breaks link(s) in a target object. Target object can be the same object the script is in or a different rezzed object owned by the same owner. The target object must have a mod key set that matches the input used to successfully break links.

    • key mod_key - Modify Key input (cannot be NULL_KEY)

    • key id - prim UUID in same region

    • list link_nums - list of link numbers to break from object

    • list handling - protocols for broken off links

      |flag name|default value|description|
      |
      |-|-|-|-|
      |BREAK_LINK_KEEP_LINKED|FALSE|if TRUE, links are broken off as a linkset, if FALSE or not declared, links are broken off individually|
      |
      |BREAK_LINK_DIE |FALSE|if TRUE, links broken off are removed from the region, if FALSE or not declared, links broken off remain in the region|
      |
      |BREAK_LINK_PHYSICS|variable|if TRUE, links broken off turn physical, if FALSE, links broken off turn non-physical, if not declared, uses the status of the linkset it was broken from|
      |
      |BREAK_LINK_PHANTOM|variable|if TRUE, links broken off turn phantom if FALSE, links broken off turn non-phantom, if not declared, uses the status of the linkset it was broken from|
      |
      |BREAK_LINK_TEMP|variable|if TRUE, links broken off turn temp, if FALSE, links broken off turn non-temp, if not declared, uses the status of the linkset it was broken from|



      Benefits this function brings over existing llBreakLink() and llBreakAllLinks() functions:


      |

  • Remotely and secure operation.

  • Mod keys can be created/changed/removed at any time and are more feasible than requiring that change link permissions be explicitly granted by the owner.

  • Complete flexibility with which links can be broken off in one call, maintaining broken off links as a linkset and whether to kill broken links or have status changes, all of which currently requires a script per prim.

    llLinkObjects(key mod_key, key a_id, key b_id, integer link_num)

    This function links one object with another. Both objects must be owned by the script owner(not deeded), must have the same base owner permissions(cannot link mod to no mod or no copy to no trans, etc.), same mod keys set and correct mod key must be inputted for linking to be successful.

    • key mod_key - Modify Key input (cannot be NULL_KEY)

    • key a_id - prim UUID in same region

    • key b_id - prim UUID in same region

    • integer link_num - this is the link number id a will have in new linkset

      Benefits this function brings over the existing llCreateLink() function:

  • Remotely and secure operation. llCreateLink() currently can link to ANY mod/copy or mod/trans objects owned by the owner. Mod keys prevent ambiguous linking abuse.

  • Mod keys can be created/changed/removed at any time and are more feasible than requiring that change link permissions be explicitly granted by the owner.

  • Complete flexibility with what link number object being linked has in new linkset instead of just link [BUG-10000] THE VIEWER DONT OPEN #1 or link [BUG-10001] Error message when dragging item onto ground from Marketplace Listings floater #2.

    llSetObjectLinkParams(key mod_key, key id, integer link, list rules)

    This function performs the same as llSetLinkPrimitiveParamsFast(), but works remotely.

    • key mod_key - Modify Key input (cannot be NULL_KEY)

    • key id - prim UUID in same region

    • integer link - Link number (0: unlinked, 1: root prim, >1: child prims and seated avatars) LINK_ALL_OTHERS and LINK_THIS reference the link number of the object the script is in.

    • list rules - same as rule set for llSetLinkPrimitiveParamsFast() function

      Benefits this function brings over the existing llSetLinkPrimitiveParamsFast() function:

  • Remote and secure operation.

  • Mod keys can be created/changed/removed at any time.

  • Complete remote and secure prim param change flexibility.

  • Applications can be made that won't require listen/chat protocols which in critical timed applications allows for reduced lag and reduced delayed results since direct access over remote objects is possible.

  • Centralized scripted applications or environments.

    llGetObjectLinkParams(key mod_key, key id, integer link, list rules)

    This function performs the same as llGetLinkPrimitiveParams(), but works remotely.

    • key mod_key - Modify Key input (cannot be NULL_KEY)

    • key id - prim UUID in same region

    • integer link - Link number (0: unlinked, 1: root prim, >1: child prims and seated avatars) LINK_ALL_OTHERS and LINK_THIS reference the link number of the object the script is in.

    • list rules - same as rule set for llGetLinkPrimitiveParams() function

      Benefits this function brings over the existing llGetLinkPrimitiveParams() function:

  • Remote and secure operation.

  • Mod keys can be created/changed/removed at any time.

  • Complete remote secure prim param read flexibility.

  • Applications can be made that won't require listen/chat protocols which in critical timed applications allows for reduced lag and reduced delayed results since direct access over remote objects is possible.

  • Centralized scripted applications or environments.

    Overall Benefits
  • Remote and secure no-mod object manipulation.

  • Mod keys can be created/changed/removed at any time.

  • Complete remote and secure prim param read/change flexibility.

  • Centralized scripted applications and environments.

  • Less script resources required for applications.

    Use Case Examples
  • No-mod pets, breedables, avatars can have official/authorized accessories/content securely linked/delinked to/from them.

  • Rezzing applications won't necessarily require prior setting up each rezzed component with a dedicated communications protocol and param updating script.

    Comments welcome. Thanks in advance for any consideration.

Links

Related

Original Jira Fields
Field Value
Issue BUG-139168
Summary Feature Request - Mod Keys. An environment where secure, remote no-mod object manipulation can be achieved.
Type New Feature Request
Priority Unset
Status Accepted
Resolution Unresolved
Reporter Lucia Nightfire (lucia.nightfire)
Created at 2017-10-03T17:00:40Z
Updated at 2022-03-15T07:00:58Z
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2017-10-30T10:50:19.885-0500',
  'How would you like the feature to work?': 'Please do not triage until November 1st or later.\r\n\r\nDear LL, You will NOT have time to tackle this feature at this time, but it is a major feature that I hope can be discussed at next feature summit for consideration into possible implementation in 2018.\r\n\r\nh1.  Problem\r\n\r\n- Creators of have long needed a means to allow accessorizing/outfitting of their products via linking of their no-mod accessories/goods to their base no-mod creations.\r\n- Current break and create link functions cannot work in a no mod environment.\r\n- Link change permissions are not third party product friendly, efficient and/or feasible.\r\n\r\nThe advent of Animesh further exemplifies the need for a new remote and secure means of no-mod object manipulation.\r\n\r\nh1. Solution\r\n\r\nThis feature request is for a new "Modify Key" object parameter and new functions to work with said parameter. Mod keys are not exposed to the viewer, nor can they be read by script.\r\n\r\n- llSetModifyKey(key mod_key)\r\n\r\nApplies modify key to every link of the object the script is in.\r\nApplying a null key removes the mod key from every link of the object the script is in.\r\nMod keys survive taking into inventory and rerez.\r\nMod keys do not allow users to modify no-mod objects through the viewer, only through the new functions that require correct mod key inputs.\r\n\r\n- llBreakObjectLinks(key mod_key, key id, list link_nums, list handling)\r\n\r\nThis function breaks link(s) in a target object. Target object can be the same object the script is in or a different rezzed object owned by the same owner. The target object must have a mod key set that matches the input used to successfully break links.\r\n\r\n- key mod_key - Modify Key input (cannot be NULL_KEY)\r\n- key id - prim UUID in same region\r\n- list link_nums - list of link numbers to break from object\r\n- list handling - protocols for broken off links\r\n\r\n||flag name||default value||description||\r\n|BREAK_LINK_KEEP_LINKED|FALSE|if TRUE, links are broken off as a linkset, if FALSE or not declared, links are broken off individually|\r\n|BREAK_LINK_DIE |FALSE|if TRUE, links broken off are removed from the region, if FALSE or not declared, links broken off remain in the region|\r\n|BREAK_LINK_PHYSICS|variable|if TRUE, links broken off turn physical, if FALSE, links broken off turn non-physical, if not declared, uses the status of the linkset it was broken from|\r\n|BREAK_LINK_PHANTOM|variable|if TRUE, links broken off turn phantom if FALSE, links broken off turn non-phantom, if not declared, uses the status of the linkset it was broken from|\r\n|BREAK_LINK_TEMP|variable|if TRUE, links broken off turn temp, if FALSE, links broken off turn non-temp, if not declared, uses the status of the linkset it was broken from|\r\n\r\nBenefits this function brings over existing llBreakLink() and llBreakAllLinks() functions:\r\n\r\n- Remotely and secure operation.\r\n- Mod keys can be created/changed/removed at any time and are more feasible than requiring that change link permissions be explicitly granted by the owner.\r\n- Complete flexibility with which links can be broken off in one call, maintaining broken off links as a linkset and whether to kill broken links or have status changes, all of which currently requires a script per prim.\r\n\r\n- llLinkObjects(key mod_key, key a_id, key b_id, integer link_num)\r\n\r\nThis function links one object with another. Both objects must be owned by the script owner, must have the same base owner permissions(cannot link mod to no mod or no copy to no trans, etc.), same mod keys set and correct mod key must be inputted for linking to be successful.\r\n\r\n- key mod_key - Modify Key input (cannot be NULL_KEY)\r\n- key a_id - prim UUID in same region\r\n- key b_id - prim UUID in same region\r\n- integer link_num - this is the link number id a will have in new linkset\r\n\r\nBenefits this function brings over the existing llCreateLink() function:\r\n\r\n- Remotely and secure operation. llCreateLink() currently can link to ANY mod/copy or mod/trans objects owned by the owner. Mod keys prevent ambiguous linking abuse.\r\n- Mod keys can be created/changed/removed at any time and are more feasible than requiring that change link permissions be explicitly granted by the owner.\r\n- Complete flexibility with what link number object being linked has in new linkset instead of just link #1 or link #2.\r\n\r\nllSetObjectLinkParams(key mod_key, key id, integer link, list rules)\r\n\r\nThis function performs the same as llSetLinkPrimitiveParamsFast(), but works remotely.\r\n\r\n- key mod_key - Modify Key input (cannot be NULL_KEY)\r\n- key id - prim UUID in same region\r\n- integer link - Link number (0: unlinked, 1: root prim, >1: child prims and seated avatars) LINK_ALL_OTHERS and LINK_THIS reference the link number of the object the script is in. \r\n- list rules - same as rule set for llSetLinkPrimitiveParamsFast() function\r\n\r\nBenefits this function brings over the existing llSetLinkPrimitiveParamsFast() function:\r\n\r\n- Remote and secure operation.\r\n- Mod keys can be created/changed/removed at any time.\r\n- Complete remote and secure prim param change flexibility.\r\n- Applications can be made that won\'t require listen/chat protocols which in critical timed applications allows for reduced lag and reduced delayed results since direct access over remote objects is possible.\r\n- Centralized scripted applications or environments.\r\n\r\nllGetObjectLinkParams(key mod_key, key id, integer link, list rules)\r\n\r\nThis function performs the same as llGetLinkPrimitiveParams(), but works remotely.\r\n\r\n- key mod_key - Modify Key input (cannot be NULL_KEY)\r\n- key id - prim UUID in same region\r\n- integer link - Link number (0: unlinked, 1: root prim, >1: child prims and seated avatars) LINK_ALL_OTHERS and LINK_THIS reference the link number of the object the script is in. \r\n- list rules - same as rule set for llGetLinkPrimitiveParams() function\r\n\r\nBenefits this function brings over the existing llGetLinkPrimitiveParams() function:\r\n\r\n- Remote and secure operation.\r\n- Mod keys can be created/changed/removed at any time.\r\n- Complete remote secure prim param read flexibility.\r\n- Applications can be made that won\'t require listen/chat protocols which in critical timed applications allows for reduced lag and reduced delayed results since direct access over remote objects is possible.\r\n- Centralized scripted applications or environments.\r\n\r\nOverall Benefits:\r\n\r\n- Remote and secure no-mod object manipulation.\r\n- Mod keys can be created/changed/removed at any time.\r\n- Complete remote and secure prim param read/change flexibility.\r\n- Centralized scripted applications and environments.\r\n- Less script resources required for applications.\r\n\r\nUse Case Examples:\r\n\r\n- No-mod pets, breedables, avatars can have official/authorized accessories/content securely linked/delinked to/from them.\r\n- Rezzing applications won\'t necessarily require prior setting up each rezzed component with a dedicated communications protocol and param updating script.\r\n\r\nComments welcome. Thanks in advance for any consideration.',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': '?',
}
@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2017-10-03T22:20:30Z

Currently LL has blocked commenting due to spammers. Hopefully they come up with a solution soon and people can comment again.

In the mean time, if you have any detailed comments you want me to file on your behalf, IM me inworld. Thanks.

@sl-service-account
Copy link
Author

Vir Linden commented at 2017-10-30T15:50:20Z

Lucia, could you talk through a bit more how this would work in practice? Say you have two no-mod meshes and you want to be able to make them into an animesh linkset. Does the creator have to assign the mod key to those objects when they are first made and then somehow tell you what the key is so you can use it in the LSL calls? Who is allowed to set the mod key of an object in the first place - does this require modify perms for all the prims of the linkset?

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2017-10-30T16:56:50Z, updated at 2017-10-30T16:57:26Z

As mentioned above, the script function, llSetModifyKey() sets the mod key, which is applied to all links in the linkset. Users CANNOT manually apply nor see the mod key through the viewer. It is not exposed data. This function can apply the mod key to mod or no-mod linksets at any time. Mod keys can also be removed at any time by changing the mod key to NULL_KEY.

Creators have the option of using the same mod key for all their products or having two products, at the desired time of linking, communicate with a website to get a random key that one will use to assign to it's linkset and the other will use to link to that linkset. An alternative to a website would be to use secure chat with encrypted negotiation/verification protocols. The key can then be removed once linked. Only official products, those created and scripted by the same creator or design team would know the key or the protocol for acquiring the key in the same way that currently only the creator or design team would know of existing updating or texture applying communication protocols.

@sl-service-account
Copy link
Author

Dyna Mole commented at 2017-10-30T17:44:41Z

If I were using this suite of functions, I would probably opt for using hashed chat. If you're working in an experience, you could also pass the mod key in KVP.

@sl-service-account
Copy link
Author

polysail commented at 2017-11-01T11:32:46Z, updated at 2017-11-01T11:42:33Z

If what I'm understanding here is correct~ essentially the notion of what you're promoting here is some sort of licencing system, where a primary creator will licence out the ability to modify a no-mod objects they created, but do not own, via a proxy object / entity. People have been asking for this sort of ability to have limited licences controlling who is allowed to design (and attach) accessories for "Product Line X" for a long time~ and it was my understanding that it was always deemed to be impossible to implement. This is perhaps a very slightly more limited implementation of that ~ where the only licence holder is the original creator. However, functionally the only real difference I see is simply having a list of one entry "creator" vs many entries "Creator + all these sanctioned UUIDS" on the table of who gains mod-perms. I still think it would be a valuable system to implement if this ever sees the light of day ~ but it's fraught with all kinds of complexities. For example: One Beq brought up was ~ "what if the creator removes the entity that performs these functions?" Doesn't that effectively annul all object functionality?? Who is left to blame for that then? How is that reported? Would the entity in question be a folder on a specific avatar? A scripted object rezzed to ground? What if the region in where that object resides goes down? How are backups handled? etc etc.

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2017-11-01T17:39:13Z

@polysail

This isn't a licensing system. It is similar to script pins, where instead of an integer being used as a "passcode", a key is used. Also, similar to script pins is that mod keys can be created and removed at any time. Also, similar to script pins is that mod keys do not allow end-users to manually modify no-mod objects through the viewer nor can mod keys be read by script or the viewer.

Could it be used as a licensing system? Maybe, but that would be the creator's responsibility for creating and maintaining a key issuing system and database that products communicate with. If the creator removes a collaborator/contributor's "access", it is up to the creator how to implement safeguards against any potential ill-intent from former colleagues prior to product release in the same way they do now with existing content.

If I'm misunderstanding anything, please clarify.

@sl-service-account
Copy link
Author

Vir Linden commented at 2017-11-01T19:09:36Z

Could we talk through specifically how this would work in my above example? Say I want to sell a no-mod sweater and a no-mod dog, and allow the purchaser to link or de-link them on demand. When do the mod keys get set on the items? How does the purchaser initiate a link?

I understand there are multiple ways the technology could be used, but it would be helpful to see at least one representative scenario where all the decisions have been made. Is there a viable way to use this without requiring a persistent web site to authorize requests? Under what circumstances can vendor A make an object that's compatible with those from vendor B? Re: your last comment, Lucia, I'm not sure how you would use this in a way that didn't amount to a licensing system. If the key is publicly known, then anyone could make items that could be linked with your items, removing the protections. If the key is not publicly known, then there has to be some intermediary to manage keys that seems like it amounts to a license manager. Maybe I'm missing something here? Again, my intent in asking for a specific sequence of steps is to make sure that any such issues can be exposed.

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2017-11-02T01:56:59Z, updated at 2017-11-02T01:57:36Z

For a basic scenario with no extrenal communication such as a website or database, chat communication using hashed messages would have to be used.

An end-user has bought a no-mod dog and a no-mod sweater from a creator.

The user rezzes both dog and sweater within a meter from each other.

The user clicks the dog and is sent a dialog menu of options and chooses "Search for Nearby Accessories" which creates a listen in the dog who then chats a hashed message on a non-public channel.

Any nearby accessory that is already scripted to listen for and verify this hashed message sends a return hashed message back to the dog which the dog in-turn verifies and populates a list of nearby accessory keys and names. Within an alloted time of, say 2 or 3 seconds the dog stops listening for these messages and gives the user a list of accessory names asking which one the user would like the dog to "wear". The user chooses the sweater. The dog sends a hashed message to the sweater that it would like to link to it.

The sweater, upon verifying the message, uses

key k = llGenerateKey();
llSetModifyKey(k);

creating a unique mod key right then and there.

A hashed message containing the mod key is sent back to the dog which, upon verification, uses the llLinkObjects() function and the received mod key to link the sweater. Upon successful linking, the dog uses llSetModifyKey(NULL_KEY) to remove the mod key from all links, including the newly linked sweater prims.

If the linking was unsuccessful and/or timed out after say 2 seconds the sweater uses llSetModifyKey(NULL_KEY) to remove the mod key from all links. The dog and/or sweater can tell the user there was a problem with linking.

This scenario didn't involve any "licensing" primarily because both the dog and sweater were offered by the same creator.

The only "licensing" system in SL that comes to mind are texture appliers for official products, but offered by third parties. Those typically involve the creator giving the "affiliate" a copy/trans applier system which must be set to copy only for next owner to work. These systems sometimes communicate with a website to setup/create/verify a liscense key before they can operate.

The only way I see "liscensing" being feasible with mod keys based accessories offered by third parties is if the accessories are no-mod, contain only the script offered by the creator and the presence of script pins applied to any links prevent mod keys from being applied to the linkset. All three conditions must be true.

The number one concern in any third party environment is the presence of rogue scripts, since any script can apply mod keys to a linkset.

I hope I answered things a little more clearly this time. If not, please scold me appropriately and I will try again.

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2017-11-04T03:47:27Z

Another means that would require mod keys is remote start/stop of object animations.

I have applications that require setting up dozens of Animesh characters with dozens to hundreds of animations.

It would be so much simpler and efficient to have a central object that contains the animations and the animation scripts that can target one or more Animesh characters using a mod keys.

llRemoteStartObjectAnimation(key mod key, key object_id, string anim);
llRemoteStopObjectAnimation(key mod key, key object_id, string anim);

@sl-service-account
Copy link
Author

Vir Linden commented at 2017-11-05T15:06:24Z

How important is it for mod keys to be persistent? It seems like the risk of them being accessible to various exploits would be much higher if they exist as part of the persistent contents of an object. If they existed only in memory on the simulator and were never sent to the viewer, they would be locked up relatively well. Most of the scenarios we've discussed so far seem to involve assigning the key on the fly anyway.

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2017-11-05T18:02:17Z, updated at 2017-11-05T18:05:15Z

Mod keys are a prim property similar to how a script pin is a prim property. http://wiki.secondlife.com/wiki/LlSetRemoteScriptAccessPin

Neither mod keys nor script pins can be sent to the viewer nor can they be changed by the viewer.

In the case of mod key persistence, the design could also be a temporary one by implementation, lastings seconds.

I don't see a problem with creators being able to use them in such an environment.

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2017-11-11T06:52:24Z

After much discussion on the topic of security when bringing a foreign linkset into another via linking, I decided to update the No Mod environment behavior for Mod Keys.

The following changes to the original Mod Keys proposal should add significant security and deterrence against rogue scripts in a newly linked object. Please read it in full.

Replace llSetModifyKey(key mod_key) with:
key llSetModKey()
returns a unique key issued by the server and applies it as a mod key to each link of the linkset
This means no two issued mod keys will ever be the same and prevents reuse.

Mod keys are active only for a few seconds or until mod keys based function execution upon the linkset, whichever comes first.
This means mod keys are "consumed" upon use or "lost" upon timeout.
Concern: Taking the restrictions below into account, Is a mod key lifetime necessary?

Introduce a "Link Group ID" prim property.
This is a key assigned to links brought into the linkset via llLinkObjects() only in no-mod linksets. In mod linksets, this key remains NULL_KEY. Whenever a sub group of links is delinked from the linkset via llBreakObjectLinks(), their Link Group ID reverts to NULL_KEY.
Link Group ID persists with taking into inventory and rerezzing.
The purpose of a Link Group ID is to act as a quasi link hierarchy where only scripts in sub groups can only make changes to links in that same sub group.
Link Group ID's can be read by any script in any link with llGetLinkGroupID(integer link_num).
Concern: Do Link Group ID's have to be keys? As long as they are unique could they also be integers that use lowest >0 available values?

Mod Keys can ONLY be applied to all links if all links have NULL_KEY for Link Group ID, thus no subgroups present.
This prevents ANY script in a subgroup from applying new mod keys, including from the root. This also prevents an already "accessorized" product from being absorbed by another linkset.

llLinkObjects() can only bring an object into the linkset if both the agent who saved the host script and the script that set the mod key on the target object is the same.
This effectively prevents scripts saved by others from exercising mod key functions if mod key communication methods have been compromised.

llLinkObjects() can only bring an object into the linkset starting at link #2 or greater, not at #1(root).
This insures the root will always have control over the linkset.

llBreakObjectLinks() can only be called from the root prim and can break off only all links in a subgroup, none individually. It cannot break the parent group from the sub groups. BREAK_LINK_KEEP_LINKED is the only status flag that can be used.
This prevents damaging/destroying linksets when delinking them from the parent. It also prevents the host from separating itself from multiple linked accessories. The accessories will have to be delinked by subgroup.
This insures the root will always have control over delinking.
Concern: Should subgroups be allowed to separate from their parent? If not, are there any scenarios where accessories could be held hostage by their host?

Due to the quasi-link hierarchy, scripts inside links in one subgroup can only make prim param changes to links in that same subgroup.
This prevents scripts from modding any links not part of the original linkset. This means local pos/rot scripts or texture applying scripts can only work on links of the original linkset.
Only a script in the root prim can change physics or phantom status of the whole linkset.
Concern: Should the root also be allowed to update a subgroup link's local pos/rot?

This setup attempts to create/maintain/contain a linkset hierarchy.

Now lets use an example product and accessories to demonstrate how this works.

Let's say Creator A offers a no-mod/no-copy dog on the marketplace.
Creator B makes a no-mod/no-copy bone for the dog and Creator C makes a no-mod/no-copy sweater for the dog.

Creator B & C receive a copy/trans "Set & Comm Mod Key" script from Creator A whom also last saved it. This script has its own affiliate validation process upon dropping into a product. The next owner transfer perms must be unchecked before the accessory is sold or it will not work later.
Creator A could have also checked Creator B and C's accessory's creation times and hardcoded them into the script so it will only work if those objects are in the linkset. Creator B & C add their own texturing and local pos/rot scripts and sell the products on marketplace.

A user buys the dog and both accessories and rezzes them on the ground.

The user clicks the dog and is sent a dialog menu of options and chooses "Search for Nearby Accessories" which creates a listen in the dog who then chats a hashed message on a non-public channel.

Any nearby accessory that is already scripted to listen for and verify this hashed message sends a return hashed message back to the dog which the dog in-turn verifies and populates a list of nearby accessory keys and names. Within an allotted time of, say 2 or 3 seconds the dog stops listening for these messages and gives the user a list of accessory names asking which one the user would like the dog to "wear". The user chooses the sweater. The dog sends a hashed message to the sweater that it would like to link to it.

The "Set & Comm Mod Key" script in the sweater, upon verifying the message, uses llSetModifyKey() to set and return the mod key, "db8bf3af-9b0c-3236-1756-2bb3a5eca231".

A hashed message containing the mod key is sent back to the dog which, upon verification, uses the llLinkObjects() function and the received mod key to link the sweater. Upon successful linking, mod keys are removed by the server automatically. The Link Group ID, "225485da-7b75-9713-132b-3d0144e5feb0" is created for all links the sweater now uses.

The user repeats the process for the bone. The Link Group ID, "7c24d858-64d7-7030-06e5-65b596851d2b" is created for all links the bone now uses.

The user now clicks the newly linked bone and gets a menu they can interact with allowing the bone to be repositioned or rotated in the dog's mouth or dropped to ground (rigged link is alpha'd and a non-rigged link is made visible) or to change colors or textures.
The user can click the sweater and get a menu allowing them to choose a color/texture.

Heres a linkset visual of the dog while accessorized:

Object Name Dog Root Bone Root Bone Child Sweater Root Sweater Child Dog Child
Link # 1 2 3 4 5 6
Creator A B B C C A
Current Mod Key NULL_KEY NULL_KEY NULL_KEY NULL_KEY NULL_KEY NULL_KEY
Link Group ID NULL_KEY 7c24d858-64d7-7030-06e5-65b596851d2b 7c24d858-64d7-7030-06e5-65b596851d2b 225485da-7b75-9713-132b-3d0144e5feb0 225485da-7b75-9713-132b-3d0144e5feb0 NULL_KEY
llSetModKey() Script Name - "Set & Comm Mod Key" - "Set & Comm Mod Key" - -
llSetModKey() Script Saved By - Creator A - Creator A - -
Other Script Name - "Texture Applier" - "Texture Applier" - -
Other Script Saved By - Creator B - Creator C - -

Let's say the sweater uses llSetLinkPrimitiveParams() function with LINK_SET to attempt to color the sweater. Since this sweater is inside a subgroup, only the links in that subgroup are affected. This prevents either accidental or intentional damage to the dog or other accessories.
Any function that changes another link's prim properties must verify the target link's link group ID is the same before applying changes.

There are concerns of eavesdropping on linked messages when linking foreign objects into a linkset.
I think linked messages can also follow the same contingency where link_message() events are only triggered with parent group to parent group messaging and subgroup A to subgroup A messaging.
In case there might be a need for a parent to communicate with a sub group or vice versa or for direct script to script communication, I'll be filing a feature request for a new link message function and event that uses "receive keys".
There is also a concern of not knowing who saved a script present in the same link as another script. I'll be filing a feature request to get access to who last saved a script and the timestamp it was saved since it seems access to script UUID's won't be allowed.

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2017-11-11T08:18:25Z

Instead of a faux link heirarchy, think of the above environment as a mod heirarchy.

In fact, Link Group ID could very well be called Mod Group ID.

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2017-11-12T05:27:23Z

The following functions won't be allowed to work in a subgroup:

llAttachToAvatarTemp() - Can be called from a child prim and upon successful attach no way to return to simulator or inventory.
llBreakAllLinks() - Doesn't work in or on no-mod objects anyway.
llBreakLink() - Doesn't work in or on no-mod objects anyway.
llCreateCharacter() - When called from child prim affects whole linkset.
llCreateLink() - Doesn't work in or on no-mod objects anyway.
llDeleteCharacter() - When called from child prim affects whole linkset.
llDie() - When called from child prim affects whole linkset.
llScaleByFactor() - When called from child prim affects whole linkset.
llSetDamage() - Can't affect the linkset when set in child prim, but not not taking chances as collisions trigger dying.
llSetRegionPos() - When called from child prim affects whole linkset.
llSetStatus() - When called from child prim affects whole linkset.
llUpdateCharacter() - When called from child prim affects whole linkset.

The following functions probably shouldn't be allowed to work, but may have some benefit even while in a subgroup:

llAllowInventoryDrop()
llRemoteLoadScriptPin()
llSetRemoteScriptAccessPin()

The following functions need the server to verify that link targets are only inside the same subgroup as the script is in:

llClearLinkMedia()
llGetLinkMedia()
llGetLinkPrimitiveParams()
llLinkSitTarget()
llMessageLinked()
llSetLinkAlpha()
llSetLinkCamera()
llSetLinkColor()
llSetLinkMedia()
llSetLinkPrimitiveParams()
llSetLinkPrimitiveParamsFast()
llSetLinkTexture()
llSetLinkTextureAnim()
llSetPrimitiveParams()

The following SLPP*() constants cannot work in a subgroup:

PRIM_PHYSICS
PRIM_TEMP_ON_REZ
PRIM_PHANTOM

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2017-11-12T05:37:09Z

I probably won't be changing the description with my previous suggested changes for more secure no mod environment behavior.

Vir has made a proposal for a more simpler operation here: https://community.secondlife.com/forums/topic/413191-project-animesh-feedback-thread/?page=5&tab=comments#comment-1685834

This makes mod keys permanent upon owner base perms change.

My latest proposed changes can still be done as an extension at a later date.

I will probably file a new jira that explains the changes that should be involved in the extension.

For now, my last few comments pretty much cover it, though.

@sl-service-account
Copy link
Author

Vir Linden commented at 2017-11-13T14:06:59Z

Trying to make sure I understand how this applies to linking in particular. Is it fair to say the link group IDs are primarily directed at other types of customization, such as param setting, rather than at linking itself, since being able to add or remove elements from a linkset necessarily crosses the boundaries of the link group IDs? For purposes of linking, I think we have:

  • mod keys can be set at any time by the objects
  • mod keys are transient, going away after a link operation
  • mod keys are agreed upon between the objects being linked using some additional secret state hidden in their scripts (the hashing scheme and maybe other information)
  • objects can only be linked if "both the agent who saved the host script and the script that set the mod key on the target object is the same". The host script is the script that's making the link request? This means we would have to store some additional info at the time the mod key is set. This seems like it would complicate the creation of compatible content by third parties, although it would also make it harder to spoof up compatible objects even if they had the script information.
  • unlink requests have to be done at the level of link ids, so a multi-piece bone or whatever could only be removed all together.
  • do link requests also have to be done in this way? It sounds like the link id only gets set later, so there's no way to flag objects as all belonging together when they are first created?

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2017-11-13T23:16:57Z

link group IDs do not and cannot handle linking or delinking.
Link groups attempt to contain prim param change requests within the same subgroup. This is important so any nefarious scripts cannot make changes to other creator's accessories already linked to the host, nor to the host itself.
Within a faux link hierachry, the root is the only authority where linking or delinking calls can be made from.

Q: mod keys can be set at any time by the objects
A: Correct, but not from a script in a subgroup. The root can apply mod keys to the linkset if it needs to delink an accessory.

Q: mod keys are transient, going away after a link operation
A: Correct

Q: mod keys are agreed upon between the objects being linked using some additional secret state hidden in their scripts (the hashing scheme and maybe other information)
A: Correct, but with all the restrictions I recently proposed, particularly the "both set and link scripts must be saved by the same person" requirement, leaked or even known mod keys arn't as big a problem as was in the initial proposal. The only time it becomes a problem is if the mod key script doesn't have any safety features added by the creator such as blocking use in unauthorized accessories or blocking use in the hands of unauthorized affiliates, but that is all on the creator to set up proper safeguards prior to handing the script out.

Q: objects can only be linked if "both the agent who saved the host script and the script that set the mod key on the target object is the same". The host script is the script that's making the link request? This means we would have to store some additional info at the time the mod key is set. This seems like it would complicate the creation of compatible content by third parties, although it would also make it harder to spoof up compatible objects even if they had the script information.
unlink requests have to be done at the level of link ids, so a multi-piece bone or whatever could only be removed all together.
A: Correct, the host is the script making the request. Yes, along with the mod key prim detail, there has to be a "script that applied the mod key was last saved by" prim detail. The only thing it complicates is affiliates(or anyone else) saving their own mod keys scripts. This means an affiliate will have to liason with and negotiate terms on the environment the mod keys script will work in and the creator can hardcode those requirements into a copy/trans script and hand it to the affiliate.

Q: unlink requests have to be done at the level of link ids, so a multi-piece bone or whatever could only be removed all together.
A: Correct, although I included it as a concern(question) if link ID's(subgroups) should be allowed to delink from their parent. I'm leaning towards, "no". The root should be the only one that can delink accessories.

Q: do link requests also have to be done in this way? It sounds like the link id only gets set later, so there's no way to flag objects as all belonging together when they are first created?
A: If I understand the question, then no, because link ID's(subgroups) are only created through successful use of llLinkObjects() when an object is pulled into(linked to) the host.
I might not have made it clear in my recent proposal change comment, but the presence of link ID's(subgroups) prevents an object from being linked to another object, but an object(host) containing subgroups(accessories) can link another accessory to itself, again as long as that accessory doesn't have any subgroups(accessories of its own).

I'd like to apologize to everyone too, because when I initially created this request, the thought of the need for it to work in an affiliate environment never crossed my mind. I only designed it for original creators releasing accessories they created for host products they also created. This is why I made revisions(my recent comments on no-mod environment operation). I know they may sound complicated and involved when it comes to implementing, but I feel this is what it is going to take to make this feature work in all desired environments as safe and securely as possible.

I have yet to update the description with those changes. I'm still waiting to see if ANY of this is going to be considered by LL. If it is needed I will file a new jira separating mod and no-mod operation in detail.

@sl-service-account
Copy link
Author

Vir Linden commented at 2017-11-14T19:07:54Z

Lucia, the way I would see this working is that we would revisit large proposals like this if we undertake a project specifically to tackle no-mod customization. That's not a project that's currently on our roadmap, but it is something that potentially would make sense if and when we have the resources, given that it's a big issue for the content creation community. Like all projects, it would need to be approved and prioritized. So I would suggest not going too deep into the design at this stage, but make any notes you need to give a broad brush picture of how this proposal would work and why it is a desirable approach. When it's in a "done enough" state, we can pull it in and tag it appropriately.

@sl-service-account
Copy link
Author

Vir Linden commented at 2017-11-15T21:01:17Z

As above - we have started collecting data for a future customization project. This JIRA has been imported and added to that bucket.

@sl-service-account
Copy link
Author

polysail commented at 2017-11-16T22:13:33Z

Given that this is now it's own roadmap entity, I would suggest that it's general case "cousin" of a full on licencing / DRM system regarding modifications of certain no-mod items by certain licenced users would be the fundamental goal of the project, instead of simply from the initial creator.

@sl-service-account
Copy link
Author

Kyrah Abattoir commented at 2019-07-08T07:21:21Z

But do we "want" a DRM system?

Shouldn't the end user be free to pick apart their purchase?

Nomod lessens the value of products, and this feature would only encourage creators to lock down their products further.

@sl-service-account
Copy link
Author

Alexa Linden commented at 2019-07-25T14:34:40Z

Marking as Needs more info so people can comment.

@sl-service-account
Copy link
Author

Kyle Linden commented at 2021-03-09T18:21:46Z

Issue has been accepted, however there is no way to predict when such a feature request will get on the product roadmap. Please feel free to attend public user groups and advocate for any feature that is important to you or the community.

Thanks!

@sl-service-account
Copy link
Author

Kadah Coba commented at 2022-03-15T07:00:59Z

This proposal is rather confusing (likely due to focusing more on explicit implementation details). From what I can understand, this feels like it'd be too limiting to be useful beyond making what sounds like a new type of no-mod but with additional steps to be less so. Something similar-but-different could potentially add new possibilities and be very powerful new feature.

Other than the linking part, most of this functionality seems like it should already be possible via existing scripted object-to-object messaging with secret handshakes and ll*etLinkPrimitiveParams. If the lack of a consistent API for such is the issue for the no-mod crowd, then an open resident defined API might be a better option than a bunch of new narrow use-case/limited LSL functions...

The "object-link" part, depending on implementation and (lack of) restrictions, could be useful. Though, reusing the term "link" for something that is not-quite-a-link may not be a great choice; they sound more analogous to "attachments for objects", but (as proposed) with less functionality and more restrictions, so I don't know if these object-links would be all that useful outside of a narrow set of use-cases.

Being able to attach objects to other objects, as opposed to linking, especially for animesh where a joint could be specified, has the potential to be very powerful. Being able to make animesh NPCs able to dynamically hold and wear things would actually be awesome for interactive experiences, games, and such. I'd much rather see this.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant