An Agent is a software resource which represents some portion of a user in the virtual world. Agents are hosted in agent servers. An agent may cause an avatar to be instantiated on behalf of a user.
* Mediate the user's message traffic * Mediate the user's asset inventory * Act as a focal point for the user's access to services in other domains * Act as a focal point for the user's access to utilties * Act to report the user's avatar's location in the Virtual World to other parts of the system
Agents do not:
* Store persistent assets (They are stored in asset servers)
Agents are not:
* The software resource which represents a user's avatar inside a region simulator. (Tho we need a name for that.)
This definition is different from the current (pre agent/region domain split) use of the term agent Second Life. Currently agents are hosted on the simulator where the user's avatar resides, and handle these tasks as well as mediating the avatar's connection to the client. The term agent, in general is overloaded, and is it possible that another, more specific term would be appropriate here.
- The envisaged massive scaling requires new forms of item organization, search, and access to cope with vast expansion. The current inventory mechanism is already stretched right now, so this issue needs early design attention.
- it should be possible to manage inventories of all your agents under one identity. The idea is to e.g. being able to move items from one inventory to another
- some organisation providing agents should be able to define on which regions an agent is allowed to connect, what he/she can do with object in their inventory
- an agent domain should be able to have certain inventory pools which might be shared among agents (like the library in SL today)
- it should be possible to import and export friends lists or groups of friends
- it should be possible to maintain a friends list among various agent domains (related to import/export maybe but as protocol function)
- it should be possible to copy inventory from one agent domain from another if the object structure is compatible.
- an agent needs to provide various methods of verification
- an agent domain needs to define presence information among an agent's friends list. This should even be possible among various agent domains.
- Each agent needs to be able to define certain permissions on what other agents or groups of agents are allowed to see about him (online status, identity information, etc.)
possible restrictions between regions and agents
- An agent domain should be able to define on which regions an agent is allowed to connect
- An agent domain should be able to define which objects are allowed to be rezzed on which region (e.g. company objects only on company regions etc. This might be related to object pools as described above).
- A region might allow only certain agent domains to connect
- A region might allow anybody to connect but the rights of that agent might be limited depending from where it comes and e.g. which verification mechanism the agent provides.
- Standard specification of rights/permissions in a serialisable form that can be edited by the viewer and uploaded to an authorative per-domain server?