https://wiki.secondlife.com/w/api.php?action=feedcontributions&user=Gareth+Ellison&feedformat=atomSecond Life Wiki - User contributions [en]2024-03-29T00:05:51ZUser contributionsMediaWiki 1.36.1https://wiki.secondlife.com/w/index.php?title=User_talk:Salahzar_Stenvaag&diff=93486User talk:Salahzar Stenvaag2008-09-28T19:46:30Z<p>Gareth Ellison: </p>
<hr />
<div>Hi, please contact me about an important issue regarding your use of litesim's code. IM me inworld (Gareth Ellison) or email me at gareth@litesim.com</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=Open_Grid_Public_Beta/Public_Regions&diff=82440Open Grid Public Beta/Public Regions2008-08-03T01:29:42Z<p>Gareth Ellison: </p>
<hr />
<div>The following OpenSim regions supporting the Open Grid protocol are available for you to teleport to once you've authenticated to the agent domain:<br />
<br />
== Litesim Mainland ==<br />
<br />
* http://lsmainland.ogs-openuser.litesim.com:8000/ogp_listen<br />
* 24/7 - occasional issues<br />
* Contact: [[User:Gareth Ellison | Gareth Nelson]]<br />
* E-Mail: [mailto://gareth@litesim.com Gareth Nelson]<br />
* About 10 regions on the grid<br />
* Can also now do TP into other random (non-OGP) grids and tested with OSGrid and central grid<br />
<br />
== Ugotrade ==<br />
<br />
* http://ugotrade.net:9000<br />
* Times Available<br />
* Contact: Tara5 Oh<br />
<br />
== COM.lounge / Tao Takashi / mrtopf.de ==<br />
<br />
* http://plonetv.de:9000<br />
* currently offline due to awaiting new patch<br />
* Contact: [http://mrtopf.de/blog Tao Takashi]<br />
<br />
== BlueWall ==<br />
<br />
* http://ascent.bluewallgroup.com:9300<br />
* 24/7 - may be unavailable for short periods for updates/maintenance<br />
* Contact: [[User:BlueWall Slade | Bluewall Slade]]<br />
* E-Mail: [mailto://BlueWall.Slade@gmail.com BlueWall Slade]<br />
<br />
== Elsewhere ==<br />
<br />
* Region URL: http://opensim.nowherevirtual.com:9000<br />
* Times Available: 24/7 (except for maintenance)<br />
* Contact: [[User:Emma Nowhere | Emma Nowhere ]]<br />
* E-Mail: [mailto://emma.nowhere@gmail.com Emma Nowhere]<br />
<br />
== LJPOGP00 ==<br />
<br />
* http://98.26.97.209:9000<br />
* 24/7 - may be unavailable for short periods for updates/maintenance<br />
* Contact: [[User:Julie Wasserstrom | Julie Wasserstrom]]<br />
* E-Mail: [mailto://Julie.Wasserstrom@gmail.com Julie Wasserstrom]<br />
<br />
== Planck ==<br />
<br />
* Region URL: planck.vworlds.co.uk:9000<br />
* Times Available: 0:800 23:00 UTC 24/7 when new server is ready<br />
* Contact [mailto://chris.samtanko@googlemail.com Chris Samtanko]<br />
<br />
== BrackenLand ==<br />
<br />
* http://<br />
* Temporarily offline<br />
* Contact: [[User:Gomez Bracken | Gomez Bracken]]<br />
* E-Mail: [mailto://gomez@temptations-club.com Gomez Bracken]<br />
<br />
== Piper ==<br />
<br />
* Region URL: http://primforge.org:9009<br />
* 24/7 - may be unavailable for short periods for updates/maintenance<br />
* Contact: [[User:Torrid Luna | Torrid Luna]]<br />
<br />
== Lakewood / Ducatillon Group Project ==<br />
<br />
* http://dgpexperimental.selfip.org:9000<br />
* 24/7 - might be unavailable for short periods as far as we update/maintain the location<br />
* Contact: [[User:McCoy Ducatillon | McCoy Ducatillon]]<br />
* E-Mail: [mailto://ducatillongroup@gmail.com McCoy Ducatillon]<br />
<br />
<br />
<br />
[[category:Open_Grid_Public_Beta]]</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=AW_Groupies&diff=69739AW Groupies2008-06-02T02:34:53Z<p>Gareth Ellison: /* AWG and citizen pages */</p>
<hr />
<div>=Purpose=<br />
Serious technical discussion about Linden Lab's [[Architecture Working Group|Architecture Working Group (AWG)]]. "AW Groupies" is an unofficial, Resident-operated group, though most (all?) members also participate in the AWG.<br />
<br />
Invite only (apply in-world to [[User:Zha Ewry|Zha Ewry]]), but the criterion is simple. Show up and contribute to the AWG, at [[User:Zero Linden|Zero Linden]]'s office hours, or on the Wiki, or on SL-Dev.<br />
<br />
=Activities=<br />
Currently, we seem to be meeting once or twice a week in-world, and the group IM chat has been quite lively.<br />
<br />
Also members are quite active on the wiki and in the SLDEV mailing list.<br />
<br />
A public SVN repository is open to all AW Groupies members here: <br />
* http://openmv.org/cgi-bin/viewvc.cgi/archwg/<br />
<br />
Contact anyone with root on openmv.org for an account if you are in the AW Groupies group in-world.<br />
<br />
==Architecture Working Group meetings==<br />
* [[AWG_Meeting_1|AWG I annual meeting transcript, participants' responses, etc]]<br />
* [[AWG_Meeting_2|AWG II annual meeting transcript, video, participants' responses, etc]]<br />
<br />
==In-World Meetings==<br />
<br />
Meetings are scheduled via the "[http://www.google.com/calendar/embed?src=pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com SL AW Groupies" google calendar]"<br />
<br />
* [http://www.google.com/calendar/feeds/pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com/public/basic XML]<br />
* [http://www.google.com/calendar/ical/pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com/public/basic.ics ICal]<br />
* Calendar ID: pdd5mpktklo89bgmfgi076mcc4@group.calendar.google.com<br />
* [http://www.google.com/calendar/render?cid=pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com Add to your Google Calendar]<br />
<br />
===Meeting Agendas===<br />
<br />
Each meeting should have an agenda --- which will be distributed via<br />
* google calendar entry<br />
* in-world notice to the SL "AW Groupies" group<br />
* the [[AW Groupies In-World Meeting Agenda]] wiki page<br />
<br />
<br />
===Chat Logs===<br />
<br />
Chat logs of the in-world meetings are published and accessible via the links below:<br />
<br />
* 2007 meetings<br />
:* September: [[sept_28_2007_AWGroupies | 28]]<br />
:* October: [[oct_1_2007_AWGroupies | 1]] [[ oct5_scale_rest | 5]] [[User:Zero_Linden/Office_Hours/2007_Oct_09|9 --Zero's office]] [[ AWG_oct16)chat| 16]]<br />
:* November: [[Nov_6_2007_Scope_IM_goingfwd | 6]] [[Nov_13_2007_Scope_Login | 13]] [[Nov_20_2007_Scope_Caps%26things | 20]]<br />
*2008 meetings<br />
:* January: [[AWGroupies-2008-01-08|08]]<br />
:*February: [[AWGroupies-2008-02-19|19]]<br />
:*April: [[AWGroupies-2008-04-08|08]] [[AWGroupies-2008-04-22|22]] [[AWGroupies-2008-04-29|29]]<br />
:*May: [[AWGroupies-2008-05-20|20]] [[AWGroupies-2008-05-27|27]]<br />
<br />
* [[User:Zero_Linden#Transcripts_of_previous_office_hours|Zero Linden's Office Hour Transcripts]]<br />
* [[User:Which_Linden|Which Linden's Office Hour Transcripts]]<br />
* [http://opensimulator.org/wiki/Special:Search?search=chat+log OpenSim chat logs]<br />
* [[Mono/2008-04-04 | mono beta meeting discussion of het-grid]]<br />
<br />
<br />
(if you post chat logs, you might want to use the [[User:Dr_Scofield/logtransform|sllog2wiki perl script]] to turn them into a more readable wiki table format ready to copy & paste into the chat log page)<br />
<br />
Chat logs of AWGroupies meetings should be summarized on the wiki.<br />
<br />
==Viewpoint Advocacy Groups==<br />
<br />
[[Viewpoint Advocacy Groups]] - groups to focus on specific requirements.<br />
=== AWG-specific VAGs===<br />
<!-- Keep these in alphabetical order --><br />
* [[Core Grid Services, Protocols, and Structures VAG]]<br />
* [[Event Scalability VAG]]<br />
* [[Geometry and Physics VAG]]<br />
* [[Live Performances VAG]]<br />
* [[Quality Assurance VAG]]<br />
* [[Scalability VAG]]<br />
=== AWG-related VAGs===<br />
* [[Map_API_VAG]]<br />
* [[Multi-Process Client VAG -- draft]]<br />
<br />
=Work-In-Progress=<br />
<br />
Work-in-progress wiki pages are architecture pages that are (as the name implies ;-)) work in progress. Once the group has reached consensus that a particular topic is "good-to-go" we'll graduate that page to the [[Architecture Working Group|main AWG page]].<br />
<br />
==General Concerns==<br />
* [[Scoping]]<br />
* [[Architecture Working Group Glossary|Glossary]]<br />
* [[Use Cases]]<br />
==Communications==<br />
* [[Initial CAPS seed]]<br />
* [[AWG initial flows]]<br />
* [[AWG flows login]]<br />
<br />
* [[Mudata]]<br />
* [[Streamlet]]<br />
===Documenting current protocols===<br />
* [[AWG_Test_Harness]]<br />
** [[User:Which_Linden/Office_Hours/2008_May_22| Which Linden office hours 22 May 2008]]<br />
====AWG and citizen pages====<br />
* [[Current_login_protocols]]<br />
* [[Current_Sim_Capabilities]]<br />
* [[Example_protocol_code]]<br />
* [[Hegemons_Login_Analysis#Very_simple_C.23__server]]<br />
* [[User:Gareth_Ellison/Supergrid|Litesim grid interop]]<br />
<br />
====Linden Lab pages====<br />
* [[Service_Disruptions|"Satellite's Eye" view of the Second Life architecture from a service disruption POV]]<br />
* [[Message_System_and_Capabilities]]<br />
* [[Viewer_Authentication]]<br />
* [[Protocol]]<br />
* [[LLSD]]<br />
* [[Certified_HTTP_Escrow]]<br />
* [[ImprovedInstantMessage]]<br />
* [[Client_parameters|client command line parameters and stuff]]<br />
<br />
<br />
====libsecondlife reference pages====<br />
* [http://www.libsecondlife.org/wiki/Login Login page] <br />
* [http://www.libsecondlife.org/wiki/Protocol_%28network%29 Protocol page] <br />
* [http://www.libsecondlife.org/wiki/Category:Packets packets index]<br />
* [http://www.libsecondlife.org/wiki/Movement Movement]<br />
<br />
====opensim reference pages====<br />
* [http://opensimulator.org/wiki/Grid_Architecture_Diagram opensim grid architecture diagram]<br />
* [http://opensimulator.org/images/3/3c/OGS1Login_Sequence.jpg login diagram (same general sequence as current LL login)]<br />
<br />
=== Future Protocols===<br />
* [[Second_Life_Login_API_Strawman]]<br />
:deprecated in favor of:<br />
* [[SLGOGP_Draft_1 | Second Life Grid Open Grid Protocol (SLGOGP_Draft_1)]]<br />
*[[Architecture_Working_Group#Design_Documents | Ongoing next generation protocols documentation effort by Linden Lab]]<br />
=== Possible future directions ===<br />
* [http://en.wikipedia.org/wiki/OpenID| OpenID A decentralized single sign-on system]<br />
* [http://en.wikipedia.org/wiki/Yadis| Yardis A digital identity protocol]<br />
<br />
==Asset Security==<br />
* [[Protecting content in an open grid]]<br />
==Scaling Issues==<br />
* [[Brainstorming#ANALYSIS:_Region_Subdivision_as_a_scaling_method| Region Subdivision]]<br />
* [[Brainstorming#ANALYSIS:_Scalability_through_reverse_proxies:_the_paravirtual_grid| Reverse Proxies]]<br />
* [[AWG Scalability through per-resident subdivision of the Grid| Resident Subdivision]]<br />
==Other==<br />
* [[Use_Cases#Extended_Capability_Clients|Extended Capability Clients]]<br />
<br />
=Thinking-in-Progress=<br />
<br />
* Have a look and contribute to the [[Brainstorming|brainstorming]] page.<br />
<br />
* It's early days on the [[Multi-Process Client VAG -- draft]], but we would highly appreciate input to help with design choices and direction.<br />
<br />
=External Resources=<br />
<br />
Stuff of interest to or in connection with the [[AW Groupies]] or the [[Architecture Working Group]]:<br />
<br />
* [[Developer_communication_tools|Developer Communication Tools (Linden Lab)]]<br />
<br />
* [http://openmv.org/wiki/Main_Page OpenMetaverse Home] <br />
**[http://www.libsecondlife.org/wiki/Main_Page libsecondlife (libsl) homepage]<br />
**[http://opensimulator.org/wiki/Main_Page opensim homepage]<br />
**[http://openviewer.org/index.php/Main_Page openviewer homepage]<br />
* [http://www.realxtend.org/ realxtend homepage]<br />
* [http://www-03.ibm.com/press/us/en/pressrelease/22428.wss IBM PR re: AWG]<br />
<br />
==Mailing Lists==<br />
* [http://wiki.secondlife.com/wiki/SLDev Linden Lab (SLDev)]<br />
* [http://www.libsecondlife.org/wiki/Resources#Mailing_Lists libsecondlife]<br />
* [http://opensimulator.org/wiki/Main_Page opensim]<br />
* [http://openviewer.org/index.php/Main_Page#Mailing_lists openviewer]<br />
<br />
==IRC==<br />
* irc://irc.efnet.net/#opensl <br />
* irc://irc.freenode.net/#opensim * irc://irc.freenode.net/#opensim-dev<br />
* irc://irc.efnet.net/#libsl * irc://irc.efnet.net/#libsl-dev<br />
* irc://irc.freenode.net/#openviewer * irc://irc.freenode.net/#openviewer-dev<br />
* irc://irc.freenode.net/#realxtend (Finnish language but can handle English if needed)<br />
<br />
==Misc==<br />
<br />
* [http://blog.signpostmarv.name/2008/01/04/map-api-in-new-location/ discussion of new Map API and related issues]<br />
* [http://wiki.secondlife.com/wiki/Open_Source Open Source Portal] --index to all things Open Source for Linden Lab<br />
* [http://www.cap-lore.com/CapTheory/index.html Capabilities theory and practice]<br />
<br />
=Members=<br />
<br />
Founder [[User: Zha Ewry|Zha Ewry]]<br />
<br />
[[User:Saijanai Kuhn|Saijanai Kuhn]]<br />
<br />
[[User:Tao Takashi|Tao Takashi]]<br />
<br />
[[User:Tillie Ariantho|Tillie Ariantho]]<br />
<br />
[[User:Dr Scofield|Dr Scofield]]<br />
<br />
[[User:Burhop Piccard|Burhop Piccard]]<br />
<br />
[[User:Vicero Lambert|Vicero Lambert]]<br />
<br />
[[User:Morgaine Dinova|Morgaine Dinova]]<br />
<br />
[[User:Silicon Plunkett|Silicon Plunkett]]<br />
<br />
[[Category: AW Groupies]]</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=User:Gareth_Ellison/Supergrid&diff=69624User:Gareth Ellison/Supergrid2008-06-01T03:56:35Z<p>Gareth Ellison: /* Basic components */</p>
<hr />
<div>{{RightToc}}<br />
I was asked by someone to post the specs of the supergrid to the wiki.<br />
<br />
The supergrid is the term I use to describe the set of services I have running at litesim.com (if it is inappropriate to mention competitors to LL here, please feel free to edit out) to enable centralised login.<br />
<br />
== Basic components ==<br />
<br />
Here's a brief overview of the current system as running today<br />
<br />
=== metaverse.xml ===<br />
This file is a listing of all known grids in a kind of local cache. It specifies as an LLSD map a listing of domains and grids under those domains together with information on what protocol each grid uses and the default region and co-ordinates with relevant URLs to different services:<br />
<pre><br />
<br />
<llsd><br />
<map><br />
<key>domains</key><br />
<map><br />
<key>secondlife.com</key><br />
<map><br />
<key>grids</key><br />
<map><br />
<key>agni</key><br />
<map><br />
<key>protocol</key><br />
<string>unknown</string><br />
<key>loginpage</key><br />
<string>http://secondlife.com/app/login</string><br />
<key>loginuri</key><br />
<string>https://login.agni.lindenlab.com/cgi-bin/login.cgi</string><br />
<key>desc</key><br />
<string>The Second Life(TM) main grid</string><br />
</map><br />
<key>aditi</key><br />
<map><br />
<key>protocol</key><br />
<string>unknown</string><br />
<key>loginpage</key><br />
<string>http://secondlife.com/app/login/beta</string><br />
<key>loginuri</key><br />
<string>https://login.aditi.lindenlab.com/cgi-bin/login.cgi</string><br />
<key>desc</key><br />
<string>The Second Life(TM) beta grid</string><br />
</map><br />
</map><br />
<key>defgrid</key><br />
<string>agni</string><br />
</map><br />
<key>osgrid.org</key><br />
<map><br />
<key>grids</key><br />
<map><br />
<key>OSGrid</key><br />
<map><br />
<key>protocol</key><br />
<string>OGS</string><br />
<key>loginuri</key><br />
<string>http://www.osgrid.org:8002/</string><br />
<key>defregion</key><br />
<array><br />
<string>Wright Plaza</string><br />
<real>128.0</real><br />
<real>128.0</real><br />
<real>30.0</real><br />
</array><br />
<key>desc</key><br />
<string>The first and oldest grid running on FLOSS code</string><br />
</map><br />
</map><br />
<key>defgrid</key><br />
<string>OSGrid</string><br />
</map><br />
<key>litesim.com</key><br />
<map><br />
<key>supergrid</key><br />
<map><br />
<key>loginpage</key><br />
<string>https://www.litesim.com/loginscreen</string><br />
<key>loginuri</key><br />
<string>https://www.litesim.com/viewer_login</string><br />
<key>desc</key><br />
<string>The original and best super grid</string><br />
</map><br />
<key>grids</key><br />
<map><br />
<key>fantasyislands</key><br />
<map><br />
<key>session_trackers</key><br />
<string>http://fantasyislands.grids.litesim.com:8000/session_trackers</string><br />
<key>account_sync</key><br />
<string>http://fantasyislands.grids.litesim.com:8000/sync_ogs</string><br />
<key>protocol</key><br />
<string>OGS</string><br />
<key>desc</key><br />
<string>A Litesim Ltd customer</string><br />
<key>defregion</key><br />
<array><br />
<string>FantasyHQ</string><br />
<real>128.0</real><br />
<real>128.0</real><br />
<real>30.0</real><br />
</array><br />
<key>loginuri</key><br />
<string>http://fantasyislands.ogs-openuser.litesim.com:8002</string><br />
</map><br />
<key>lsmainland</key><br />
<map><br />
<key>session_trackers</key><br />
<string>http://71.6.154.182:8000/session_trackers</string><br />
<key>account_sync</key><br />
<string>http://71.6.154.182:8000/sync_ogs</string><br />
<key>protocol</key><br />
<string>OGS</string><br />
<key>desc</key><br />
<string>The litesim.com mainland</string><br />
<key>defregion</key><br />
<array><br />
<string>Litesim welcome</string><br />
<real>128.0</real><br />
<real>128.0</real><br />
<real>30.0</real><br />
</array><br />
<key>loginuri</key><br />
<string>http://lsmainland.ogs-openuser.litesim.com:8002</string><br />
</map><br />
<key>lsdevraw</key><br />
<map><br />
<key>protocol</key><br />
<string>raw</string><br />
<key>desc</key><br />
<string>Litesim development grid, RAW protocol, i.e you provide a UDP endpoint as the region name</string><br />
</map><br />
</map><br />
<key>defgrid</key><br />
<string>lsmainland</string><br />
</map><br />
</map><br />
</map><br />
</llsd><br />
</pre><br />
<br />
Should a domain not occur in this listing, it is intended that the login server or other client will instead retrieve www.domain.com/metaverse.xml and attempt to obtain the same data. In the current implementation, domain.com is authorative only for grids hosted at domain.com, and www.example.com/metaverse.xml may contain grids under domain.com only for the purposes of caching. Clients connect to a grid via a non-authorative metaverse.xml at their own risk.<br />
<br />
=== node controller daemon ===<br />
<br />
Somewhat misnamed due to its origins as a remote admin daemon for administering cluster nodes, this daemon has now taken on the role of sync'ing accounts between the supergrid and trusting remote subgrids. Should a user try to login via the supergrid to a remote subgrid which does not trust it, the supergrid may still contact the node controller if one exists to request session updates by posting to the relevant URL.<br />
<br />
The purpose in the current system of the node controller is to accept account syncronisations and to route session updates. It acts like a bridge currently between the supergrid and the open grid services installation or other protocols and source code in python is available here - https://www.litesim.com/svn/node_control - please note that this code may also be mixed up with general maintenance scripts.<br />
<br />
=== supergrid login server ===<br />
<br />
The login server is integrated presently as a web.py module on the website and handles parsing login requests to locate the right subgrid. At startup the webserver loads the known grids out of a MySQL database and creates the LLSD representation for metaverse.xml. It then caches these details in memory and enables users to login with the URL scheme described in the next section. Should an untrusted or untrusting grid be requested it acts as a passive proxy, only relaying the XML-RPC login as-is and manipulating only the user agent string in the request. At the present time I am awaiting consent from LL's lawyers to begin testing more direct manipulation of the login request and the creation of ghost avatars etc to enable cross-grid TPs and IMs (by maintaining presence on SL with a bot that can act as a relay).<br />
<br />
== URL scheme ==<br />
<br />
The URL scheme has been chosen to be very simple to use and expand, quite simply:<br />
<br />
RegionName@domain.tld:gridname<br />
<br />
For example, my home location is one of:<br />
<br />
baikal@secondlife.com:agni<br />
or<br />
home@secondlife.com:agni<br />
or<br />
last@secondlife.com:agni<br />
or<br />
Litesim Welcome@litesim.com:lsmainland<br />
or<br />
home@litesim.com:lsmainland<br />
<br />
This URL is entered into the start location on the standard viewer and eliminates the need for a seperate grid selection dropdown box and thus enables use of the standard viewer unchanged.<br />
<br />
== The rest ==<br />
<br />
More specs and code to come!</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=User:Gareth_Ellison/Supergrid&diff=69617User:Gareth Ellison/Supergrid2008-06-01T03:47:32Z<p>Gareth Ellison: /* metaverse.xml */</p>
<hr />
<div>{{RightToc}}<br />
I was asked by someone to post the specs of the supergrid to the wiki.<br />
<br />
The supergrid is the term I use to describe the set of services I have running at litesim.com (if it is inappropriate to mention competitors to LL here, please feel free to edit out) to enable centralised login.<br />
<br />
== Basic components ==<br />
<br />
Here's a brief overview of the current system as running today<br />
<br />
=== metaverse.xml ===<br />
This file is a listing of all known grids in a kind of local cache. It specifies as an LLSD map a listing of domains and grids under those domains together with information on what protocol each grid uses and the default region and co-ordinates with relevant URLs to different services:<br />
<pre><br />
<br />
<llsd><br />
<map><br />
<key>domains</key><br />
<map><br />
<key>secondlife.com</key><br />
<map><br />
<key>grids</key><br />
<map><br />
<key>agni</key><br />
<map><br />
<key>protocol</key><br />
<string>unknown</string><br />
<key>loginpage</key><br />
<string>http://secondlife.com/app/login</string><br />
<key>loginuri</key><br />
<string>https://login.agni.lindenlab.com/cgi-bin/login.cgi</string><br />
<key>desc</key><br />
<string>The Second Life(TM) main grid</string><br />
</map><br />
<key>aditi</key><br />
<map><br />
<key>protocol</key><br />
<string>unknown</string><br />
<key>loginpage</key><br />
<string>http://secondlife.com/app/login/beta</string><br />
<key>loginuri</key><br />
<string>https://login.aditi.lindenlab.com/cgi-bin/login.cgi</string><br />
<key>desc</key><br />
<string>The Second Life(TM) beta grid</string><br />
</map><br />
</map><br />
<key>defgrid</key><br />
<string>agni</string><br />
</map><br />
<key>osgrid.org</key><br />
<map><br />
<key>grids</key><br />
<map><br />
<key>OSGrid</key><br />
<map><br />
<key>protocol</key><br />
<string>OGS</string><br />
<key>loginuri</key><br />
<string>http://www.osgrid.org:8002/</string><br />
<key>defregion</key><br />
<array><br />
<string>Wright Plaza</string><br />
<real>128.0</real><br />
<real>128.0</real><br />
<real>30.0</real><br />
</array><br />
<key>desc</key><br />
<string>The first and oldest grid running on FLOSS code</string><br />
</map><br />
</map><br />
<key>defgrid</key><br />
<string>OSGrid</string><br />
</map><br />
<key>litesim.com</key><br />
<map><br />
<key>supergrid</key><br />
<map><br />
<key>loginpage</key><br />
<string>https://www.litesim.com/loginscreen</string><br />
<key>loginuri</key><br />
<string>https://www.litesim.com/viewer_login</string><br />
<key>desc</key><br />
<string>The original and best super grid</string><br />
</map><br />
<key>grids</key><br />
<map><br />
<key>fantasyislands</key><br />
<map><br />
<key>session_trackers</key><br />
<string>http://fantasyislands.grids.litesim.com:8000/session_trackers</string><br />
<key>account_sync</key><br />
<string>http://fantasyislands.grids.litesim.com:8000/sync_ogs</string><br />
<key>protocol</key><br />
<string>OGS</string><br />
<key>desc</key><br />
<string>A Litesim Ltd customer</string><br />
<key>defregion</key><br />
<array><br />
<string>FantasyHQ</string><br />
<real>128.0</real><br />
<real>128.0</real><br />
<real>30.0</real><br />
</array><br />
<key>loginuri</key><br />
<string>http://fantasyislands.ogs-openuser.litesim.com:8002</string><br />
</map><br />
<key>lsmainland</key><br />
<map><br />
<key>session_trackers</key><br />
<string>http://71.6.154.182:8000/session_trackers</string><br />
<key>account_sync</key><br />
<string>http://71.6.154.182:8000/sync_ogs</string><br />
<key>protocol</key><br />
<string>OGS</string><br />
<key>desc</key><br />
<string>The litesim.com mainland</string><br />
<key>defregion</key><br />
<array><br />
<string>Litesim welcome</string><br />
<real>128.0</real><br />
<real>128.0</real><br />
<real>30.0</real><br />
</array><br />
<key>loginuri</key><br />
<string>http://lsmainland.ogs-openuser.litesim.com:8002</string><br />
</map><br />
<key>lsdevraw</key><br />
<map><br />
<key>protocol</key><br />
<string>raw</string><br />
<key>desc</key><br />
<string>Litesim development grid, RAW protocol, i.e you provide a UDP endpoint as the region name</string><br />
</map><br />
</map><br />
<key>defgrid</key><br />
<string>lsmainland</string><br />
</map><br />
</map><br />
</map><br />
</llsd><br />
</pre><br />
<br />
Should a domain not occur in this listing, it is intended that the login server or other client will instead retrieve www.domain.com/metaverse.xml and attempt to obtain the same data. In the current implementation, domain.com is authorative only for grids hosted at domain.com, and www.example.com/metaverse.xml may contain grids under domain.com only for the purposes of caching. Clients connect to a grid via a non-authorative metaverse.xml at their own risk.</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=User:Gareth_Ellison/Supergrid&diff=69615User:Gareth Ellison/Supergrid2008-06-01T03:45:06Z<p>Gareth Ellison: /* Basic components */</p>
<hr />
<div>{{RightToc}}<br />
I was asked by someone to post the specs of the supergrid to the wiki.<br />
<br />
The supergrid is the term I use to describe the set of services I have running at litesim.com (if it is inappropriate to mention competitors to LL here, please feel free to edit out) to enable centralised login.<br />
<br />
== Basic components ==<br />
<br />
Here's a brief overview of the current system as running today<br />
<br />
=== metaverse.xml ===<br />
This file is a listing of all known grids in a kind of local cache. It specifies as an LLSD map a listing of domains and grids under those domains together with information on what protocol each grid uses and the default region and co-ordinates with relevant URLs to different services:<br />
<pre><br />
<br />
<llsd><br />
<map><br />
<key>domains</key><br />
<map><br />
<key>secondlife.com</key><br />
<map><br />
<key>grids</key><br />
<map><br />
<key>agni</key><br />
<map><br />
<key>protocol</key><br />
<string>unknown</string><br />
<key>loginpage</key><br />
<string>http://secondlife.com/app/login</string><br />
<key>loginuri</key><br />
<string>https://login.agni.lindenlab.com/cgi-bin/login.cgi</string><br />
<key>desc</key><br />
<string>The Second Life(TM) main grid</string><br />
</map><br />
<key>aditi</key><br />
<map><br />
<key>protocol</key><br />
<string>unknown</string><br />
<key>loginpage</key><br />
<string>http://secondlife.com/app/login/beta</string><br />
<key>loginuri</key><br />
<string>https://login.aditi.lindenlab.com/cgi-bin/login.cgi</string><br />
<key>desc</key><br />
<string>The Second Life(TM) beta grid</string><br />
</map><br />
</map><br />
<key>defgrid</key><br />
<string>agni</string><br />
</map><br />
<key>osgrid.org</key><br />
<map><br />
<key>grids</key><br />
<map><br />
<key>OSGrid</key><br />
<map><br />
<key>protocol</key><br />
<string>OGS</string><br />
<key>loginuri</key><br />
<string>http://www.osgrid.org:8002/</string><br />
<key>defregion</key><br />
<array><br />
<string>Wright Plaza</string><br />
<real>128.0</real><br />
<real>128.0</real><br />
<real>30.0</real><br />
</array><br />
<key>desc</key><br />
<string>The first and oldest grid running on FLOSS code</string><br />
</map><br />
</map><br />
<key>defgrid</key><br />
<string>OSGrid</string><br />
</map><br />
<key>litesim.com</key><br />
<map><br />
<key>supergrid</key><br />
<map><br />
<key>loginpage</key><br />
<string>https://www.litesim.com/loginscreen</string><br />
<key>loginuri</key><br />
<string>https://www.litesim.com/viewer_login</string><br />
<key>desc</key><br />
<string>The original and best super grid</string><br />
</map><br />
<key>grids</key><br />
<map><br />
<key>fantasyislands</key><br />
<map><br />
<key>session_trackers</key><br />
<string>http://fantasyislands.grids.litesim.com:8000/session_trackers</string><br />
<key>account_sync</key><br />
<string>http://fantasyislands.grids.litesim.com:8000/sync_ogs</string><br />
<key>protocol</key><br />
<string>OGS</string><br />
<key>desc</key><br />
<string>A Litesim Ltd customer</string><br />
<key>defregion</key><br />
<array><br />
<string>FantasyHQ</string><br />
<real>128.0</real><br />
<real>128.0</real><br />
<real>30.0</real><br />
</array><br />
<key>loginuri</key><br />
<string>http://fantasyislands.ogs-openuser.litesim.com:8002</string><br />
</map><br />
<key>lsmainland</key><br />
<map><br />
<key>session_trackers</key><br />
<string>http://71.6.154.182:8000/session_trackers</string><br />
<key>account_sync</key><br />
<string>http://71.6.154.182:8000/sync_ogs</string><br />
<key>protocol</key><br />
<string>OGS</string><br />
<key>desc</key><br />
<string>The litesim.com mainland</string><br />
<key>defregion</key><br />
<array><br />
<string>Litesim welcome</string><br />
<real>128.0</real><br />
<real>128.0</real><br />
<real>30.0</real><br />
</array><br />
<key>loginuri</key><br />
<string>http://lsmainland.ogs-openuser.litesim.com:8002</string><br />
</map><br />
<key>lsdevraw</key><br />
<map><br />
<key>protocol</key><br />
<string>raw</string><br />
<key>desc</key><br />
<string>Litesim development grid, RAW protocol, i.e you provide a UDP endpoint as the region name</string><br />
</map><br />
</map><br />
<key>defgrid</key><br />
<string>lsmainland</string><br />
</map><br />
</map><br />
</map><br />
</llsd><br />
</pre></div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=User:Gareth_Ellison/Supergrid&diff=69610User:Gareth Ellison/Supergrid2008-06-01T03:34:42Z<p>Gareth Ellison: New page: {{RightToc}} I was asked by someone to post the specs of the supergrid to the wiki. The supergrid is the term I use to describe the set of services I have running at litesim.com (if it is...</p>
<hr />
<div>{{RightToc}}<br />
I was asked by someone to post the specs of the supergrid to the wiki.<br />
<br />
The supergrid is the term I use to describe the set of services I have running at litesim.com (if it is inappropriate to mention competitors to LL here, please feel free to edit out) to enable centralised login.<br />
<br />
== Basic components ==</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=Core_Grid_Services,_Protocols,_and_Structures_VAG&diff=37886Core Grid Services, Protocols, and Structures VAG2007-10-23T22:56:35Z<p>Gareth Ellison: /* Members (Stakeholders) */</p>
<hr />
<div>(this is an initial draft so scope and focus are still fairly open. Please add comments to the [[Talk: VAG]] if you have slightly different viewpoints so we can try to converge on a common view. This discussion could also expose other similar VAG that are needed in this area --[[User:Zha Ewry|Zah]] 15:20, 23 October 2007 (PDT) )<br />
<br />
=Purpose=<br />
<br />
The Core Grid Services, Protocols and structure VAG focuses on the grid and web services, the protocols and the overall structure of the AWG's work. Particular attention is focused on creating designs and architecture which is consistent with the nature and approaches of the World Wide Web. <br />
<br />
See the [[Architecture Working Group]] and the [[Viewpoint Advocacy Groups]] for more information.<br />
<br />
=List of concerns addressed by this viewpoint=<br />
* Modeling services via REST<br />
* Best practices in Web Services Design<br />
* Appropriate uses of C-hhtp, Escrow, and capabilities<br />
* How to handle continuing streams of events (pub/sub) in the architecture<br />
* The overall shape of the design, including concepts such as domains, proxies and computational boundaries. <br />
<br />
<br />
=Areas not addressed by this viewpoint=<br />
<br />
* Implementation of core components behind the architectural boundaries. We will examine such items only to the extent that they drive our core concerns.<br />
<br />
* Underlying representations of 3d objects. We may examine efficient encodings, but we will defer 3d issues to the [[Geometry and Physics VAG]]<br />
<br />
=Source of Viewpoint=<br />
<br />
=Use Cases=<br />
<br />
See the [[Architecture Working Group Glossary]] and [[usecase templates]] for more information on creating usecases. One liners are fine (and better than nothing) but more detail will result in a better understanding and a better architecture.<br />
<br />
* Category 1<br />
** Use case a<br />
** Use case b<br />
<br />
* Category 2<br />
** use case c<br />
** use case d<br />
<br />
=Related JIRA Issues=<br />
<br />
The following JIRA issues are known problems that this VAG would like to see resolved in any future architecture. The purpose of this list it to avoid problems that exist in the curent architecture. The more typical JIRAs that are more short term in nature or can be resolved by simple code or design change should not be listed here.<br />
<br />
* JIRA1<br />
* JIRA2<br />
<br />
=Organization=<br />
<br />
<br />
== Joining ==<br />
<br />
Anyone with an interest in this Viewpoint is welcome to join. You should join the [[AW_Groupies]] group in Second Life.<br />
<br />
== In world meetings ==<br />
<br />
We meet once a week in-world and more if people are available.<br />
<br />
Also members are active on the wiki and in the SLDEV mailing list.<br />
<br />
Meetings are scheduled via the "[http://www.google.com/calendar/embed?src=pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com SL AW Groupies" google calendar]"<br />
<br />
<br />
===Meeting Agendas===<br />
<br />
* TBD<br />
<br />
===Chat Logs===<br />
<br />
* TBD<br />
<br />
== Modeling Techniques used to express viewpoint ==<br />
<br />
None decided.<br />
<br />
<br />
=External Links=<br />
<br />
=Members (Stakeholders)=<br />
<br />
:[[User: Zha Ewry| Zha]] - Founder<br />
:[[User: Gareth Ellison| Gareth]] Generic hacker - you design, i code!</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=Streamlet&diff=35826Streamlet2007-10-16T02:06:08Z<p>Gareth Ellison: </p>
<hr />
<div>Streamlet is an extension on top of mulib which enables convienient event streams. For examples of streamlet in use please check the following links:<br />
<br />
* http://openmv.org/cgi-bin/viewvc.cgi/archwg/trunk/chat_client.py?view=markup<br />
* http://openmv.org/cgi-bin/viewvc.cgi/archwg/trunk/chat_server.py?view=markup</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=Streamlet&diff=35825Streamlet2007-10-16T02:05:43Z<p>Gareth Ellison: New page: Streamlet is an extension on top of mulib which enables convienient event streams. For examples of streamlet in use please check the following links: * http://openmv.org/cgi-bin/viewvc.cg...</p>
<hr />
<div>Streamlet is an extension on top of mulib which enables convienient event streams. For examples of streamlet in use please check the following links:<br />
<br />
* http://openmv.org/cgi-bin/viewvc.cgi/archwg/trunk/chat_client.py?view=markup<br />
* http://openmv.org/cgi-bin/viewvc.cgi/archwg/trunk/chat_server.py?view=log</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=AW_Groupies&diff=35824AW Groupies2007-10-16T02:04:16Z<p>Gareth Ellison: /* Communications */</p>
<hr />
<div>=Purpose=<br />
Serious technical discussion about the next generation architecture working group that Linden Labs is sponsoring. See:<br />
<br />
[[Architecture Working Group]]<br />
<br />
Invite only (apply in-world to [[User:Zha Ewry|Zha Ewry]]), but the criterion is simple. Show up and contribute to the AWG, at Zero Linden's office hours, or on the Wiki, or on SL-Dev.<br />
<br />
=Activities=<br />
Currently, we seem to be meeting once or twice a week in-world, and the group IM chat has been quite lively.<br />
<br />
Also members are quite active on the wiki and in the SLDEV mailing list.<br />
<br />
A public SVN repository is open to all AW Groupies members here: <br />
* http://openmv.org/cgi-bin/viewvc.cgi/archwg/<br />
<br />
Contact anyone with root on openmv.org for an account if you are in the AW Groupies group in-world.<br />
<br />
==In-World Meetings==<br />
<br />
Meetings are scheduled via the "[http://www.google.com/calendar/embed?src=pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com SL AW Groupies" google calendar]"<br />
<br />
* [http://www.google.com/calendar/feeds/pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com/public/basic XML]<br />
* [http://www.google.com/calendar/ical/pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com/public/basic.ics ICal]<br />
* Calendar ID: pdd5mpktklo89bgmfgi076mcc4@group.calendar.google.com<br />
* [http://www.google.com/calendar/render?cid=pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com Add to your Google Calendar]<br />
<br />
===Meeting Agendas===<br />
<br />
Each meeting should have an agenda --- which will be distributed via<br />
* google calendar entry<br />
* in-world notice to the SL "AW Groupies" group<br />
* the [[AW Groupies In-World Meeting Agenda]] wiki page<br />
<br />
<br />
===Chat Logs===<br />
<br />
Chat logs of the in-world meetings are published and accessible via the links below:<br />
<br />
* 2007 meetings<br />
:* September: [[sept_28_2007_AWGroupies | 28]]<br />
:* October: [[oct_1_2007_AWGroupies | 1]] [[ oct5_scale_rest | 5]] [[User:Zero_Linden/Office_Hours/2007_Oct_09|9 --Zero's office]]<br />
<br />
(if you post chat logs, you might want to use the [[User:Dr_Scofield/logtransform|sllog2wiki perl script]] to turn them into a more readable wiki table format ready to copy & paste into the chat log page)<br />
<br />
Chat logs of AWGroupies meetings should be summarized on the wiki.<br />
<br />
=Work-In-Progress=<br />
<br />
Work-in-progress wiki pages are architecture pages that are (as the name implies ;-)) work in progress. Once the group has reached consensus that a particular topic is "good-to-go" we'll graduate that page to the [[Architecture Working Group|main AWG page]].<br />
<br />
==General Concerns==<br />
* [[Scoping]]<br />
* [[Architecture Working Group Glossary|Glossary]]<br />
* [[Use Cases]]<br />
==Communications==<br />
* [[Initial CAPS seed]]<br />
* [[AWG initial flows]]<br />
* [[AWG flows login]]<br />
* [[Mudata]]<br />
* [[Streamlet]]<br />
<br />
==Asset Security==<br />
* [[Protecting content in an open grid]]<br />
==Scaling Issues==<br />
* [[Brainstorming#ANALYSIS:_Region_Subdivision_as_a_scaling_method| Region Subdivision]]<br />
* [[Brainstorming#ANALYSIS:_Scalability_through_reverse_proxies:_the_paravirtual_grid| Reverse Proxies]]<br />
==Other==<br />
* [[Use_Cases#Extended_Capability_Clients|Extended Capability Clients]]<br />
<br />
=Thinking-in-Progress=<br />
<br />
Have a look and contribute to the [[Brainstorming|brainstorming]] page.<br />
<br />
=External Links=<br />
<br />
Stuff of interest to or in connection with the [[AW Groupies]] or the [[Architecture Working Group]]:<br />
<br />
* [http://www-03.ibm.com/press/us/en/pressrelease/22428.wss IBM PR re: AWG]<br />
<br />
=Members=<br />
<br />
Founder [[User: Zha Ewry|Zha Ewry]]<br />
<br />
[[User:Saijanai Kuhn|Saijanai Kuhn]]<br />
<br />
[[User:Tao Takashi|Tao Takashi]]<br />
<br />
[[User:Tillie Ariantho|Tillie Ariantho]]<br />
<br />
[[User:Dr Scofield|Dr Scofield]]<br />
<br />
[[User:Burhop Piccard|Burhop Piccard]]<br />
<br />
[[Category:Architecture Working Group]]</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=Mudata&diff=35689Mudata2007-10-15T07:48:35Z<p>Gareth Ellison: New page: == Mudata == Mudata is an extension on top of Mulib which enables a REST-based interface to a MySQL interface.</p>
<hr />
<div>== Mudata ==<br />
<br />
Mudata is an extension on top of [[Mulib]] which enables a REST-based interface to a MySQL interface.</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=AW_Groupies&diff=35688AW Groupies2007-10-15T07:48:04Z<p>Gareth Ellison: /* Communications */</p>
<hr />
<div>=Purpose=<br />
Serious technical discussion about the next generation architecture working group that Linden Labs is sponsoring. See:<br />
<br />
[[Architecture Working Group]]<br />
<br />
Invite only (apply in-world to [[User:Zha Ewry|Zha Ewry]]), but the criterion is simple. Show up and contribute to the AWG, at Zero Linden's office hours, or on the Wiki, or on SL-Dev.<br />
<br />
=Activities=<br />
Currently, we seem to be meeting once or twice a week in-world, and the group IM chat has been quite lively.<br />
<br />
Also members are quite active on the wiki and in the SLDEV mailing list.<br />
<br />
A public SVN repository is open to all AW Groupies members here: <br />
* http://openmv.org/cgi-bin/viewvc.cgi/archwg/<br />
<br />
Contact anyone with root on openmv.org for an account if you are in the AW Groupies group in-world.<br />
<br />
==In-World Meetings==<br />
<br />
Meetings are scheduled via the "[http://www.google.com/calendar/embed?src=pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com SL AW Groupies" google calendar]"<br />
<br />
* [http://www.google.com/calendar/feeds/pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com/public/basic XML]<br />
* [http://www.google.com/calendar/ical/pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com/public/basic.ics ICal]<br />
* Calendar ID: pdd5mpktklo89bgmfgi076mcc4@group.calendar.google.com<br />
* [http://www.google.com/calendar/render?cid=pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com Add to your Google Calendar]<br />
<br />
===Meeting Agendas===<br />
<br />
Each meeting should have an agenda --- which will be distributed via<br />
* google calendar entry<br />
* in-world notice to the SL "AW Groupies" group<br />
* the [[AW Groupies In-World Meeting Agenda]] wiki page<br />
<br />
<br />
===Chat Logs===<br />
<br />
Chat logs of the in-world meetings are published and accessible via the links below:<br />
<br />
* 2007 meetings<br />
:* September: [[sept_28_2007_AWGroupies | 28]]<br />
:* October: [[oct_1_2007_AWGroupies | 1]] [[ oct5_scale_rest | 5]] [[User:Zero_Linden/Office_Hours/2007_Oct_09|9 --Zero's office]]<br />
<br />
(if you post chat logs, you might want to use the [[User:Dr_Scofield/logtransform|sllog2wiki perl script]] to turn them into a more readable wiki table format ready to copy & paste into the chat log page)<br />
<br />
Chat logs of AWGroupies meetings should be summarized on the wiki.<br />
<br />
=Work-In-Progress=<br />
<br />
Work-in-progress wiki pages are architecture pages that are (as the name implies ;-)) work in progress. Once the group has reached consensus that a particular topic is "good-to-go" we'll graduate that page to the [[Architecture Working Group|main AWG page]].<br />
<br />
==General Concerns==<br />
* [[Scoping]]<br />
* [[Architecture Working Group Glossary|Glossary]]<br />
* [[Use Cases]]<br />
==Communications==<br />
* [[Initial CAPS seed]]<br />
* [[AWG initial flows]]<br />
* [[AWG flows login]]<br />
* [[Mudata]]<br />
<br />
==Asset Security==<br />
* [[Protecting content in an open grid]]<br />
==Scaling Issues==<br />
* [[Brainstorming#ANALYSIS:_Region_Subdivision_as_a_scaling_method| Region Subdivision]]<br />
* [[Brainstorming#ANALYSIS:_Scalability_through_reverse_proxies:_the_paravirtual_grid| Reverse Proxies]]<br />
==Other==<br />
* [[Use_Cases#Extended_Capability_Clients|Extended Capability Clients]]<br />
<br />
=Thinking-in-Progress=<br />
<br />
Have a look and contribute to the [[Brainstorming|brainstorming]] page.<br />
<br />
=External Links=<br />
<br />
Stuff of interest to or in connection with the [[AW Groupies]] or the [[Architecture Working Group]]:<br />
<br />
* [http://www-03.ibm.com/press/us/en/pressrelease/22428.wss IBM PR re: AWG]<br />
<br />
=Members=<br />
<br />
Founder [[User: Zha Ewry|Zha Ewry]]<br />
<br />
[[User:Saijanai Kuhn|Saijanai Kuhn]]<br />
<br />
[[User:Tao Takashi|Tao Takashi]]<br />
<br />
[[User:Tillie Ariantho|Tillie Ariantho]]<br />
<br />
[[User:Dr Scofield|Dr Scofield]]<br />
<br />
[[User:Burhop Piccard|Burhop Piccard]]<br />
<br />
[[Category:Architecture Working Group]]</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=AW_Groupies&diff=35657AW Groupies2007-10-15T02:20:30Z<p>Gareth Ellison: </p>
<hr />
<div>=Purpose=<br />
Serious technical discussion about the next generation architecture working group that Linden Labs is sponsoring. See:<br />
<br />
[[Architecture Working Group]]<br />
<br />
Invite only (apply in-world to [[User:Zha Ewry|Zha Ewry]]), but the criterion is simple. Show up and contribute to the AWG, at Zero Linden's office hours, or on the Wiki, or on SL-Dev.<br />
<br />
=Activities=<br />
Currently, we seem to be meeting once or twice a week in-world, and the group IM chat has been quite lively.<br />
<br />
Also members are quite active on the wiki and in the SLDEV mailing list.<br />
<br />
A public SVN repository is open to all AW Groupies members here: <br />
* http://openmv.org/cgi-bin/viewvc.cgi/archwg/<br />
<br />
Contact anyone with root on openmv.org for an account if you are in the AW Groupies group in-world.<br />
<br />
==In-World Meetings==<br />
<br />
Meetings are scheduled via the "[http://www.google.com/calendar/embed?src=pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com SL AW Groupies" google calendar]"<br />
<br />
* [http://www.google.com/calendar/feeds/pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com/public/basic XML]<br />
* [http://www.google.com/calendar/ical/pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com/public/basic.ics ICal]<br />
* Calendar ID: pdd5mpktklo89bgmfgi076mcc4@group.calendar.google.com<br />
* [http://www.google.com/calendar/render?cid=pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com Add to your Google Calendar]<br />
<br />
===Meeting Agendas===<br />
<br />
Each meeting should have an agenda --- which will be distributed via<br />
* google calendar entry<br />
* in-world notice to the SL "AW Groupies" group<br />
* the [[AW Groupies In-World Meeting Agenda]] wiki page<br />
<br />
<br />
===Chat Logs===<br />
<br />
Chat logs of the in-world meetings are published and accessible via the links below:<br />
<br />
* 2007 meetings<br />
:* September: [[sept_28_2007_AWGroupies | 28]]<br />
:* October: [[oct_1_2007_AWGroupies | 1]] [[ oct5_scale_rest | 5]] [[User:Zero_Linden/Office_Hours/2007_Oct_09|9 --Zero's office]]<br />
<br />
(if you post chat logs, you might want to use the [[User:Dr_Scofield/logtransform|sllog2wiki perl script]] to turn them into a more readable wiki table format ready to copy & paste into the chat log page)<br />
<br />
Chat logs of AWGroupies meetings should be summarized on the wiki.<br />
<br />
=Work-In-Progress=<br />
<br />
Work-in-progress wiki pages are architecture pages that are (as the name implies ;-)) work in progress. Once the group has reached consensus that a particular topic is "good-to-go" we'll graduate that page to the [[Architecture Working Group|main AWG page]].<br />
<br />
==General Concerns==<br />
* [[Scoping]]<br />
* [[Architecture Working Group Glossary|Glossary]]<br />
* [[Use Cases]]<br />
==Communications==<br />
* [[Initial CAPS seed]]<br />
* [[AWG initial flows]]<br />
* [[AWG flows login]]<br />
==Asset Security==<br />
* [[Protecting content in an open grid]]<br />
==Scaling Issues==<br />
* [[Brainstorming#ANALYSIS:_Region_Subdivision_as_a_scaling_method| Region Subdivision]]<br />
* [[Brainstorming#ANALYSIS:_Scalability_through_reverse_proxies:_the_paravirtual_grid| Reverse Proxies]]<br />
==Other==<br />
* [[Use_Cases#Extended_Capability_Clients|Extended Capability Clients]]<br />
<br />
=Thinking-in-Progress=<br />
<br />
Have a look and contribute to the [[Brainstorming|brainstorming]] page.<br />
<br />
=External Links=<br />
<br />
Stuff of interest to or in connection with the [[AW Groupies]] or the [[Architecture Working Group]]:<br />
<br />
* [http://www-03.ibm.com/press/us/en/pressrelease/22428.wss IBM PR re: AWG]<br />
<br />
=Members=<br />
<br />
Founder [[User: Zha Ewry|Zha Ewry]]<br />
<br />
[[User:Saijanai Kuhn|Saijanai Kuhn]]<br />
<br />
[[User:Tao Takashi|Tao Takashi]]<br />
<br />
[[User:Tillie Ariantho|Tillie Ariantho]]<br />
<br />
[[User:Dr Scofield|Dr Scofield]]<br />
<br />
[[User:Burhop Piccard|Burhop Piccard]]<br />
<br />
[[Category:Architecture Working Group]]</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=Initial_CAPS_seed&diff=34662Initial CAPS seed2007-10-08T00:18:32Z<p>Gareth Ellison: </p>
<hr />
<div>At login, the current proposal from the AW Groupies group is for the client to be fed back an LLSD map:<br />
<br />
67153d5b-3659-afb4-8510-adda2c034649 is used here as a generic example UUID.<br />
<br />
<llsd><br />
<map><br />
<key>User</user><br />
<uri>http://profiles.isp.com/67153d5b-3659-afb4-8510-adda2c034649</uri><br />
<key>Agent</key><br />
<uri>http://sims.isp.com/My%20Home/agents/67153d5b-3659-afb4-8510-adda2c034649</uri><br />
<key>Session</key><br />
<uri>http://agenthost.isp.com/sessions/67153d5b-3659-afb4-8510-adda2c034649</uri><br />
<key>Inventory</key><br />
<uri>http://inventory.isp.com/67153d5b-3659-afb4-8510-adda2c034649</uri><br />
</map><br />
</llsd><br />
<br />
<br />
== Discussion on this ==<br />
<br />
* User profile links to what you'd think of as "a profile" (under search > people on the current system)<br />
* Agents are the user's presence on the system, could perhaps be allowed to have multiple agents<br />
* Agents and sessions are not the same thing - an agent is a unique singular instance, a session is a connected client controlling that instance (client moving avatar, or a simple IM-only textmode client, or a mobile phone even)<br />
* Agents<br />
* Please add more points....</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=Initial_CAPS_seed&diff=34661Initial CAPS seed2007-10-08T00:12:50Z<p>Gareth Ellison: </p>
<hr />
<div>At login, the current proposal from the AW Groupies group is for the client to be fed back an LLSD map:<br />
<br />
67153d5b-3659-afb4-8510-adda2c034649 is used here as a generic example UUID.<br />
<br />
<llsd><br />
<map><br />
<key>Agent</key><br />
<uri>http://agenthost.isp.com/agentprofiles/67153d5b-3659-afb4-8510-adda2c034649</uri><br />
<key>Session</key><br />
<uri>http://agenthost.isp.com/sessions/67153d5b-3659-afb4-8510-adda2c034649</uri><br />
<key>Inventory</key><br />
<uri>http://inventory.isp.com/aggreator/67153d5b-3659-afb4-8510-adda2c034649</uri><br />
</map><br />
</llsd></div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=Initial_CAPS_seed&diff=34658Initial CAPS seed2007-10-08T00:03:47Z<p>Gareth Ellison: New page: At login, the current proposal from the AW Groupies group is for the client to be fed back an LLSD map: <nowiki> <llsd> <map> </map> </llsd> </nowiki></p>
<hr />
<div>At login, the current proposal from the AW Groupies group is for the client to be fed back an LLSD map:<br />
<nowiki><br />
<llsd><br />
<map><br />
</map><br />
</llsd><br />
</nowiki></div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=Architecture_Working_Group&diff=34655Architecture Working Group2007-10-08T00:01:19Z<p>Gareth Ellison: /* Discussions */</p>
<hr />
<div>[[Image:slarch.jpg]]<br />
<br />
I have gathered my tools and my charts,<br />
My plans are finished and practical.<br />
I shall roll up my sleeves — make Second Life over. <br />
<br />
==Goal==<br />
<br />
Discuss, design and implement a scalable architecture for the future Second Life Grid.<br />
<br />
==Materials==<br />
<br />
* [[Project Motivation]]<br />
* [[Proposed Architecture|Architecture proposed by Linden Lab]]<br />
* [[Components and Roles]]<br />
* [[Use Cases]]<br />
* [[Brainstorming]]<br />
<br />
==Meetings==<br />
<br />
* Meeting 1<br />
** [[ArchWG_Mtg_1_Agenda|September 13th 2007, Meeting 1]] <br />
** [[Workitems for Meeting 1]]<br />
** [[2007-09-13 Arch WG Minutes]]<br />
* [[Chatlog from 2007/09/16]] (Gigs, otakup0pe and Tao_T talk about possible forms of regions etc.)<br />
* [http://taotakashi.wordpress.com/2007/09/24/second-life-grid-architecture-meetup-transcript/ Transcript and Slides from Tao Takashi's informal meetup on 2007/09/23]<br />
* [[In World Chatlogs]]<br />
* [[AW Groupies]]<br />
<br />
See also: [[User:Zero Linden|Zero Linden's office hour transcripts]]<br />
<br />
==Individual Reviews and Feedback==<br />
<br />
* [[ Zha's comments on meeting 1]]<br />
* [[AWG: Zha's Desiderata for evaluating the proposed design]]<br />
* [[ Tree's comments on meeting 1]]<br />
* [[Diva Canto's Review]]<br />
* [[Mic's Feedback]]<br />
* [[Views of the Gareth]]<br />
<br />
==Discussions==<br />
<br />
* [[DRM, IP and permissions]] (from the mailing list)<br />
* [[Initial CAPS seed]]<br />
<br />
<br />
<noinclude><br />
[[Category:Architecture Working Group]]</noinclude></div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=User:Gareth_Ellison/Views_of_the_Gareth&diff=34577User:Gareth Ellison/Views of the Gareth2007-10-07T08:22:56Z<p>Gareth Ellison: /* Viewer architecture */ Clarified VIEWS OF THE GARETH!</p>
<hr />
<div>=== Gareth Nelson's views on the new grid architecture ===<br />
<br />
As always I must let my views be known in a mildly eccentric manner. I shall do so upon this wiki.<br />
<br />
So, watch this space and the rest of the wiki articles for my views.......<br />
<br />
== General considerations ==<br />
<br />
* The network protocol needs to be headed towards something RFCish to really take off<br />
* There needs to be multiple implementations of every component of the whole system<br />
<br />
== Comments on central services ==<br />
<br />
The idea of central services under the control of LL makes sense on purely technical grounds (centralise search, domain lookup, L$ and identity management) but the social and legal issues need to be analysed further: Would LL still enforce the TOS as strictly for 3rd party sims that merely make use of these central services?<br />
<br />
== Viewer architecture ==<br />
<br />
Where all end users see it all: everything starts here.<br />
<br />
A few points as to how the viewer should function:<br />
* Cross-platform<br />
** The viewer needs to be accessible to as many platforms as possible, I am personally of the view that a minimal library of core protocol functions needs<br />
to be maintained as a seperate project to enable fast porting to new platforms<br />
* Lightweight<br />
** The viewer as it stands is to be blunt a bloated mess - I believe that the structure of the code could do with some improvement<br />
** On top of the code structure, the system requirements are too high<br />
* Graceful degradation of content<br />
** Tieing in with the previous point - the viewer is all or nothing: you have all the fancy new features or you have nothing currently. This needs to be replaced with something more graceful<br />
<br />
== Scaling up individual regions ==<br />
<br />
I distributed a notecard in-world with this:<br />
Let's say we have a standard 256x256 region. We want to fit 500 users into it.<br />
Opensim's average benchmarks scaled up have given a general estimate of 100 users per sim.<br />
This means that for 500 users we need 5 sims regardless of the geographical/spatial configuration.<br />
<br />
So, we have a 256x256 area of land to fit our 500 people into, using 5 sims.<br />
<br />
256x256=65536<br />
65536/5=13107<br />
<br />
13107m2 of land can hold 100 users with a single sim instance.<br />
Laying this out is more complex, but I would suggest partitioning it with simple equal divisions, cutting up any non-regular region borders into regular geometric shapes to make this easier. A standard BSP algorithm will do for the more complex region border shapes. For a basic 65536m2 square-shaped border this works:<br />
<br />
N<br />
1111<br />
2222<br />
W 3333 E<br />
4444<br />
5555<br />
S<br />
<br />
(Excuse the crap ASCII art)<br />
<br />
Now, if an avatar starts in our region at the north in sim 1 and walks south, they will have to cross 4 borders. Presuming that the actual crossing is just another UDP packet like the standard AgentUpdate the overhead in these crossings will be updating each sim's internal data structures.<br />
<br />
In real terms this involves the old sim downgrading the agent's thread to a child agent and the new one upgrading the child agent to a full agent and setting co-ordinates. Other overhead related to moving the avatar around is ignored as irrelevant (it exists regardless of whether you walk around inside one sim or across into another).<br />
<br />
So, the client has to wait 4 times for the following operations:<br />
1.Boolean flag flip on old sim to downgrade<br />
2.Extra "this avatar has moved sim" packets to other clients<br />
3.Boolean flag flip on new sim to upgrade<br />
4.Extra "this avatar just arrived in local sim" packets to other clients on new sim.<br />
<br />
Without having profiling figures to hand - the only real bottleneck here is informing other clients. However, one must also note that this becomes essentially the same overhead as AgentUpdates anyway.<br />
<br />
An avatar is either moving locally or moving sim<>sim but never both at the same time, and each state requires 1 packet to move it.<br />
<br />
What this means ultimately is that the overhead of sim crossings turns out to be nothing but a simple bit flip operation on a properly designed sim. 1 instruction on modern CPUs!<br />
<br />
Contrast this with how much network overhead would result from distributed physics and the complex interactions between different objects simulated on different network hosts.</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=User:Gareth_Ellison/Views_of_the_Gareth&diff=34576User:Gareth Ellison/Views of the Gareth2007-10-07T08:19:01Z<p>Gareth Ellison: </p>
<hr />
<div>=== Gareth Nelson's views on the new grid architecture ===<br />
<br />
As always I must let my views be known in a mildly eccentric manner. I shall do so upon this wiki.<br />
<br />
So, watch this space and the rest of the wiki articles for my views.......<br />
<br />
== General considerations ==<br />
<br />
* The network protocol needs to be headed towards something RFCish to really take off<br />
* There needs to be multiple implementations of every component of the whole system<br />
<br />
== Comments on central services ==<br />
<br />
The idea of central services under the control of LL makes sense on purely technical grounds (centralise search, domain lookup, L$ and identity management) but the social and legal issues need to be analysed further: Would LL still enforce the TOS as strictly for 3rd party sims that merely make use of these central services?<br />
<br />
== Viewer architecture ==<br />
<br />
Where all end users see it all: everything starts here.<br />
<br />
A few points as to how the viewer should function:<br />
* Cross-platform<br />
** The viewer needs to be accessible to as many platforms as possible, I am personally of the view that a minimal library of core protocol functions needs<br />
to be maintained as a seperate project to enable fast porting to new platforms<br />
* Lightweight<br />
** The viewer as it stands is to be blunt a bloated mess - I believe that the structure of the code could do with some improvement<br />
** On top of the code structure, the system requirements are too high<br />
* Graceful degradation of content<br />
** Tieing in with the previous point - the viewer is all or nothing: you have all the fancy new features or you have nothing<br />
<br />
== Scaling up individual regions ==<br />
<br />
I distributed a notecard in-world with this:<br />
Let's say we have a standard 256x256 region. We want to fit 500 users into it.<br />
Opensim's average benchmarks scaled up have given a general estimate of 100 users per sim.<br />
This means that for 500 users we need 5 sims regardless of the geographical/spatial configuration.<br />
<br />
So, we have a 256x256 area of land to fit our 500 people into, using 5 sims.<br />
<br />
256x256=65536<br />
65536/5=13107<br />
<br />
13107m2 of land can hold 100 users with a single sim instance.<br />
Laying this out is more complex, but I would suggest partitioning it with simple equal divisions, cutting up any non-regular region borders into regular geometric shapes to make this easier. A standard BSP algorithm will do for the more complex region border shapes. For a basic 65536m2 square-shaped border this works:<br />
<br />
N<br />
1111<br />
2222<br />
W 3333 E<br />
4444<br />
5555<br />
S<br />
<br />
(Excuse the crap ASCII art)<br />
<br />
Now, if an avatar starts in our region at the north in sim 1 and walks south, they will have to cross 4 borders. Presuming that the actual crossing is just another UDP packet like the standard AgentUpdate the overhead in these crossings will be updating each sim's internal data structures.<br />
<br />
In real terms this involves the old sim downgrading the agent's thread to a child agent and the new one upgrading the child agent to a full agent and setting co-ordinates. Other overhead related to moving the avatar around is ignored as irrelevant (it exists regardless of whether you walk around inside one sim or across into another).<br />
<br />
So, the client has to wait 4 times for the following operations:<br />
1.Boolean flag flip on old sim to downgrade<br />
2.Extra "this avatar has moved sim" packets to other clients<br />
3.Boolean flag flip on new sim to upgrade<br />
4.Extra "this avatar just arrived in local sim" packets to other clients on new sim.<br />
<br />
Without having profiling figures to hand - the only real bottleneck here is informing other clients. However, one must also note that this becomes essentially the same overhead as AgentUpdates anyway.<br />
<br />
An avatar is either moving locally or moving sim<>sim but never both at the same time, and each state requires 1 packet to move it.<br />
<br />
What this means ultimately is that the overhead of sim crossings turns out to be nothing but a simple bit flip operation on a properly designed sim. 1 instruction on modern CPUs!<br />
<br />
Contrast this with how much network overhead would result from distributed physics and the complex interactions between different objects simulated on different network hosts.</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=User:Gareth_Ellison/Views_of_the_Gareth&diff=33068User:Gareth Ellison/Views of the Gareth2007-09-27T03:14:27Z<p>Gareth Ellison: New page: === Gareth Nelson's views on the new grid architecture === As always I must let my views be known in a mildly eccentric manner. I shall do so upon this wiki. So, watch this space and the...</p>
<hr />
<div>=== Gareth Nelson's views on the new grid architecture ===<br />
<br />
As always I must let my views be known in a mildly eccentric manner. I shall do so upon this wiki.<br />
<br />
So, watch this space and the rest of the wiki articles for my views.......<br />
<br />
== General considerations ==<br />
<br />
* The network protocol needs to be headed towards something RFCish to really take off<br />
* There needs to be multiple implementations of every component of the whole system<br />
<br />
== Comments on central services ==<br />
<br />
The idea of central services under the control of LL makes sense on purely technical grounds (centralise search, domain lookup, L$ and identity management) but the social and legal issues need to be analysed further: Would LL still enforce the TOS as strictly for 3rd party sims that merely make use of these central services?<br />
<br />
== Viewer architecture ==<br />
<br />
Where all end users see it all: everything starts here.<br />
<br />
A few points as to how the viewer should function:<br />
* Cross-platform<br />
** The viewer needs to be accessible to as many platforms as possible, I am personally of the view that a minimal library of core protocol functions needs<br />
to be maintained as a seperate project to enable fast porting to new platforms<br />
* Lightweight<br />
** The viewer as it stands is to be blunt a bloated mess - I believe that the structure of the code could do with some improvement<br />
** On top of the code structure, the system requirements are too high<br />
* Graceful degradation of content<br />
** Tieing in with the previous point - the viewer is all or nothing: you have all the fancy new features or you have nothing</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=Architecture_Working_Group&diff=33066Architecture Working Group2007-09-27T03:03:59Z<p>Gareth Ellison: /* Individual Reviews and Feedback */</p>
<hr />
<div>[[Image:slarch.jpg]]<br />
<br />
==Goal==<br />
<br />
Discuss and implement the architecture of the future Second Life Grid.<br />
<br />
==Materials==<br />
<br />
[[Project Motivation]]<br />
<br />
[[Proposed Architecture|Architecture proposed by Linden Lab]]<br />
<br />
[[Components and Roles]]<br />
<br />
[[Use Cases]]<br />
<br />
[[Brainstorming]]<br />
<br />
[[AWG: Zha's Desiderata for evaluating the proposed design]]<br />
<br />
==Meetings==<br />
<br />
[[ArchWG_Mtg_1_Agenda|September 13th 2007, Meeting 1]] <br />
<br />
[[Workitems for Meeting 1]]<br />
<br />
[[ Zha's comments on meeting 1]]<br />
<br />
[[ Tree's comments on meeting 1]]<br />
<br />
[http://taotakashi.wordpress.com/2007/09/24/second-life-grid-architecture-meetup-transcript/ Transcript and Slides from Tao Takashi's informal meetup on 2007/09/23]<br />
<br />
==Individual Reviews and Feedback==<br />
<br />
[[Diva Canto's Review]]<br />
<br />
[[Mic's Feedback]]<br />
<br />
[[Views of the Gareth]]<br />
<br />
==Discussions==<br />
<br />
[[DRM, IP and permissions]] (from the mailing list)<br />
<br />
==IRC Chat Logs==<br />
<br />
* [[2007-09-13 Arch WG Minutes]]<br />
* [[Chatlog from 2007/09/16]] (Gigs, otakup0pe and Tao_T talk about possible forms of regions etc.)<br />
<br />
<br />
<noinclude><br />
[[Category:Architecture Working Group]]</noinclude></div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=Region_feature_requirements&diff=32613Region feature requirements2007-09-25T01:42:56Z<p>Gareth Ellison: </p>
<hr />
<div>(Off the top of my head) Here are some features which individual sims may or may not support. We should decide on which features a compliant sim MUST support, and which it MAY support.<br />
<br />
* Physics<br />
** Pluggable? (think OpenSim's physics modules ;) )<br />
* Portals<br />
* Building<br />
* Crossings (from other arbitrary sims)<br />
** Seperate TP and neighbours or not?<br />
* Estate management<br />
* Money (Lindens, private currency?)<br />
* Chat<br />
* Voice<br />
* Instant Messaging, Intra-Sim<br />
* Instant Messaging, Inter-Sim<br />
* Various avatar attributes, such as prim attachments<br />
* Scripting (LSL, mono?, etc)<br />
* Asset relay (local serving of textures, etc vs pointing elsewhere)<br />
** Sim offers a list of asset servers via CAPS and includes itself in the list<br />
*** If viewer tries to download asset from sim and it is not present, sim relays to another server (caching?)<br />
* Access restriction<br />
** Need standard ruleset specification for this<br />
* Centralized logging (dwell, performance)<br />
** Is this an absolute requirement on a distributed grid where sims may reside out of LL?<br />
<br />
Please add your own ideas, and feel free to rearrange this list.</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=Brainstorming&diff=32394Brainstorming2007-09-23T01:33:31Z<p>Gareth Ellison: /* General architecture */</p>
<hr />
<div>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.<br />
<br />
<br />
== Usage examples and requirements ==<br />
<br />
=== General architecture ===<br />
* allow to run a small grid on my laptop<br />
* allow plug-ins<br />
* 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.<br />
* 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.<br />
** 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<br />
<br />
=== Interoperability ===<br />
* 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.<br />
* 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.<br />
* look at things like Multiverse or Metaplace to see how these can be interconnected.<br />
* 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.<br />
<br />
===Commerce===<br />
<br />
=== Objects and Assets ===<br />
* allow objects to only be allowed to be rezzed on certain regions (adds to the agent's restrictions)<br />
* AND/OR limit object rezzing to specific groups of objects (give region owner ability to control what content is allowed in their regions)<br />
* allow assets to be transferred between agent domains<br />
* allow assets to be accessed from multiple agent domains<br />
* allow truly distributed asset storage<br />
* 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.<br />
* allow licenses to be attached to objects such as CC licenses etc. Could be some license field in the protocol.<br />
<br />
==== Permissions ====<br />
* 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.<br />
* 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.<br />
* 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<br />
* Agent buys object which is full perm but it should not be allowed to sell multiple copies of it, only the one you bought.<br />
* Agent rezzes multiple copies and eventually modifies them<br />
* Agent give the object to another agent (or sells it). When he does this all the copies should be deleted.<br />
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.<br />
* 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. <br />
* 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.<br />
<br />
=== Identity ===<br />
* identity should be pluggable<br />
** [Please build a list of desired identity verification systems]<br />
** OpenID<br />
* various grades of verification should be possible<br />
** Identity Verification:<br />
*** "Is the user exactly who he/she claims he/she is?"<br />
*** Very strong verification. Permanently links ID of account to real-world ID of user.<br />
** Age Verification:<br />
*** "Is the user old enough to be on this system?"<br />
*** Weak verification. Minimum amount needed to maintain compliance with child online access laws.<br />
** Unique Verification:<br />
*** "Is this user unique, or is it an Alt?"<br />
*** Weak verification. Minimum needed to enforce bans due to TOS violations.<br />
*** Very difficult to enforce due to ease of changing commonly-used identifiers: IP address, MAC address, hardware serial numbers/profiles, etc.<br />
* Verification must not require sensitive data to pass through insecure systems or require storage of sensitive data.<br />
* It should be possible to attach an unlimited amount of agent from different domains to one identity<br />
<br />
=== Viewer ===<br />
* allow all sorts of viewers, from 3D to cellphone to web sites<br />
** Create a viewer with the absolute minimum functionality possible (i.e. core client functions) and then make it optionally extensible based on client capability.<br />
*** Put core protocol functionality (login/logout, movement etc) into a library<br />
*** Make the server only send client data it has asked for (client sends "i want prims" message and get prims etc)<br />
*** Should be trivial to integrate with other systems if this is done correctly - IRC gateways for IMs for example<br />
** Allow the client to reassign controls and common functions to a Human Interface Device (gamepad, joystick, customized keyboard, a Bluetooth-connected Wii Remote, etc.)<br />
* Client-side Script runtime<br />
** 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<br />
** scriptable chat & movements avatar (bot)<br />
** advanced graphical hud<br />
*** 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<br />
<br />
=== Agents ===<br />
* 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<br />
* 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<br />
* an agent domain should be able to have certain inventory pools which might be shared among agents (like the library in SL today)<br />
* it should be possible to import and export friends lists or groups of friends<br />
* it should be possible to maintain a friends list among various agent domains (related to import/export maybe but as protocol function)<br />
* it should be possible to copy inventory from one agent domain from another if the object structure is compatible.<br />
* an agent needs to provide various methods of verification<br />
* an agent domain needs to define presence information among an agent's friends list. This should even be possible among various agent domains. <br />
* 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.)<br />
<br />
==== possible restrictions between regions and agents ====<br />
<br />
* An agent domain should be able to define on which regions an agent is allowed to connect<br />
* 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).<br />
* A region might allow only certain agent domains to connect<br />
* 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.<br />
* Standard specification of rights/permissions in a serialisable form that can be edited by the viewer and uploaded to an authorative per-domain server?<br />
<br />
=== Regions ===<br />
* allow regions of arbitrary size and form<br />
* allow portals and landmass-style connections between regions or a mix of both<br />
* region should be able to decide which agents to let in depending on the grade of verification (age, RL identity, financial, ... )<br />
* User defined topology. Like bookmarks, but in 2D. Crossing a custom boundary would result in a "walking teleport"<br />
* Multiple instances of a region within a topology. Everyone can have a front row seat for the show.<br />
* 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.<br />
<br />
== Implementation thoughts ==<br />
=== Viewer ===<br />
* 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?<br />
** 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<br />
** Any new assets, or locally modified assets can be re-uploaded<br />
** "Can download" must imply "Can modify" for practical reasons (DRM will not work!)<br />
<br />
=== Regions ===<br />
* 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?<br />
* Can we see into neighboring regions using a low LOD mesh dynamically created to represent the land and objects in a region?<br />
* 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.<br />
* Allow arbitrary assignment of geography to processing resources - including dynamic migration.<br />
** 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). <br />
*** 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.<br />
*** 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).<br />
*** 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.<br />
*** 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)<br />
<br />
=== Currency ===<br />
* how will virtual currency be handled in a distributed grid architecture?<br />
** 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 ?)<br />
** L$ exists as "a limited license right" within Second Life and therefore only makes sense within the official grid(s) owned by LL.<br />
*** Privately-owned grids could be responsible for issuing their own licenses, to throttle their clients' use of those private resources.<br />
**** 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.<br />
**** Such disconnections may allow us to implement a fully localized grid for use on private intranets or on a standalone system.<br />
*** By their nature, private licenses would be mutually incompatible with the official "L$" licenses.<br />
**** 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<br />
*** 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.<br />
* allow for secure transactions other than in L$ via PayPal, credit cards, etc.<br />
* 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.<br />
* Replace currency with cryptographically signed documents with the electronic equivalent of an IOU?<br />
<br />
=== Assets ===<br />
<br />
* It is possible to implement asset storage in a completely distributed way<br />
** Assets need not be stored in fixed locations (such as in the 'home' grid of the creator, for example)<br />
** A completely Peer-to-Peer (P2P) storage protocol is possible<br />
** To be successful it would have to retain many of the properties of the current 'fixed' storage schemes<br />
*** 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<br />
*** 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.).<br />
*** Persistent: Some mechanism to control the lifetime of assets may be needed<br />
**** Given the pace of storage technology progress, it may be possible to just keep every asset ever created (ride the wave of progress)<br />
**** If limited asset lifetimes are needed, some kind of distributed garbage-collection algorithm could be employed<br />
**** 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'!)<br />
**** Will it be possible to delete assets/accounts someday?<br />
** 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.<br />
*** 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).<br />
* Assets should support being signed (and notarized)<br />
** Perhaps they should even allow arbitrary meta-data to be attached to them by their creators (or anyone with perms) and accessed via scripts<br />
* Assets should be raw data.<br />
** Asset type, permissions, creator, watermark, etc would be meta-data.<br />
** Any kind of meta-data could be added and used or ignored as needed.<br />
* 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?<br />
** Would an upload fee make sense for transferring objects to different grids?<br />
** If so, how would that fee be determined for a completed object?<br />
** Would some grids (or domains if you'd prefer) be able to reject items from other domains on a permission basis?<br />
<br />
[[Category:Architecture Working Group]]</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=Brainstorming&diff=32393Brainstorming2007-09-23T01:32:14Z<p>Gareth Ellison: /* Viewer */</p>
<hr />
<div>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.<br />
<br />
<br />
== Usage examples and requirements ==<br />
<br />
=== General architecture ===<br />
* allow to run a small grid on my laptop<br />
* allow plug-ins<br />
* 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.<br />
* 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.<br />
<br />
=== Interoperability ===<br />
* 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.<br />
* 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.<br />
* look at things like Multiverse or Metaplace to see how these can be interconnected.<br />
* 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.<br />
<br />
===Commerce===<br />
<br />
=== Objects and Assets ===<br />
* allow objects to only be allowed to be rezzed on certain regions (adds to the agent's restrictions)<br />
* AND/OR limit object rezzing to specific groups of objects (give region owner ability to control what content is allowed in their regions)<br />
* allow assets to be transferred between agent domains<br />
* allow assets to be accessed from multiple agent domains<br />
* allow truly distributed asset storage<br />
* 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.<br />
* allow licenses to be attached to objects such as CC licenses etc. Could be some license field in the protocol.<br />
<br />
==== Permissions ====<br />
* 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.<br />
* 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.<br />
* 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<br />
* Agent buys object which is full perm but it should not be allowed to sell multiple copies of it, only the one you bought.<br />
* Agent rezzes multiple copies and eventually modifies them<br />
* Agent give the object to another agent (or sells it). When he does this all the copies should be deleted.<br />
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.<br />
* 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. <br />
* 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.<br />
<br />
=== Identity ===<br />
* identity should be pluggable<br />
** [Please build a list of desired identity verification systems]<br />
** OpenID<br />
* various grades of verification should be possible<br />
** Identity Verification:<br />
*** "Is the user exactly who he/she claims he/she is?"<br />
*** Very strong verification. Permanently links ID of account to real-world ID of user.<br />
** Age Verification:<br />
*** "Is the user old enough to be on this system?"<br />
*** Weak verification. Minimum amount needed to maintain compliance with child online access laws.<br />
** Unique Verification:<br />
*** "Is this user unique, or is it an Alt?"<br />
*** Weak verification. Minimum needed to enforce bans due to TOS violations.<br />
*** Very difficult to enforce due to ease of changing commonly-used identifiers: IP address, MAC address, hardware serial numbers/profiles, etc.<br />
* Verification must not require sensitive data to pass through insecure systems or require storage of sensitive data.<br />
* It should be possible to attach an unlimited amount of agent from different domains to one identity<br />
<br />
=== Viewer ===<br />
* allow all sorts of viewers, from 3D to cellphone to web sites<br />
** Create a viewer with the absolute minimum functionality possible (i.e. core client functions) and then make it optionally extensible based on client capability.<br />
*** Put core protocol functionality (login/logout, movement etc) into a library<br />
*** Make the server only send client data it has asked for (client sends "i want prims" message and get prims etc)<br />
*** Should be trivial to integrate with other systems if this is done correctly - IRC gateways for IMs for example<br />
** Allow the client to reassign controls and common functions to a Human Interface Device (gamepad, joystick, customized keyboard, a Bluetooth-connected Wii Remote, etc.)<br />
* Client-side Script runtime<br />
** 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<br />
** scriptable chat & movements avatar (bot)<br />
** advanced graphical hud<br />
*** 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<br />
<br />
=== Agents ===<br />
* 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<br />
* 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<br />
* an agent domain should be able to have certain inventory pools which might be shared among agents (like the library in SL today)<br />
* it should be possible to import and export friends lists or groups of friends<br />
* it should be possible to maintain a friends list among various agent domains (related to import/export maybe but as protocol function)<br />
* it should be possible to copy inventory from one agent domain from another if the object structure is compatible.<br />
* an agent needs to provide various methods of verification<br />
* an agent domain needs to define presence information among an agent's friends list. This should even be possible among various agent domains. <br />
* 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.)<br />
<br />
==== possible restrictions between regions and agents ====<br />
<br />
* An agent domain should be able to define on which regions an agent is allowed to connect<br />
* 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).<br />
* A region might allow only certain agent domains to connect<br />
* 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.<br />
* Standard specification of rights/permissions in a serialisable form that can be edited by the viewer and uploaded to an authorative per-domain server?<br />
<br />
=== Regions ===<br />
* allow regions of arbitrary size and form<br />
* allow portals and landmass-style connections between regions or a mix of both<br />
* region should be able to decide which agents to let in depending on the grade of verification (age, RL identity, financial, ... )<br />
* User defined topology. Like bookmarks, but in 2D. Crossing a custom boundary would result in a "walking teleport"<br />
* Multiple instances of a region within a topology. Everyone can have a front row seat for the show.<br />
* 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.<br />
<br />
== Implementation thoughts ==<br />
=== Viewer ===<br />
* 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?<br />
** 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<br />
** Any new assets, or locally modified assets can be re-uploaded<br />
** "Can download" must imply "Can modify" for practical reasons (DRM will not work!)<br />
<br />
=== Regions ===<br />
* 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?<br />
* Can we see into neighboring regions using a low LOD mesh dynamically created to represent the land and objects in a region?<br />
* 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.<br />
* Allow arbitrary assignment of geography to processing resources - including dynamic migration.<br />
** 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). <br />
*** 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.<br />
*** 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).<br />
*** 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.<br />
*** 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)<br />
<br />
=== Currency ===<br />
* how will virtual currency be handled in a distributed grid architecture?<br />
** 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 ?)<br />
** L$ exists as "a limited license right" within Second Life and therefore only makes sense within the official grid(s) owned by LL.<br />
*** Privately-owned grids could be responsible for issuing their own licenses, to throttle their clients' use of those private resources.<br />
**** 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.<br />
**** Such disconnections may allow us to implement a fully localized grid for use on private intranets or on a standalone system.<br />
*** By their nature, private licenses would be mutually incompatible with the official "L$" licenses.<br />
**** 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<br />
*** 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.<br />
* allow for secure transactions other than in L$ via PayPal, credit cards, etc.<br />
* 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.<br />
* Replace currency with cryptographically signed documents with the electronic equivalent of an IOU?<br />
<br />
=== Assets ===<br />
<br />
* It is possible to implement asset storage in a completely distributed way<br />
** Assets need not be stored in fixed locations (such as in the 'home' grid of the creator, for example)<br />
** A completely Peer-to-Peer (P2P) storage protocol is possible<br />
** To be successful it would have to retain many of the properties of the current 'fixed' storage schemes<br />
*** 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<br />
*** 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.).<br />
*** Persistent: Some mechanism to control the lifetime of assets may be needed<br />
**** Given the pace of storage technology progress, it may be possible to just keep every asset ever created (ride the wave of progress)<br />
**** If limited asset lifetimes are needed, some kind of distributed garbage-collection algorithm could be employed<br />
**** 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'!)<br />
**** Will it be possible to delete assets/accounts someday?<br />
** 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.<br />
*** 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).<br />
* Assets should support being signed (and notarized)<br />
** Perhaps they should even allow arbitrary meta-data to be attached to them by their creators (or anyone with perms) and accessed via scripts<br />
* Assets should be raw data.<br />
** Asset type, permissions, creator, watermark, etc would be meta-data.<br />
** Any kind of meta-data could be added and used or ignored as needed.<br />
* 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?<br />
** Would an upload fee make sense for transferring objects to different grids?<br />
** If so, how would that fee be determined for a completed object?<br />
** Would some grids (or domains if you'd prefer) be able to reject items from other domains on a permission basis?<br />
<br />
[[Category:Architecture Working Group]]</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=Brainstorming&diff=32392Brainstorming2007-09-23T01:30:22Z<p>Gareth Ellison: /* Currency */</p>
<hr />
<div>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.<br />
<br />
<br />
== Usage examples and requirements ==<br />
<br />
=== General architecture ===<br />
* allow to run a small grid on my laptop<br />
* allow plug-ins<br />
* 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.<br />
* 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.<br />
<br />
=== Interoperability ===<br />
* 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.<br />
* 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.<br />
* look at things like Multiverse or Metaplace to see how these can be interconnected.<br />
* 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.<br />
<br />
===Commerce===<br />
<br />
=== Objects and Assets ===<br />
* allow objects to only be allowed to be rezzed on certain regions (adds to the agent's restrictions)<br />
* AND/OR limit object rezzing to specific groups of objects (give region owner ability to control what content is allowed in their regions)<br />
* allow assets to be transferred between agent domains<br />
* allow assets to be accessed from multiple agent domains<br />
* allow truly distributed asset storage<br />
* 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.<br />
* allow licenses to be attached to objects such as CC licenses etc. Could be some license field in the protocol.<br />
<br />
==== Permissions ====<br />
* 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.<br />
* 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.<br />
* 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<br />
* Agent buys object which is full perm but it should not be allowed to sell multiple copies of it, only the one you bought.<br />
* Agent rezzes multiple copies and eventually modifies them<br />
* Agent give the object to another agent (or sells it). When he does this all the copies should be deleted.<br />
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.<br />
* 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. <br />
* 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.<br />
<br />
=== Identity ===<br />
* identity should be pluggable<br />
** [Please build a list of desired identity verification systems]<br />
** OpenID<br />
* various grades of verification should be possible<br />
** Identity Verification:<br />
*** "Is the user exactly who he/she claims he/she is?"<br />
*** Very strong verification. Permanently links ID of account to real-world ID of user.<br />
** Age Verification:<br />
*** "Is the user old enough to be on this system?"<br />
*** Weak verification. Minimum amount needed to maintain compliance with child online access laws.<br />
** Unique Verification:<br />
*** "Is this user unique, or is it an Alt?"<br />
*** Weak verification. Minimum needed to enforce bans due to TOS violations.<br />
*** Very difficult to enforce due to ease of changing commonly-used identifiers: IP address, MAC address, hardware serial numbers/profiles, etc.<br />
* Verification must not require sensitive data to pass through insecure systems or require storage of sensitive data.<br />
* It should be possible to attach an unlimited amount of agent from different domains to one identity<br />
<br />
=== Viewer ===<br />
* allow all sorts of viewers, from 3D to cellphone to web sites<br />
** Create a viewer with the absolute minimum functionality possible (i.e. core client functions) and then make it optionally extensible based on client capability.<br />
*** Put core protocol functionality (login/logout, movement etc) into a library<br />
*** Make the server only send client data it has asked for (client sends "i want prims" message and get prims etc)<br />
*** Should be trivial to integrate with other systems if this is done correctly - IRC gateways for IMs for example<br />
** Allow the client to reassign controls and common functions to a Human Interface Device (gamepad, joystick, customized keyboard, a Bluetooth-connected Wii Remote, etc.)<br />
* Client-side Script runtime<br />
** 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<br />
** scriptable chat & movements avatar (bot)<br />
** advanced graphical hud<br />
*** 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<br />
<br />
=== Agents ===<br />
* 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<br />
* 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<br />
* an agent domain should be able to have certain inventory pools which might be shared among agents (like the library in SL today)<br />
* it should be possible to import and export friends lists or groups of friends<br />
* it should be possible to maintain a friends list among various agent domains (related to import/export maybe but as protocol function)<br />
* it should be possible to copy inventory from one agent domain from another if the object structure is compatible.<br />
* an agent needs to provide various methods of verification<br />
* an agent domain needs to define presence information among an agent's friends list. This should even be possible among various agent domains. <br />
* 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.)<br />
<br />
==== possible restrictions between regions and agents ====<br />
<br />
* An agent domain should be able to define on which regions an agent is allowed to connect<br />
* 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).<br />
* A region might allow only certain agent domains to connect<br />
* 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.<br />
* Standard specification of rights/permissions in a serialisable form that can be edited by the viewer and uploaded to an authorative per-domain server?<br />
<br />
=== Regions ===<br />
* allow regions of arbitrary size and form<br />
* allow portals and landmass-style connections between regions or a mix of both<br />
* region should be able to decide which agents to let in depending on the grade of verification (age, RL identity, financial, ... )<br />
* User defined topology. Like bookmarks, but in 2D. Crossing a custom boundary would result in a "walking teleport"<br />
* Multiple instances of a region within a topology. Everyone can have a front row seat for the show.<br />
* 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.<br />
<br />
== Implementation thoughts ==<br />
=== Viewer ===<br />
* 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?<br />
<br />
=== Regions ===<br />
* 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?<br />
* Can we see into neighboring regions using a low LOD mesh dynamically created to represent the land and objects in a region?<br />
* 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.<br />
* Allow arbitrary assignment of geography to processing resources - including dynamic migration.<br />
** 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). <br />
*** 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.<br />
*** 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).<br />
*** 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.<br />
*** 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)<br />
<br />
=== Currency ===<br />
* how will virtual currency be handled in a distributed grid architecture?<br />
** 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 ?)<br />
** L$ exists as "a limited license right" within Second Life and therefore only makes sense within the official grid(s) owned by LL.<br />
*** Privately-owned grids could be responsible for issuing their own licenses, to throttle their clients' use of those private resources.<br />
**** 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.<br />
**** Such disconnections may allow us to implement a fully localized grid for use on private intranets or on a standalone system.<br />
*** By their nature, private licenses would be mutually incompatible with the official "L$" licenses.<br />
**** 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<br />
*** 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.<br />
* allow for secure transactions other than in L$ via PayPal, credit cards, etc.<br />
* 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.<br />
* Replace currency with cryptographically signed documents with the electronic equivalent of an IOU?<br />
<br />
=== Assets ===<br />
<br />
* It is possible to implement asset storage in a completely distributed way<br />
** Assets need not be stored in fixed locations (such as in the 'home' grid of the creator, for example)<br />
** A completely Peer-to-Peer (P2P) storage protocol is possible<br />
** To be successful it would have to retain many of the properties of the current 'fixed' storage schemes<br />
*** 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<br />
*** 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.).<br />
*** Persistent: Some mechanism to control the lifetime of assets may be needed<br />
**** Given the pace of storage technology progress, it may be possible to just keep every asset ever created (ride the wave of progress)<br />
**** If limited asset lifetimes are needed, some kind of distributed garbage-collection algorithm could be employed<br />
**** 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'!)<br />
**** Will it be possible to delete assets/accounts someday?<br />
** 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.<br />
*** 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).<br />
* Assets should support being signed (and notarized)<br />
** Perhaps they should even allow arbitrary meta-data to be attached to them by their creators (or anyone with perms) and accessed via scripts<br />
* Assets should be raw data.<br />
** Asset type, permissions, creator, watermark, etc would be meta-data.<br />
** Any kind of meta-data could be added and used or ignored as needed.<br />
* 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?<br />
** Would an upload fee make sense for transferring objects to different grids?<br />
** If so, how would that fee be determined for a completed object?<br />
** Would some grids (or domains if you'd prefer) be able to reject items from other domains on a permission basis?<br />
<br />
[[Category:Architecture Working Group]]</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=Brainstorming&diff=32390Brainstorming2007-09-23T01:26:05Z<p>Gareth Ellison: /* possible restrictions between regions and agents */</p>
<hr />
<div>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.<br />
<br />
<br />
== Usage examples and requirements ==<br />
<br />
=== General architecture ===<br />
* allow to run a small grid on my laptop<br />
* allow plug-ins<br />
* 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.<br />
* 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.<br />
<br />
=== Interoperability ===<br />
* 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.<br />
* 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.<br />
* look at things like Multiverse or Metaplace to see how these can be interconnected.<br />
* 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.<br />
<br />
===Commerce===<br />
<br />
=== Objects and Assets ===<br />
* allow objects to only be allowed to be rezzed on certain regions (adds to the agent's restrictions)<br />
* AND/OR limit object rezzing to specific groups of objects (give region owner ability to control what content is allowed in their regions)<br />
* allow assets to be transferred between agent domains<br />
* allow assets to be accessed from multiple agent domains<br />
* allow truly distributed asset storage<br />
* 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.<br />
* allow licenses to be attached to objects such as CC licenses etc. Could be some license field in the protocol.<br />
<br />
==== Permissions ====<br />
* 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.<br />
* 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.<br />
* 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<br />
* Agent buys object which is full perm but it should not be allowed to sell multiple copies of it, only the one you bought.<br />
* Agent rezzes multiple copies and eventually modifies them<br />
* Agent give the object to another agent (or sells it). When he does this all the copies should be deleted.<br />
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.<br />
* 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. <br />
* 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.<br />
<br />
=== Identity ===<br />
* identity should be pluggable<br />
** [Please build a list of desired identity verification systems]<br />
** OpenID<br />
* various grades of verification should be possible<br />
** Identity Verification:<br />
*** "Is the user exactly who he/she claims he/she is?"<br />
*** Very strong verification. Permanently links ID of account to real-world ID of user.<br />
** Age Verification:<br />
*** "Is the user old enough to be on this system?"<br />
*** Weak verification. Minimum amount needed to maintain compliance with child online access laws.<br />
** Unique Verification:<br />
*** "Is this user unique, or is it an Alt?"<br />
*** Weak verification. Minimum needed to enforce bans due to TOS violations.<br />
*** Very difficult to enforce due to ease of changing commonly-used identifiers: IP address, MAC address, hardware serial numbers/profiles, etc.<br />
* Verification must not require sensitive data to pass through insecure systems or require storage of sensitive data.<br />
* It should be possible to attach an unlimited amount of agent from different domains to one identity<br />
<br />
=== Viewer ===<br />
* allow all sorts of viewers, from 3D to cellphone to web sites<br />
** Create a viewer with the absolute minimum functionality possible (i.e. core client functions) and then make it optionally extensible based on client capability.<br />
*** Put core protocol functionality (login/logout, movement etc) into a library<br />
*** Make the server only send client data it has asked for (client sends "i want prims" message and get prims etc)<br />
*** Should be trivial to integrate with other systems if this is done correctly - IRC gateways for IMs for example<br />
** Allow the client to reassign controls and common functions to a Human Interface Device (gamepad, joystick, customized keyboard, a Bluetooth-connected Wii Remote, etc.)<br />
* Client-side Script runtime<br />
** scriptable chat & movements avatar (bot)<br />
** advanced graphical hud<br />
*** 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<br />
<br />
=== Agents ===<br />
* 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<br />
* 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<br />
* an agent domain should be able to have certain inventory pools which might be shared among agents (like the library in SL today)<br />
* it should be possible to import and export friends lists or groups of friends<br />
* it should be possible to maintain a friends list among various agent domains (related to import/export maybe but as protocol function)<br />
* it should be possible to copy inventory from one agent domain from another if the object structure is compatible.<br />
* an agent needs to provide various methods of verification<br />
* an agent domain needs to define presence information among an agent's friends list. This should even be possible among various agent domains. <br />
* 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.)<br />
<br />
==== possible restrictions between regions and agents ====<br />
<br />
* An agent domain should be able to define on which regions an agent is allowed to connect<br />
* 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).<br />
* A region might allow only certain agent domains to connect<br />
* 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.<br />
* Standard specification of rights/permissions in a serialisable form that can be edited by the viewer and uploaded to an authorative per-domain server?<br />
<br />
=== Regions ===<br />
* allow regions of arbitrary size and form<br />
* allow portals and landmass-style connections between regions or a mix of both<br />
* region should be able to decide which agents to let in depending on the grade of verification (age, RL identity, financial, ... )<br />
* User defined topology. Like bookmarks, but in 2D. Crossing a custom boundary would result in a "walking teleport"<br />
* Multiple instances of a region within a topology. Everyone can have a front row seat for the show.<br />
* 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.<br />
<br />
== Implementation thoughts ==<br />
=== Viewer ===<br />
* 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?<br />
<br />
=== Regions ===<br />
* 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?<br />
* Can we see into neighboring regions using a low LOD mesh dynamically created to represent the land and objects in a region?<br />
* 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.<br />
* Allow arbitrary assignment of geography to processing resources - including dynamic migration.<br />
** 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). <br />
*** 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.<br />
*** 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).<br />
*** 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.<br />
*** 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)<br />
<br />
=== Currency ===<br />
* how will virtual currency be handled in a distributed grid architecture?<br />
** 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 ?)<br />
** L$ exists as "a limited license right" within Second Life and therefore only makes sense within the official grid(s) owned by LL.<br />
*** Privately-owned grids could be responsible for issuing their own licenses, to throttle their clients' use of those private resources.<br />
**** 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.<br />
**** Such disconnections may allow us to implement a fully localized grid for use on private intranets or on a standalone system.<br />
*** By their nature, private licenses would be mutually incompatible with the official "L$" licenses.<br />
*** 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.<br />
* allow for secure transactions other than in L$ via PayPal, credit cards, etc.<br />
* 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.<br />
<br />
=== Assets ===<br />
<br />
* It is possible to implement asset storage in a completely distributed way<br />
** Assets need not be stored in fixed locations (such as in the 'home' grid of the creator, for example)<br />
** A completely Peer-to-Peer (P2P) storage protocol is possible<br />
** To be successful it would have to retain many of the properties of the current 'fixed' storage schemes<br />
*** 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<br />
*** 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.).<br />
*** Persistent: Some mechanism to control the lifetime of assets may be needed<br />
**** Given the pace of storage technology progress, it may be possible to just keep every asset ever created (ride the wave of progress)<br />
**** If limited asset lifetimes are needed, some kind of distributed garbage-collection algorithm could be employed<br />
**** 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'!)<br />
**** Will it be possible to delete assets/accounts someday?<br />
** 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.<br />
*** 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).<br />
* Assets should support being signed (and notarized)<br />
** Perhaps they should even allow arbitrary meta-data to be attached to them by their creators (or anyone with perms) and accessed via scripts<br />
* Assets should be raw data.<br />
** Asset type, permissions, creator, watermark, etc would be meta-data.<br />
** Any kind of meta-data could be added and used or ignored as needed.<br />
* 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?<br />
** Would an upload fee make sense for transferring objects to different grids?<br />
** If so, how would that fee be determined for a completed object?<br />
** Would some grids (or domains if you'd prefer) be able to reject items from other domains on a permission basis?<br />
<br />
[[Category:Architecture Working Group]]</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=Brainstorming&diff=32391Brainstorming2007-09-23T01:23:40Z<p>Gareth Ellison: /* Viewer */</p>
<hr />
<div>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.<br />
<br />
<br />
== Usage examples and requirements ==<br />
<br />
=== General architecture ===<br />
* allow to run a small grid on my laptop<br />
* allow plug-ins<br />
* 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.<br />
* 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.<br />
<br />
=== Interoperability ===<br />
* 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.<br />
* 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.<br />
* look at things like Multiverse or Metaplace to see how these can be interconnected.<br />
* 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.<br />
<br />
===Commerce===<br />
<br />
=== Objects and Assets ===<br />
* allow objects to only be allowed to be rezzed on certain regions (adds to the agent's restrictions)<br />
* AND/OR limit object rezzing to specific groups of objects (give region owner ability to control what content is allowed in their regions)<br />
* allow assets to be transferred between agent domains<br />
* allow assets to be accessed from multiple agent domains<br />
* allow truly distributed asset storage<br />
* 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.<br />
* allow licenses to be attached to objects such as CC licenses etc. Could be some license field in the protocol.<br />
<br />
==== Permissions ====<br />
* 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.<br />
* 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.<br />
* 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<br />
* Agent buys object which is full perm but it should not be allowed to sell multiple copies of it, only the one you bought.<br />
* Agent rezzes multiple copies and eventually modifies them<br />
* Agent give the object to another agent (or sells it). When he does this all the copies should be deleted.<br />
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.<br />
* 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. <br />
* 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.<br />
<br />
=== Identity ===<br />
* identity should be pluggable<br />
** [Please build a list of desired identity verification systems]<br />
** OpenID<br />
* various grades of verification should be possible<br />
** Identity Verification:<br />
*** "Is the user exactly who he/she claims he/she is?"<br />
*** Very strong verification. Permanently links ID of account to real-world ID of user.<br />
** Age Verification:<br />
*** "Is the user old enough to be on this system?"<br />
*** Weak verification. Minimum amount needed to maintain compliance with child online access laws.<br />
** Unique Verification:<br />
*** "Is this user unique, or is it an Alt?"<br />
*** Weak verification. Minimum needed to enforce bans due to TOS violations.<br />
*** Very difficult to enforce due to ease of changing commonly-used identifiers: IP address, MAC address, hardware serial numbers/profiles, etc.<br />
* Verification must not require sensitive data to pass through insecure systems or require storage of sensitive data.<br />
* It should be possible to attach an unlimited amount of agent from different domains to one identity<br />
<br />
=== Viewer ===<br />
* allow all sorts of viewers, from 3D to cellphone to web sites<br />
** Create a viewer with the absolute minimum functionality possible (i.e. core client functions) and then make it optionally extensible based on client capability.<br />
*** Put core protocol functionality (login/logout, movement etc) into a library<br />
*** Make the server only send client data it has asked for (client sends "i want prims" message and get prims etc)<br />
*** Should be trivial to integrate with other systems if this is done correctly - IRC gateways for IMs for example<br />
** Allow the client to reassign controls and common functions to a Human Interface Device (gamepad, joystick, customized keyboard, a Bluetooth-connected Wii Remote, etc.)<br />
* Client-side Script runtime<br />
** 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<br />
** scriptable chat & movements avatar (bot)<br />
** advanced graphical hud<br />
*** 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<br />
<br />
=== Agents ===<br />
* 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<br />
* 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<br />
* an agent domain should be able to have certain inventory pools which might be shared among agents (like the library in SL today)<br />
* it should be possible to import and export friends lists or groups of friends<br />
* it should be possible to maintain a friends list among various agent domains (related to import/export maybe but as protocol function)<br />
* it should be possible to copy inventory from one agent domain from another if the object structure is compatible.<br />
* an agent needs to provide various methods of verification<br />
* an agent domain needs to define presence information among an agent's friends list. This should even be possible among various agent domains. <br />
* 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.)<br />
<br />
==== possible restrictions between regions and agents ====<br />
<br />
* An agent domain should be able to define on which regions an agent is allowed to connect<br />
* 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).<br />
* A region might allow only certain agent domains to connect<br />
* 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.<br />
* Standard specification of rights/permissions in a serialisable form that can be edited by the viewer and uploaded to an authorative per-domain server?<br />
<br />
=== Regions ===<br />
* allow regions of arbitrary size and form<br />
* allow portals and landmass-style connections between regions or a mix of both<br />
* region should be able to decide which agents to let in depending on the grade of verification (age, RL identity, financial, ... )<br />
* User defined topology. Like bookmarks, but in 2D. Crossing a custom boundary would result in a "walking teleport"<br />
* Multiple instances of a region within a topology. Everyone can have a front row seat for the show.<br />
* 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.<br />
<br />
== Implementation thoughts ==<br />
=== Viewer ===<br />
* 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?<br />
<br />
=== Regions ===<br />
* 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?<br />
* Can we see into neighboring regions using a low LOD mesh dynamically created to represent the land and objects in a region?<br />
* 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.<br />
* Allow arbitrary assignment of geography to processing resources - including dynamic migration.<br />
** 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). <br />
*** 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.<br />
*** 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).<br />
*** 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.<br />
*** 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)<br />
<br />
=== Currency ===<br />
* how will virtual currency be handled in a distributed grid architecture?<br />
** 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 ?)<br />
** L$ exists as "a limited license right" within Second Life and therefore only makes sense within the official grid(s) owned by LL.<br />
*** Privately-owned grids could be responsible for issuing their own licenses, to throttle their clients' use of those private resources.<br />
**** 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.<br />
**** Such disconnections may allow us to implement a fully localized grid for use on private intranets or on a standalone system.<br />
*** By their nature, private licenses would be mutually incompatible with the official "L$" licenses.<br />
*** 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.<br />
* allow for secure transactions other than in L$ via PayPal, credit cards, etc.<br />
* 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.<br />
<br />
=== Assets ===<br />
<br />
* It is possible to implement asset storage in a completely distributed way<br />
** Assets need not be stored in fixed locations (such as in the 'home' grid of the creator, for example)<br />
** A completely Peer-to-Peer (P2P) storage protocol is possible<br />
** To be successful it would have to retain many of the properties of the current 'fixed' storage schemes<br />
*** 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<br />
*** 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.).<br />
*** Persistent: Some mechanism to control the lifetime of assets may be needed<br />
**** Given the pace of storage technology progress, it may be possible to just keep every asset ever created (ride the wave of progress)<br />
**** If limited asset lifetimes are needed, some kind of distributed garbage-collection algorithm could be employed<br />
**** 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'!)<br />
**** Will it be possible to delete assets/accounts someday?<br />
** 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.<br />
*** 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).<br />
* Assets should support being signed (and notarized)<br />
** Perhaps they should even allow arbitrary meta-data to be attached to them by their creators (or anyone with perms) and accessed via scripts<br />
* Assets should be raw data.<br />
** Asset type, permissions, creator, watermark, etc would be meta-data.<br />
** Any kind of meta-data could be added and used or ignored as needed.<br />
* 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?<br />
** Would an upload fee make sense for transferring objects to different grids?<br />
** If so, how would that fee be determined for a completed object?<br />
** Would some grids (or domains if you'd prefer) be able to reject items from other domains on a permission basis?<br />
<br />
[[Category:Architecture Working Group]]</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=Brainstorming&diff=32389Brainstorming2007-09-23T01:19:25Z<p>Gareth Ellison: /* Viewer */</p>
<hr />
<div>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.<br />
<br />
<br />
== Usage examples and requirements ==<br />
<br />
=== General architecture ===<br />
* allow to run a small grid on my laptop<br />
* allow plug-ins<br />
* 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.<br />
* 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.<br />
<br />
=== Interoperability ===<br />
* 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.<br />
* 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.<br />
* look at things like Multiverse or Metaplace to see how these can be interconnected.<br />
* 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.<br />
<br />
===Commerce===<br />
<br />
=== Objects and Assets ===<br />
* allow objects to only be allowed to be rezzed on certain regions (adds to the agent's restrictions)<br />
* AND/OR limit object rezzing to specific groups of objects (give region owner ability to control what content is allowed in their regions)<br />
* allow assets to be transferred between agent domains<br />
* allow assets to be accessed from multiple agent domains<br />
* allow truly distributed asset storage<br />
* 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.<br />
* allow licenses to be attached to objects such as CC licenses etc. Could be some license field in the protocol.<br />
<br />
==== Permissions ====<br />
* 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.<br />
* 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.<br />
* 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<br />
* Agent buys object which is full perm but it should not be allowed to sell multiple copies of it, only the one you bought.<br />
* Agent rezzes multiple copies and eventually modifies them<br />
* Agent give the object to another agent (or sells it). When he does this all the copies should be deleted.<br />
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.<br />
* 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. <br />
* 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.<br />
<br />
=== Identity ===<br />
* identity should be pluggable<br />
** [Please build a list of desired identity verification systems]<br />
** OpenID<br />
* various grades of verification should be possible<br />
** Identity Verification:<br />
*** "Is the user exactly who he/she claims he/she is?"<br />
*** Very strong verification. Permanently links ID of account to real-world ID of user.<br />
** Age Verification:<br />
*** "Is the user old enough to be on this system?"<br />
*** Weak verification. Minimum amount needed to maintain compliance with child online access laws.<br />
** Unique Verification:<br />
*** "Is this user unique, or is it an Alt?"<br />
*** Weak verification. Minimum needed to enforce bans due to TOS violations.<br />
*** Very difficult to enforce due to ease of changing commonly-used identifiers: IP address, MAC address, hardware serial numbers/profiles, etc.<br />
* Verification must not require sensitive data to pass through insecure systems or require storage of sensitive data.<br />
* It should be possible to attach an unlimited amount of agent from different domains to one identity<br />
<br />
=== Viewer ===<br />
* allow all sorts of viewers, from 3D to cellphone to web sites<br />
** Create a viewer with the absolute minimum functionality possible (i.e. core client functions) and then make it optionally extensible based on client capability.<br />
*** Put core protocol functionality (login/logout, movement etc) into a library<br />
*** Make the server only send client data it has asked for (client sends "i want prims" message and get prims etc)<br />
*** Should be trivial to integrate with other systems if this is done correctly - IRC gateways for IMs for example<br />
** Allow the client to reassign controls and common functions to a Human Interface Device (gamepad, joystick, customized keyboard, a Bluetooth-connected Wii Remote, etc.)<br />
* Client-side Script runtime<br />
** scriptable chat & movements avatar (bot)<br />
** advanced graphical hud<br />
*** 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<br />
<br />
=== Agents ===<br />
* 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<br />
* 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<br />
* an agent domain should be able to have certain inventory pools which might be shared among agents (like the library in SL today)<br />
* it should be possible to import and export friends lists or groups of friends<br />
* it should be possible to maintain a friends list among various agent domains (related to import/export maybe but as protocol function)<br />
* it should be possible to copy inventory from one agent domain from another if the object structure is compatible.<br />
* an agent needs to provide various methods of verification<br />
* an agent domain needs to define presence information among an agent's friends list. This should even be possible among various agent domains. <br />
* 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.)<br />
<br />
==== possible restrictions between regions and agents ====<br />
<br />
* An agent domain should be able to define on which regions an agent is allowed to connect<br />
* 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).<br />
* A region might allow only certain agent domains to connect<br />
* 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.<br />
<br />
=== Regions ===<br />
* allow regions of arbitrary size and form<br />
* allow portals and landmass-style connections between regions or a mix of both<br />
* region should be able to decide which agents to let in depending on the grade of verification (age, RL identity, financial, ... )<br />
* User defined topology. Like bookmarks, but in 2D. Crossing a custom boundary would result in a "walking teleport"<br />
* Multiple instances of a region within a topology. Everyone can have a front row seat for the show.<br />
* 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.<br />
<br />
== Implementation thoughts ==<br />
=== Viewer ===<br />
* 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?<br />
<br />
=== Regions ===<br />
* 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?<br />
* Can we see into neighboring regions using a low LOD mesh dynamically created to represent the land and objects in a region?<br />
* 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.<br />
* Allow arbitrary assignment of geography to processing resources - including dynamic migration.<br />
** 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). <br />
*** 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.<br />
*** 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).<br />
*** 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.<br />
*** 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)<br />
<br />
=== Currency ===<br />
* how will virtual currency be handled in a distributed grid architecture?<br />
** 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 ?)<br />
** L$ exists as "a limited license right" within Second Life and therefore only makes sense within the official grid(s) owned by LL.<br />
*** Privately-owned grids could be responsible for issuing their own licenses, to throttle their clients' use of those private resources.<br />
**** 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.<br />
**** Such disconnections may allow us to implement a fully localized grid for use on private intranets or on a standalone system.<br />
*** By their nature, private licenses would be mutually incompatible with the official "L$" licenses.<br />
*** 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.<br />
* allow for secure transactions other than in L$ via PayPal, credit cards, etc.<br />
* 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.<br />
<br />
=== Assets ===<br />
<br />
* It is possible to implement asset storage in a completely distributed way<br />
** Assets need not be stored in fixed locations (such as in the 'home' grid of the creator, for example)<br />
** A completely Peer-to-Peer (P2P) storage protocol is possible<br />
** To be successful it would have to retain many of the properties of the current 'fixed' storage schemes<br />
*** 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<br />
*** 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.).<br />
*** Persistent: Some mechanism to control the lifetime of assets may be needed<br />
**** Given the pace of storage technology progress, it may be possible to just keep every asset ever created (ride the wave of progress)<br />
**** If limited asset lifetimes are needed, some kind of distributed garbage-collection algorithm could be employed<br />
**** 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'!)<br />
**** Will it be possible to delete assets/accounts someday?<br />
** 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.<br />
*** 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).<br />
* Assets should support being signed (and notarized)<br />
** Perhaps they should even allow arbitrary meta-data to be attached to them by their creators (or anyone with perms) and accessed via scripts<br />
* Assets should be raw data.<br />
** Asset type, permissions, creator, watermark, etc would be meta-data.<br />
** Any kind of meta-data could be added and used or ignored as needed.<br />
* 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?<br />
** Would an upload fee make sense for transferring objects to different grids?<br />
** If so, how would that fee be determined for a completed object?<br />
** Would some grids (or domains if you'd prefer) be able to reject items from other domains on a permission basis?<br />
<br />
[[Category:Architecture Working Group]]</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=Vhosting_possibilities&diff=32388Vhosting possibilities2007-09-23T01:14:11Z<p>Gareth Ellison: </p>
<hr />
<div>I would like to see SL provide the means for Agents, and Nautical Vehicles (Sailboats, Yachts, etc.) to traverse on a course between non-connected Sims, or along the shoreline boundary of the SL Mainland, by on demand instantiation of a series of Virtual Sims, which would only need to support sufficient prims for the vehicle and its occupants, along the course between a point of departure, and a destination. As a vessel, or group of vessels, vacated a SIM along the course, the VM could be brought down, and another one instantiated further ahead, with the next region's data and configuration preloaded.<br />
<br />
Reservations could be taken via some scripted interface prior to departure, L$ could be charged as toll (deferring costs of the service), random events (weather, seas, currents, sea creatures) could be presented along the course to provide realism and adventure. Regattas and tours could be organized within the performance constraints of such virtual host instances.<br />
<br />
Speaking of performance, I would submit that tuned paravirtualized Xen DomU instances running on a 64bit Linux DomO (a feature of Xen 3.1) on appropriate hardware, could readily handle significant load for such features. Moreover, in general, I would say that LL should consider moving from monolithic hosts, to virtualization in general, ASAP, as a means to better balance load and provide fault tolerance (live migration) of sims for maintenance, and performance optimization.<br />
<br />
I was extremely interested in the coments made in the wiki regarding the dynamic splitting of a busy SIM onto additional server resources.<br />
<br />
http://wiki.secondlife.com/wiki/Brainstorming (Implementation thoughts->Regions)<br />
<br />
Under virtualization, and employing Xen's API and scripting automation, LL could dynamically add processor vcpu, and memory, to an overloaded SIM, to restore adequate performance (I.E. xm vcpu-set and xm mem-set). If not all of the hardware's cpu and memory were preallocated, and 'reserves' were kept available to bolster flagging performance in a sim, then the system would not need to scavenge vcpu and memory from underused SIMs. Additionally, heavily loaded SIMs could be migrated (live migration) as needed, and memory and vcpu adjusted, to an optimized 'best fit' between a set of servers (say within the same Datacenter and VLAN) where such were possible. SL could even data-mine upcoming events from 'Search', I.E.: Live Music Events, Popular Night Clubs at peak hours, Sporting Events, etc., and dynamically scale the performance of SIMs hosting such events, prior to their scheduled commencement, by increasing memory and vcpu and/or migrating them to hardware where such resources were available.<br />
<br />
Vhosting opens up a great deal of opportunity for innovative, on demand, features and services, as well as gains in overall performance and reliability, at the cost of additional complexity in management. However, such complexity can be tamed by developing customized sysadmin management tools, which directly addressed SL needs, from the suite of tools provided by the Open Source Xen development community. Of course, if the financials warranted, LL could choose to purchase XenEnterprise v4, or even VMWare VI3 (for twice the price) and have most of the management tools at hand immediately.<br />
<br />
<br />
<br />
== Port numbers ==<br />
<br />
One thing that is rather annoying at times with the current SL protocol is that a particular sim or other grid component may be listening on any arbitary port in the 13000+ range. Perhaps it is possible to simplify this to just 1 port per server type and register these ports with IANA?<br />
<br />
Furthermore, to permit vhosting, one could do it HTTP-style and indicate per-circuit or per-message which region on that particular region host (for example) you wish to speak to.</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=URL_addressing&diff=32387URL addressing2007-09-23T01:13:22Z<p>Gareth Ellison: New page: This is one that i've been working on myself for a while and is rather simple. sl://domain/region/x/y/z Where "domain" is a DNS name (like secondlife.com) and region is the region name. ...</p>
<hr />
<div>This is one that i've been working on myself for a while and is rather simple.<br />
<br />
sl://domain/region/x/y/z<br />
<br />
Where "domain" is a DNS name (like secondlife.com) and region is the region name.<br />
<br />
An example:<br />
<br />
sl://secondlife.com/Hooper/128/128/50<br />
sl://localhost/My%20Sim/128/128/60<br />
<br />
<br />
DNS SRV records or DNS A records could be used to identify the login server for that particular domain if logging into it directly or to identify the appropriate region stores for that particular region domain.</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=User:Baba_Yamamoto/SL4B_OS_Plan&diff=23392User:Baba Yamamoto/SL4B OS Plan2007-06-15T00:15:04Z<p>Gareth Ellison: /* Open Source The GPL and Second Life */</p>
<hr />
<div>== Overview == <br />
Open discussion area of Open Source and Second Life related topics. Several scheduled talks and presentations on SL and OS topics.<br />
<br />
The Open Source plot is located in the main SL4B sim just east of center.<br />
<br />
[http://slurl.com/secondlife/SL4B/208/129/254 SLURL]<br />
<br />
== Events ==<br />
If you would like to see a discussion on a specific topic please leave a note on the [[{{TALKPAGENAMEE}} | talk]] page.<br />
<br />
{| cellspacing="0" border="1"<br />
|style="width:4em;"| '''Date''' ||style="width:10em;"| '''Time(SLT)''' ||style="width:30em;"| '''Topic''' ||style="width:9em;"| '''Presenter'''<br />
|-<br />
|| Jun 25 || 3:00pm - 4:00pm || Open Source, The GPL and Second Life || Gareth<br />
|-<br />
|| Jun 25 || 4:00pm - || Open Discussion || Open Discussion<br />
|-<br />
|| TBD || 1:00pm - 1:30pm || libsecondlife Introduction / History || TBD<br />
|-<br />
|| TBD || 1:30pm - || libsecondlife Discussion || Open Discussion<br />
|-<br />
|| TBD || TBD || Rob Linden Office Hours || [[User:Rob_Linden |Rob Linden]]<br />
|- <br />
|| TBD || TBD || Improving the viewer || Open Discussion<br />
|-<br />
|| TBD || TBD || Open Simulators || Open Discussion<br />
|}<br />
<br />
== Open Source The GPL and Second Life ==<br />
<br />
I'll be discussing how LL's recent GPLing of the source code is starting to affect the community (both technical and non-technical members). Included in this talk will be more general discussion about open source in SL and what future lies ahead. The merits of the different FLOSS licenses will be reviewed and a few of the SL-related projects which have been generated by the community. It is my firm belief that in opening up the viewer and supporting open source in general, LL have laid out the path for Second Life and systems based upon it to expand in a way other 3D worlds would never have dreamed possible.<br />
[[User:Gareth Ellison|Gareth Ellison]] 17:15, 14 June 2007 (PDT)</div>Gareth Ellisonhttps://wiki.secondlife.com/w/index.php?title=User:Baba_Yamamoto/SL4B_OS_Plan&diff=23391User:Baba Yamamoto/SL4B OS Plan2007-06-15T00:14:18Z<p>Gareth Ellison: </p>
<hr />
<div>== Overview == <br />
Open discussion area of Open Source and Second Life related topics. Several scheduled talks and presentations on SL and OS topics.<br />
<br />
The Open Source plot is located in the main SL4B sim just east of center.<br />
<br />
[http://slurl.com/secondlife/SL4B/208/129/254 SLURL]<br />
<br />
== Events ==<br />
If you would like to see a discussion on a specific topic please leave a note on the [[{{TALKPAGENAMEE}} | talk]] page.<br />
<br />
{| cellspacing="0" border="1"<br />
|style="width:4em;"| '''Date''' ||style="width:10em;"| '''Time(SLT)''' ||style="width:30em;"| '''Topic''' ||style="width:9em;"| '''Presenter'''<br />
|-<br />
|| Jun 25 || 3:00pm - 4:00pm || Open Source, The GPL and Second Life || Gareth<br />
|-<br />
|| Jun 25 || 4:00pm - || Open Discussion || Open Discussion<br />
|-<br />
|| TBD || 1:00pm - 1:30pm || libsecondlife Introduction / History || TBD<br />
|-<br />
|| TBD || 1:30pm - || libsecondlife Discussion || Open Discussion<br />
|-<br />
|| TBD || TBD || Rob Linden Office Hours || [[User:Rob_Linden |Rob Linden]]<br />
|- <br />
|| TBD || TBD || Improving the viewer || Open Discussion<br />
|-<br />
|| TBD || TBD || Open Simulators || Open Discussion<br />
|}<br />
<br />
== Open Source The GPL and Second Life ==<br />
<br />
I'll be discussing how LL's recent GPLing of the source code is starting to affect the community (both technical and non-technical members). Included in this talk will be more general discussion about open source in SL and what future lies ahead. The merits of the different FLOSS licenses will be reviewed and a few of the SL-related projects which have been generated by the community. It is my firm belief that in opening up the viewer and supporting open source in general, LL have laid out the path for Second Life and systems based upon it to expand in a way other 3D worlds would never have dreamed possible.</div>Gareth Ellison