Second Life Wiki - User contributions [en]

Talk:Viewer Visual Update

2007-11-28T10:08:16Z

Nik Woodget: /* Multiple Monitor Support */

== Thanx for the feedback thus far... ==
Hello and thanks for the comments! I'm involved with this project, codename "Dazzle", insofar as helping the Rx Team get the word out to our community. I haven't read all of these comments in close detail yet, but I appreciate not just the content, but the presentation too.

LordJason Kiesler — thanks for embedding that graphic to communicate what you think of about the button gradients. If anyone else wants to contribute screenshot mockups, please, you're more than welcome. Since this is a ''visual'' update, those type of aids help.

I also had [http://www.flickr.com/photos/torley/1801183618/ some nice comments on my Flickr photostream], and will be encouraging more... and responding in kind. Appreciatively yours! --[[User:Torley Linden|Torley Linden]] 16:28, 1 November 2007 (PDT)

Great, [http://torley.com/introducing-second-lifes-dazzle-user-interface-update even more Dazzle feedback on my personal blog!] --[[User:Torley Linden|Torley Linden]] 08:04, 5 November 2007 (PST)

i love the new version :O is fantastic 
the near me bug is fixed exellent 
now i'm bugfixing my purple version 
really a good job benjamin :D --[[User:Aliceinwire Bleac|Aliceinwire Bleac]] 04:56, 12 November 2007 (PST)

== Feedback and Ideas ==
*As far as I'm concerned, one of the gold standard issues for interface usability in this or any other application is the ability to pull pop up menus off the interface. If one can't do that, it doesn't matter how pretty they look; they block content and make working in the interface overly difficult. Gotta be able to pull stuff off the interface or it's more of the same with new candy colors. [Professor Beliveau/5:18SL 10/30/07]
* In the Mac instructions, if you start with 'Make a copy of the Second Life application with "Duplicate" and rename it "Second Life Visual Update"...' and move on from there then the "uninstall" step won't be needed, and people can more easily compare the two. -- [[User:Argent Stonecutter|Argent Stonecutter]] 06:14, 22 October 2007 (PDT)

* Great work on the graphics! Definitely shows off the potential for what can be done.

Well how novel: ripping off the Mac OS X metallic buttons and giving them an Aqua feel... Well, don't stop there. Read Apple's Human Interface Guidelines and implement them. Then we'll not only have the feel too, but then the whole thing may work as standard instead of being buggy, bloated, roll your own code. We would have international settings and keyboards that worked, standard window behaviour, one menu bar not two, and text editing handling that worked properly, and properly transposed keyboard shorcuts. Get that stuff sorted first then you can think of moving on to skinning.
: I would like to point out, that SecondLife client is Cross-Platform. If they stuck to the Mac guidelines, then it wouldn't fit windows or linux. To be honest, as SecondLife is effectively a game, the interface has to be a roll your own (Read Apples guidelines, it actually says that somewhere) --[[User:Nik Woodget|Nik Woodget]] 02:37, 22 October 2007 (PDT)

* Just to introduce the conservative voice *8) while I greatly appreciate thought going into the viewer and all, I wouldn't say that making the colors prettier and the buttons and icons slicker-looking would be where I'd focus efforts if it was me. Give me back a tearoffable friends list, let me tear off and move around llDialog() / GroupNotice style dropdowns, make the viewer notice and tell me something useful when packets-in-per-second drops to zero, and other actual functional enhancements would do me a world more good than shinier-looking buttons... [[User:Dale Innis|Dale Innis]] 11:06, 13 November 2007 (PST)

* Great look, how ever the big problems in the gui layout are net even addressed in this preview. Friends and group was so much more easier to use before the voice release. I really like to get that in the 18.4 viewer nice Linux bug fixes but no working friends list yet in that version. Voice i guess that will come some ware around 2010 at best. I'm not asking for much just two patches from nicholaz. (and probably a hard admittance from someone onside Linden that new look with friends inside the IM window was a bad idea.) --[[User:Balp Allen|Balp Allen]] 00:36, 14 November 2007 (PST)

== Feedback on the style itself ==

*The problem I'm having is with the fact that most of the text in search results is white on a bright blue/gray background, which makes it hard to read. Also, text in profiles and (non-editable) group descriptions is difficult to read for the same reason. I think that adding more contrast would definitely improve the usability (not to mention the accessibility) of this skin. -- ????

The theme seems to be mostly based on one of a variety of "glossy" 3d themes that have become popular in UNIX/X11 environments. I would much rather see the glossiness eliminated and something less overpowering being used as inspiration.

Specific points:
:* With a light background ALL the text needs to be dark.
:* The window close and minimize buttons look smaller in this style, even if they aren't, and I keep slowing down to hit them more precisely.
:* The translucent menu bar is an improvement. It needs to extend under the menus themselves, of course. The backdrop for the button bars on the bottom should be translucent as well, for symmetry... and with the new style I don't think the little "loops" over the buttons above the chat bar are really useful.
:* The glossiness of the buttons is a problem, and they also look more like tabs than buttons. A flatter more "matte" style would work better.
:* The slight border around the chat and nametags is VERY nice.
:* The 3d look of hover text is not so good, I think because it's light. The light colored pie menu is ''really'' a problem.
:* The inventory and appearance editor seem significantly less professional.
:At the moment I think the original style is preferrable. I would say that the dark color scheme works better, particularly for translucent windows... if the ghosted windows could turn dark (but with light text) that would work, but that's probably more than XUI can handle. -- [[User:Argent Stonecutter|Argent Stonecutter]] 06:25, 22 October 2007 (PDT)

*I'm not a fan of square buttons.
*Like Argent I struggle with some of the light backgrounds
*Would it be possible to have an instruction page? This file does... for all the images. I know its possible to open them all, and I will, but pointers for how to tweak what be nice. I'm going to try a nicer (for my eyes) skin with greens, similar to the theme I've got on my mac menus, and hack some buttons, but it will take a while to get right because I'm flying blind (particularly for .j2c's that don't automatically preview for me). --[[User:Eloise Pasteur|Eloise Pasteur]] 06:53, 22 October 2007 (PDT)
:* Good print, J2Cs aren't well supported in bitmap editors yet. -- [[User:Argent Stonecutter|Argent Stonecutter]] 09:14, 22 October 2007 (PDT)
:* In the textures folder is a textures.xml file. This is the mapping {purpose}.tga -> UUID.{any extension} --[[User:Thraxis Epsilon|Thraxis Epsilon]] 11:51, 22 October 2007 (PDT)

I too struggle with the chat history and permission/worn status in inventory, as it's light text on a light background, but I hope you'll correct this by darkening the text. I like dark text on a light background very much... but OTOH I can understand how in a dark environment, you might want the opposite, sort of like the dashboard on your car... can it be made skinnable, so people can have what they prefer? (Changing with time of day or ambient lighting is probably a bit much to ask for, but would be very cool.) --[[User:Melissa Yeuxdoux|Melissa Yeuxdoux]] 16:23, 2 November 2007 (PDT)

=== Similarity to Mac/Aqua ===
Well how novel: ripping off the Mac OS X metallic buttons and giving them an Aqua feel... Well, don't stop there. Read Apple's Human Interface Guidelines and implement them. Then we'll not only have the feel too, but then the whole thing may work as standard instead of being buggy, bloated, roll your own code. We would have international settings and keyboards that worked, standard window behaviour, one menu bar not two, and text editing handling that worked properly, and properly transposed keyboard shorcuts. Get that stuff sorted first then you can think of moving on to skinning.
: I would like to point out, that SecondLife client is Cross-Platform. If they stuck to the Mac guidelines, then it wouldn't fit windows or linux. To be honest, as SecondLife is effectively a game, the interface has to be a roll your own (Read Apples guidelines, it actually says that somewhere) --[[User:Nik Woodget|Nik Woodget]] 02:37, 22 October 2007 (PDT)
:: I don't think it looks Mac-like at all. In fact while Apple popularized the glossy look the "shiny metallic" look isn't really their schtick, and they have been moving away from the aggressive glossiness of the early OS X versions to a smoother and more professional look in Panther and Tiger. -- [[User:Argent Stonecutter|Argent Stonecutter]] 18:02, 22 October 2007 (PDT)
:::I personally wouldn’t complain if they implemented as much of Apple’s HIG as possible. I wouldn’t expect them to get rid of the in-window menubar, but it would be nice if things like keyboard layouts worked properly. —[[User:Frungi Stastny|Frungi Stastny]] 06:53, 23 October 2007 (PDT)

=== Icons ===

The icons representing prims in the object builder are too small. It is quite difficult to distinguish between similar prims as, for example, the cone and the semicone.--[[User:Eadoin Welles|Eadoin Welles]] 10:22, 22 October 2007 (PDT)

I'm not loving it... Although I do like some of the icons but color wise and color balance theme are killing my eyes. The whole "gloss jem" buttons from Window Vista and OS Mac got really really old so fast. For me, I'd like a dark theme. Something more like this theme. [[http://www.wincustomize.com/zoom.aspx?skinid=4617&libid=1]] --[[User:Vincent Nacon|Vincent Nacon]] 12:32, 22 October 2007 (PDT)

I don't think the icons on the map or in other windows should be changed from the standard client unless absolutely necessary... and again I don't think that encapsulating the icons is really a good idea. -- [[User:Argent Stonecutter|Argent Stonecutter]] 18:06, 22 October 2007 (PDT)

I have to say I am underwhelmed by the icon set. Have you considered the [http://en.wikipedia.org/wiki/Tango_Desktop_Project Tango Desktop Project]? The Tango Project seeks to create a consistent graphical user interface experience across applications and platforms. IMHO, the quality of their icon sets is very high. Have a look at the icon sets and [http://tango.freedesktop.org/Tango_Icon_Theme_Guidelines style guidelines on their website]. — [[User:Yuu Nakamichi|Yuu Nakamichi]] 15:21, 2 November 2007 (PDT)

== Additional suggestions ==
This section should be kept for suggestions that are really beyond the scope of a theme change.

=== Multiple Monitor Support ===

Would like more than anything to see the UI windows capable of being moved onto a second monitor off the main viewer window. Now that would be very cool and make life a whole lot easier.
:This would also mean making that the second life viewer would have to use system controls. Again its a pain for cross-platform software. Though not impossible. --[[User:Nik Woodget|Nik Woodget]] 02:38, 22 October 2007 (PDT)
::Why would this require using system controls ?
::[[User:SignpostMarv Martin|SignpostMarv Martin]] 06:59, 22 October 2007 (PDT)
:::The UI in Second Life is part of the OpenGL rendering pipeline. In order for the controls to be seperated from the main window they would have to be contained in seperate OS controls. Maybe not system independent controls, perhaps custom controls rendered into borderless windows might work. --[[User:Nik Woodget|Nik Woodget]] 02:08, 28 November 2007 (PST)
:::: Aren't there free open-source cross platform systems already out there to do stuff like that?--[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 05:32, 13 November 2007 (PST)
::::: Possibly, do you have any you can suggest? --[[User:Nik Woodget|Nik Woodget]] 02:08, 28 November 2007 (PST)

=== Mac Support ===

For the Mac port, at least, the way that command and control are reversed is really hard to deal with. It would be nice if there was an option to reverse the command and control keys ''for XUI only''. -- [[User:Argent Stonecutter|Argent Stonecutter]] 06:07, 22 October 2007 (PDT)

Whilst we're talking about this - can we add a request for a proper implementation of the Mac GUIs, without the irritating internal menus as well please. Swap the menu bar menus the way the GUI guidelines suggest. It's a different code base after all. I may have got used to this structure, but it's one bit of muscle memory I'd be very happy to get rid of! --[[User:Eloise Pasteur|Eloise Pasteur]] 15:56, 22 October 2007 (PDT)

=== Widgets ===

I like the new interface. It is surely better than the black one but, by the way, the real value would be to have a choice of skins which, in my understanding, is the main goal of this test. I think that another improvement might be to have the possibility to add gadgets. For example, I would like to have, close to the PDT time, also the local time, since most of events that I prepare are located in my country, and I prefer to use local time rather than useless PDT time. Rather than adding this feature, which may be of no interest to USA people and surely not at all to California people, you may give us the possibility to create gadgets, like in Google or Vista. So I could develop a small gadget to see time in various timezones, another one that automatically convert Linden dollars to various currencies, and so forth. By facilitating the development of user gadgets, you would dramatically improve the SL interface without having to develop them yourself. IMHO Greetings from Rome, Italy --[[User:Eadoin Welles|Eadoin Welles]] 10:19, 22 October 2007 (PDT)

==== Vector Graphics Widgets ====

Would like to see a flash layer, where flash widgets could communicate to the UI via an API and either replace or partially replace bits and pieces of it. This could be a big market for companies wishing to have customized clients but still take advantage of Linden Labs robust source.
:I would actively NOT want to see a layer that can only be programmed with a closed system like flash. -- [[User:Argent Stonecutter|Argent Stonecutter]] 06:07, 22 October 2007 (PDT)
::SVG + Javascript would work- uBrowser would be the place to start with that.
::[[User:SignpostMarv Martin|SignpostMarv Martin]] 06:59, 22 October 2007 (PDT)
:::That's one approach. Javascript based controls are used in a number of programs: Firefox (XUL), Mac OS (Dashboard), Yahoo Widgets (for that matter Adobe's Actionscript has converged on Javascript). I'm not sure that SVG is the way to go, but that's not an objection... I just don't know wnough about SVG. Another possibility is to use Tk, since that has bindings for several scripting languages already. All this is somewhat out of the scope of a theme change. -- [[User:Argent Stonecutter|Argent Stonecutter]] 08:47, 22 October 2007 (PDT)
::::SVG would provide an "open" system for vector graphics where flash provides a "closed" system.
::::[[User:SignpostMarv Martin|SignpostMarv Martin]] 12:41, 22 October 2007 (PDT)

=== Skin Support ===
I'd like to suggest Hue changer for quick custom theme color for users.... However, for graphic artist like myself, I would like to able customize the skin with ease. Just think more like WinAmp 5. --[[User:Vincent Nacon|Vincent Nacon]] 12:32, 22 October 2007 (PDT)

is also good to make a little program in php for the second life site or a executable for create new skin in more simple way

this is my purple skin :)
[[Image:Dazzle_purple_version.JPG|thumb|300px|Purple Skin]]

--[[User:Aliceinwire Bleac|Aliceinwire Bleac]] 04:56, 7 November 2007 (PST)

* Purple skin made me smile a lot! Thanx for sharing that with Ben and I, Aliceinwire! /me open-secretly hopes for a green-and-pink skin. :D --[[User:Torley Linden|Torley Linden]] 11:26, 7 November 2007 (PST)

===Too Little===
Just looking at the pic...except for the icons, which are probably needed, I'm underwhelmed. It's the same old interface except for being white and shinier (IMO, too shiny), and the consensus among people I know tends torward the opinion that the UI needs to be reinvented, not just polished, and I'd rather see development time being taken on that. Take as an example the work being done by e-Sheep with their new custom client. I'm not saying they've done things that I necescarily want to see but they've got their goals in the right place. I could list a number of UI suggestions and pet peeves but this isn't the place for it...some day I wil actualy get around to putting them on the JIRA. That said, I agree with the people who mentioned skins and even just being able to set UI color preferences from the preferences menu; that by itself would address a lot of issues. [[User:Elle Pollack|Elle Pollack]] 15:00, 22 October 2007 (PDT)

===Enhancement?===
I would love to beable to collect a Landmark while viewing another resident's profile picks. --[[User:Sabina Stenvaag] , 1 nov 2007 (PDT)

== Buttons. ==

The gradient effect on the buttons need to weigh one way or the other. Having the 'line' go right through the text with as much contrast as it has, is distracting, and hard on the eyes.
I would suggest more smoothing to it as well.
Here is a mock up of what I mean. The lower left button is the only one modified.
[[Image:NewViewer_button_mockup.jpg|mock up]]

== what is wrong with light text on dark background? ==

for me, light text on dark background is way more comfortable for my eyes, I find light backgrounds kinda too aggressive :/

why not continue with the dark backgrounds? imitating rl paper on software is kinda lame on my opinion :\ --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 01:08, 13 November 2007 (PST)

Talk:Viewer Visual Update

2007-11-13T10:42:50Z

Nik Woodget:

== Thanx for the feedback thus far... ==
Hello and thanks for the comments! I'm involved with this project, codename "Dazzle", insofar as helping the Rx Team get the word out to our community. I haven't read all of these comments in close detail yet, but I appreciate not just the content, but the presentation too.

LordJason Kiesler — thanks for embedding that graphic to communicate what you think of about the button gradients. If anyone else wants to contribute screenshot mockups, please, you're more than welcome. Since this is a ''visual'' update, those type of aids help.

I also had [http://www.flickr.com/photos/torley/1801183618/ some nice comments on my Flickr photostream], and will be encouraging more... and responding in kind. Appreciatively yours! --[[User:Torley Linden|Torley Linden]] 16:28, 1 November 2007 (PDT)

Great, [http://torley.com/introducing-second-lifes-dazzle-user-interface-update even more Dazzle feedback on my personal blog!] --[[User:Torley Linden|Torley Linden]] 08:04, 5 November 2007 (PST)

i love the new version :O is fantastic 
the near me bug is fixed exellent 
now i'm bugfixing my purple version 
really a good job benjamin :D --[[User:Aliceinwire Bleac|Aliceinwire Bleac]] 04:56, 12 November 2007 (PST)

== Feedback and Ideas ==
*As far as I'm concerned, one of the gold standard issues for interface usability in this or any other application is the ability to pull pop up menus off the interface. If one can't do that, it doesn't matter how pretty they look; they block content and make working in the interface overly difficult. Gotta be able to pull stuff off the interface or it's more of the same with new candy colors. [Professor Beliveau/5:18SL 10/30/07]
* In the Mac instructions, if you start with 'Make a copy of the Second Life application with "Duplicate" and rename it "Second Life Visual Update"...' and move on from there then the "uninstall" step won't be needed, and people can more easily compare the two. -- [[User:Argent Stonecutter|Argent Stonecutter]] 06:14, 22 October 2007 (PDT)

* Great work on the graphics! Definitely shows off the potential for what can be done.

Well how novel: ripping off the Mac OS X metallic buttons and giving them an Aqua feel... Well, don't stop there. Read Apple's Human Interface Guidelines and implement them. Then we'll not only have the feel too, but then the whole thing may work as standard instead of being buggy, bloated, roll your own code. We would have international settings and keyboards that worked, standard window behaviour, one menu bar not two, and text editing handling that worked properly, and properly transposed keyboard shorcuts. Get that stuff sorted first then you can think of moving on to skinning.
: I would like to point out, that SecondLife client is Cross-Platform. If they stuck to the Mac guidelines, then it wouldn't fit windows or linux. To be honest, as SecondLife is effectively a game, the interface has to be a roll your own (Read Apples guidelines, it actually says that somewhere) --[[User:Nik Woodget|Nik Woodget]] 02:37, 22 October 2007 (PDT)

== Feedback on the style itself ==

*The problem I'm having is with the fact that most of the text in search results is white on a bright blue/gray background, which makes it hard to read. Also, text in profiles and (non-editable) group descriptions is difficult to read for the same reason. I think that adding more contrast would definitely improve the usability (not to mention the accessibility) of this skin. -- ????

The theme seems to be mostly based on one of a variety of "glossy" 3d themes that have become popular in UNIX/X11 environments. I would much rather see the glossiness eliminated and something less overpowering being used as inspiration.

Specific points:
:* With a light background ALL the text needs to be dark.
:* The window close and minimize buttons look smaller in this style, even if they aren't, and I keep slowing down to hit them more precisely.
:* The translucent menu bar is an improvement. It needs to extend under the menus themselves, of course. The backdrop for the button bars on the bottom should be translucent as well, for symmetry... and with the new style I don't think the little "loops" over the buttons above the chat bar are really useful.
:* The glossiness of the buttons is a problem, and they also look more like tabs than buttons. A flatter more "matte" style would work better.
:* The slight border around the chat and nametags is VERY nice.
:* The 3d look of hover text is not so good, I think because it's light. The light colored pie menu is ''really'' a problem.
:* The inventory and appearance editor seem significantly less professional.
:At the moment I think the original style is preferrable. I would say that the dark color scheme works better, particularly for translucent windows... if the ghosted windows could turn dark (but with light text) that would work, but that's probably more than XUI can handle. -- [[User:Argent Stonecutter|Argent Stonecutter]] 06:25, 22 October 2007 (PDT)

*I'm not a fan of square buttons.
*Like Argent I struggle with some of the light backgrounds
*Would it be possible to have an instruction page? This file does... for all the images. I know its possible to open them all, and I will, but pointers for how to tweak what be nice. I'm going to try a nicer (for my eyes) skin with greens, similar to the theme I've got on my mac menus, and hack some buttons, but it will take a while to get right because I'm flying blind (particularly for .j2c's that don't automatically preview for me). --[[User:Eloise Pasteur|Eloise Pasteur]] 06:53, 22 October 2007 (PDT)
:* Good print, J2Cs aren't well supported in bitmap editors yet. -- [[User:Argent Stonecutter|Argent Stonecutter]] 09:14, 22 October 2007 (PDT)
:* In the textures folder is a textures.xml file. This is the mapping {purpose}.tga -> UUID.{any extension} --[[User:Thraxis Epsilon|Thraxis Epsilon]] 11:51, 22 October 2007 (PDT)

I too struggle with the chat history and permission/worn status in inventory, as it's light text on a light background, but I hope you'll correct this by darkening the text. I like dark text on a light background very much... but OTOH I can understand how in a dark environment, you might want the opposite, sort of like the dashboard on your car... can it be made skinnable, so people can have what they prefer? (Changing with time of day or ambient lighting is probably a bit much to ask for, but would be very cool.) --[[User:Melissa Yeuxdoux|Melissa Yeuxdoux]] 16:23, 2 November 2007 (PDT)

=== Similarity to Mac/Aqua ===
Well how novel: ripping off the Mac OS X metallic buttons and giving them an Aqua feel... Well, don't stop there. Read Apple's Human Interface Guidelines and implement them. Then we'll not only have the feel too, but then the whole thing may work as standard instead of being buggy, bloated, roll your own code. We would have international settings and keyboards that worked, standard window behaviour, one menu bar not two, and text editing handling that worked properly, and properly transposed keyboard shorcuts. Get that stuff sorted first then you can think of moving on to skinning.
: I would like to point out, that SecondLife client is Cross-Platform. If they stuck to the Mac guidelines, then it wouldn't fit windows or linux. To be honest, as SecondLife is effectively a game, the interface has to be a roll your own (Read Apples guidelines, it actually says that somewhere) --[[User:Nik Woodget|Nik Woodget]] 02:37, 22 October 2007 (PDT)
:: I don't think it looks Mac-like at all. In fact while Apple popularized the glossy look the "shiny metallic" look isn't really their schtick, and they have been moving away from the aggressive glossiness of the early OS X versions to a smoother and more professional look in Panther and Tiger. -- [[User:Argent Stonecutter|Argent Stonecutter]] 18:02, 22 October 2007 (PDT)
:::I personally wouldn’t complain if they implemented as much of Apple’s HIG as possible. I wouldn’t expect them to get rid of the in-window menubar, but it would be nice if things like keyboard layouts worked properly. —[[User:Frungi Stastny|Frungi Stastny]] 06:53, 23 October 2007 (PDT)

=== Icons ===

The icons representing prims in the object builder are too small. It is quite difficult to distinguish between similar prims as, for example, the cone and the semicone.--[[User:Eadoin Welles|Eadoin Welles]] 10:22, 22 October 2007 (PDT)

I'm not loving it... Although I do like some of the icons but color wise and color balance theme are killing my eyes. The whole "gloss jem" buttons from Window Vista and OS Mac got really really old so fast. For me, I'd like a dark theme. Something more like this theme. [[http://www.wincustomize.com/zoom.aspx?skinid=4617&libid=1]] --[[User:Vincent Nacon|Vincent Nacon]] 12:32, 22 October 2007 (PDT)

I don't think the icons on the map or in other windows should be changed from the standard client unless absolutely necessary... and again I don't think that encapsulating the icons is really a good idea. -- [[User:Argent Stonecutter|Argent Stonecutter]] 18:06, 22 October 2007 (PDT)

I have to say I am underwhelmed by the icon set. Have you considered the [http://en.wikipedia.org/wiki/Tango_Desktop_Project Tango Desktop Project]? The Tango Project seeks to create a consistent graphical user interface experience across applications and platforms. IMHO, the quality of their icon sets is very high. Have a look at the icon sets and [http://tango.freedesktop.org/Tango_Icon_Theme_Guidelines style guidelines on their website]. — [[User:Yuu Nakamichi|Yuu Nakamichi]] 15:21, 2 November 2007 (PDT)

== Additional suggestions ==
This section should be kept for suggestions that are really beyond the scope of a theme change.

=== Multiple Monitor Support ===

Would like more than anything to see the UI windows capable of being moved onto a second monitor off the main viewer window. Now that would be very cool and make life a whole lot easier.
:This would also mean making that the second life viewer would have to use system controls. Again its a pain for cross-platform software. Though not impossible. --[[User:Nik Woodget|Nik Woodget]] 02:38, 22 October 2007 (PDT)
::Why would this require using system controls ?
::[[User:SignpostMarv Martin|SignpostMarv Martin]] 06:59, 22 October 2007 (PDT)
:::The UI in Second Life is part of the OpenGL rendering pipeline. In order for the controls to be seperated from the main window they would have to be contained in seperate OS controls. Maybe not system independent controls, perhaps custom controls rendered into borderless windows might work.
=== Mac Support ===

For the Mac port, at least, the way that command and control are reversed is really hard to deal with. It would be nice if there was an option to reverse the command and control keys ''for XUI only''. -- [[User:Argent Stonecutter|Argent Stonecutter]] 06:07, 22 October 2007 (PDT)

Whilst we're talking about this - can we add a request for a proper implementation of the Mac GUIs, without the irritating internal menus as well please. Swap the menu bar menus the way the GUI guidelines suggest. It's a different code base after all. I may have got used to this structure, but it's one bit of muscle memory I'd be very happy to get rid of! --[[User:Eloise Pasteur|Eloise Pasteur]] 15:56, 22 October 2007 (PDT)

=== Widgets ===

I like the new interface. It is surely better than the black one but, by the way, the real value would be to have a choice of skins which, in my understanding, is the main goal of this test. I think that another improvement might be to have the possibility to add gadgets. For example, I would like to have, close to the PDT time, also the local time, since most of events that I prepare are located in my country, and I prefer to use local time rather than useless PDT time. Rather than adding this feature, which may be of no interest to USA people and surely not at all to California people, you may give us the possibility to create gadgets, like in Google or Vista. So I could develop a small gadget to see time in various timezones, another one that automatically convert Linden dollars to various currencies, and so forth. By facilitating the development of user gadgets, you would dramatically improve the SL interface without having to develop them yourself. IMHO Greetings from Rome, Italy --[[User:Eadoin Welles|Eadoin Welles]] 10:19, 22 October 2007 (PDT)

==== Vector Graphics Widgets ====

Would like to see a flash layer, where flash widgets could communicate to the UI via an API and either replace or partially replace bits and pieces of it. This could be a big market for companies wishing to have customized clients but still take advantage of Linden Labs robust source.
:I would actively NOT want to see a layer that can only be programmed with a closed system like flash. -- [[User:Argent Stonecutter|Argent Stonecutter]] 06:07, 22 October 2007 (PDT)
::SVG + Javascript would work- uBrowser would be the place to start with that.
::[[User:SignpostMarv Martin|SignpostMarv Martin]] 06:59, 22 October 2007 (PDT)
:::That's one approach. Javascript based controls are used in a number of programs: Firefox (XUL), Mac OS (Dashboard), Yahoo Widgets (for that matter Adobe's Actionscript has converged on Javascript). I'm not sure that SVG is the way to go, but that's not an objection... I just don't know wnough about SVG. Another possibility is to use Tk, since that has bindings for several scripting languages already. All this is somewhat out of the scope of a theme change. -- [[User:Argent Stonecutter|Argent Stonecutter]] 08:47, 22 October 2007 (PDT)
::::SVG would provide an "open" system for vector graphics where flash provides a "closed" system.
::::[[User:SignpostMarv Martin|SignpostMarv Martin]] 12:41, 22 October 2007 (PDT)

=== Skin Support ===
I'd like to suggest Hue changer for quick custom theme color for users.... However, for graphic artist like myself, I would like to able customize the skin with ease. Just think more like WinAmp 5. --[[User:Vincent Nacon|Vincent Nacon]] 12:32, 22 October 2007 (PDT)

is also good to make a little program in php for the second life site or a executable for create new skin in more simple way

this is my purple skin :)
[[Image:Dazzle_purple_version.JPG|thumb|300px|Purple Skin]]

--[[User:Aliceinwire Bleac|Aliceinwire Bleac]] 04:56, 7 November 2007 (PST)

* Purple skin made me smile a lot! Thanx for sharing that with Ben and I, Aliceinwire! /me open-secretly hopes for a green-and-pink skin. :D --[[User:Torley Linden|Torley Linden]] 11:26, 7 November 2007 (PST)

===Too Little===
Just looking at the pic...except for the icons, which are probably needed, I'm underwhelmed. It's the same old interface except for being white and shinier (IMO, too shiny), and the consensus among people I know tends torward the opinion that the UI needs to be reinvented, not just polished, and I'd rather see development time being taken on that. Take as an example the work being done by e-Sheep with their new custom client. I'm not saying they've done things that I necescarily want to see but they've got their goals in the right place. I could list a number of UI suggestions and pet peeves but this isn't the place for it...some day I wil actualy get around to putting them on the JIRA. That said, I agree with the people who mentioned skins and even just being able to set UI color preferences from the preferences menu; that by itself would address a lot of issues. [[User:Elle Pollack|Elle Pollack]] 15:00, 22 October 2007 (PDT)

===Enhancement?===
I would love to beable to collect a Landmark while viewing another resident's profile picks. --[[User:Sabina Stenvaag] , 1 nov 2007 (PDT)

== Buttons. ==

The gradient effect on the buttons need to weigh one way or the other. Having the 'line' go right through the text with as much contrast as it has, is distracting, and hard on the eyes.
I would suggest more smoothing to it as well.
Here is a mock up of what I mean. The lower left button is the only one modified.
[[Image:NewViewer_button_mockup.jpg|mock up]]

== what is wrong with light text on dark background? ==

for me, light text on dark background is way more comfortable for my eyes, I find light backgrounds kinda too aggressive :/

why not continue with the dark backgrounds? imitating rl paper on software is kinda lame on my opinion :\ --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 01:08, 13 November 2007 (PST)

User:Dzonatas Sol/AWG Agent/Description

2007-10-22T10:13:17Z

Nik Woodget:

An ''Agent'' is a software resource which represents some portion of a user in the virtual world. Agents are hosted in agent servers. An agent may cause an avatar to be instantiated on behalf of a user.

Agents:

* Mediate the user's message traffic
* Mediate the user's asset inventory
* Act as a focal point for the user's access to services in other domains
* Act as a focal point for the user's access to utilties
* Act to report the user's avatar's location in the Virtual World to other parts of the system

Agents do not:

* Store persistent assets (They are stored in asset servers)

Agents are not:

* The software resource which represents a user's avatar inside a region simulator. (Tho we need a name for that.)

This definition is different from the current (pre agent/region domain split) use of the term agent Second Life. Currently agents are hosted on the simulator where the user's avatar resides, and handle these tasks as well as mediating the avatar's connection to the client. The term agent, in general is overloaded, and is it possible that another, more specific term would be appropriate here.

User:Dzonatas Sol/AWG Agent/Description

2007-10-22T10:13:06Z

Nik Woodget:

Talk:Viewer Visual Update

2007-10-22T09:38:41Z

Nik Woodget:

=== Feedback and Ideas ===

* Would like to see a flash layer, where flash widgets could communicate to the UI via an API and either replace or partially replace bits and pieces of it. This could be a big market for companies wishing to have customized clients but still take advantage of Linden Labs robust source.

* Great work on the graphics! Definitely shows off the potential for what can be done.

* Well how novel: ripping off the Mac OS X metallic buttons and giving them an Aqua feel... Well, don't stop there. Read Apple's Human Interface Guidelines and implement them. Then we'll not only have the feel too, but then the whole thing may work as standard instead of being buggy, bloated, roll your own code. We would have international settings and keyboards that worked, standard window behaviour, one menu bar not two, and text editing handling that worked properly, and properly transposed keyboard shorcuts. Get that stuff sorted first then you can think of moving on to skinning.
** I would like to point out, that SecondLife client is Cross-Platform. If they stuck to the Mac guidelines, then it wouldn't fit windows or linux. To be honest, as SecondLife is effectively a game, the interface has to be a roll your own (Read Apples guidelines, it actually says that somewhere) --[[User:Nik Woodget|Nik Woodget]] 02:37, 22 October 2007 (PDT)

* Would like more than anything to see the UI windows capable of being moved onto a second monitor off the main viewer window. Now that would be very cool and make life a whole lot easier.
** This would also mean making that the second life viewer would have to use system controls. Again its a pain for cross-platform software. Though not impossible. --[[User:Nik Woodget|Nik Woodget]] 02:38, 22 October 2007 (PDT)

Talk:Viewer Visual Update

2007-10-22T09:37:38Z

Nik Woodget:

Viewer Authentication Critique

2007-10-01T12:19:08Z

Nik Woodget:

This is a formal critique of [[Viewer Authentication]] that was [https://lists.secondlife.com/pipermail/sldev/2007-September/005403.html requested] by [[User:Rob Linden]] on the [[SLDev]] mailing list.

For a branch of the discussion see [https://wiki.secondlife.com/wiki/Talk:Viewer_Authentication Talk page on the original proposal.]

== Summary ==

The new authentication method proposed by LL seems to be an attempt to solve a perceived but non-existent problem.

There are currently no known password capturing third party viewers in the wild, and a third party viewer requires such a privilege level of access to an account anyway that if you don't trust it with your username and password, you shouldn't be running it anyway. The mechanism proposed, however, is more prone to phishing attacks. Most password compromises are probably due to weaknesses in the current protocol challenge response, due to allowing weak passwords or due to the usual phishing e-mails (which are likely to be increased by the proposed method rather than decreased).

Providing a single authentication mechanism for LL (and third party) websites would be an improvement to multiple backend copies of username and password, however this could be implemented without touching the viewer authentication method. Support for OpenID and other identity metasystems would increase the flexibility and offer features such as brokered identity verification. However, these would only be part of the solution, and although the proposed mechanism would provide a way for future support of these, there are other ways this could be achieved. Future support for OpenID is perhaps a topic for a seperate discussion and debate, but a open debate on this should happen.

There seems to be no real demand to synchronise the authentication of the viewer with authentication on the SL web site (account, forums, etc.), and any benefits gained would be negated by the problems this would cause anyone running alts (e.g. for in world permissions testing etc.) or multiple viewers (e.g. main, test and firstlook). It also raises problems for those running OpenSim based Grids, and may also cause difficulties further down the line as regards the new architecture discussions.

Overall, the additional development time both with LL and for external developers doesn't seem to warrant the promoted benefits.

It was also noted that consideration should be given when considering enhancements to the security/authentication models whether these should be optional - allowing users to make their own risk/convenience decisions.

== Security ==

=== LL's Objectives ===
* To mitigate the danger of password capturing Trojans masquerading as third party viewers
* Improve trust in third party viewers by providing a means of assurance to the user that the third party viewer could not be a Trojan capturing usernames and passwords.

=== Pros ===
* Viewer does not have to process (and "see") username and password

=== Cons ===
* The main risk of running a third party viewer (or any other application not provided by Linden Labs) is not stealing passwords, it's direct attacks through the client... and the "official" client is not really any protection against that.
** Viewer can still be used in direct and indirect attacks even if it never sees the password (for example: salami slicing through cutout accounts, acting as a cutout account or an in-world botnet, faking a failed connection while giving an attacker access).
** NON-viewer applications (such as editors, 3d tools) designed for use by SL residents could use a keystroke logger and macro to perform any of these attacks, or could inject code into the viewer to do the same thing. Look at 'cheating' programs in combat MMORPGs for ideas.
* But this is still not a large risk, unless people get the client through a mechanism that makes the creator anonymous. Historically, attempts to disseminate boobytrapped versions of applications have only worked in environments where it's routine for people to download applications from anonymous sources (file areas in the BBS era, for example). It's too easy to trace down the originator of any compromised client when you're getting them from their own website.
 
* Bottom line here is that third party viewers stealing passwords are a very small risk for the user: the bigger risk is from the web browser!
** Potential for phishing websites to entice users to enter username and password and then pass control to SL website and viewer.
*** This kind of attack is not theoretical, phishing websites are a criminal industry.
*** It would be very easy to set up a temporary (i.e. hard to trace the real owner) phishing webpage which looks like the official SL logon, and send e-mails such as "You've received xxx in SL, Click here to logon" apparently from LL - with far less work than trying to create, and entice people to download a trojan viewer
** Relies on browser security, and uses a mechanism often disabled or filtered due to security concerns
** Too reliant on browser/OS implementations (proxies, firewalls, used browsers, etc.)
* So using the browser to perform the authentication moves the authentication to a mechanism that has historically proven more likely to be compromised.
 
* And the mechanism itself is relatively inflexible.
** Links to secondlife:// can only point to one instance (version, e.g. homebrew, release candidate official) of the program
** Links to secondlife:// can not pass parameters to the program
*** In fact allowing that was a security flaw recently found and fixed in the SL client. :(
** It will raise problems for those running alternative (e.g. OpenSim) grids, and also have impact on the dicussions for a future open grid.
 
* Possibility some third party clients will retain the existing UI in order to make it easier for people with alts and multiple clients, and do appropriate GETs and POSTs on the SL to initiate a logon and get the token (thus defeating the original purpose)
** The issues raised in the next sections would mean that people would have an incentive to use this kind of client.

=== Alternatives ===
* One time passwords (for copy paste into a non-secure viewer or to print and take with you to friends, internet cafes, public terminals, etc.)
* lower perm passwords (pwds which put the account into a restricted state, disallowing "dangerous" transactions)
* separate passwords for website account and being inworld
* Account restrictions
* Allow third party plug-ins in the viewer (these would allow the extra functionality which are sometimes the reason for running third party viewers, but would rely on the official viewer for validation)
* Do nothing, keep everything as it is.
** Without a strong case for the status quo being a problem, this is certainly a viable alternative, particularly given the impact this will have on developers of third party tools and viewers
** It is arguable that most losses of assets and value are incurred due to SL bugs (inventory, classifieds search, etc.) and outtages rather than through account compromises
 
* This may be the wrong problem - password compromises are more likely to be through standard phishing attacks (logon here to update your account info) which is not addressed, or by weaknesses in the current authentication mechnism or just insecure passwords.
** CRAM-MD5 or a similar challenge-response type
** Dictionary check to reject insecure passwords

== Flexibility ==

=== LL's Objectives ===
* Single Sign On - allowing multiple web applications (forums, support, account, jira, wiki etc.) and viewers to use the same username and password through a single point without duplicating usernames and passwords into multiple systems
* Extension of this to allow non-LL applications and web sites to participate in this single sign on system.

=== Pros ===
* Enables username/password authentication to work on third party sites without them having to "see" username and password

=== Cons ===
* This is really an unrelated issue...
** The client doesn't need to depend on the website for this purpose, or this could be a command line option.
** The client could just as easily be the 'authentication source' as the website.
*** Via a "go to website" link in the client that passed an equivalent token.
 
* As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes

=== Alternatives ===
* Use this mechanism for websites (including third party) only but not for viewers
 
* Identity Metasystem - [http://en.wikipedia.org/wiki/Identity_Metasystem]
** OpenID - [http://openid.net/]
** CardSpace - [http://msdn2.microsoft.com/en-us/netframework/aa663320.aspx]
** Shibboleth - [http://shibboleth.internet2.edu/]
** CAS - [http://www.ja-sig.org/products/cas/]
*** These could be handled by the client poping up a window using the internal web browser to connect to a HTML logon. It may be difficult or impossible to determine if the client really is displaying the official HTML logon and not capturing key strokes so this would be a way of implementing the above for flexibility or other reasons (e.g. brokered identity verification [http://www.agimo.gov.au/publications/2004/05/egovt_challenges/privacy/identity/brokered]) not for security

== Persistence ==

=== LL's Objectives ===
* To synchronise the various LL's systems (forums, support, jira, account, etc.) so that by logging onto one, you are automatically logged onto the others.

=== Pros ===
* Selecting "Account History" or "Manage My Account" and similar menu items would open the web page for the account logged into SL, rather than the account logged into the web site, which currently can be different

=== Cons ===
* As in the previous section, LL's objectives could be met without the viewer logging in via the same mechanism.
* Inconvenient for those with alts or multiple clients
** Cumbersome to change alts and logon with multiple alts
** Those with alts, often have a primary account which is used for forums and logged on permanently to forums even when the alt is online in SL
** As noted in section 1, this reduces flexibility for the *users* which may result in third party viewers adopting the current UI and doing the authentication behind the scenes
* Danger on public or multi-user machines that the user will log out of the client, but not log out of the website properly allowing the next user to access their account.
* Staying online on secondlife.com (which many people seem to do) automatically means anyone with access to the computer/browser (family) can log in with the account inworld
* starting SL from the web browser on a regular basis will most likely result in the web browser lingering in memory in the background when running the viewer, which based on the heavy memory requirement may impair viewer performance.
* this would have an impact on the architecture discussions for a future open grid.

=== Alternatives ===
* As regards menu items such as "Account History", send the account name on the URL, and have the web page check if that is the currently logged on account. If not prompt the user to log on with the same account as being used in the viewer (for security reasons the viewer should not automatically log the account on to the web site in such cases).
* Is this really needed or desirable (''for the client'')? SL is not an extension of the web, it's a different kind of interface... one that has the potential of becoming a "3d web".

== Signatories ==

Please sign this below with "<nowiki>~~~~</nowiki>" if you agree with the version of this document you are reading. The date will indicate which version of the document you read and agree with.

* [[User:Matthew Dowd|Matthew Dowd]] 11:27, 29 September 2007 (PDT)
* [[User:Argent Stonecutter|Argent Stonecutter]] 13:53, 29 September 2007 (PDT)
* [[User:Dale Glass|Dale Glass]] 14:28, 29 September 2007 (PDT)
* [[User:Tillie Ariantho|Tillie Ariantho]] 03:48, 30 September 2007 (PDT)
* [[User:Jesse Barnett|Jesse Barnett]] 9:53, 30 September 2007 (PDT)
* [[User:Winter Ventura|Winter Ventura]] 19:42, 29 September 2007 (PDT)
* [[User:Balp Allen|Balp Allen]] 01:33, 30 September 2007 (PDT)
* [[User:Michelle2 Zenovka|Michelle2 Zenovka]] 02:52, 30 September 2007 (PDT)
* [[User:Nicholaz Beresford|Nicholaz]] 03:42, 30 September 2007 (PDT)
* [[User:Dzonatas Sol|Dzonatas Sol]] 06:54, 30 September 2007 (PDT)
* [[User:Eloise Pasteur|Eloise Pasteur]] 06:57, 30 September 2007 (PDT)
* [[User:Becky Tardis|Becky Tardis]] 08:34, 30 September 2007 (PDT)
* [[User:Peter Newell|Peter Newell]] 14:14, 30 September 2007 (PDT)
* [[User:Dr Scofield|Dr Scofield]] 00:45, 1 October 2007 (PDT)
* [[User:Jabath Steuart|Jabath Steuart]] 04:03, 1 October 2007 (PDT)
* [[User:Nik Woodget|Nik Woodget]] 05:19, 1 October 2007 (PDT)

Brainstorming

2007-09-22T11:13:09Z

Nik Woodget:

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

== Usage examples and requirements ==

=== General architecture ===
* allow to run a small grid on my laptop
* allow plug-ins
* Talk to other online virtual worlds to discuss interconnectivity, at least to some degree. For instance, with one online ID and perhaps registration with each virtual world, residents could inhabit seamlessly Second Life then possibly World of Warcraft or any other virtual world, in the same way online surfers can go from one website to another. In short, let there eventually be one huge interconnected 3d environment, with each world as distinctive as a website on the net.
* Integrate within Second Life a platform to allow residents to create their own virtual world which can then be connected via a personal server to the grid. If this is not entirely possible then create a download so a world can be created offline to be later uploaded to a personal server and then be added to the grid. The development of such software could be a challenge to present to the many resident coders. People with technical knowledge should not be the only ones able to add their own sim to the grid. This should be developed in a way to enable everyone to do so.

===Commerce===

=== Objects and Assets ===
* allow objects to only be allowed to be rezzed on certain regions (adds to the agent's restrictions)
* AND/OR limit object rezzing to specific groups of objects (give region owner ability to control what content is allowed in their regions)
* allow assets to be transferred between agent domains
* allow assets to be accessed from multiple agent domains
* allow truly distributed asset storage
* Think beyond the limitations of prims and sculpties by allowing items made in 3d modelling software to be directly imported onto the grid. Other online virtual 3D environments allow this.

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

=== Viewer ===
* allow all sorts of viewers, from 3D to cellphone to web sites
** Create a viewer with the absolute minimum functionality possible (i.e. core client functions) and then make it optionally extensible based on client capability.
** Allow the client to reassign controls and common functions to a Human Interface Device (gamepad, joystick, customized keyboard, a Bluetooth-connected Wii Remote, etc.)
* Client-side Script runtime
** scriptable chat & movements avatar (bot)
** advanced graphical hud

=== Agents ===
* allow agents to only allow to connect to certain regions

=== Regions ===
* allow regions of arbitrary size and form
* allow portals and landmass-style connections between regions or a mix of both
* region should be able to decide which agents to let in depending on the grade of verification (age, RL identity, financial, ... )
* User defined topology. Like bookmarks, but in 2D. Crossing a custom boundary would result in a "walking teleport"
* Multiple instances of a region within a topology. Everyone can have a front row seat for the show.
* Allow as many avatars as will fit in the virtual space of a region. Don't limit the population of a region based on architectural limitations.

== Implementation thoughts ==
=== Viewer ===
* How does a locally-run, disconnected grid provide texture/animation uploads or anything of use without the centralized system to accept the upload fee, read and update the user's inventory, or receive the new asset information?

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

=== Currency ===
* how will virtual currency be handled in a distributed grid architecture?
** Will LL still support L$ in future, or will it be phased out? (perhaps a virtual currency should have no special place in the grid at all - just as there is no special currency on the web ?)
** L$ exists as "a limited license right" within Second Life and therefore only makes sense within the official grid(s) owned by LL.
*** Privately-owned grids could be responsible for issuing their own licenses, to throttle their clients' use of those private resources.
**** Allowing private grids to issue their own limited license rights for use of their hardware makes it possible to disconnect them from many if not all centralized systems.
**** Such disconnections may allow us to implement a fully localized grid for use on private intranets or on a standalone system.
*** By their nature, private licenses would be mutually incompatible with the official "L$" licenses.
*** Alternative servers (or local grids) with accounts linked to LL servers might be able to purchase L$ to be issued to its members for use on LL servers.
* allow for secure transactions other than in L$ via PayPal, credit cards, etc.
* It is possible to maintain a single payment mechanism across multiple grids in a decentralized way using a social-network credit, or Hawala. Actual payment systems using this method exist (for example Ripple) and allow transparent convertibility between different currencies, some of them also allow transfers from and to Paypal and other online payment systems.

=== Assets ===

* It is possible to implement asset storage in a completely distributed way
** Assets need not be stored in fixed locations (such as in the 'home' grid of the creator, for example)
** A completely Peer-to-Peer (P2P) storage protocol is possible
** To be successful it would have to retain many of the properties of the current 'fixed' storage schemes
*** Available: Since the individual physical storage providers in a P2P network can't be trusted, a great deal of redundancy would be required to make it unlikely an asset would ever become unavailable
*** Secure: Assets would need to be encrypted using strong PKI where appropriate (for example, so you can be sure nobody but the primary key holder (/ capability holder) can view your script source or edit your object). For the same reason, no asset should be stored in-whole at any single physical location (hence requiring the collusion of a large number of parties to even assemble the encrypted form of an asset in order to mount a cryptographic attack, unless the 'directory' of storage addresses for the asset has also been compromised). Obviously this wouldn't apply to the 'public' form of an asset (e.g. script bytecode, pre-optimized object mesh etc.).
*** Persistent: Some mechanism to control the lifetime of assets may be needed
**** Given the pace of storage technology progress, it may be possible to just keep every asset ever created (ride the wave of progress)
**** If limited asset lifetimes are needed, some kind of distributed garbage-collection algorithm could be employed
**** What would happen to assets that remain accessible but never 'accessed' for long periods of time? (We don't want the 'virtual data archaeologists' who research the 22nd century in one thousand years from now to keep running into cases of assets that are no longer available just because a long time has passed without 'access'!)
**** Will it be possible to delete assets/accounts someday?
** This may be a hard problem to solve properly now, but just designing an architecture with it in mind and then implementing something similar to the fixed scheme utilized now would leave the possibility open of implementing the more general case in the future.
*** Lets avoid a repeat of the mistake made in the 'design' of the www, where public pages are often stored on servers owned/leased by their creators and routinely lost for the future (save the efforts of the way-back-machine etc).
* Assets should support being signed (and notarized)
** Perhaps they should even allow arbitrary meta-data to be attached to them by their creators (or anyone with perms) and accessed via scripts
* Assets should be raw data.
** Asset type, permissions, creator, watermark, etc would be meta-data.
** Any kind of meta-data could be added and used or ignored as needed.
* How will a region be able to accept an alien object from another system's inventory, or an inventory to accept an object from a foreign region?
** Would an upload fee make sense for transferring objects to different grids?
** If so, how would that fee be determined for a completed object?
** Would some grids (or domains if you'd prefer) be able to reject items from other domains on a permission basis?

Talk:Brainstorming

2007-09-22T11:04:25Z

Nik Woodget:

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. --[[User:Nik Woodget|Nik Woodget]] 04:01, 22 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. --[[User:Nik Woodget|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.--[[User:Nik Woodget|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. --[[User:Nik Woodget|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.

Prokofy Neva

Talk:Brainstorming

2007-09-22T11:01:47Z

Nik Woodget:

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. --[[User:Nik Woodget|Nik Woodget]] 04:01, 22 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. --[[User:Nik Woodget|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.--[[User:Nik Woodget|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. --[[User:Nik Woodget|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.

Prokofy Neva

Talk:Certified HTTP

2007-09-19T09:28:11Z

Nik Woodget:

==X-Message-ID==

How about replacing the $random_uuid with an MD5 (or stronger) digest of the message body? That would eliminate the undefined result of sending a message with the same message id but a a different body. (Undefined results can be opportunities for exploits.) --[[User:Omei Turnbull|Omei Turnbull]] 20:21, 10 July 2007 (PDT)

:That wouldn't solve the problem, you would still be sending a message with the same message id if you sent two identical messages bodies. You would be guarantying a collision. It is really only an issue if two messages of the same ID are being processed at the same time. I think using $random_uuid is reasonable and in the event of a Message-ID collision or malformed Message-ID have the server return a [http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.1 400]. -- [[User:Strife Onizuka|Strife Onizuka]] 00:01, 11 July 2007 (PDT)

:Heh, looks like Strife and I saw this at the same moment. :-) I guess if you digested the entire state of the message, including headers, receiving url, and sending url/host, then you're only ruling out the case where you do actually want to send two of the exact same message between the same two hosts at the exact same time and have both be processed as independent message. Thanks for the idea! [[User:Which Linden|Which Linden]] 00:06, 11 July 2007 (PDT)

== X-Message-URL ==

:"If the client performs a GET to the message url prior to DELETE, the server must return the same body as the original response, including the X-Message-URL."

I think this may be an attack point, since it would require the server to cache the response body. There should also be a short timeout on the caching. This requirement makes it look like this protocol isn't something you want use with unauthorized clients. -- [[User:Strife Onizuka|Strife Onizuka]] 00:18, 11 July 2007 (PDT)

::How does this differ from the explicit requirement that "the server must persist the response body or have a mechanism to idempotent generate the same response to the same request"? But yes, it seems like the need to persist un-acknowledged response bodies for 15 days creates a big opportunity for a DDOS-type attack if reliable messages from unauthenticated clients are allowed. - [[User:Omei_Turnbull|Omei Turnbull]]

::: That would be a problem if it only statically persisted a complete response. If it has a way to generate the idempotent response at any later time, there is no need to statically persist the complete response. [[User:Dzonatas Sol|Dzonatas Sol]] 10:22, 11 July 2007 (PDT)

:::: The entire response body has to be stored so that if the connection was terminated before the response was received it can be requested by sending a GET to X-Message-URL (instead of a DELETE). -- [[User:Strife Onizuka|Strife Onizuka]] 15:27, 11 July 2007 (PDT)

::::: That would be one way. There are other ways to generate a response that is idempotent. [[User:Dzonatas Sol|Dzonatas Sol]] 15:49, 11 July 2007 (PDT)

:::::: True, but it really depends on what is being requested and whether what is wanted is the old status or the current status. -- [[User:Strife Onizuka|Strife Onizuka]] 16:11, 11 July 2007 (PDT)

::::::: Indeed, it depends on the intervals of when data is aggregated or archived. The complexity begins there. [[User:Dzonatas Sol|Dzonatas Sol]] 16:15, 11 July 2007 (PDT)

::The issue I see (which I think is the same issue Strife was referring to) is that when the server gets a request, it has to check to see whether it is a duplicate of any outstanding request (i.e. a request for which the response hasn't been acknowledged) issued within the last 15 days, so that if it is, it will repeat its previous response. If these requests can come from untrusted clients, the server could purposely be subjected to requests that are not acknowledged, until the server is no longer able to respond to any requests in a timely manner.--[[User:Omei Turnbull|Omei Turnbull]] 12:59, 11 July 2007 (PDT)

:::Thats what I was thinking. -- [[User:Strife Onizuka|Strife Onizuka]] 15:27, 11 July 2007 (PDT)

::This could be mitigated by adding a header field in the client message saying whether this is an initial or a follow-up request. The server would not be required to check initial requests against its history of open requests. Follow-up requests, which would require a lookup against the open requests, could be done at reduced priority, so that they don't interfere with normal traffic.--[[User:Omei Turnbull|Omei Turnbull]] 16:43, 11 July 2007 (PDT)

== Thoughts ==
For a simple setup X-Message-URL could be the original request URL. The DELETE command should send the same X-Message-ID as the orig request to better facilitate this. This would have the added benefit that a client could possibly cancel a request by sending a DELETE before getting a response.
This doesn't have to be all that complicated to implement. Once a request comes in, check to see if there is a DB entry for it, if it does not exist in the DB, execute the command and write the body to file and return the body. If it does exist in the DB already, check the status of the request, if there is a body, return it and wait for the timeout or DELETE command before removing the DB entry. -- [[User:Strife Onizuka|Strife Onizuka]] 15:34, 11 July 2007 (PDT)

== Cleanup ==

Limiting the number of concurrent requests per client is one way of reducing DOS risk but if a client crashes and reconnects then it will need some way of finding out what requests need to be closed. There should probably be some interface the client can query the server to find out what requests it has open. The response to such a query would give URLs to close those requests but they should not be able to return those request's response bodies as that could be a security breach. Additionally those requests returned should be tagged with the session that created them and the status of that session (so multiple sessions can use the same authorization information concurrently). -- [[User:Strife Onizuka|Strife Onizuka]] 16:24, 11 July 2007 (PDT)

:This is a really interesting point. We've given very little thought to communication with untrusted and unreliable clients. Right now, we are assuming that the client is a reliable service itself -- chttp is essentially a peer protocol between durable hosts. In particular, we want to assume delivery, which means that all the application logic doesn't have to contain a lot of failure cases (always a bugbear to write and test). The application just assumes that the message will eventually make it, despite temporary failures on both sending and receiving hosts. With those assumptions, it's reasonable to say that the client doesn't need to query the server to find out what requests it has open. It's not clear if the semantics even mean anything if the client is untrusted or unreliable. [[User:Which Linden|Which Linden]] 22:01, 11 July 2007 (PDT)

::Perhaps there needs to be a way of identifing trusted hosts? Perhaps using HTTP authentication on servers that require identity? and if they can be identified, don't apply a limit to concurrent requests or at least increase the limit? Though this would surely make https as the perfered protocol in such a case, so authentication information is more secure. -- [[User:Nik Woodget|Nik Woodget]] 10:20, 19 September 2007

Talk:Certified HTTP

2007-09-19T09:19:27Z

Nik Woodget:

Talk:Certified HTTP

2007-09-19T09:18:56Z

Nik Woodget:

==X-Message-ID==

How about replacing the $random_uuid with an MD5 (or stronger) digest of the message body? That would eliminate the undefined result of sending a message with the same message id but a a different body. (Undefined results can be opportunities for exploits.) --[[User:Omei Turnbull|Omei Turnbull]] 20:21, 10 July 2007 (PDT)

:That wouldn't solve the problem, you would still be sending a message with the same message id if you sent two identical messages bodies. You would be guarantying a collision. It is really only an issue if two messages of the same ID are being processed at the same time. I think using $random_uuid is reasonable and in the event of a Message-ID collision or malformed Message-ID have the server return a [http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.1 400]. -- [[User:Strife Onizuka|Strife Onizuka]] 00:01, 11 July 2007 (PDT)

:Heh, looks like Strife and I saw this at the same moment. :-) I guess if you digested the entire state of the message, including headers, receiving url, and sending url/host, then you're only ruling out the case where you do actually want to send two of the exact same message between the same two hosts at the exact same time and have both be processed as independent message. Thanks for the idea! [[User:Which Linden|Which Linden]] 00:06, 11 July 2007 (PDT)

== X-Message-URL ==

:"If the client performs a GET to the message url prior to DELETE, the server must return the same body as the original response, including the X-Message-URL."

I think this may be an attack point, since it would require the server to cache the response body. There should also be a short timeout on the caching. This requirement makes it look like this protocol isn't something you want use with unauthorized clients. -- [[User:Strife Onizuka|Strife Onizuka]] 00:18, 11 July 2007 (PDT)

::How does this differ from the explicit requirement that "the server must persist the response body or have a mechanism to idempotent generate the same response to the same request"? But yes, it seems like the need to persist un-acknowledged response bodies for 15 days creates a big opportunity for a DDOS-type attack if reliable messages from unauthenticated clients are allowed. - [[User:Omei_Turnbull|Omei Turnbull]]

::: That would be a problem if it only statically persisted a complete response. If it has a way to generate the idempotent response at any later time, there is no need to statically persist the complete response. [[User:Dzonatas Sol|Dzonatas Sol]] 10:22, 11 July 2007 (PDT)

:::: The entire response body has to be stored so that if the connection was terminated before the response was received it can be requested by sending a GET to X-Message-URL (instead of a DELETE). -- [[User:Strife Onizuka|Strife Onizuka]] 15:27, 11 July 2007 (PDT)

::::: That would be one way. There are other ways to generate a response that is idempotent. [[User:Dzonatas Sol|Dzonatas Sol]] 15:49, 11 July 2007 (PDT)

:::::: True, but it really depends on what is being requested and whether what is wanted is the old status or the current status. -- [[User:Strife Onizuka|Strife Onizuka]] 16:11, 11 July 2007 (PDT)

::::::: Indeed, it depends on the intervals of when data is aggregated or archived. The complexity begins there. [[User:Dzonatas Sol|Dzonatas Sol]] 16:15, 11 July 2007 (PDT)

::The issue I see (which I think is the same issue Strife was referring to) is that when the server gets a request, it has to check to see whether it is a duplicate of any outstanding request (i.e. a request for which the response hasn't been acknowledged) issued within the last 15 days, so that if it is, it will repeat its previous response. If these requests can come from untrusted clients, the server could purposely be subjected to requests that are not acknowledged, until the server is no longer able to respond to any requests in a timely manner.--[[User:Omei Turnbull|Omei Turnbull]] 12:59, 11 July 2007 (PDT)

:::Thats what I was thinking. -- [[User:Strife Onizuka|Strife Onizuka]] 15:27, 11 July 2007 (PDT)

::This could be mitigated by adding a header field in the client message saying whether this is an initial or a follow-up request. The server would not be required to check initial requests against its history of open requests. Follow-up requests, which would require a lookup against the open requests, could be done at reduced priority, so that they don't interfere with normal traffic.--[[User:Omei Turnbull|Omei Turnbull]] 16:43, 11 July 2007 (PDT)

== Thoughts ==
For a simple setup X-Message-URL could be the original request URL. The DELETE command should send the same X-Message-ID as the orig request to better facilitate this. This would have the added benefit that a client could possibly cancel a request by sending a DELETE before getting a response.
This doesn't have to be all that complicated to implement. Once a request comes in, check to see if there is a DB entry for it, if it does not exist in the DB, execute the command and write the body to file and return the body. If it does exist in the DB already, check the status of the request, if there is a body, return it and wait for the timeout or DELETE command before removing the DB entry. -- [[User:Strife Onizuka|Strife Onizuka]] 15:34, 11 July 2007 (PDT)

== Cleanup ==

Limiting the number of concurrent requests per client is one way of reducing DOS risk but if a client crashes and reconnects then it will need some way of finding out what requests need to be closed. There should probably be some interface the client can query the server to find out what requests it has open. The response to such a query would give URLs to close those requests but they should not be able to return those request's response bodies as that could be a security breach. Additionally those requests returned should be tagged with the session that created them and the status of that session (so multiple sessions can use the same authorization information concurrently). -- [[User:Strife Onizuka|Strife Onizuka]] 16:24, 11 July 2007 (PDT)

:This is a really interesting point. We've given very little thought to communication with untrusted and unreliable clients. Right now, we are assuming that the client is a reliable service itself -- chttp is essentially a peer protocol between durable hosts. In particular, we want to assume delivery, which means that all the application logic doesn't have to contain a lot of failure cases (always a bugbear to write and test). The application just assumes that the message will eventually make it, despite temporary failures on both sending and receiving hosts. With those assumptions, it's reasonable to say that the client doesn't need to query the server to find out what requests it has open. It's not clear if the semantics even mean anything if the client is untrusted or unreliable. [[User:Which Linden|Which Linden]] 22:01, 11 July 2007 (PDT)

::Perhaps there needs to be a way of identifing trusted hosts? Perhaps using HTTP authentication on servers that require identity?
and if they can be identified, don't apply a limit to concurrent requests or at least increase the limit? Though this would surely make https as the perfered protocol in such a case, so authentication information is more secure. -- [[User::Nik Woodget|Nik Woodget]] 10:20, 19 September 2007

User:Nik Woodget

2007-09-07T08:19:27Z

Nik Woodget: New page: Works for a document life cycle solutions provider as a developer in c#. Works with C++ in his spare time. Though has yet to do anything on the Second Life Viewer

Works for a document life cycle solutions provider as a developer in c#. Works with C++ in his spare time. Though has yet to do anything on the Second Life Viewer

SLDev Resident Names

2007-09-07T08:17:44Z

Nik Woodget:

[[SLDev]] > '''SLDev Resident Names'''

This page is (or will hopefully be) a decoder ring for people to figure out who's who on the [[SLDev]] mailing list.

If you post messages to the SLDev mailing list under a different name than your Second Life Resident name, please note it here. (Tip: putting three tildes, e.g. "<nowiki>~~~</nowiki>", will automatically convert to your name and a link to your username on this wiki) :

{|border="1" cellpadding="2" class=sortable
|-
!| SLDev Posting Name
!| Second Life Resident Name
|-
| Rob Lanphier || [[User:Rob Linden|Rob Linden]]
|-
| Harold "LabRat" Brown || [[User:Thraxis Epsilon|Thraxis Epsilon]]
|-
| Laurent Laborde || [[User:Kerunix Flan|Kerunix Flan]]
|-
| Lawson English || [[User:Saijanai Kuhn|Saijanai Kuhn]]
|-
| Callum Lerwick || [[User:Seg Baphomet|Seg Baphomet]]
|-
| Matt Kimmel || [[User:Feep Larsson|Feep Larsson]]
|-
| Dirk Moerenhout || [[User:Blakar Ogre|Blakar Ogre]]
|-
| Nik Radford || [[User:Nik Woodget|Nik Woodget]]
|}

Talk:Hegemons Login Analysis

2007-07-24T15:57:18Z

Nik Woodget: Removing all content from page

Talk:Hegemons Login Analysis

2007-07-24T15:38:28Z

Nik Woodget:

Harrah for those with inquisitive minds.

Certainly an interesting read.

Even though you don't want to rely on the SL Viewer source to see how things work, it may make understanding easier. You can, if you don't know already, then send an XML-RPC calls to the real servers with valid data in order to find out what the valid response is. Or, just look in viewer code.

Just a suggestion though.

Nik Woodget

----

Talk:Hegemons Login Analysis

2007-07-24T15:38:09Z

Nik Woodget: New page: Harrah for those with inquisitive minds. Certainly an interesting read. Even though you don't want to rely on the SL Viewer source to see how things work, it may make understanding easie...