Difference between revisions of "Brainstorming"

From Second Life Wiki
Jump to navigation Jump to search
m
 
(185 intermediate revisions by 15 users not shown)
Line 1: Line 1:
{{architecture_header}}
This page is all about brainstorming about the upcoming architecture. Add your thoughts here in no particular format. Can be use cases, requirements, scenarios. Maybe shouldn't be too long but long enough to get your idea across. Can also be implementation details maybe but in the lower section.
This page is all about brainstorming about the upcoming architecture. Add your thoughts here in no particular format. Can be use cases, requirements, scenarios. Maybe shouldn't be too long but long enough to get your idea across. Can also be implementation details maybe but in the lower section.




== Usage examples and requirements ==
= Usage examples and requirements =


=== General architecture ===
=== General architecture ===
* always keep the '''scary numbers''' of [[http://wiki.secondlife.com/wiki/Project_Motivation]] in mind, ie. design for scalability
* always keep the '''scary numbers''' of [[Project_Motivation]] in mind, ie. design for scalability.
* allow to run a small grid on my laptop
* allow to run a small grid on my laptop.
* allow big-iron sites (eg. LL) to run as proxy cache for small but authoritative private grid
* allow big-iron sites (eg. LL) to run as proxy cache for small but authoritative private grid.
* allow plug-ins
** ''I don't understand this.  [[User:Zero Linden|Zero Linden]] 11:27, 16 October 2007 (PDT)''
*** The above was a reference to long-standing architecture discussions in the SL forums about how the LL server grid(s) could continue to generate revenue in a distributed universe of open-source 3rd-party subgrids and worlds.  The key observation was that small private servers have no hope of scaling massively, so that if they want to be integrated into a virtual space and still be visitable by large crowds (without meltdown) then they would have to "buy world power" from Linden.  A useful architectural approach for this would be that the private worlds would connect and be authoritative over their own content, while LL's big-iron resources would act as a non-authoritative powerhouse.  The term "proxy cache" here goes far beyond its simple meaning in web technology, but both "proxying" and "caching" would be key components of this complex new function. --[[User:Morgaine Dinova|Morgaine Dinova]] 08:12, 12 November 2007 (PST)
**** In any case, a central database, or at least a central authority, might be necessary in order to integrate together those myriads small virtual worlds. Think of it as the position the ICANN has over DNS, for example. (shameless plug: in my proposed design, the Grid Domain, or central services, serves as the authority that determines who owns a given parcel of the static, predetermined landscape, and which address the corresponding server has - it's DNS except the domain name is replaced by the geographical position and surface area). Processing power and bandwidth, "proxying" included, is probably best offered by the already well developped commercial hosting business, although LL will undoubtedly keep an edge by having the know-how. --[[User:Jesrad Seraph|Jesrad Seraph]] 09:12, 13 November 2007 (PST)
* allow plug-ins ''as a general principle for extensibility by attachment''; this should apply at all levels.
** ''We must be careful here: plug-ins often lead to balkanization.  [[User:Zero Linden|Zero Linden]] 11:27, 16 October 2007 (PDT)''
*** Fortunately balkanization is easily countered by supplying any plug-ins that are considered foundational along with the main client dowload. --[[User:Morgaine Dinova|Morgaine Dinova]] 08:12, 12 November 2007 (PST)
* Talk to other online virtual worlds to discuss interconnectivity, at least to some degree. For instance, with one online ID and perhaps registration with each virtual world, residents could inhabit seamlessly Second Life then possibly World of Warcraft or any other virtual world, in the same way online surfers can go from one website to another. In short, let there eventually be one huge interconnected 3d environment, with each world as distinctive as a website on the net.
* Talk to other online virtual worlds to discuss interconnectivity, at least to some degree. For instance, with one online ID and perhaps registration with each virtual world, residents could inhabit seamlessly Second Life then possibly World of Warcraft or any other virtual world, in the same way online surfers can go from one website to another. In short, let there eventually be one huge interconnected 3d environment, with each world as distinctive as a website on the net.
** ''Other industry groups may be tackling this soon.  We shouldn't loose our focus on extending our virtual world to Internet scale. [[User:Zero Linden|Zero Linden]] 11:27, 16 October 2007 (PDT)''
* Integrate within Second Life a platform to allow residents to create their own virtual world which can then be connected via a personal server to the grid. If this is not entirely possible then create a download so a world can be created offline to be later uploaded to a personal server and then be added to the grid. The development of such software could be a challenge to present to the many resident coders. People with technical knowledge should not be the only ones able to add their own sim to the grid. This should be developed in a way to enable everyone to do so.
* Integrate within Second Life a platform to allow residents to create their own virtual world which can then be connected via a personal server to the grid. If this is not entirely possible then create a download so a world can be created offline to be later uploaded to a personal server and then be added to the grid. The development of such software could be a challenge to present to the many resident coders. People with technical knowledge should not be the only ones able to add their own sim to the grid. This should be developed in a way to enable everyone to do so.
** Enable short-term sandboxes launched from within a viewer - think like a traditional LAN party for a multiplayer game, this would do for short social events etc, for 24/7 sims allow hosting by 3rd parties and those 3rd parties (like web hosts) charge for their server space and administration
** Enable short-term sandboxes launched from within a viewer - think like a traditional LAN party for a multiplayer game, this would do for short social events etc, for 24/7 sims allow hosting by 3rd parties and those 3rd parties (like web hosts) charge for their server space and administration.
* Make Second Life more democratic. Rather than having rules and regulations imposed on residents, allow democratically elected members to represent residents wishes and aspirations, and even let such individuals govern regions. Essentially, Linden Labs should let go of its junta like hold of Second life and allow residents to govern themselves. In its present state Second Life does not represent a free or democratic entity and this lack of freedom is becoming ever more tangible to residents.
** ''Perhaps this is a better way to say this: Ensure other entities hosting land can manage those regions as they choose.  This may include land managed as LL does now, land managed by elected leaders, or land run under very strict control.  [[User:Zero Linden|Zero Linden]] 11:27, 16 October 2007 (PDT)''


=== Interoperability ===
=== Interoperability ===
Line 21: Line 30:


===Commerce===
===Commerce===
* If Second Life is going to live up to its name it should incorporate as many real world activities as possible, and one important area is business. Rather than companies use of Second Life being pretty much restricted to meetings, perhaps this could be expanded to include as many aspects of real world commerce as possible.
Ensure that the entities used in commerce are supported
* currencies or other forms of payment accepted (object trading, external payment systems)
* exchanging rates and such
* timestamped transaction records (''this'' was exchanged for ''that'')
* unforgeable documents for contracts


* Could Second Life eventually incorporate real world stores on the grid where residents could buy items to be delivered to their homes? Or perhaps service industries could be allowed to function on the grid, so for example real world banking transactions etc could take place. It is not a big leap from this to see how online businesses could be developed within Second Life following the models of for example, Amazon and Ebay.
=== Objects and Assets ===


* Could it be possible to also develop areas such as real world education/training within Second Life with recognised qualifications? I believe a university (or a number of places of learning) within Second Life where recognised qualifications could be gained would attract and help a lot of people.
This section has been moved to its own wikipage: {{AWG|Asset}}
 
=== Objects and Assets ===
* allow objects to only be allowed to be rezzed on certain regions (adds to the agent's restrictions)
* AND/OR limit object rezzing to specific groups of objects (give region owner ability to control what content is allowed in their regions)
* allow assets to be transferred between agent domains
* allow assets to be accessed from multiple agent domains
* allow truly distributed asset storage
* Think beyond the limitations of prims and sculpties by allowing items made in 3d modelling software to be directly imported onto the grid. Other online virtual 3D environments allow this.
* allow licenses to be attached to objects such as CC licenses etc. Could be some license field in the protocol.


==== Permissions ====
==== Permissions ====
* What does a creator need to define? It should be possible for the creator to e.g. define that an object is only valid within a certain grid. The question here might be what makes up a grid. Probably it means a certain agent domain. What does that mean to the user though? If the user bought that object I'd think that he/she should really own it and be able to copy it to other agent domains and other grids. The problem might be what happens if these have lesser security policies and it got copied? (of course in general there is no way to prevent it anyway, I am talking here about different policies for different grids). Should it be some new permission which say "copy to other grids"? When buying such an object you can decide then whether it's worth it or not.
* What does a creator need to define? It should be possible for the creator to e.g. define that an object is only valid within a certain grid. The question here might be what makes up a grid. Probably it means a certain agent domain (or region domain?).
* What does that mean to the user though? If the user bought that object should he/she really own it and be able to copy it to other agent domains and other grids? But then what happens if these have lesser security policies, say allowing copying of no-copy objects. and it got copied? Should it be some new permission which say "copy to other grids"? When buying such an object you can decide then whether it's worth it or not.
* On the general idea of being able to express perms for something like "this grid" vs "trusted grids" vs "untrusted grids", see https://jira.secondlife.com/browse/MISC-1272.
* We already discussed DRM in general and the opinion was that it should be not hardwired into the protocol. Of course it should be possible to plug it in if people think it makes sense.
* We already discussed DRM in general and the opinion was that it should be not hardwired into the protocol. Of course it should be possible to plug it in if people think it makes sense.
* What about being able to link from objects. E.g. it is annoying right now that an object cannot be mod,copy,trans but "trans" meaning here that all the copied will be deleted once you give it to another person. Because of that one permission is usually missing. Either you cannot copy it or you cannot transfer it. So here is how it might be
* What about being able to link from objects. E.g. it is annoying right now that an object cannot be mod,copy,trans but "trans" meaning here that all the copied will be deleted once you give it to another person. Because of that one permission is usually missing. Either you cannot copy it or you cannot transfer it. So here is how it might be
    * Agent buys object which is full perm but it should not be allowed to sell multiple copies of it, only the one you bought.
** Agent buys object which is full perm but it should not be allowed to sell multiple copies of it, only the one you bought.
    * Agent rezzes multiple copies and eventually modifies them
** Agent rezzes multiple copies and eventually modifies them
    * Agent give the object to another agent (or sells it). When he does this all the copies should be deleted.
** Agent give the object to another agent (or sells it). When he does this all the copies should be deleted.
In could be implemented as links to the original object or the object itself is more or less the group of all rezzed items. It makes sure the user can do whatever he wants but cannot just make money from selling multiple copies if not bought.
** It could be implemented as links to the original object or the object itself is more or less the group of all rezzed items. It makes sure the user can do whatever he wants but cannot just make money from selling multiple copies if not bought.
* Make derivations possible, like e.g. IMVU has it. You buy some object and modify it. You then can resell it but the original creator still gets some fraction for each sold copy.  
* Make derivations possible, like e.g. IMVU has it. You buy some object and modify it. You then can resell it but the original creator still gets some fraction for each sold copy.  
* For all the mentioned permissions the protocol should provide a means of specifying these capabilities. If you want to sell derivations the other agent domain also needs to support it and needs to be trusted.
* For all the mentioned permissions the protocol should provide a means of specifying these capabilities. If you want to sell derivations the other agent domain also needs to support it and needs to be trusted. Possible new permissions could be 'sell copies' and 'franchise' with additional minimum percentage the creator defines (modifiable upwards by the next owner, but not downwards). If object is copy and transfer, seller's copies get deleted with a transfer, if object is set to sell copies, seller's copies are not deleted. Maybe the definition of a minimum price might be interesting, too.
* Access controls beyond the walls of a single managed protection domain like the Linden grid are actually doomed to failure, for numerous reasons detailed by security and cryptography heavyweights who have explored DRM.  Nevertheless, extending existing SL object permissions to "trusted" external sites is still perfectly feasible ... but it would be a mistake to believe that such access restrictions would be anything but temporary.  ''This fact will have to be made clear to asset creators to avoid legal problems and discontent later on,'' as a social measure.  As a limited technical measure, a Local_Distribution_Only permissions bit will probably be required as well.
** To put it bluntly, unless you can create a system which either allows no objects without full perms to leave a particular trusted group of agent domains, or create a system which guarantees that permissions will be respected, you will get a massive shit-storm from content creators, which no amount of explanations about the ultimate pointlessness of DRM will negate. Create a grid system which doesn't respect the current system or permissions, and content creators will not use it. --[[User:Ian Betteridge|Ian Betteridge]] 08:49, 2 November 2007 (PDT)


=== Identity ===
=== Identity ===
* identity should be pluggable
 
** [Please build a list of desired identity verification systems]
This section has been moved to its own wikipage: {{AWG|Identity}}
** OpenID
 
* various grades of verification should be possible
=== Privacy and control ===
** RL Identity Verification:
* '''Motivation'''
*** "Is the user exactly who he/she claims he/she is?"
:* The single-grid SL implemented privacy and control in a manner not untypical for centralized, managed systems, effectively denying privacy as a concept and exercising control (lighthanded, but nevertheless control) over world inhabitants.  The policy also lead to implicit responsibility for the actions of inhabitants, on the basis of "''if you police it, then you are responsible for any infractions''".
*** Very strong verification. Permanently links ID of account to real-world ID of user.
:* In a worldwide, distributed, and massively scaled universe of interconnected 3rd party worlds and grids, this current approach is no longer tenable, for a number of reasons:
** Age Verification:
::* RL identity verification is neither generally feasible nor in many instances desireable (see '''Identity''', above).
*** "Is the user old enough to be on this system?"
::* Attempts to enforce strong guarantees suffer from the same fundamental weakness as DRM, and lead to a similar arms race.
*** Weak verification. Minimum amount needed to maintain compliance with child online access laws.
::* The laws of California are not generally of interest in the rest of the world.
** Unique Verification:
::* The operators of individual grids will not in general have control rights elsewhere, let alone legal jurisdiction.
*** "Is this user unique, or is it an Alt?"
::* In some countries more than others, citizens place extremely high value on individual privacy, often protected by law.
*** Weak verification. Minimum needed to enforce bans due to TOS violations.
::* Privacy is relevant to personal security as well, thwarting stalkers and even being helpful for domestic security.
*** Very difficult to enforce due to ease of changing commonly-used identifiers: IP address, MAC address, hardware serial numbers/profiles, etc.
::* Social mores vary immensely across the world, so imposing those of one society on another is misplaced and generally not desireable.
** Virtual Identity Verification:
::* Open source denies the possibility of adding covert wiretaps and similar measures, so distributed monitoring is infeasible.
*** In a multi-site, multi-grid, multi-world and multi-national distributed architecture, RL verification is not feasible.
::* Policing and assuming responsibility for the actions of others is itself a recipe for discontent and ultimately failure.
*** RL identity must be safeguarded for residents living under conditions where human rights are not protected.
:* The above suggests that attempting to implement the privacy and control policies of the original SL in the new architecture would not be an appropriate goal. Instead, privacy and control might better be focussed in a different direction, as below.
*** Relevant question: "Is this person XXXX the same XXXX I was talking to yesterday on a different world?"
 
* Verification must not require sensitive data to pass through insecure systems or require storage of sensitive data.
* '''Requirements'''
* It should be possible to attach an unlimited amount of agent from different domains to one identity
:* The following requirements could be well suited to a universe of multiple distributed domains and high cultural diversity:
::* Implement strong(er) privacy guarantees
::: Although "evil" attached worlds and grids will unavoidably be able to subvert privacy measures within their own domains, by default there should be a presumption of privacy to cater for those societies where privacy is valued.  This includes:
::::* Built-in volumetric barriers, for example Argent Stonecutter's remarkably simple [[http://forums.secondlife.com/showthread.php?p=1533912#post1533912 Parcel Basements]].
::::* End-to-end encryption for non-vicinity communication channels.
::::* Encryption of client-server traffic to defeat in-transit monitoring.
 
::* Disclaim control / gain immunity of common carrier
::: "Common carrier" immunity is historically only recognized for PTTs, and has been slow in moving into the realm of ISPs and higher level services providers.  Nevertheless, commonsense offers that you cannot control what you cannot see, and you cannot reasonably be held accountable for what you do not control. Barriers to visibility added for the sake of privacy can therefore also deliver a useful defence and tangible business benefits, particularly in domains where personal freedoms are expected.
::::* Limit the amount of logging, and keep permanent records for financial transactions alone.
::::* Replace "guardian responsibility" by "personal responsibility":
::::::* Increase the power of parcel and region owners to detect the sources of abuse and remove it.
::::::* Increase the power of individuals to make unwanted effects/objects disappear from client visibility.
::::::* Add arbitrary owner-defined land tags to provide flexible classification, and land entry barriers.
::::::* Add personal interest tagging, to trigger land barriers and avoid unwanted surprises.
::* While the above are technical measures relevant to architecture, many coercive forces are arrayed against privacy and towards stronger control over virtual citizens, so be prepared for hard times and pressure.


=== Viewer ===
=== Viewer ===
Line 74: Line 97:
*** Put core protocol functionality (login/logout, movement etc) into a library
*** Put core protocol functionality (login/logout, movement etc) into a library
*** Make the server only send client data it has asked for (client sends "i want prims" message and get prims etc)
*** Make the server only send client data it has asked for (client sends "i want prims" message and get prims etc)
*** Should be trivial to integrate with other systems if this is done correctly - IRC gateways for IMs for example
*** Should be trivial to integrate with other systems if this is done correctly - IRC gateways for IMs for example - note: there should be thoughts about SPAM prevention from the very beginning. A "We can think about that later" wont work here!
** Allow the client to reassign controls and common functions to a Human Interface Device (gamepad, joystick, customized keyboard, a Bluetooth-connected Wii Remote, etc.)
** Allow the client to reassign controls and common functions to a Human Interface Device (gamepad, joystick, customized keyboard, a Bluetooth-connected Wii Remote, etc.)
* Client-side Script runtime
* Client-side Script runtime
Line 87: Line 110:
:::'''[Use cases]'''
:::'''[Use cases]'''
:::* An intermittent mobile viewer could periodically manipulate or monitor an avatar presence currently logged in from home.
:::* An intermittent mobile viewer could periodically manipulate or monitor an avatar presence currently logged in from home.
:::* Within the home, secondary screens running on home theatre equipment would offer a very appealing view of the world.
:::* A scripted presence could run without any 3D viewer at all, for example a shop transactions handler.
:::* A scripted presence could run without any 3D viewer at all, for example a shop transactions handler.
:::* An audio-only mobile viewer could attend an SL live music concert and still pay the musician's tip jar.
:::* An audio-only mobile viewer could attend an SL live music concert and still pay the musician's tip jar.
Line 93: Line 117:
:::* Under crowd conditions (eg. most live music events), a low-detail viewer could be switched in without relogging.
:::* Under crowd conditions (eg. most live music events), a low-detail viewer could be switched in without relogging.
:::* SL-based games and sports would be able to run their own bespoke viewer and UI, without reworking presence code.
:::* SL-based games and sports would be able to run their own bespoke viewer and UI, without reworking presence code.
:::* A client could be used for remote changing/editing 'information'. Think of a 'blog editor' for SL, for text displayed by hovertext, prim displays and future SVG or HTML displays.


::* To achieve this, the "viewer" needs to be redesigned as '''a view attached to a presence''', in an N:1 relationship.  Client-side scripting would then also attach to the presence in a similar manner, for UI control, as a proxy for human input, and also for distributed computation at the request of servers.
::* To achieve this, the "viewer" needs to be redesigned as '''a view attached to a presence''' (more precisely, to the client-side presence handler, because the real presence is more properly considered to be server-side), in an N:1 relationship.  Client-side scripting would then also attach to the presence handler in a similar manner, for UI control, as a proxy for human input, and also for distributed computation at the request of servers.


::* Or, as another way of looking at it, the presence needs to become an independent multiplexer process, with graphics viewers and other applications and scripts attaching to it as needed, or not at all if no view is required.  The development of many other diverse and quite minimalist viewers then becomes quite a simple matter. --[[User:Morgaine Dinova|Morgaine Dinova]] 10:13, 23 September 2007 (PDT)
::* Or, as another way of looking at it, the presence handler (currently a part of the monolithic viewer) needs to become an independent multiplexer process, with graphics viewers and other applications and scripts attaching to it as needed, or not at all if no view is required.  The development of many other diverse and quite minimalist viewers then becomes significantly easier.


=== Agents ===
=== Agents ===
* The envisaged massive scaling [[http://wiki.secondlife.com/wiki/Project_Motivation]] 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 ====
This section has been to its own wikipage: {{AWG|Agent}}


* An agent domain should be able to define on which regions an agent is allowed to connect
=== Regions ===
* 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?


=== Regions ===
This section has been moved its own wikipage: {{AWG|Region}}
* allow regions of arbitrary size and form
 
* allow portals and landmass-style connections between regions or a mix of both
== Virtualization of regions ==
* region should be able to decide which agents to let in depending on the grade of verification (age, RL identity, financial, ... )
 
* User defined topology.  Like bookmarks, but in 2D.  Crossing a custom boundary would result in a "walking teleport"
This section has been moved to its own wikipage: {{AWG|Virtualization}}
* Multiple instances of a region within a topology.  Everyone can have a front row seat for the show.
 
* Allow as many avatars as will fit in the virtual space of a region.  Don't limit the population of a region based on architectural limitations.
== IM ==
* Inactive land acreage and passive prims cost only the price of disk storage.  Scripts cost the price of CPU power.  Avatars cost the price of bandwidth.  In the LL grid, these issues are all coupled together, but this will change in a distributed world.
Scalability of Instant Messaging ('''IM''') is required along all the dimensions given in [[Project_Motivation]], with added requirements:
* Beyond the confines of the Linden grid, land, prim, script and avatar limits should not have a-priori restrictions that are relevant only to the static Linden grid.  In the distributed world, local resourcing will determine which limits and costs are appropriate. One fallout from this will be that inactive land acreage will cost next to nothing, since the price of storage is in freefall. [[User:Morgaine Dinova|Morgaine Dinova]] 00:59, 24 September 2007 (PDT)
:* Messaging must be extended to the distributed worldspace of attached regions and identities
:* Messaging fanout capability needs to grow automatically with world population to avoid endemic lag
:* Alongside increases to IM extent, we also need recipient-end facilities for IM denial and filtering
:* Local vicinity messaging requires additional controls to tame crowd spam at very large events
The magnitude of this task, as shown by the inability of the current IM system to handle even current population levels, suggests that it may be best not to reinvent the wheel of IM, but merely to interface to existing open-source messaging systems.
 
= Implementation thoughts =


== Implementation thoughts ==
=== Decentralized assets ===
(Was "Viewer", See Talk) [[User:Morgaine Dinova|Morgaine Dinova]] 10:27, 23 September 2007 (PDT)
* How does a locally-run, disconnected grid provide texture/animation uploads or anything of use without the centralized system to accept the upload fee, read and update the user's inventory, or receive the new asset information?
** Local database backend stores all the local content, any content on the remote asset servers with appropriate permissions (perhaps a "can download" flag?) can be downloaded for use on a local stand-alone grid
** Any new assets, or locally modified assets can be re-uploaded
** "Can download" must imply "Can modify" for practical reasons (DRM will not work!)


=== Regions ===
=== Regions ===
* if we have different region domains will each of them have their own map or would it somehow work to connect certain region domains together while it would still be possible to grow one domains space?
 
* Can we see into neighboring regions using a low LOD mesh dynamically created to represent the land and objects in a region?
This section has been moved its own wikipage: {{AWG|Region}}
* Virtualize the regions.  If no one is in or near a region, don't waste hardware on it.  If a region gets too busy, dynamically split it onto two servers, each taking half of the area.
* Allow arbitrary assignment of geography to processing resources - including dynamic migration.
** As someone who's developed 3D virtual world simulations before (and always wanted to create something like SL), the first thing that hit me when I entered SL for the first time was that sims were visible to residents (and scripts). 
*** A sim is an implementation detail and residents should never need to know they exist. Making that particular initial implementation choice (to divide processing power into a regular grid and distribute it statically over separate servers) has now locked it in for the future - as removing the concept of regions would break a lot of scripted content.
*** However, it is still possible to lay a foundation that can deal with arbitrary assignment of geographic simulation to processing units (including dynamically) transparently and then add a 'backward-compatibility' layer over it which simulates the familiar square regions for legacy content (virtualizes them as suggested above).
*** Such a system could also be implemented to allow non-flat and non-contiguous geography (e.g. like planets, for example).  Current continents could be mapped into small surface patches in a 'legacy' area.
*** It would also allow the possibility of distributing the various aspects of simulation of a geographic area differently - such a physics, collision, scripts, occlusion etc. (for example, if there are few physical objects over a large area, one processing unit could compute the physics for the whole area, while a larger number of processing units execute the area's scripts if required)


=== Currency ===
=== Currency ===
* how will virtual currency be handled in a distributed grid architecture?
* how will the Linden Dollar be handled in a distributed grid architecture?
** Will LL still support L$ in future, or will it be phased out? (perhaps a virtual currency should have no special place in the grid at all - just as there is no special currency on the web ?)
** Will LL still support L$ in future, or will it be phased out? (perhaps a it should have no special place in the grid at all - just as there is no special currency on the web ?)
** L$ exists as "a limited license right" within Second Life and therefore only makes sense within the official grid(s) owned by LL.
** L$ exists as "a limited license right" within Second Life and therefore only makes sense within the official grid(s) owned by LL.
*** Privately-owned grids could be responsible for issuing their own licenses, to throttle their clients' use of those private resources.
*** Privately-owned grids could be responsible for issuing their own licenses, to throttle their clients' use of those private resources.
**** Allowing private grids to issue their own limited license rights for use of their hardware makes it possible to disconnect them from many if not all centralized systems.
**** Allowing private grids to issue their own limited license rights for use of their hardware makes it possible to disconnect them from many if not all centralized systems.
***** Remember that "resources" also includes "design and creation talent". Simply because there is no cost of reproduction of objects doesn't mean that it takes zero resources to make them. It takes the time, effort and knowledge of the designer. This is classical economics - labour, capital, and the means of production :) --[[User:Ian Betteridge|Ian Betteridge]] 08:37, 2 November 2007 (PDT)
**** Such disconnections may allow us to implement a fully localized grid for use on private intranets or on a standalone system.
**** Such disconnections may allow us to implement a fully localized grid for use on private intranets or on a standalone system.
*** By their nature, private licenses would be mutually incompatible with the official "L$" licenses.
*** By their nature, private licenses would be mutually incompatible with the official "L$" licenses.
**** However it may be possible to setup automated gateways to convert between a 3rd-party currency and L$ or any other arbitary currency - something like a cross between paypal and the current popups for when one's L$ balance is too low
**** However it may be possible to setup automated gateways to convert between a 3rd-party currency and L$ or any other arbitary currency - something like a cross between paypal and the current popups for when one's L$ balance is too low
***** This is possible, but who gets to do the arbitrage? My guess is that, even if such systems are not created, there will emerge individuals and corporations who will exchange one currency for another for popular grid groupings. Consider, for example, the gold sellers in WoW. --[[User:Ian Betteridge|Ian Betteridge]] 08:37, 2 November 2007 (PDT)
*** Alternative servers (or local grids) with accounts linked to LL servers might be able to purchase L$ to be issued to its members for use on LL servers.
*** Alternative servers (or local grids) with accounts linked to LL servers might be able to purchase L$ to be issued to its members for use on LL servers.
* allow for secure transactions other than in L$ via PayPal, credit cards, etc.
* allow for secure transactions other than in L$ via PayPal, credit cards, etc.
Line 163: Line 168:
=== Assets ===
=== Assets ===


* It is possible to implement asset storage in a completely distributed way
This section has been moved its own wikipage: {{AWG|Asset}}
** Assets need not be stored in fixed locations (such as in the 'home' grid of the creator, for example)
 
** A completely Peer-to-Peer (P2P) storage protocol is possible
== Protocols and interaction patterns ==
:: It's worth pointing out that P2P is the ''only'' topology that scales with the number of participants in the world. Other topologies have useful properties and get us part of the way (eg. I've been proposing private distributed authoritative world servers fronted by non-authoritative commercial big-iron caches for years on the SL forums), but ultimately P2P has no real challanger. [[User:Morgaine Dinova|Morgaine Dinova]] 11:51, 23 September 2007 (PDT)
 
** To be successful it would have to retain many of the properties of the current 'fixed' storage schemes
I've added this bucket to discuss the related topics of protocols and interaction patterns.
*** Available: Since the individual physical storage providers in a P2P network can't be trusted, a great deal of redundancy would be required to make it unlikely an asset would ever become unavailable
 
*** Secure: Assets would need to be encrypted using strong PKI where appropriate (for example, so you can be sure nobody but the primary key holder (/ capability holder) can view your script source or edit your object).  For the same reason, no asset should be stored in-whole at any single physical location (hence requiring the collusion of a large number of parties to even assemble the encrypted form of an asset in order to mount a cryptographic attack, unless the 'directory' of storage addresses for the asset has also been compromised). Obviously this wouldn't apply to the 'public' form of an asset (e.g. script bytecode, pre-optimized object mesh etc.).
We have several building blocks proposed from Linden Labs, in the form of [certified http], REST, and [capabilties].
*** Persistent: Some mechanism to control the lifetime of assets may be needed
 
**** Given the pace of storage technology progress, it may be possible to just keep every asset ever created (ride the wave of progress)
We do not have much described from Linden in two other major areas, namely how to choreograph calls into sets of calls which achieve an end (interaction patterns) and how to manage situations where we wish to setup an ongoing stream of interaction between multiple components. This last case is especially cogent when we discuss how region servers interact to provide the illusion of seamlass land.
**** If limited asset lifetimes are needed, some kind of distributed garbage-collection algorithm could be employed
 
**** What would happen to assets that remain accessible but never 'accessed' for long periods of time?  (We don't want the 'virtual data archaeologists' who research the 22nd century in one thousand years from now to keep running into cases of assets that are no longer available just because a long time has passed without 'access'!)
Zha Ewry - 9/25/07
**** Will it be possible to delete assets/accounts someday?
 
** This may be a hard problem to solve properly now, but just designing an architecture with it in mind and then implementing something similar to the fixed scheme utilized now would leave the possibility open of implementing the more general case in the future.
 
*** Lets avoid a repeat of the mistake made in the 'design' of the www, where public pages are often stored on servers owned/leased by their creators and routinely lost for the future (save the efforts of the way-back-machine etc).
== Capabilities ==
* Assets should support being signed (and notarized)
 
** Perhaps they should even allow arbitrary meta-data to be attached to them by their creators (or anyone with perms) and accessed via scripts
The capabilities of a domain, region or client do not have to mesh perfectly, but we should set about making sure it doesn't choke.
* Assets should be raw data.
 
** Asset type, permissions, creator, watermark, etc would be meta-data.
=== 3D Web ===
** Any kind of meta-data could be added and used or ignored as needed.
3D Web simply put is forcing the multidimensional flat data of the internet into a single continuous three dimensional space. In the past it has largely failed because of a lack of hardware and attainable social pressure. SL has the potential to fill the 3D Web niche if it can at the region & domain level be integrated with traditional web applications.
* How will a region be able to accept an alien object from another system's inventory, or an inventory to accept an object from a foreign region?
* I'm not sure that previous efforts failed because of the technology - they mostly failed because navigating information in 3D (as opposed to realistic looking environments) isn't very natural. I'm thinking particularly of Apple's HotSauce project [http://en.wikipedia.org/wiki/HotSauce].
** Would an upload fee make sense for transferring objects to different grids?
 
** If so, how would that fee be determined for a completed object?
=== Limited Capability Clients ===
** Would some grids (or domains if you'd prefer) be able to reject items from other domains on a permission basis?
When a client such as a cellphone or any limited capability client (LCC) connects, many of the more advanced features could be turned off for them but if there were a way to automate some of them, then the LCC could still participate.
 
There are a number of features that would enable supporting LCCs.
*'''Scriptable capability deficiency handler'''
**This could allow the world to automate features not supported by the client so the client could still participate.
***A cellphone user goes to a show to listen to the audio stream, when they connect to the audio stream the region automatically seats them in a vacant chair.
*'''Scriptable Auto-navigation waypoint system''' (choices would be present as menus, etc)
**This could allow a user who can't see the world navigate it by menu.
*'''Embedded web pages from prims made the primary focus so they can broken out and interacted with.'''
 
 
''There is no requirement stated here that they be scripted in LSL. I don't think LSL would necessarily be appropriate -- [[User:Strife Onizuka|Strife Onizuka]] 17:07, 27 September 2007 (PDT)''
 
* LCCs now have their own use case section, [[Use_Cases#Limited Capability Clients]].
 
=== Capabilities: The path to 3D Web ===
 
With a framework in place to negotiate and script deficiencies in supported features, the ability to support an LCC that is in fact a web browser becomes possible. More importantly, the transition from Web to full 3D Web can be transitioned one feature at a time.
 
A website could be described as something like an art gallery. Information is organized into rooms and it typically line the walls. The passages between the rooms allow traversal from one page to another. This analogy is nowhere from perfect.
 
With a dynamic capabilities system, the client could drop down to dumb mode and browse the art gallery like a webpage or it could explore it as a 3D space with all the features turned on.
 
:One interesting question for a migration/incremental move between static 3d content and a fully immersive environment, is when you can, and how you can, bring the space from static traditional content to a space where multiple avatars can interact. When we look at this space, it is interesting to notice that we're really doing several things at once in a space like SecondLife. There is the presentation of 3d content, there is the melding of multiple presences with the 3d content and the presentation of that content, the shared space to the viewers interacting in the space. Note that a 3d web, that is to say our current web with 3d content, would be a very static place, there isn't much notion of shared presence in the 2d web. -- [[User:Zha Ewry|Zha]]
 
::If the Capabilities Framework is designed properly, it can allow for static 3d spaces with no user interaction. They won't be much fun, but thats another issue altogether. IMHO 3D Web by itself is doomed but when you tie it into the SL grid it has a chance of not being a total flop. LL is in an interesting position, they could be the next Network Solutions but for the 3D Web. -- [[User:Strife Onizuka|Strife Onizuka]] 23:49, 27 September 2007 (PDT)
 
 
= ANALYSIS: Region Subdivision as a scaling method =
* This section has been moved to its own page, [[ANALYSIS: Region Subdivision as a scaling method]].
 
: It shows why Region Subdivision is a flawed concept for a large number of reasons.
 
= ANALYSIS: Per-resident subdivision of the Grid as a scaling method =
This section has been moved to [[AWG Scalability through per-resident subdivision of the Grid]].
 
=== A 'per-resident sim' as a finite state automaton ? ===
:"one simulator software running per machine, but capable of opening or closing or transferring single VMs corresponding to a given resident"
That's one more trail of thought to pursue: how far can sim processes be parallelized ? The per-resident subdivision of the Grid might allow for a considerable independance of sim processes, that could in turn make it possible to run simulators as interchangeable instances. Thoughts, suggestions ?
 
=== Customer processing power contribution in exchange for sqm ===
One easy way to solve the problem of landless residents having no real simulator of their own or parasiting other people's sqm allotments: allow them to contribute their computer's processing power and net access bandwidth to the Grid, and earn sqm in return, so they can rez objects and run scripts. Make it possible to resell or rent those sqm, and the Grid will be self-growing.
 
= ANALYSIS: Scalability through reverse proxies: the paravirtual grid =
 
This section is now located on its own page: [[AWG:Scalability_through_reverse_proxies:_the_paravirtual_grid]]


[[Category:Architecture Working Group]]
[[Category: AW Groupies]]

Latest revision as of 14:05, 15 October 2015

Architecture Working Group main Project Motivation Proposed Architecture Use Cases In World Chatlogs

This page is all about brainstorming about the upcoming architecture. Add your thoughts here in no particular format. Can be use cases, requirements, scenarios. Maybe shouldn't be too long but long enough to get your idea across. Can also be implementation details maybe but in the lower section.


Usage examples and requirements

General architecture

  • always keep the scary numbers of Project_Motivation in mind, ie. design for scalability.
  • allow to run a small grid on my laptop.
  • allow big-iron sites (eg. LL) to run as proxy cache for small but authoritative private grid.
    • I don't understand this. Zero Linden 11:27, 16 October 2007 (PDT)
      • The above was a reference to long-standing architecture discussions in the SL forums about how the LL server grid(s) could continue to generate revenue in a distributed universe of open-source 3rd-party subgrids and worlds. The key observation was that small private servers have no hope of scaling massively, so that if they want to be integrated into a virtual space and still be visitable by large crowds (without meltdown) then they would have to "buy world power" from Linden. A useful architectural approach for this would be that the private worlds would connect and be authoritative over their own content, while LL's big-iron resources would act as a non-authoritative powerhouse. The term "proxy cache" here goes far beyond its simple meaning in web technology, but both "proxying" and "caching" would be key components of this complex new function. --Morgaine Dinova 08:12, 12 November 2007 (PST)
        • In any case, a central database, or at least a central authority, might be necessary in order to integrate together those myriads small virtual worlds. Think of it as the position the ICANN has over DNS, for example. (shameless plug: in my proposed design, the Grid Domain, or central services, serves as the authority that determines who owns a given parcel of the static, predetermined landscape, and which address the corresponding server has - it's DNS except the domain name is replaced by the geographical position and surface area). Processing power and bandwidth, "proxying" included, is probably best offered by the already well developped commercial hosting business, although LL will undoubtedly keep an edge by having the know-how. --Jesrad Seraph 09:12, 13 November 2007 (PST)
  • allow plug-ins as a general principle for extensibility by attachment; this should apply at all levels.
    • We must be careful here: plug-ins often lead to balkanization. Zero Linden 11:27, 16 October 2007 (PDT)
      • Fortunately balkanization is easily countered by supplying any plug-ins that are considered foundational along with the main client dowload. --Morgaine Dinova 08:12, 12 November 2007 (PST)
  • Talk to other online virtual worlds to discuss interconnectivity, at least to some degree. For instance, with one online ID and perhaps registration with each virtual world, residents could inhabit seamlessly Second Life then possibly World of Warcraft or any other virtual world, in the same way online surfers can go from one website to another. In short, let there eventually be one huge interconnected 3d environment, with each world as distinctive as a website on the net.
    • Other industry groups may be tackling this soon. We shouldn't loose our focus on extending our virtual world to Internet scale. Zero Linden 11:27, 16 October 2007 (PDT)
  • Integrate within Second Life a platform to allow residents to create their own virtual world which can then be connected via a personal server to the grid. If this is not entirely possible then create a download so a world can be created offline to be later uploaded to a personal server and then be added to the grid. The development of such software could be a challenge to present to the many resident coders. People with technical knowledge should not be the only ones able to add their own sim to the grid. This should be developed in a way to enable everyone to do so.
    • Enable short-term sandboxes launched from within a viewer - think like a traditional LAN party for a multiplayer game, this would do for short social events etc, for 24/7 sims allow hosting by 3rd parties and those 3rd parties (like web hosts) charge for their server space and administration.
  • Make Second Life more democratic. Rather than having rules and regulations imposed on residents, allow democratically elected members to represent residents wishes and aspirations, and even let such individuals govern regions. Essentially, Linden Labs should let go of its junta like hold of Second life and allow residents to govern themselves. In its present state Second Life does not represent a free or democratic entity and this lack of freedom is becoming ever more tangible to residents.
    • Perhaps this is a better way to say this: Ensure other entities hosting land can manage those regions as they choose. This may include land managed as LL does now, land managed by elected leaders, or land run under very strict control. Zero Linden 11:27, 16 October 2007 (PDT)

Interoperability

  • allow different formats for objects or assets in general. You might need different viewers for that (e.g. WoW and SL or EVE are quite different in their structure) but you should at least be able to share an identity. You might need different agents though as e.g. in games you want to store game information in the profile and the profile is attached to an agent. (See Viewer Refactoring below to help with this.)
  • for interoperability, objects at the protocol level must be self-describing to allow transformation to the local format.
  • allow different types of regions and region formats. Again as an example, EVE and WoW have different understanding on how to partition the world and how to implement it.
  • look at things like Multiverse or Metaplace to see how these can be interconnected.
  • Use some common IM format to IM between agents. Jabber comes to mind but should probably also be pluggable. Maybe integrating existing multi-format clients (of open source) is an option.

Commerce

Ensure that the entities used in commerce are supported

  • currencies or other forms of payment accepted (object trading, external payment systems)
  • exchanging rates and such
  • timestamped transaction records (this was exchanged for that)
  • unforgeable documents for contracts

Objects and Assets

This section has been moved to its own wikipage: Asset

Permissions

  • What does a creator need to define? It should be possible for the creator to e.g. define that an object is only valid within a certain grid. The question here might be what makes up a grid. Probably it means a certain agent domain (or region domain?).
  • What does that mean to the user though? If the user bought that object should he/she really own it and be able to copy it to other agent domains and other grids? But then what happens if these have lesser security policies, say allowing copying of no-copy objects. and it got copied? Should it be some new permission which say "copy to other grids"? When buying such an object you can decide then whether it's worth it or not.
  • On the general idea of being able to express perms for something like "this grid" vs "trusted grids" vs "untrusted grids", see https://jira.secondlife.com/browse/MISC-1272.
  • We already discussed DRM in general and the opinion was that it should be not hardwired into the protocol. Of course it should be possible to plug it in if people think it makes sense.
  • What about being able to link from objects. E.g. it is annoying right now that an object cannot be mod,copy,trans but "trans" meaning here that all the copied will be deleted once you give it to another person. Because of that one permission is usually missing. Either you cannot copy it or you cannot transfer it. So here is how it might be
    • Agent buys object which is full perm but it should not be allowed to sell multiple copies of it, only the one you bought.
    • Agent rezzes multiple copies and eventually modifies them
    • Agent give the object to another agent (or sells it). When he does this all the copies should be deleted.
    • It could be implemented as links to the original object or the object itself is more or less the group of all rezzed items. It makes sure the user can do whatever he wants but cannot just make money from selling multiple copies if not bought.
  • Make derivations possible, like e.g. IMVU has it. You buy some object and modify it. You then can resell it but the original creator still gets some fraction for each sold copy.
  • For all the mentioned permissions the protocol should provide a means of specifying these capabilities. If you want to sell derivations the other agent domain also needs to support it and needs to be trusted. Possible new permissions could be 'sell copies' and 'franchise' with additional minimum percentage the creator defines (modifiable upwards by the next owner, but not downwards). If object is copy and transfer, seller's copies get deleted with a transfer, if object is set to sell copies, seller's copies are not deleted. Maybe the definition of a minimum price might be interesting, too.
  • Access controls beyond the walls of a single managed protection domain like the Linden grid are actually doomed to failure, for numerous reasons detailed by security and cryptography heavyweights who have explored DRM. Nevertheless, extending existing SL object permissions to "trusted" external sites is still perfectly feasible ... but it would be a mistake to believe that such access restrictions would be anything but temporary. This fact will have to be made clear to asset creators to avoid legal problems and discontent later on, as a social measure. As a limited technical measure, a Local_Distribution_Only permissions bit will probably be required as well.
    • To put it bluntly, unless you can create a system which either allows no objects without full perms to leave a particular trusted group of agent domains, or create a system which guarantees that permissions will be respected, you will get a massive shit-storm from content creators, which no amount of explanations about the ultimate pointlessness of DRM will negate. Create a grid system which doesn't respect the current system or permissions, and content creators will not use it. --Ian Betteridge 08:49, 2 November 2007 (PDT)

Identity

This section has been moved to its own wikipage: Identity

Privacy and control

  • Motivation
  • The single-grid SL implemented privacy and control in a manner not untypical for centralized, managed systems, effectively denying privacy as a concept and exercising control (lighthanded, but nevertheless control) over world inhabitants. The policy also lead to implicit responsibility for the actions of inhabitants, on the basis of "if you police it, then you are responsible for any infractions".
  • In a worldwide, distributed, and massively scaled universe of interconnected 3rd party worlds and grids, this current approach is no longer tenable, for a number of reasons:
  • RL identity verification is neither generally feasible nor in many instances desireable (see Identity, above).
  • Attempts to enforce strong guarantees suffer from the same fundamental weakness as DRM, and lead to a similar arms race.
  • The laws of California are not generally of interest in the rest of the world.
  • The operators of individual grids will not in general have control rights elsewhere, let alone legal jurisdiction.
  • In some countries more than others, citizens place extremely high value on individual privacy, often protected by law.
  • Privacy is relevant to personal security as well, thwarting stalkers and even being helpful for domestic security.
  • Social mores vary immensely across the world, so imposing those of one society on another is misplaced and generally not desireable.
  • Open source denies the possibility of adding covert wiretaps and similar measures, so distributed monitoring is infeasible.
  • Policing and assuming responsibility for the actions of others is itself a recipe for discontent and ultimately failure.
  • The above suggests that attempting to implement the privacy and control policies of the original SL in the new architecture would not be an appropriate goal. Instead, privacy and control might better be focussed in a different direction, as below.
  • Requirements
  • The following requirements could be well suited to a universe of multiple distributed domains and high cultural diversity:
  • Implement strong(er) privacy guarantees
Although "evil" attached worlds and grids will unavoidably be able to subvert privacy measures within their own domains, by default there should be a presumption of privacy to cater for those societies where privacy is valued. This includes:
  • Built-in volumetric barriers, for example Argent Stonecutter's remarkably simple [Parcel Basements].
  • End-to-end encryption for non-vicinity communication channels.
  • Encryption of client-server traffic to defeat in-transit monitoring.
  • Disclaim control / gain immunity of common carrier
"Common carrier" immunity is historically only recognized for PTTs, and has been slow in moving into the realm of ISPs and higher level services providers. Nevertheless, commonsense offers that you cannot control what you cannot see, and you cannot reasonably be held accountable for what you do not control. Barriers to visibility added for the sake of privacy can therefore also deliver a useful defence and tangible business benefits, particularly in domains where personal freedoms are expected.
  • Limit the amount of logging, and keep permanent records for financial transactions alone.
  • Replace "guardian responsibility" by "personal responsibility":
  • Increase the power of parcel and region owners to detect the sources of abuse and remove it.
  • Increase the power of individuals to make unwanted effects/objects disappear from client visibility.
  • Add arbitrary owner-defined land tags to provide flexible classification, and land entry barriers.
  • Add personal interest tagging, to trigger land barriers and avoid unwanted surprises.
  • While the above are technical measures relevant to architecture, many coercive forces are arrayed against privacy and towards stronger control over virtual citizens, so be prepared for hard times and pressure.

Viewer

  • allow all sorts of viewers, from 3D to cellphone to web sites
    • Create a viewer with the absolute minimum functionality possible (i.e. core client functions) and then make it optionally extensible based on client capability.
      • Put core protocol functionality (login/logout, movement etc) into a library
      • Make the server only send client data it has asked for (client sends "i want prims" message and get prims etc)
      • Should be trivial to integrate with other systems if this is done correctly - IRC gateways for IMs for example - note: there should be thoughts about SPAM prevention from the very beginning. A "We can think about that later" wont work here!
    • Allow the client to reassign controls and common functions to a Human Interface Device (gamepad, joystick, customized keyboard, a Bluetooth-connected Wii Remote, etc.)
  • Client-side Script runtime
    • In keeping with the idea of the core protocol functionality being a mere library, it could be possible to make the rest of the viewer very modular in this sense and use a scripting language as the glue, or to enable the scripts to execute library calls directly depending on configuration
    • scriptable chat & movements avatar (bot)
    • advanced graphical hud
      • This needs clarification - it seems a good idea to allow 2D sprites rather than only 3D objects built on prims to be mapped onto the HUD, it also seems a good idea to empower the scripts with better capabilities for drawing on such a 2D plane
  • Functional refactoring of viewer
    • The current SL viewer implements functions from a large number of domains, many of them concerned with maintaining avatar presence (login, avatar state and behaviour, communications/protocol and event handling, etc), and many others concerned with the actual viewing (managing and rendering a graphic 2D UI and 3D world representation). It is large, monolithic and growing, and quite inflexible in this state, because new clients can be supported only by full code replication, and only one can run at a time per presence because of this. Large-scale refactoring is required here if we desire something better.
  • To cater for the stated requirement of allowing all sorts of viewers and running client-side scripting in a flexible manner, then at least the presence-related functions need to be extracted from current graphics code. This would then permit the following scenarios, for example:
[Use cases]
  • An intermittent mobile viewer could periodically manipulate or monitor an avatar presence currently logged in from home.
  • Within the home, secondary screens running on home theatre equipment would offer a very appealing view of the world.
  • A scripted presence could run without any 3D viewer at all, for example a shop transactions handler.
  • An audio-only mobile viewer could attend an SL live music concert and still pay the musician's tip jar.
  • An event-only viewer could send events to the presence corresponding to RL events, eg. from musical instruments.
  • The machinima community could run multiple cameras observing a single presence for great flexibility.
  • Under crowd conditions (eg. most live music events), a low-detail viewer could be switched in without relogging.
  • SL-based games and sports would be able to run their own bespoke viewer and UI, without reworking presence code.
  • A client could be used for remote changing/editing 'information'. Think of a 'blog editor' for SL, for text displayed by hovertext, prim displays and future SVG or HTML displays.
  • To achieve this, the "viewer" needs to be redesigned as a view attached to a presence (more precisely, to the client-side presence handler, because the real presence is more properly considered to be server-side), in an N:1 relationship. Client-side scripting would then also attach to the presence handler in a similar manner, for UI control, as a proxy for human input, and also for distributed computation at the request of servers.
  • Or, as another way of looking at it, the presence handler (currently a part of the monolithic viewer) needs to become an independent multiplexer process, with graphics viewers and other applications and scripts attaching to it as needed, or not at all if no view is required. The development of many other diverse and quite minimalist viewers then becomes significantly easier.

Agents

This section has been to its own wikipage: Agent

Regions

This section has been moved its own wikipage: Region

Virtualization of regions

This section has been moved to its own wikipage: Virtualization

IM

Scalability of Instant Messaging (IM) is required along all the dimensions given in Project_Motivation, with added requirements:

  • Messaging must be extended to the distributed worldspace of attached regions and identities
  • Messaging fanout capability needs to grow automatically with world population to avoid endemic lag
  • Alongside increases to IM extent, we also need recipient-end facilities for IM denial and filtering
  • Local vicinity messaging requires additional controls to tame crowd spam at very large events

The magnitude of this task, as shown by the inability of the current IM system to handle even current population levels, suggests that it may be best not to reinvent the wheel of IM, but merely to interface to existing open-source messaging systems.

Implementation thoughts

Regions

This section has been moved its own wikipage: Region

Currency

  • how will the Linden Dollar be handled in a distributed grid architecture?
    • Will LL still support L$ in future, or will it be phased out? (perhaps a it should have no special place in the grid at all - just as there is no special currency on the web ?)
    • L$ exists as "a limited license right" within Second Life and therefore only makes sense within the official grid(s) owned by LL.
      • Privately-owned grids could be responsible for issuing their own licenses, to throttle their clients' use of those private resources.
        • Allowing private grids to issue their own limited license rights for use of their hardware makes it possible to disconnect them from many if not all centralized systems.
          • Remember that "resources" also includes "design and creation talent". Simply because there is no cost of reproduction of objects doesn't mean that it takes zero resources to make them. It takes the time, effort and knowledge of the designer. This is classical economics - labour, capital, and the means of production :) --Ian Betteridge 08:37, 2 November 2007 (PDT)
        • Such disconnections may allow us to implement a fully localized grid for use on private intranets or on a standalone system.
      • By their nature, private licenses would be mutually incompatible with the official "L$" licenses.
        • However it may be possible to setup automated gateways to convert between a 3rd-party currency and L$ or any other arbitary currency - something like a cross between paypal and the current popups for when one's L$ balance is too low
          • This is possible, but who gets to do the arbitrage? My guess is that, even if such systems are not created, there will emerge individuals and corporations who will exchange one currency for another for popular grid groupings. Consider, for example, the gold sellers in WoW. --Ian Betteridge 08:37, 2 November 2007 (PDT)
      • Alternative servers (or local grids) with accounts linked to LL servers might be able to purchase L$ to be issued to its members for use on LL servers.
  • allow for secure transactions other than in L$ via PayPal, credit cards, etc.
  • It is possible to maintain a single payment mechanism across multiple grids in a decentralized way using a social-network credit, or Hawala. Actual payment systems using this method exist (for example Ripple) and allow transparent convertibility between different currencies, some of them also allow transfers from and to Paypal and other online payment systems.
  • Replace currency with cryptographically signed documents with the electronic equivalent of an IOU?

Assets

This section has been moved its own wikipage: Asset

Protocols and interaction patterns

I've added this bucket to discuss the related topics of protocols and interaction patterns.

We have several building blocks proposed from Linden Labs, in the form of [certified http], REST, and [capabilties].

We do not have much described from Linden in two other major areas, namely how to choreograph calls into sets of calls which achieve an end (interaction patterns) and how to manage situations where we wish to setup an ongoing stream of interaction between multiple components. This last case is especially cogent when we discuss how region servers interact to provide the illusion of seamlass land.

Zha Ewry - 9/25/07


Capabilities

The capabilities of a domain, region or client do not have to mesh perfectly, but we should set about making sure it doesn't choke.

3D Web

3D Web simply put is forcing the multidimensional flat data of the internet into a single continuous three dimensional space. In the past it has largely failed because of a lack of hardware and attainable social pressure. SL has the potential to fill the 3D Web niche if it can at the region & domain level be integrated with traditional web applications.

  • I'm not sure that previous efforts failed because of the technology - they mostly failed because navigating information in 3D (as opposed to realistic looking environments) isn't very natural. I'm thinking particularly of Apple's HotSauce project [1].

Limited Capability Clients

When a client such as a cellphone or any limited capability client (LCC) connects, many of the more advanced features could be turned off for them but if there were a way to automate some of them, then the LCC could still participate.

There are a number of features that would enable supporting LCCs.

  • Scriptable capability deficiency handler
    • This could allow the world to automate features not supported by the client so the client could still participate.
      • A cellphone user goes to a show to listen to the audio stream, when they connect to the audio stream the region automatically seats them in a vacant chair.
  • Scriptable Auto-navigation waypoint system (choices would be present as menus, etc)
    • This could allow a user who can't see the world navigate it by menu.
  • Embedded web pages from prims made the primary focus so they can broken out and interacted with.


There is no requirement stated here that they be scripted in LSL. I don't think LSL would necessarily be appropriate -- Strife Onizuka 17:07, 27 September 2007 (PDT)

Capabilities: The path to 3D Web

With a framework in place to negotiate and script deficiencies in supported features, the ability to support an LCC that is in fact a web browser becomes possible. More importantly, the transition from Web to full 3D Web can be transitioned one feature at a time.

A website could be described as something like an art gallery. Information is organized into rooms and it typically line the walls. The passages between the rooms allow traversal from one page to another. This analogy is nowhere from perfect.

With a dynamic capabilities system, the client could drop down to dumb mode and browse the art gallery like a webpage or it could explore it as a 3D space with all the features turned on.

One interesting question for a migration/incremental move between static 3d content and a fully immersive environment, is when you can, and how you can, bring the space from static traditional content to a space where multiple avatars can interact. When we look at this space, it is interesting to notice that we're really doing several things at once in a space like SecondLife. There is the presentation of 3d content, there is the melding of multiple presences with the 3d content and the presentation of that content, the shared space to the viewers interacting in the space. Note that a 3d web, that is to say our current web with 3d content, would be a very static place, there isn't much notion of shared presence in the 2d web. -- Zha
If the Capabilities Framework is designed properly, it can allow for static 3d spaces with no user interaction. They won't be much fun, but thats another issue altogether. IMHO 3D Web by itself is doomed but when you tie it into the SL grid it has a chance of not being a total flop. LL is in an interesting position, they could be the next Network Solutions but for the 3D Web. -- Strife Onizuka 23:49, 27 September 2007 (PDT)


ANALYSIS: Region Subdivision as a scaling method

It shows why Region Subdivision is a flawed concept for a large number of reasons.

ANALYSIS: Per-resident subdivision of the Grid as a scaling method

This section has been moved to AWG Scalability through per-resident subdivision of the Grid.

A 'per-resident sim' as a finite state automaton ?

"one simulator software running per machine, but capable of opening or closing or transferring single VMs corresponding to a given resident"

That's one more trail of thought to pursue: how far can sim processes be parallelized ? The per-resident subdivision of the Grid might allow for a considerable independance of sim processes, that could in turn make it possible to run simulators as interchangeable instances. Thoughts, suggestions ?

Customer processing power contribution in exchange for sqm

One easy way to solve the problem of landless residents having no real simulator of their own or parasiting other people's sqm allotments: allow them to contribute their computer's processing power and net access bandwidth to the Grid, and earn sqm in return, so they can rez objects and run scripts. Make it possible to resell or rent those sqm, and the Grid will be self-growing.

ANALYSIS: Scalability through reverse proxies: the paravirtual grid

This section is now located on its own page: AWG:Scalability_through_reverse_proxies:_the_paravirtual_grid