Talk:Brainstorming

Brainstorming (metadiscussion)

I find this entire wiki construct for this deeply radical change to Second Life to be very troublesome, because it doesn't allow for normal, forums-type discussion about a huge variety of issues that will profoundly alter SL as we know it. So I urge you to cease this driving of ordinary people to a wiki construct that really can't serve their needs, and open up the forums with "general" "politics/governance" and "land/economy" as it used to be available. I see that as the only fair way to accommodate the many concerns, problems, and fears generated by open-sourcing a platform that has absorbed with little recognition hundreds of thousands of people's dollars and hours.

Conversation may flow differently on a wiki, but it does allow for proper conversation if used correctly. --Nik Woodget 04:01, 22 September 2007 (PDT)

It's precisely to avoid "normal, forums-type discussions" that we have wikis. The general idea is to collaborate on creating a jointly agreed entity (a design in this case), as opposed to witnessing a linear string of vocal messages that leave previous useful contributions hidden in the mists of debating history. On a wiki, your contribution remains on the front page if it was good, no matter how many more-vocal people drowned you out on the chat page. --Morgaine Dinova 10:07, 23 September 2007 (PDT)

I would like to know who has authored the articles up to this point. I'd like to know their qualifications for so casually writing things like "Should we close the Lindex or not, given it's a limited license for use on a solely-LL owned grid." Sure, this is the decision of a proprietary company in a way. But the LindEx is also a community-owned resource, that has value precisely because people's labour and content production and land development have value. It's a public utility that you can't so casually program hither and youn.

Quite possible one of the open source devs has written this page. And the question about the lindex is simply something there that we have to consider. Though like you, I would like them to find a way to keep the linden as SL's currency. --Nik Woodget 04:01, 22 September 2007 (PDT)

Zero Linden said that Linden always "engineers to migrate the world along with them." But that very perspective lets us know that we are merely a flock that somebody is supposed to "migrate" like dumb beasts, and not *participants in the social as well as technical engineering.*

we are participants for this open architecture project, you've juse become a minimal participant writting this. Why not add you own things to the Brainstorming you belive needs to be considered in the designing of the open architecture.--Nik Woodget 04:01, 22 September 2007 (PDT)

I predicted that open sourcing would lead to closure of the Lindex for other reasons (dollarization of the economy) but what boggles the mind here is that despite these really huge issues that will have an enormous impact on people, community, value, land, content, it's being treated as a purely technical exercise -- it's being treated as merely an "architecture" program and not an economic one, and one engineers and not economists and land owners get to decide.

like I said, then get yourself and others involved that will look at the economic and social sides and get them to add they're thoughts and concern to the pages dedicated for this in the wiki. The more who discuss, the more ideas we'll have to play, the more chance residents will get an open architecture that they would like. --Nik Woodget 04:01, 22 September 2007 (PDT)

It's anything but a simple programming issue! A decision to close the LindEx has profound implications affecting small business and individual purchases.

Over history, changes in physical technology have always affected adversely those whose fortunes were tied to earlier technological constraints. That is in the nature of technological change. Virtual world technology will change even more rapidly as it is not subject to many physical constraints. Virtual world businesses need to adapt to this dynamic landscape. Agile businesses will probably survive and thrive, but others may not. --Morgaine Dinova 02:03, 24 September 2007 (PDT)

Prokofy Neva

---

• I've split off the above into a "Brainstorming (metadiscussion)" topic, although it's debateable whether it fits here under Brainstorming at all. In any event, brainstorming isn't compulsory, if you don't want to help us, then don't. :-) --Morgaine Dinova 09:07, 23 September 2007 (PDT)

Brainstorming (technical)

• Restructured comments under the same headings as main namespace. --Morgaine Dinova 22:22, 27 September 2007 (PDT)

Usage examples and requirements

General architecture

• The [comments] added to this section today by User:Lusus_Saule concerning SL democracy are physically misplaced. The General architecture referred to in the title is a computing architecture, not a social one. I'm not sure exactly where those comments should be relocated, but they definitely don't fall under the remit of the AWG. --Morgaine Dinova 05:57, 1 October 2007 (PDT)

Usage examples and requirements

Viewer

Functional refactoring of viewer

• Small section added on refactoring of client into front-end + graphics. I'd appreciate comments and counter-suggestions. --Morgaine Dinova 09:07, 23 September 2007 (PDT)

• Tillie, that was an interesting Use Case you added to the viewer refactoring section, ie. "blog editor" type functionality:

• It's quite distinct from the earlier Use Cases, in that it isn't attached to a presence but to an object, namely the object being edited. It may be a stretch to call it a viewer because of that, since all other viewers are attached to a presence, even audio-only or script-only "viewers". However, I think you may be on to a good idea there, one related to XML-RPC and other attempts to establish communication between RL agents and SL objects directly.
• Perhaps the concept of presence needs to have a number of stages of progressive refinement: first overall presence in a world or grid, then overall presence in a specific zone or region, then in a parcel within the zone, and at the most detailed level, exact location within the zone. Your object editor would then need to establish a presence only at the grid level in order to edit an object there. Likewise, an audio viewer for live concerts would need to establish only a parcel presence, whereas a normal avatar login would require a fully defined presence. --Morgaine Dinova 08:28, 24 September 2007 (PDT)

• Note that the event/protocol API exposed by the front-end half of the refactored client should be a language-agnostic API, so that we can create language bindings for it appropriate for different types of platform, including LCCs. In practical terms, this means that it should not be a hierarchical OO API, as this creates substantial problems when embedding languages. --Morgaine Dinova 01:11, 28 September 2007 (PDT)

Commerce

• If Second Life is going to live up to its name it should incorporate as many real world activities as possible, and one important area is business. Rather than companies use of Second Life being pretty much restricted to meetings, perhaps this could be expanded to include as many aspects of real world commerce as possible.

• Could Second Life eventually incorporate real world stores on the grid where residents could buy items to be delivered to their homes? Or perhaps service industries could be allowed to function on the grid, so for example real world banking transactions etc could take place. It is not a big leap from this to see how online businesses could be developed within Second Life following the models of for example, Amazon and Ebay. - [This has been done by a few already, and is up to developers to take advantage or create the functional connections. Some improvement to external SL communications could help promote this more though.]

• Could it be possible to also develop areas such as real world education/training within Second Life with recognized qualifications? I believe a university (or a number of places of learning) within Second Life where recognized qualifications could be gained would attract and help a lot of people. - [I believe the functionality exists for this. Are there specific technical items that are inhibited and need to bee changed to attract a University to start an online learning program in SL? ] --Lusus Saule (attribution got lost in reshuffle, corrected by hand -- Morg)

• Note that the brainstorm is for the future, massively scaled and distributed virtual world of which LL's grid will be only one part, and not for the current SL. Some comments seemed to apply to the current SL only.
• From a technical perspective, I think the onus is on designers to ensure that the entities used in commerce are supported, ie. currencies, timestamped transaction records (this was exchanged for that), unforgeable documents for contracts, etc etc. Perhaps that deserves mention in the brainstorm. Given a good framework, commerce will come of its own accord, and in the envisaged multinational, distributed architecture, it will probably develop in ways which we never imagined. --Morgaine Dinova 00:33, 24 September 2007 (PDT)

Identity

• Added Virtual Identity Verification section. The preceding items seemed to be very "now" and LL-oriented, rather than looking ahead to a worldwide and more distributed architecture. --Morgaine Dinova 00:02, 24 September 2007 (PDT)

Privacy and control

• New section added to tie in with an earlier discussion with Tillie about privacy. --Morgaine Dinova 08:03, 2 October 2007 (PDT)

Regions

Virtualization of regions

• New section Virtualization of regions added, to tie in with the server-side requirements for implementing massive scalability for events.
• The same scheme delivers numerous other benefits, highlighted in that section, such as the ability of a large grid to deliver decent performance to its residents when they visit a small external attached grid, through caching. Without such functionality, new worlds cannot easily grow at the periphery, and large grids will tend to be insular.

Implementation thoughts

Viewer (--> Decentralized assets)

• Section heading Viewer under "Implementation thoughts" renamed as Decentralized assets, because running a local sim, grid, or asset server is entirely independent of the viewer, even if the viewer manipulates those assets. --Morgaine Dinova 10:32, 23 September 2007 (PDT)

Regions (dynamic)

• The [additions] made by Cenji Neutra on 20th Sept are quite strongly related to (or at least overlap with) the changes that I suggest are needed in server-side region handling in order to support the various kinds of SecondlifeTube-type use cases. I would like to start brainstorming some implementation details for these use cases, but ideally I should be cooperating with Cenji on this since he/she must have additional perspective on the issue. Calling Cenji .... :-) --Morgaine Dinova 10:04, 29 September 2007 (PDT)

• I've now added a new section Virtualization of regions and started brainstorming this area. Still need to talk to Cenji ... --Morgaine Dinova 03:43, 30 September 2007 (PDT)

Problems with region subdivision as a scaling method

• New section added to contain my analysis of the proposed region subdivision method. --Morgaine Dinova

• This is currently in mid-edit, and contains temporary section markers and placeholders. They will disappear imminently. --Morgaine Dinova

Capabilities

Limited Capability Clients

• This sounds extremely promising as a concept to me. I've added a Use_Cases#Limited Capability Clients heading, and would love to see a few examples in there. I might add some myself too.
• I agree totally on the point about LSL not being appropriate for that kind of scripting, because the object and asset environment of LSL doesn't exist on the client. I'm quite agnostic about languages, but the smaller and more efficient a language the better for LCCs, so Lua stands out by a mile for this. --Morgaine Dinova 21:45, 27 September 2007 (PDT)

I was intending that when scripting LCCs that the script be run on the region and not the client. The client would be partially oblivious to what the region was doing for it. Some aspects of it should require permission or user decisions but most not. The LCC configuration might be easiest to express as a web page (having it as a webpage would reduce the amount of custom software the LCC would have to run to interact with the region). -- Strife Onizuka 23:03, 27 September 2007 (PDT)

• Aha, I understand. OK, we have two different scripting requirements then:

1. Agent-based server-side scripting (this implies that the LSL runs in an attachment or HUD), which performs automatically certain actions which would be either impossible, hard or at least tiresome to perform manually on LCCs.
2. Client-based scripting which performs local processing on LCCs, eg. triggering the agent-based server-side scripts as described above. As well as issuing those event triggers, client-side scripting would create all local UI objects and use that event API for UI-related communications.

• This looks good to me. An LCC might not even have physical buttons (eg. the OpenMoko phone), so the combination of client and server scripting would make up for the powerful capabilities of desktop clients lacking on an LCC. --Morgaine Dinova 00:48, 28 September 2007 (PDT)
• I have several LCC-type use cases listed under Functional refactoring of viewer, justifying the need to refactor the client code so that all these very different UIs (some not even graphical) can be accommodated. Now that you've introduced the LCC category, I'll try to rethink that section and refocus it in terms of LCCs where appropriate. --Morgaine Dinova 00:57, 28 September 2007 (PDT)

LCC is just half of the equation. By mixing and matching features things could get really interesting, SLTube is just one example. My next goal is to organize the Capabilities, which has largely already been done for the domain model and more so by the Use Cases. Once that is organized we can look at it's dependencies in the network protocols. But the larger task will be to design the Capability Negotiation system for client & region and client & client negotiations. CN and all the Capabilities need to all fit into a Capabilities Framework, the CF will provide the structures needed for extending SL's capabilities for the future. If CN can be done dynamically then some of the more interesting Use Cases will sort themselves out (you unplug your laptop and it drops the capabilities so you don't use all the battery power, you get on the train and it switches to a passive mode where it syncs the world when it can get a connection otherwise it runs locally). Some of what we discussed at ArchWG meeting went over my head but I think this is the right direction to travel in. CN & CF is what we should be standardizing. -- Strife Onizuka 03:23, 28 September 2007 (PDT)

• Good, this sounds like a powerful approach. As long as the CN is done in a sane engineering manner as transitions in a state machine (I really don't want to see add hoc negociations, they are difficult to test with full coverage and often go wrong or leave something out), then state switching for capability changes becomes a very deterministic operation which can be triggered nicely in any number of ways, including from client-side scripts into a tidy API. --Morgaine Dinova 12:00, 28 September 2007 (PDT)

Extended Capability Clients

• I added Use_Cases#Extended_Capability_Clients section for the other extreme from the Limited Capability Case. Saijanai 20:12, 6 October 2007 (PDT)

ANALYSIS: Region Subdivision as a scaling method

• New section added. I'm building this section up as wiki responsiveness allows ... which means very slowly. --Morgaine Dinova 02:32, 8 October 2007 (PDT)
• My first-cut analysis is now done. All queries, comments and extensions of the analysis welcome, and especially suggestions for how the problems might be overcome. --Morgaine Dinova 07:17, 8 October 2007 (PDT)

ANALYSIS: Region Virtualization as a scaling method

• New section added. It's early days (and I'm still doing analysis of the previous proposal), but feel free to note down any problems you see early on. You can find some initial info in Brainstorming#Virtualization of regions. --Morgaine Dinova 03:32, 8 October 2007 (PDT)

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

• Jesrad, I think this is quite an excellent proposal, and also a very thorough analysis with good coverage.

I can't see any serious problems in it after a few reads, except for one small one which you said yourself was optional, namely the issue of 'physics'. If you strike physics off from the duties of the avatar-based computing service (leaving it to the event region to handle as now), then the rest looks very viable. The reason why physics can't really be included (for now) is that this would give rise to the need for distributed physics (not merely distributed computing, which is much easier), and that's not a simple problem at all --- it's fact it's still somewhat of a research area.

With regards to scalability, I see only one hard ceiling in your model at the present time, and that's up high enough not to matter too much, as it's roughly conformant to our scary numbers for scalability for events given in Project_Motivation.

I'll be looking more deeply tomorrow after I get some sleep, but it's looking very good indeed so far. Good work! --Morgaine Dinova 02:12, 11 October 2007 (PDT)

• Thanks for the cheers :) The reason I'm including physics (even though it makes collision handling problematic) is that keeping physics territorially-run would require either additional and continuous data transmission between simulators because of physics-changing scripts (vehicles !) and the necessity to keep track, for the owner simulator, of the coordinates. There is no way around this: either objects are run in a given simulator, including their physics and scripts and all, either they are run by the land's simulator. There is too much interdependency to do otherwise, so my preferred suggestion is to keep as many things as possible together, and only exchange the bare minimum of data between servers of the Grid. I'm not even suggesting a decentralized physical simulation (I have done research work on this subject in 2004 but my software implementation and model have remained incomplete), just that each of the parties that meet in the same coordinate space behave nicely and pretend they be colliding as best they can figure, that would be very sufficient IMO. Think about it: right now in SL the only collisions that are really well handled are static/physic ; when two physical objects collide there are bugs and lag and overall trouble. It gets worse when a static object warps into a physical object (crashing and burning). If such colliding objects were handled by different servers I don't think it'd matter much if they miss the collision, only pretend to be colliding or if there is some delay or post-collision correction. I can already warp through walls by flying fast enough anyway (which I find useful :D).
• There is an hard ceiling in my proposal, which is that of the maximum number of simultaneous connections one can maintain. I fear this would multiply any connection-state data, reducing the total useful bandwidth left in crowded situations. If we can get stateless connections for SL content and interaction, that problem will be lifted (and presence lists can be trimmed by simple timeout and beatpulse). In the case of scalability of events, the local simulator is still limited to the number of people it can serve the presence list AND the content to, so it means someone who wishes to invite a lot of people in one place will still have to ramp up that place's capacity to support the higher number of parallel connections. But, eh, that's the same RL, we have to rent halls if we want to gather a hundred or more persons, after all. We could have a few higher-end servers for hosting bigger events, for one.
• The main idea of this proposal is to keep data streams seperated until they reach the client, in order that my other idea (SL events as data streams) can be much more easily implemented. When one simulator is trying to broadcast a single data stream to thousands of clients, and does not have to care about all these clients sending massive loads of data back to be included into that stream or exchanging data about their own interaction and presence, it's much easier to devise load-balancing, caching, etc. solutions for higher scalability. --Jesrad Seraph 03:59, 11 October 2007 (PDT)

• OK more brainstorming: feasability of gradual introduction of such "per-resident sims" to SL
• There is no way per-resident sims could coexist with per-region sims to this date, and the passage from one sort to the other would require that all content in each region be transferred, in its current state, to its owner's simulation as if it crossed a region boundary, which is quite a considerable amount of work and data hauling (it could be interesting to know the complexity of such a process). However there is one possible intermediate step before such a 'big switch': introducing alternate spaces run by a different sort of sim.
• By alternate spaces I mean non-region places (ocean) and high-altitude (above 768 m ? Above 4096 m ? Higher still ?) in SL. Basically, when you run or fly your avatar off-world or too high, you'd cross region into such a space and your avatar gets handled by this different sort of simulator: an instance kind of sim that is created when your avatar or objects cross into the alternate space, and handles it entirely for as long as it roams the oceans or skies of SL on its own (it's all empty, but for the water and ground in the ocean space only), and is stopped when you and your object leave the alternate space. It could first be no-script and only accept avatars. Then could receive region-crossing objects (which would be returned to your inventory when the instance stops). Then add script running capacity. Then add the presence mechanism so that people can start meeting in the alternate space instead of experiencing it as their own personal alternate dimension. Then maybe add the collision info exchange mechanism, so they can also bump into each other when they meet. At this point, we'd have a robust enough codebase to start thinking about switching everything to the new model or at least envisage creating alternate Grids with them. What do you think ?