UUID

UUID is an abbreviation for Universally Unique Identifier. It is a 128-bit (16 byte) value which is generated in such a way as to make collisions very unlikely. They are often represented as a string of 32 hex characters with four dashes interspersed. See Wikipedia on UUIDs for more information.

In LSL they are stored in the key variable type (which is a specialized form of a string).

The UUID and Secondlife

In Second Life every object and every avatar have an UUID, which can be split up into four groups: Asset, Instance, Account and Land UUIDs.

key whatever = "01234567-89ab-cdef-0123-456789abcdef";

SL uses Version 4 UUIDs as defined in RFC-4122, though there are some that are not V4.

key uuid = "xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx";

//  where:
//      4 is 4
//      x is [0-9a-f]
//      y is [8-9a-b]

UUID Version

While SL uses Version 4 UUIDs for some things (ex. All avatar UUIDs post ~Jan 2006, exact date TBD), you may find Version 5 UUIDs (Generated by llGenerateKey, July 2012 - present (STC)), Version 3 UUIDs (Generated by llGenerateKey, prior to July 2012), and non-standard UUIDs (All UUIDs prior to ~Jan 2006, Exact date TBD), ∞-present for some assets (e.g. in-world objects, textures, etc.).

Inventory

Inventory as it is thought of is only a permissions layer. The inventory item is really just a wrapper around an asset. The wrapper contains the permissions, creator & owner of the asset and a link to the asset. The link is the asset UUID.

Asset UUIDs

Asset UUIDs are used as the handle for all types that can be inventory items. The asset UUID is what is returned by llGetInventoryKey and by the "Copy UUID" feature in the client. Full (asset) permissions are required to get the UUID. Assets are immutable (they cannot be modified); when the user is editing an asset, they are in fact creating new assets. The appearance is that modified inventory items are assigned new UUIDs.

• Animation
• Gestures
• Objects
• Notecards
• Scripts
• Sounds
• Textures (including sculpty textures)

• When an Object is modified in-world, it is not assigned a new asset UUID until it is derezzed, copied back to inventory or during sim-state save. Modifying an instance of an asset will not update other instances or inventory copies.
• Brand new notecards are just asset wrappers without an asset. That is to say, new notecards have an asset UUID of NULL_KEY. The asset isn't created until the notecard is edited and then saved.
• Assets that are no longer inventory and are not referenced by any script are eventually deleted. Before they are deleted, they are placed in a database where they await deletion but can still be revived.

Instance UUIDs

Every time an object is rezzed, all the prims (including the root prim) are assigned instance UUIDs. An avatar's attachment keeps its instance UUID when the user teleports or moves from one region to another (they are not kept when an avatar logs off). The instance UUID is what is returned by llGetKey and other functions.

Account UUIDs

Account UUIDs are assigned during the creation process and never change. They are generally public information.

• Avatar — Public
• Group — Public or private depending on setup.

The avatar UUID is returned by llGetOwner and other functions.

While avatar UUIDs have been using Version 4 UUIDs for more than a decade, you cannot assume that because a given key is not Version 4, that the asset the key is linked to is not an avatar — this is because older accounts have a non-standard UUID format assigned to them.

Land UUIDs

• Parcel
• Region

• This information is technically available to the public but there is no interface to get at it directly (the UUIDs are sent to the client but consumed internally and never exposed to the user).
  • The parcel UUID is returned by llGetParcelDetails.
• Only one instance of these can exist in-world at any time.
  • When copied, new UUIDs are assigned.
• Modification does not cause a new UUID to be assigned.