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)

• I've been signing my modifications to the main namespaces, which is unorthodox, and also contrary to wiki guidelines. :P This is only temporary to highlight recent changes, as I'm slightly uncomfortable with the very low rate of commentary here (and hence no feedback/corrections). I'll remove my signatures in a few days if all is well, or immediately if there is feedback. --Morgaine Dinova 12:48, 24 September 2007 (PDT)
• Most of my main namespace signatures now removed. --Morgaine Dinova 22:02, 27 September 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)

Commerce

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

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)

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)

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)