Brainstorming

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

• allow to run a small grid on my laptop
• allow plug-ins
• 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.
• 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.

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.

Identity

• identity should be pluggable
  • [Please build a list of desired identity verification systems]
  • OpenID
• various grades of verification should be possible
  • Identity Verification:
    • "Is the user exactly who he/she claims he/she is?"
    • Very strong verification. Permanently links ID of account to real-world ID of user.
  • Age Verification:
    • "Is the user old enough to be on this system?"
    • Weak verification. Minimum amount needed to maintain compliance with child online access laws.
  • Unique Verification:
    • "Is this user unique, or is it an Alt?"
    • Weak verification. Minimum needed to enforce bans due to TOS violations.
    • Very difficult to enforce due to ease of changing commonly-used identifiers: IP address, MAC address, hardware serial numbers/profiles, etc.
• Verification must not require sensitive data to pass through insecure systems or require storage of sensitive data.

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.
  • 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
  • scriptable chat & movements avatar (bot)
  • advanced graphical hud

Agents

• allow agents to only allow to connect to certain regions

Regions

• allow regions of arbitrary size and form
• allow portals and landmass-style connections between regions or a mix of both
• 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"
• 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.

Implementation thoughts

Viewer

• 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?

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?
• 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

• how will virtual currency 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 ?)
  • 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.
      • 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.
    • 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.

Assets

• It is possible to implement asset storage in a completely distributed way
  • 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
  • To be successful it would have to retain many of the properties of the current 'fixed' storage schemes
    • 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.).
    • 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)
      • 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'!)
      • 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).
• 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
• Assets should be raw data.
  • Asset type, permissions, creator, watermark, etc would be meta-data.
  • Any kind of meta-data could be added and used or ignored as needed.
• 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?
  • Would an upload fee make sense for transferring objects to different grids?
  • If so, how would that fee be determined for a completed object?
  • Would some grids (or domains if you'd prefer) be able to reject items from other domains on a permission basis?