Jump to content

Jenna Felton

Resident
  • Posts

    38
  • Joined

  • Last visited

Everything posted by Jenna Felton

  1. Hi Eden I think it is because RLV is something not everyone who uses SL needs in the viewer. If you sail mostly or even only, you not need RLV. And if creators tools come alive you not need RLV for gridwide teleporting. So RLV is a partial solution used by part of residents. The SL viewer needs only stuff every SL resident uses mostly. So the current solution is to have the official SL viewer and the third party viewers implement the RLV. This solution works actually good. Perhaps the better solution would be modular viewers when the SL viewer offrs a framework for plug-ins (one for inventory, one for world map and so on)and you as user simply install the plug-in you need, like it is done by Eclipse. Than RLV would be simply a plug-in to install. This solution needs plently of work i think, though.
  2. The Problem Some residents do experience inventory problems last times when the inventory in Aditi, especially after password change (made to update the Aditi inventory) breaks. And I also read from indirect sources that the inventory on Aditi is on smaller hardware so there are needs to cull out data that are not used. As I understood the asset index for Agni and Aditi are in separate databases while asset server has the files on disc (notecards, LMs textures, objects and so on) and every asset index just links the files for avatar and object inventories. This makes it easy to look up the inventory: Loading index is faster than the files. But you have than to maintain both asset indexes for Agni and Aditi. You must keep them in sync, for example by copying the Agni inventory (the asset indexes) into Aditi inventory so you have an updated inventory there. This also wastes resources because you have to maintain two index databases with almost equal data, the one for Agni and one for Aditi, while for many residents that data are even not used (the residents not went to beta grid yet or went and left for good.) And the question is now how to cull out the unused database indexes. I have a suggestion to solve that problem which bases on two principles: Don’t use redundant indexesHandle the beta inventory as joint of the inventory in Agni and items added in beta grid. How to do that: In the first step flush out the avatars inventory in beta grid except for items created or acquired in beta grid. When the viewer in Aditi requests inventory from the server, the server passes the request over to the Agni inventory server. The result is then extended by items and folders the user added in Agni by creating the folders, notecards, objects picked fromworld etc. So you always see the full inventory and everything you own in Aditi or agni. You see them here automatically, without needs to copy everything from Agni to Aditi first. Now, if the user tries to perform an operation on inventory that affects the Agni inventory, and the operation would remove or alter the items (can you alter an item without making a copy?) than the operation is rejected with an error message. For example You are in Aditi and want to give out an item that is in your Agni inventory and is no copy. This would remove the item from Agni inventory – fail.You have selected an item in inventory and hit delete button, but you are in Aditi and the item is in Agni – fail.You open a notecard that is in your Agni inventory, edit and save it – accept. The new copy of the edited notecard is now in your Aditi inventory. If you go to Agni, and open this notecard, you still see the old text.You are in Aditi and rezz an object from inventory, or put this object into another object rezzed inworld. The object is in your Agni inventory and is copy. Ok, the new copy of this object is created and is in your Aditi inventory if you pick up the object fromworld.You are in Aditi and upload a mesh or image or sound etc. That all lands in your Aditi inventory which is in fact an extension of the Aditi inventory. You are free to rezz the mesh or use the notecard etc. If you go to Agni, you will not find the item in the place it is in Aditi.You are wearing a clothing layer or attachment, and this is in your Agni inventory and no copy. Because you have read access, the viewer can wear or attach it with no problems.You can also modify the item, the changes are saved in your instance of the item in Aditi, the changes are not passed over to Agni.This way you have always a read-only access to your current Agni inventory from Aditi and must not change password in order your inventory updates. And the server load of the Aditi inventory is minimal, so you not need to cull out anything. Actually you need only to change the servers (I hope) and add a new error message, or even extend existing error notification by new text, i.e. I hope by now this suggestion doesn’t affect the viewers at all. But i would to go farther and extend also the viewer. I’d like to see the properties of inventory items extended by a new grid field telling if this is an item in Aditi or Agni inventory, so you can see if you have full access to the item or the read-only and you must not await the error message if you was wrong. This field the viewer has to display than at some way. Possibly even more: “this item is in Agni inventory”, “this item is a modified copy of an item in Agni inventory” and “this item was acquired in Aditi”. If you go to Agni, the viewer displays only the first possibility. Limits This design doesn’t support deleting Agni inventory from Aditi login. Sometimes it is necessary. For example most Agni landmarks don’t work in Aditi and your favorites list is full in Agni, and you want it to list way other landmarks in Aditi. Although you can put some favorite landmarks in the favorites list also in Aditi, but have than troubles to find them under the amount of not working landmarks. The solutions of that are filtering and hiding, which needs more altering of the viewer. Filtering means you can set the viewer to filter folders and types of inventory items that are only in Agni inventory, so you don’t see them in Aditi. The filtering should be a separate setting for each folder and inventory type, so you can filter out all Agni landmarks or those in favorites list but nothing else. Hiding means you explicitly hide an item or a folder from being shown in Aditi. This way you can refine the hiding criteria. The disadvantage of that design is further, that by hiding or filtering inventory parts you create data for inventory index and can potentially make relatively much of them so the benefit of incremental inventory design looses. For this reason I’d suggest to support filtering by grid property for every inventory item (this setting doesn’t increases with inventory), but restrict individual filtering and hiding only to the top-level folders and system folders (that are top-level actually) and their direct content. The subfolders and their content should be no more individual filter- and hide able. That's all. Hope it willl give some constructire ideas, or start a usefull discussion. Greetings Jenna
  3. I have the sae theory like Freya A default script that you always create by clicking "New script" in contents tab of the build floater is telling "Touched" in local chat if touching the object. The script is called "New script", eventually with a number appended to it (if the prim has nother item called new script" and is always edit-able for the one who created it. The content should look like in this page: Hello Avatar The script does not interract with other scripts and since created accidentally should not harm others if deleted. If you can't see such a script, than the reason is possibly an other.
  4. Yes Darien, and thanks for replay. Yes, the script looses permissions if copied out of inworld object and if copied with object copied inworld. But it retains permissions if the object is taken into inventory and copied there. And i am pretty unhappy with the fact that once granted permisions can not be taken back, unless the owner of the object holding the script makes some mistake like resetting the script. The owner of the object gained avatar permissions can use the permissions in another means than the grant was intended to, and the victim can do nothing about it, or at leas i not know any way to, say revoke animation permission given to a griefing object pretended to be a hug attachment . However, i may be wrong. I see there is a message for revoking permissions if the script is on the sim, as far i can understand the definition. Edit: To be honest, i can't figure out how this message works and even it this message is sent when you decline a permission request, or really to revoke a permission granted once. My indirect informations state, this message is sent to revoke permission granted to a script available on the sim but not to a script in an attachment.If so, returning to the sim to revoke teleport permission seems not a good idea for me, since the griefing teleporter may send you out on sight before you take it the ability to do so. I've also not found a button allowing revoking permisions in Firestorm viewer. The only place dealing with permissions i found is Privacy tab in Firestorm settings. Permissions being revoked this are just two, animation and taking control, as far i can read on the help page. Especialy for dangerous permissions like debit or teleport this is an issue.But also animation permissions can be used for grief. This proopsal was a try to give a possible answer to the issue. I tried to keep the overhead low, so a permanent traffic for every script action is not a good idea. This made the complete design very complex.
  5. 9. Status interface a) Permission confirmation floater (temporary) If a script connects to the status storage, due the sync protocol, and the storage is missing the status for the script runtime permissions, a floater is prompted that is similar to the permission request but is 1) telling what permission the script has already, and 2) allows to confirm the permissions or revoke them. In the shown example we rezzed a dance machine, which has already the animation permission, but the status for the permission is missing in the status storage. Now we can confirm the permission, revoke it, mute the device as usual. Because there will be many such floaters, we can here check the check box and the decision taken now will be auto-applied to all following confirmation requests. The floater is temporary, it is fading out because there will be probably a quite number of such confirmations, especially if we cleaned out the status storage. The floater toast could collect the floaters and display the number of floaters not confirmed yet, so we can reopen the floaters at later point. b) Run-time permissions floater Here is the legend of the icons and also the view to open lists: This floater demonstrates the interface to the status storage or storages. The floater presents a list of permissions granted to objects, i.e. the scripts inside. Each script requested permanent permissions produces an entry for an object, as it produces a permission item which is registered by a status storage. The entries can be filtered by the name of the object and it's owner, as well by the granted permissions and their status. The displayed legend presents the filters and explains the used symbols. Entries passed the filters are displayed page wise, since 3218 permission entries is not a unrealistic number, even if not every permission request produces an entry. The list dislays the objects requested and granted run-time permissions, with Object name and name of the object owner, The region where the object requested the permissions. Revealing the current position of foreign object would be a privacy flaw, so for unowned inworld objects the position should be hidden. Attachments have no current position, The permissions holding by the object are shown by icons, if a script holds more than one permission, the entry for the script displays multiple icons. The status icon is clickable, if clicked a floater is shown with a possibility to set the permission status, i.e. revoke or re-grant the permissions. The last column 'last used' displays when the script into the object used the given permission and what permission was used. If one object is selected and the entry shows the object position, we can teleport there by clicking a button. If at least one object is selected we can delete the selected entries (not the objects) or change the permission status for them. The 'last used' column is a very nice to have feature, but perhaps not so easy to implement. It may require a permanent data stream from the script to the status storage. In return this allows to identify a griefer who used a script permission given to the griefer's gadget months ago. The list displays some teleporting devices (TP Relay, Pingpong Teleporter, Personal Teleporter), animation devices (Dance Machine, Hug&Kiss attachments), a radar working on links, two vendors with access to the avatar's money, and a RC device holding a permissions set. You can see, the dance machine still has unconfirmed animation permission, the permission floater was just ignored. You can also see how a grief was defeated: The Pingpong Teleporter gained the teleport permission but after we broke out of the grief, we just open the floater and revoke the teleporter the TP permission. At same point or earlier we revoked also the animation permission to the strange named ring device belonging the same griefer. Here we are at the end of the proposal. I put it on discussion so we can find out if this idea can be implemented and must be implemented at all. LG, Jenna
  6. 7. Sync protocol Via status interface, the user can change status of every permission item holding permissions granted to a script before. The sync protocol ensures that the status storage provides the new status of a permission item to the script as soon as possible. The protocol avoids generating too much traffic; it uses only asynchronous events that are sent on demand. a) If the script is available while the permission status is changed via status interface, an event is sent to the script immediately. If the new state is 'revoked' and the old state was 'granted' or 'unconfirmed' (which both means the script is granted permissions) than a revocation event is sent to the script. The script looses the permissions by receiving the event. If the new state is 'granted' or 'unconfirmed' and the old state was 'revoked' (which means the script had no permissions granted) than a regranting event is sent, due this the script stores the permission item holding the permissions bitfield. b) If the script was not available at time of changing permission status, than only the new status is saved in the status storage. c) As soon the script and the status storage become available to each other, for example while the script is in an attachment and the script owner is logging on, than the script connects to the status storage and requests status for the held permission item. If the status is 'revoked', a revocation event is sent to the script with the same effect of script loosing the held permissions. d) If a script recycles a permission item from the cache, the script sends a status request to the status storage and names the UUID of the recycled permission item. If its status is 'revoked', the status storage also sends a revocation event to the script. 8. Revocation messages If a script was revoked a permission, this may also affect another person than the agent revoked the previously given permission. In this case an instant message should be sent to the affected agent. a) If a script given say an avatar permission (e.g. animation permission) by an agent who is not owner of the script, and the agent revoked this permission, the owner of the script should be informed that the avatar actions are no more possible. b) If the CHANGE_LINKS property permission was revoked, there is no affected avatar, so no messages must be sent. c) If the DEBIT property permission was revoked, this can broke content potentially, because the debit action is used often to split money or to implement affiliate vending systems. Revoking this permission can create fraud affiliate vendors if the script relies on non-revocability of the DEBIT permission. In this case, as soon a script tries to give money and the debit permission was revoked, the recipient of the money should receive an instant message telling the money transfer was aborted because of missing permission. This way the creator could ban the fraud affiliate from the vending network for instance.
  7. 5. Status storage Status storage is an instance keeping states of permission items. The storage allows to manage the script permissions without access to the script, so script permissions can be revoked even if the script is not available. The status storage must be instanced in an appropriate place, for example kept by the user agent if the avatar permission is handled, or the sim agent if the property permission is handled. The connection between the script and status storage must be fast and short, as well the connection between the status storage and the status interface (of the viewer.) The status storage binds more data to the permission item than the script created and stored the item: The permission item on the storage side holds also the UUID of the holding script, object, and the object's owner, as well also the region where the permissions were granted to the script. I can imagine a few scenarios where to hold the status storage. a) Global status storage The simplest variant uses a global server holding all permission states. The scripts and viewers can find it easily, but we have a tight bottleneck here, even if we synchronize status due initialization of the script only and not in real-time, all scripts access the same place. Also the way is far for the data between viewer and status server and between the status server and the script VM. b) Outsourcing avatar permissions Because avatar actions make no sense without target avatar being available on the sim, we can separate the permissions in two parts: The pure avatar permissions, e.g. TRIGGER_ANIMATION|TELEPORT, will be handled by status storage attached to the user agent of the target avatar. The pure property permissions, like DEBIT, and mixed permissions like TRIGGER_ANIMATION|CHANGE_LINKS will be handled by the global status storage server. In this case, the permission item in the script may need the reference to what status storage is handling it's permission status. This way the viewer would always able to access the status storages, either the one attached to the user agent (pure avatar permission) or the global status storage. A teleporter device will synchronize the permission status as soon the avatar becomes available on the sim, and hence teleport-able. A vendor or device working on linksets will load the permission status from the global server accessible instantly. The bottleneck is relieved, but not eliminated: The property permissions will need access to global status server and this may generate huge traffic on a single point, even if the hits are only generated while rezzing an object with script requesting the status. c) Outsourcing all permissions Here we eliminate also the global status storage: The pure avatar permissions, e.g. TRIGGER_ANIMATION|TELEPORT, will be handled by status storage attached to the user agent of the target avatar. The pure property permissions, like DEBIT, and mixed permissions like TRIGGER_ANIMATION|CHANGE_LINKS will be handled by the status storage attached to the sim agent of the sim where the script was rezzed last time. To implement this the permission item in the script should definitely keep track about what status storage handles the permission status. If the script holding property or mixed permissions is moved to another sim, the status storages of the sim agents will have to move the status information, too. This way we eliminate the bottleneck: The scripts access the right status storage easily and on a short way, also the status interface in the viewer will have access to all (pure) avatar permissions granted before, as they are handled by the status storage sticked to the user agent. Access to the mixed and pure property permissions is only possible for objects on the sim the avatar is currently, which is insufficient. Imagine a bugged device requested and granted the CHANGE_LINKS|TELEPORT permission. As it is mixed, you would not be able to revoke the permission without return to the sim, and once there the device would send you out on sight. To enlarge the range for mixed and property permissions, the viewer could store references to status storages of, say, 16 last sim agents. This way you can access and change states of script permissions remotely, without needing to visit the target sim. Also connected regions like in a continent or estate could connect the status storages of each sim, than you can teleport to a sim in the continent and manage the status of permissions granted to an object everywhere on this continent. d) Splitting mixed permissions If the states for avatar and property permissions are handled by different storages, as suggested above, it may make sense to split mixed permissions into avatar and property permissions. The permission item in the script refers than both storage servers, one for avatar permissions and one for property permissions. Both storage servers may synchronize the permission states if needed and possible. This way the viewer has a direct access to the status storage for avatar properties (it is sticked to the user agent), and the scripts an access to the status storage for property permissions (sticked to the sim agent), even if the user agent is not available. This way a device can not take the avatar permission like animation or teleport out of reach from the viewer just by making the permission mixed. 6. States of permission items On the script side, a permission item has two states: Either it exists, the script is holding a permission item (actively, not in cache,) than the script is granted permissions bound to the item, or the permission item doesn't exist (or it is just cached but not held actively), than the script is not granted any permissions. For the status storage, the permission item has three states: Granted, revoked and unconfirmed. a) Granted permission state. In this state is a permission item if saved into the status storage if the script has generated the item (the user accepted requested permission.) Say a script working in a kiss hud requested the animation permission which was granted. The script generated the permission item (if recycling was not possible) and it was stored inside the script and the user's status storage. b) Revoked permission state. In this state a permission item is in the status storage, when the user decided to revoke the script’s run-time permission. Say the owner of the kiss hud decides to grief the user by starting of nasty animations. Traditionally, the user has no other way to stop that but fill the abuse report. Now, the user opens the status interface which connects to the status storage. There, the user finds the hud animating them and changes the state of the permission from granted to revoked. The sync protocol ensures that the animation script into the kiss hud is notified as soon as possible and looses the animation permission. c) Unconfirmed permission state. It is possible, that the status storage saves not every permission item: Permissions granted before the revocation system is established, will generate new permission items by first script action but those permission items will be not in the status storage, Status storage may remove items that are not used for long time, unter assumption the objects holding the scripts are temporally or removed meanwhile, The user may remove obsolete permission items to keep the list clean. If a script executes an action due holding permission item allowing the action, but the permission item is not in the permission storage, this item is saved into the permission storage but with unconfirmed state. The user receives a message, that a script is executing an action which was allowed before but this action is not confirmed. The message may be shown by a floater, which is fading out after a while. The user is now able to... To accept the action, than the permission item changes the state to granted. To decline the action, than the permission item becomes the revoked state and the revocation event is sent. Or to ignore the floater allowing the action to continue. At later point the user can find the new permission item in the status storage interface and change the permission state correctly. d) Temporally granted permissions Sat unowned objects may give the permissions TAKE_CONTROLS, TRIGGER_ANIMATION, TRACK_CAMERA and CONTROL_CAMERA automatically to the sitting agent. This permissions are given temporary, after standing up they are lifted. Hence the permission items generated temporally for the sitting period must not be stored into the stats storage and managed by the status interface for instance. The same applies to other possible cases where permissions are granted temporally to scripts.
  8. 3. Permission item In order we can revoke a given permission, we have to clearly identify it. This identification goes deeper than per object and per script: An object can hold different permissions via scripts inside, as well every copy of the same script (with same UUID) can hold another permission. To do so, we bind permissions given to a script (a bitfield of permissions to be exactly) to a permission item. This item will have an unique UUID and store the bound permissions bitfield. The permission item is only generated by the script as soon the requested permissions are granted. There is no other way to create the permission item. Declined request will not generate the item. Also, not every accepted permissions request will generate a permission item, and in some cases even an already created item can be reused, 'recycled' so to say. In some cases the permission is given temporary resulting in a short-living permission item managed very locally. As soon generated, the permission item will be stored into the script and the status storage(s). Now the script has an efficient way to check what permissions it hold, and the user granted the permission has a way to revoke it by changing the status of the permission item. For implementation reasons you can divide the permissions and actions allowed by them in two classes: The avatar actions are actions affecting the avatar, the avatar permissions are TAKE_CONTROLS, TRIGGER_ANIMATION, ATTACH, TRACK_CAMERA, CONTROL_CAMERA and TELEPORT. The property actions are actions affecting the user’s property and are allowed by property permissions DEBIT and CHANGE_LINKS. The avatar actions require the affected avatar to be available (online and on the sim) while the property actions do not require the avatar granted the permission (i.e. the script owner) to be available or even online. 4. Recycling of the permission items A disadvantage of permission items is that they generate an UUID which is to be managed by the whole SL infrastructure. Generating an item for every granted or auto-granted permission request will create a new permission item and waste resources even if used temporally. The recycling technique avoids this by reusing already created permission items. Generally said, if we have to create a permission item and we have already another permission item created for the same parameters (avatar granted permissions and the permission bitfield) so we would not tell the new item from the existing one, we reuse the existing permissions item instead of creating the new. Here are a few examples how we do this: a) Copying of the script with granted permissions If a script grants a permission, say to animate an avatar, and then copied by copying the holding object, every copy of the script holds a copy of the permission item, i.e. every copy of the permission item will have the same UUID and bind the same permissions. This is similar to traditional definition: If a script holding run-time permission is copied by copying the holding object, every copy of the script will hold the same permissions. The difference is now, that by revoking the (animation) permission of one object will revoke the permission for every copy of that object, since all copies share the same permission item. This is a new behavior, but since the revocation system is new, the existing content is not corrupted at this point. b) Repeatedly requested permissions If a script holding some run-time permissions, requests permissions again, the already created permission item may be re-used, if all this are true: The requested permissions are granted, The avatar being requested and having granted the permissions is the same of the existing permission item, The requested permissions are the same of the permissions bound to existing permission item. This way a script (for instance animation machines or poseballs) requesting the permissions repeatedly without checking if the permissions are already granted eventually, will not produce a bunch of permission items while only one of them is sufficient. c) Permission cache If a script holding the permission item has to remove it or to generate another one, say because The avatar granted the permission to actual permission item but declined the new request, Or because other permissions were requested and granted (but the avatar is the same) Or because another avatar was requested and accepted the permissions. Than the actual permision item is not removed but stored in a limited cache (for example of 64 items.) As soon an avatar is requested permissions and the new permission item to create would exactly match (avatar and permission bitfield is the same) the item in the cache, than the item from the permission cache is restored instead of creating a new item. This way for example a multiuser animation script would not produce a lot of permission items because a group of avatars use it sequentially.
  9. Hello Well, this post will quite long so i better split it in a few. Also i am not sure where to post ths proposal, as it affects the SL infrastructure, hence the servers, but also the viewer. Choosen the SL Servers category, as this part is more affected. The current system of run-time script permissions is (apparently) build of a bitfield storing locally into a script giving the run-time permissions granted to the script (if not, the suggestion will be probably not obsolete, but the suggested components would need a maping to the implemented.) However, this solution is very efficient on run-time since to perform an action, the script has simply to read in the locally saved permissions bitfield if a permission to run this action is granted to the script or not. But this solution makes it hard to give a resident a way to revoke permission given to a script at least if the script is temporally not available, e.g. taken into inventory or if the script owner gone offline. 1. The challenge The problems we are facing if making the run-time script permissions revocable: To make script run-time permissions revocable instantly, you have to store the granted permissions in a place not bound to the script, so you can revoke the script permissions even if the script is not available at time.The permission storage must be also available if the avatar granted the permission is not available, so the script is able to check if it is allowed to access to the money of the avatar for instance.By outsourcing the permissions out of the script, we create a traffic between the script and the permission storage every time an action, say animation of the avatar has to be started, and this is very often the case.The data volume of the permission storage will be extremely high, as every avatar could have granted a quite large amount of animation permissions (sitting on furniture, vehicles, and kiss&hug huds produce such a grant.) This proposal gives a possible way to allow an instant revocability of run-time script permissions with less management overhead and data load. 2. Abstract overwiew The permissions revokability system is roughly based on few things A permission item is an unique object holding permissions granted to the script. The permission item is stored in place of the permissions bitfield and represent the runtime permissions held by the script.A status storage maintains the status of the permission items and thus the run-time permissions granted to the script related to this item. The status tells if the permission is granted or revoked.A status interface is a floater in the viewer, with a direct access to the status storage. The floater allows to identify and revoke every permission the user ever grated to scripts, regardless if the scripts are available or not.The sync protocol between scripts and the status storage allows to revoke run-time permissions at the point the script to revoke permissions becomes available. The protocol uses ...... the revocation event sent by the status storage towards the script (holding the permission item) with an effect of revoking permissions given to the script.The revocation message is again sent by the script (or possibly the status storage) to an agent affected by revoking the script permission.
  10. Nods @Misti RLV affects way more then just the 'kinky' community.... RLV allows for example to redress avatar like in RL - you see what you'll wear, watch the video to this warderobe please: RLV Wardrobe. Or forcing teleport without needs to open map or chat history (although i'm awaiting the technology of Linden Realms, where it might be also possible without RLV) There are applications for RLV far aside of BDSM, even in PG sector, and i'm glad this inventory issue affecting #RLV folder was really a bug and not a feature. Thanks for correcting that.
×
×
  • Create New...