Second Life Wiki - User contributions [en]

User:Nyx Linden/Office Hours Agenda

Teravus Ousley — Wed, 20 Oct 2010 18:58:31 GMT

Teravus Ousley:

==Nyx Linden's Office Hours Agenda==

Office hours are on Wednesdays at Noon in Pacific time (SL standard time) located in Borrowdale at: http://slurl.com/secondlife/Borrowdale/74/217/32

Topics are focused on avatars, content creation efficiency, content creation tools and methods, rendering issues, and many related random topics.

Please add topics for discussion / agenda items to the end of the list below prior to 11:50 AM. Priority will be given to topics that are posted in advance and are relevant to the goals of the office hour. Feel free to include relevant links to JIRA or wiki pages. Contact Nyx Linden if you are unsure if your topic is relevant or appropriate.

Archived agendas can be found at the [[User:Nyx_Linden/Office_Hours_Agenda_Archive|agenda archive]].

Next meeting scheduled for: October 20, 2010.

===Agenda===

== October 20, 2010 ==
# updates!
## mesh viewer source code
## mesh project JIRA category
# Other Uses for UploadObjectAsset
# Your Topic Here!

Mesh Project Viewer FAQ

Teravus Ousley — Fri, 15 Oct 2010 15:08:01 GMT

Teravus Ousley: /* Modifying LINK with the actual link */

{{Navbox/Mesh_QSG}}

'''Mesh First Look Frequently Asked Questions'''

=General=
==Does it cost anything to participate in the SL Mesh Open Beta program?==
No, the Open Beta program is free, including the uploading of meshes themselves. We are exploring different pricing models that will be introduced when the product is formally launched.

==Do I have to learn Viewer 2 to use mesh?==
The mesh feature will initially be available in Viewer 2.x and in future Viewer 2 versions; viewers without mesh support will be unable to display mesh content. Linden Lab has no plans to integrate it into Viewer 1.23.

Third party viewers may also choose to add mesh support.

==What will I see if I use a Viewer that doesn't support mesh?==
Here is a scene filled with mesh objects, as rendered by Viewer 2:
[[File:Mesh_001.png|600px]]

Here is the same scene, as rendered by a viewer that does not support mesh:
[[File:Meshes_001.png|600px]]

==Can I use the mesh-enabled Viewer 2 on the main grid?==
Yes. But, mesh functionality will not work on the main grid. Regions need to be mesh-enabled in order to support the uploading and rezzing of meshes. Currently, the mesh regions on Aditi are the only ones enabled with this functionality. Additionally, inventory and L$ changes on Aditi will not carry over onto the main grid.

==Is the mesh-enabled Viewer 2 stable?==
The mesh-enabled Viewer 2 is tracking the viewer-public branch so all of the changes made in our public open source branch--which comprise most of the development slated for Viewer 2.x--are incorporated into our mesh-enabled Viewer codebase frequently. You will be notified at login when new mesh-enabled Viewers are available. Please keep in mind that this is still an experimental Viewer with a great deal of new functionality, so you may experience higher than normal crash rates.

==Will mesh be ported to third party viewers? If so, when?==
Yes, SL Mesh will be available in our open source code base soon. We do not have a specific date yet, but we'll update you when it's available.

At that time third party viewers may integrate the new source into their release.

==How will permission systems work with meshes?==
Meshes have exactly the same permissions system as sculpted prims and textures.

==Will SL Mesh create a disadvantage for prim/sculpty builders? Will it upset the economy?==

Maybe. The future is hard to predict. Mesh is the next generation of building technologies available in Second Life and offers content creators new ways to quickly create virtual goods and objects in Second Life, greatly enhancing the inworld experience for all Residents and opening up new opportunities to create highly marketable, quality items

==Will the existing content tools in the viewer go away?==
Absolutely not! As with flexiprims and sculpties, meshes will be added to the growing set of building tools already available in SL. Our goal is always to expand the capability to create compelling experiences in SL. By adding new options like meshes to our builders' tool sets, we're enabling the next generation of content creation while still supporting the classic tools that have existed.

==Will mesh be available in other languages?==
Today, the SL Mesh Open Beta program is only available in English. When the product is released, it will be available in the standard languages in which we deliver Viewer 2.

=Open Beta Program=

==What do you expect us to do in this Open Beta?==
One SL Mesh Open Beta goal is to test many disparate types of COLLADA files and see how they each behave inworld. We know there are many different applications and modeling techniques out there, and we want to ensure that we can correctly support as many as possible. So, we invite you to stress test the regions with large and complex content and to try "unconventional" models so that we can understand feature constraints and limits. If you run into problems, or potential bugs, then definitely file a [http://jira.secondlife.com/browse/cts jira] and attach the mesh.

==How long will the SL Mesh Open Beta last?==
The SL Mesh Open Beta dates are not set yet. We anticipate it will be at least several weeks, to enable everyone the chance to become familiar with this new form of content creation before it is generally available to all Second Life Residents on the main grid.

==What will I see on the mesh-enabled regions of Aditi?==
The regions will be mostly empty at first, but we're counting on you to help fill them up! We've created 40 regions on our test grid, called Aditi, to help guide you by interest and skill set. Beyond that, we're not placing too many restrictions at first. We want to see what your creativity will produce! See the [[Mesh/MeshRegions|region list]] for information on the themes and features of each area.

=Intellectual Property and Mesh=

==Do I retain intellectual property rights of the meshes that I create?==
Yes, under the [http://secondlife.com/corporate/tos.php#tos7 Second Life Terms of Service], you retain any intellectual property rights you have in the meshes and other content that you import into Second Life. It's important to remember that you're responsible for knowing your intellectual property rights, and if you're importing meshes or other content to Second Life, you must have all the necessary rights and permissions.

==How can I protect my intellectual property in my meshes?==
As we announced in our [http://blogs.secondlife.com/community/community/blog/2009/08/04/our-content-management-roadmap Content Management Roadmap blog post], we are committed to empowering content creators to better manage and control their content.

Mesh intellectual property rights must be respected during the Mesh First Look program. If we believe that any participant in the program is abusing intellectual property, then we may suspend the Resident from the program and, in egregious cases, from Second Life altogether.

Although meshes will be limited to our test grid during the First Look program, the protections of the [http://secondlife.com/corporate/tos.php Second Life Terms of Service], our [http://wiki.secondlife.com/wiki/Intellectual_Property Intellectual Property Policy], and [http://secondlife.com/corporate/tpv.php Policy on Third-Party Viewers] will apply to meshes. If content creators believe their meshes are being infringed, they may submit intellectual property complaints to Linden Lab requesting removal of the content at issue as provided in our [http://wiki.secondlife.com/wiki/Intellectual_Property Intellectual Property Policy]. We are currently testing some early improvements to our [http://blogs.secondlife.com/community/community/blog/2009/12/09/testing-improvements-to-our-intellectual-property-complaint-process intellectual property complaint process]. Stay tuned for more content management announcements as we have them.

==What if I download or purchase meshes from a service such as Google 3D Warehouse or Turbosquid? Can I use those in Second Life?==
Every mesh you acquire from these and other sites is subject to its creator/vendor's particular license terms, and must be adhered to as such. Every individual Turbosquid model contains a license link on its main page, and Turbosquid's general Licensing Terms and FAQ can be found [https://turbosquid.custhelp.com/cgi-bin/turbosquid.cfg/php/enduser/std_adp.php?p_faqid=329 here]. Google's 3D Warehouse Terms of Service can be found [http://sketchup.google.com/intl/en/3dwh/tos.html here]. If any meshes violate either the original creator/vendor's license terms, or Second Life's Terms of Service and Policies, then we will handle the matter as previously mentioned.

=Performance and Stability=

==Will regions be stable? Will I be able to access them immediately?==
We've created 40 regions to allow many residents to test out meshes concurrently. Because we expect this to be a popular feature, and given that it's running on our test grid, you may experience some bumps and downtime at the beginning. We'll monitor the regions closely and place announcements on our [http://blogs.secondlife.com/community/forums/mesh forums] about grid status. We may increase the number of regions, if needed.

==Will meshes introduce more lag when they debut on the main grid?==
Meshes have several advantages over prims and sculpties when it comes to rendering efficiency and quality. First, you need far fewer triangles using mesh vs. prims resulting in higher quality and faster rezzing times. For example, we've found that a very high quality character model took only 15,000 triangles using a mesh, while a far inferior version took 250,000 triangles using prims! Additionally, meshes generally have topology that highly optimized for real time rendering, when compared to prims or scuplties, and the result is much faster rendering speeds. However, meshes are a new asset type for the viewer to download and some may require higher bandwidth usage, potentially longer load times, and potentially higher physics loads on the sims. This is why we're carrying out such an extensive First Look program.

Physics simulation is something that we will also be watching very closely, especially in light of our new Havok 7 '''[[Havok_7_Beta_Home]]''' implementation, that should substantially optimize mesh collision calculations. Regarding heavier bandwidth and longer load times, we will track bandwidth usage and, if necessary, work to make the streaming mesh format as size-optimal as possible and/or impose stricter quotas on the number of meshes that a region can efficiently support.

==Is there a scale limit to mesh files that can be imported into SL?==
At the start of the Open Beta, the default prim scale limit will be 64m. As testing continues and we gather data, we will settle on a size that can easily facilitate your creativity while still ensuring region stability.

==Is there a file size limit to mesh files that can be imported into SL?==
Yes. The maximum mesh asset size after compression is 8MB, roughly equivalent to a 256MB raw COLLADA file. An entire region can support up to 128MB of distinct mesh assets after compression, not including attachments. The size of attached mesh assets is effectively unlimited, but there's no guarantee that all of your attachments will be downloaded by other viewers.

==How are meshes stored in SL?==
Meshes are stored the same way as all other Second Life assets (textures, scripts, etc.). The mesh asset data is stored as a custom mesh format based on gzip and LLSD.

[[Category:Mesh]]

EventQueueGet

Teravus Ousley — Thu, 16 Oct 2008 06:08:46 GMT

Teravus Ousley: /* TeleportFinish */

The EventQueueGet cap is actually a service. The CAP provides access to the service.
Currently if the client cannot get an EventQueueGet cap, it will refuse to show neighbor regions and you will not be able to teleport to another region. You're essentially trapped where you are.

It's also very easy for the client to stop polling the EventQueueGet CAP

The Client essentially sends an application/xml Map with two keys. ack and done. Ack is an integer of the last Event ID and done is.. well, we don't know what done is yet besides it's a boolean. At this moment, it's always false.

The simulator will hold on to this request until it has some events to send to the client or the simulator times out the connection with a very specific response. The simulator will usually do this in around 20 to 30 seconds from the request start. To understand this, think in terms of requesting a web page that does a lot of background processing before sending you back a response. If you were to be able to post to the EventQueueGet Cap in a browser, it would look like a white page loading for about 20 or 30 seconds, and then it would give you back a 502 error. Don't fret! the 502 error is normal! When the EventQueueGet service doesn't have any events to send to the client, it typically sends a 'HTTP/1.0 502 Upstream error:' response with 'Upstream error: ' as the body. It's really important to note that the client will *only* accept a response like stated above. If you send it as a HTTP/1.1 response, the client will stop polling!

After the client closes the connection to the simulator (with a DisableSimulator packet), further attempts to poll the EventQueueGet cap will result in a 404 response. This tells the client to stop polling the cap. On the Debug Console, you'll see a nice message paraphrased: EventPollResponder: {1} https://CAPADDRESS/ stop 404

The client will keep polling the EventQueueGet cap until you give it a 404 even after you've left the region!

The client posts to the EventQueueGet cap provided in the region seed cap with an application/xml content type. (this will eventually be application/llsd+xml)

Client Request ->
{
ack : integer,
done : boolean
}

; Successful response (no events) <-
HTTP/1.0 502 Upstream error:
Content-Type: text/plain
Connection: close

Upstream error:

; Successful Response (event) <-
{
events : [ event ],
id : integer
}

There are a few events that OpenSimulator has implemented over the EventQueueGet cap.
So far they're;
* EnableSimulator
* CrossedRegion
* TeleportFinish

===EnableSimulator===
EnableSimulator is the event that tells the client to connect to a new simulator. We use it to inform clients that there is a neighbor region to the one that the avatar is currently in. This causes the client to attempt to connect to the region described in the EnableSimulator event.

{
body : {
SimulatorInfo : [
{
Handle : binary
IP : binary
Port : integer
}
]
},
message : 'EnableSimulator'
}

Remember, Handle is the regionhandle of the new simulator in BIG Endian format, base64 encoded.
IP is the IP Address of the new simulator as a byte array, base64 encoded.
Port is the UDP port of the new simulator UDP service.

Note:
The IP address (24.151.1.250) contains 4 bytes:
24
151
1
250

The regionhandle is a 64 bit representation of the X and Y cordinate of the 0,0 point of the new simulator
Where x is the uint X coordinate, and y is the uint Y coordinate, the formula for creating a regionhandle is:
ulong regionhandle = ((ulong)x << 32) | (ulong)y;

===CrossedRegion===
The simulator uses CrossedRegion to inform your client that it has crossed into a new region. Typically this is sent out when an avatar crosses a border between two simulators.

{
body : {
CrossedRegion : [
{
AgentData : [
{
AgentID : UUID,
SessionID : UUID
}
],
RegionData : [
{
RegionHandle : binary,
SeedCapability : string,
SimIP : binary,
SimPort : integer
}
],
Info : [
{
LookAt : [ real, real, real ],
Position : [ real, real, real ]
}
]
}
]
},
message : 'EnableSimulator'
}

===TeleportFinish===
This tells the client that the serverside processing for teleport is complete and that the client should begin the client side portion of the teleport.
{
body : {
Info : [
{
AgentID : UUID,
LocationID : integer,
RegionHandle : binary,
SeedCapability : string,
SimAccess : integer,
SimIP : binary,
SimPort : integer,
TeleportFlags : binary
}
]
},
message : 'TeleportFinish'
}

You can find additional information on : [http://www.libsecondlife.org/wiki/EventQueueGet a page from lisecondlife.org].

EventQueueGet

Teravus Ousley — Thu, 16 Oct 2008 06:08:11 GMT

Teravus Ousley: /* CrossedRegion */

The EventQueueGet cap is actually a service. The CAP provides access to the service.
Currently if the client cannot get an EventQueueGet cap, it will refuse to show neighbor regions and you will not be able to teleport to another region. You're essentially trapped where you are.

It's also very easy for the client to stop polling the EventQueueGet CAP

The Client essentially sends an application/xml Map with two keys. ack and done. Ack is an integer of the last Event ID and done is.. well, we don't know what done is yet besides it's a boolean. At this moment, it's always false.

The simulator will hold on to this request until it has some events to send to the client or the simulator times out the connection with a very specific response. The simulator will usually do this in around 20 to 30 seconds from the request start. To understand this, think in terms of requesting a web page that does a lot of background processing before sending you back a response. If you were to be able to post to the EventQueueGet Cap in a browser, it would look like a white page loading for about 20 or 30 seconds, and then it would give you back a 502 error. Don't fret! the 502 error is normal! When the EventQueueGet service doesn't have any events to send to the client, it typically sends a 'HTTP/1.0 502 Upstream error:' response with 'Upstream error: ' as the body. It's really important to note that the client will *only* accept a response like stated above. If you send it as a HTTP/1.1 response, the client will stop polling!

After the client closes the connection to the simulator (with a DisableSimulator packet), further attempts to poll the EventQueueGet cap will result in a 404 response. This tells the client to stop polling the cap. On the Debug Console, you'll see a nice message paraphrased: EventPollResponder: {1} https://CAPADDRESS/ stop 404

The client will keep polling the EventQueueGet cap until you give it a 404 even after you've left the region!

The client posts to the EventQueueGet cap provided in the region seed cap with an application/xml content type. (this will eventually be application/llsd+xml)

Client Request ->
{
ack : integer,
done : boolean
}

; Successful response (no events) <-
HTTP/1.0 502 Upstream error:
Content-Type: text/plain
Connection: close

Upstream error:

; Successful Response (event) <-
{
events : [ event ],
id : integer
}

There are a few events that OpenSimulator has implemented over the EventQueueGet cap.
So far they're;
* EnableSimulator
* CrossedRegion
* TeleportFinish

===EnableSimulator===
EnableSimulator is the event that tells the client to connect to a new simulator. We use it to inform clients that there is a neighbor region to the one that the avatar is currently in. This causes the client to attempt to connect to the region described in the EnableSimulator event.

{
body : {
SimulatorInfo : [
{
Handle : binary
IP : binary
Port : integer
}
]
},
message : 'EnableSimulator'
}

Remember, Handle is the regionhandle of the new simulator in BIG Endian format, base64 encoded.
IP is the IP Address of the new simulator as a byte array, base64 encoded.
Port is the UDP port of the new simulator UDP service.

Note:
The IP address (24.151.1.250) contains 4 bytes:
24
151
1
250

The regionhandle is a 64 bit representation of the X and Y cordinate of the 0,0 point of the new simulator
Where x is the uint X coordinate, and y is the uint Y coordinate, the formula for creating a regionhandle is:
ulong regionhandle = ((ulong)x << 32) | (ulong)y;

===CrossedRegion===
The simulator uses CrossedRegion to inform your client that it has crossed into a new region. Typically this is sent out when an avatar crosses a border between two simulators.

{
body : {
CrossedRegion : [
{
AgentData : [
{
AgentID : UUID,
SessionID : UUID
}
],
RegionData : [
{
RegionHandle : binary,
SeedCapability : string,
SimIP : binary,
SimPort : integer
}
],
Info : [
{
LookAt : [ real, real, real ],
Position : [ real, real, real ]
}
]
}
]
},
message : 'EnableSimulator'
}

===TeleportFinish===
This tells the client that the serverside processing for teleport is complete and that the client should begin the client side portion of the teleport.
{
body : {
Info : [
AgentID : UUID,
LocationID : integer,
RegionHandle : binary,
SeedCapability : string,
SimAccess : integer,
SimIP : binary,
SimPort : integer,
TeleportFlags : binary
]
},
message : 'TeleportFinish'
}

You can find additional information on : [http://www.libsecondlife.org/wiki/EventQueueGet a page from lisecondlife.org].

EventQueueGet

Teravus Ousley — Thu, 16 Oct 2008 05:52:40 GMT

Teravus Ousley:

The EventQueueGet cap is actually a service. The CAP provides access to the service.
Currently if the client cannot get an EventQueueGet cap, it will refuse to show neighbor regions and you will not be able to teleport to another region. You're essentially trapped where you are.

It's also very easy for the client to stop polling the EventQueueGet CAP

The Client essentially sends an application/xml Map with two keys. ack and done. Ack is an integer of the last Event ID and done is.. well, we don't know what done is yet besides it's a boolean. At this moment, it's always false.

The simulator will hold on to this request until it has some events to send to the client or the simulator times out the connection with a very specific response. The simulator will usually do this in around 20 to 30 seconds from the request start. To understand this, think in terms of requesting a web page that does a lot of background processing before sending you back a response. If you were to be able to post to the EventQueueGet Cap in a browser, it would look like a white page loading for about 20 or 30 seconds, and then it would give you back a 502 error. Don't fret! the 502 error is normal! When the EventQueueGet service doesn't have any events to send to the client, it typically sends a 'HTTP/1.0 502 Upstream error:' response with 'Upstream error: ' as the body. It's really important to note that the client will *only* accept a response like stated above. If you send it as a HTTP/1.1 response, the client will stop polling!

After the client closes the connection to the simulator (with a DisableSimulator packet), further attempts to poll the EventQueueGet cap will result in a 404 response. This tells the client to stop polling the cap. On the Debug Console, you'll see a nice message paraphrased: EventPollResponder: {1} https://CAPADDRESS/ stop 404

The client will keep polling the EventQueueGet cap until you give it a 404 even after you've left the region!

The client posts to the EventQueueGet cap provided in the region seed cap with an application/xml content type. (this will eventually be application/llsd+xml)

Client Request ->
{
ack : integer,
done : boolean
}

; Successful response (no events) <-
HTTP/1.0 502 Upstream error:
Content-Type: text/plain
Connection: close

Upstream error:

; Successful Response (event) <-
{
events : [ event ],
id : integer
}

There are a few events that OpenSimulator has implemented over the EventQueueGet cap.
So far they're;
* EnableSimulator
* CrossedRegion
* TeleportFinish

===EnableSimulator===
EnableSimulator is the event that tells the client to connect to a new simulator. We use it to inform clients that there is a neighbor region to the one that the avatar is currently in. This causes the client to attempt to connect to the region described in the EnableSimulator event.

{
body : {
SimulatorInfo : [
{
Handle : binary
IP : binary
Port : integer
}
]
},
message : 'EnableSimulator'
}

Remember, Handle is the regionhandle of the new simulator in BIG Endian format, base64 encoded.
IP is the IP Address of the new simulator as a byte array, base64 encoded.
Port is the UDP port of the new simulator UDP service.

Note:
The IP address (24.151.1.250) contains 4 bytes:
24
151
1
250

The regionhandle is a 64 bit representation of the X and Y cordinate of the 0,0 point of the new simulator
Where x is the uint X coordinate, and y is the uint Y coordinate, the formula for creating a regionhandle is:
ulong regionhandle = ((ulong)x << 32) | (ulong)y;

===CrossedRegion===
The simulator uses CrossedRegion to inform your client that it has crossed into a new region. Typically this is sent out when an avatar crosses a border between two simulators.

{
body : {
CrossedRegion : [
AgentData : [
{
AgentID : UUID,
SessionID : UUID
}
],
RegionData : [
{
RegionHandle : binary,
SeedCapability : string,
SimIP : binary,
SimPort : integer
}
],
Info : [
{
LookAt : [ real, real, real ],
Position : [ real, real, real ]
}
]
]
},
message : 'EnableSimulator'
}

===TeleportFinish===
This tells the client that the serverside processing for teleport is complete and that the client should begin the client side portion of the teleport.
{
body : {
Info : [
AgentID : UUID,
LocationID : integer,
RegionHandle : binary,
SeedCapability : string,
SimAccess : integer,
SimIP : binary,
SimPort : integer,
TeleportFlags : binary
]
},
message : 'TeleportFinish'
}

You can find additional information on : [http://www.libsecondlife.org/wiki/EventQueueGet a page from lisecondlife.org].

EventQueueGet

Teravus Ousley — Thu, 16 Oct 2008 05:50:10 GMT

Teravus Ousley:

The EventQueueGet cap is actually a service. The CAP provides access to the service.
Currently if the client cannot get an EventQueueGet cap, it will refuse to show neighbor regions and you will not be able to teleport to another region. You're essentially trapped where you are.

It's also very easy for the client to stop polling the EventQueueGet CAP

The Client essentially sends an application/xml Map with two keys. ack and done. Ack is an integer of the last Event ID and done is.. well, we don't know what done is yet besides it's a boolean. At this moment, it's always false.

The simulator will hold on to this request until it has some events to send to the client or the simulator times out the connection with a very specific response. The simulator will usually do this in around 20 to 30 seconds from the request start. To understand this, think in terms of requesting a web page that does a lot of background processing before sending you back a response. If you were to be able to post to the EventQueueGet Cap in a browser, it would look like a white page loading for about 20 or 30 seconds, and then it would give you back a 502 error. Don't fret! the 502 error is normal! When the EventQueueGet service doesn't have any events to send to the client, it typically sends a 'HTTP/1.0 502 Upstream error:' response with 'Upstream error: ' as the body. It's really important to note that the client will *only* accept a response like stated above. If you send it as a HTTP/1.1 response, the client will stop polling!

After the client closes the connection to the simulator (with a DisableSimulator packet), further attempts to poll the EventQueueGet cap will result in a 404 response. This tells the client to stop polling the cap. On the Debug Console, you'll see a nice message paraphrased: EventPollResponder: {1} https://CAPADDRESS/ stop 404

The client will keep polling the EventQueueGet cap until you give it a 404 even after you've left the region!

The client posts to the EventQueueGet cap provided in the region seed cap with an application/xml content type. (this will eventually be application/llsd+xml)

Client Request ->
{
ack : integer,
done : boolean
}

; Successful response (no events) <-
HTTP/1.0 502 Upstream error:
Content-Type: text/plain
Connection: close

Upstream error:

; Successful Response (event) <-
{
events : [ event ],
id : integer
}

There are a few events that OpenSimulator has implemented over the EventQueueGet cap.
So far they're;
* EnableSimulator
* CrossedRegion
* TeleportFinish

===EnableSimulator===
EnableSimulator is the event that tells the client to connect to a new simulator. We use it to inform clients that there is a neighbor region to the one that the avatar is currently in. This causes the client to attempt to connect to the region described in the EnableSimulator event.

{
body : {
SimulatorInfo : [
{
Handle : binary
IP : binary
Port : integer
}
],
message : 'EnableSimulator'
}

Remember, Handle is the regionhandle of the new simulator in BIG Endian format, base64 encoded.
IP is the IP Address of the new simulator as a byte array, base64 encoded.
Port is the UDP port of the new simulator UDP service.

Note:
The IP address (24.151.1.250) contains 4 bytes:
24
151
1
250

The regionhandle is a 64 bit representation of the X and Y cordinate of the 0,0 point of the new simulator
Where x is the uint X coordinate, and y is the uint Y coordinate, the formula for creating a regionhandle is:
ulong regionhandle = ((ulong)x << 32) | (ulong)y;

===CrossedRegion===
The simulator uses CrossedRegion to inform your client that it has crossed into a new region. Typically this is sent out when an avatar crosses a border between two simulators.

{
body : {
CrossedRegion : [
AgentData : [
{
AgentID : UUID,
SessionID : UUID
}
],
RegionData : [
{
RegionHandle : binary,
SeedCapability : string,
SimIP : binary,
SimPort : integer
}
],
Info : [
{
LookAt : [ real, real, real ],
Position : [ real, real, real ]
}
]
]
},
message : 'EnableSimulator'
}

===TeleportFinish===
This tells the client that the serverside processing for teleport is complete and that the client should begin the client side portion of the teleport.
{
body : {
Info : [
AgentID : UUID,
LocationID : integer,
RegionHandle : binary,
SeedCapability : string,
SimAccess : integer,
SimIP : binary,
SimPort : integer,
TeleportFlags : binary
]
},
message : 'TeleportFinish'
}

You can find additional information on : [http://www.libsecondlife.org/wiki/EventQueueGet a page from lisecondlife.org].

EventQueueGet

Teravus Ousley — Thu, 16 Oct 2008 05:37:13 GMT

Teravus Ousley:

The EventQueueGet cap is actually a service. The CAP provides access to the service.
Currently if the client cannot get an EventQueueGet cap, it will refuse to show neighbor regions and you will not be able to teleport to another region. You're essentially trapped where you are.

It's also very easy for the client to stop polling the EventQueueGet CAP

The Client essentially sends an application/xml Map with two keys. ack and done. Ack is an integer of the last Event ID and done is.. well, we don't know what done is yet besides it's a boolean. At this moment, it's always false.

The simulator will hold on to this request until it has some events to send to the client or the simulator times out the connection with a very specific response. The simulator will usually do this in around 20 to 30 seconds from the request start. To understand this, think in terms of requesting a web page that does a lot of background processing before sending you back a response. If you were to be able to post to the EventQueueGet Cap in a browser, it would look like a white page loading for about 20 or 30 seconds, and then it would give you back a 502 error. Don't fret! the 502 error is normal! When the EventQueueGet service doesn't have any events to send to the client, it typically sends a 'HTTP/1.0 502 Upstream error:' response with 'Upstream error: ' as the body. It's really important to note that the client will *only* accept a response like stated above. If you send it as a HTTP/1.1 response, the client will stop polling!

The client posts to the EventQueueGet cap provided in the region seed cap with an application/xml content type. (this will eventually be application/llsd+xml)

Client Request ->
{
ack : integer,
done : boolean
}

; Successful response (no events) <-
HTTP/1.0 502 Upstream error:
Content-Type: text/plain
Connection: close

Upstream error:

; Successful Response (event) <-
{
events : [ event ],
id : integer
}

There are a few events that OpenSimulator has implemented over the EventQueueGet cap.
So far they're;
* EnableSimulator
* CrossedRegion
* TeleportFinish

===EnableSimulator===
EnableSimulator is the event that tells the client to connect to a new simulator. We use it to inform clients that there is a neighbor region to the one that the avatar is currently in. This causes the client to attempt to connect to the region described in the EnableSimulator event.

{
body : {
SimulatorInfo : [
{
Handle : binary
IP : binary
Port : integer
}
],
message : 'EnableSimulator'
}

Remember, Handle is the regionhandle of the new simulator in BIG Endian format, base64 encoded.
IP is the IP Address of the new simulator as a byte array, base64 encoded.
Port is the UDP port of the new simulator UDP service.

Note:
The IP address (24.151.1.250) contains 4 bytes:
24
151
1
250

The regionhandle is a 64 bit representation of the X and Y cordinate of the 0,0 point of the new simulator
Where x is the uint X coordinate, and y is the uint Y coordinate, the formula for creating a regionhandle is:
ulong regionhandle = ((ulong)x << 32) | (ulong)y;

===CrossedRegion===
The simulator uses CrossedRegion to inform your client that it has crossed into a new region. Typically this is sent out when an avatar crosses a border between two simulators.

{
body : {
CrossedRegion : [
AgentData : [
{
AgentID : UUID,
SessionID : UUID
}
],
RegionData : [
{
RegionHandle : binary,
SeedCapability : string,
SimIP : binary,
SimPort : integer
}
],
Info : [
{
LookAt : [ real, real, real ],
Position : [ real, real, real ]
}
]
],
message : 'EnableSimulator'
}

No info created for this yet, sorry. The best we have is [http://www.libsecondlife.org/wiki/EventQueueGet a page from lisecondlife.org].

EventQueueGet

Teravus Ousley — Thu, 16 Oct 2008 05:25:26 GMT

Teravus Ousley: /* Detailed data on the EventQueueGet CAP */

The EventQueueGet cap is actually a service. The CAP provides access to the service.
Currently if the client cannot get an EventQueueGet cap, it will refuse to show neighbor regions and you will not be able to teleport to another region. You're essentially trapped where you are.

It's also very easy for the client to stop polling the EventQueueGet CAP

The Client essentially sends an application/xml Map with two keys. ack and done. Ack is an integer of the last Event ID and done is.. well, we don't know what done is yet besides it's a boolean. At this moment, it's always false.

The simulator will hold on to this request until it has some events to send to the client or the simulator times out the connection with a very specific response. The simulator will usually do this in around 20 to 30 seconds from the request start. To understand this, think in terms of requesting a web page that does a lot of background processing before sending you back a response. If you were to be able to post to the EventQueueGet Cap in a browser, it would look like a white page loading for about 20 or 30 seconds, and then it would give you back a 502 error. Don't fret! the 502 error is normal! When the EventQueueGet service doesn't have any events to send to the client, it typically sends a 'HTTP/1.0 502 Upstream error:' response with 'Upstream error: ' as the body. It's really important to note that the client will *only* accept a response like stated above. If you send it as a HTTP/1.1 response, the client will stop polling!

The client posts to the EventQueueGet cap provided in the region seed cap with an application/xml content type. (this will eventually be application/llsd+xml)

Client Request ->
{
ack : integer,
done : boolean
}

; Successful response (no events) <-
HTTP/1.0 502 Upstream error:
Content-Type: text/plain
Connection: close

Upstream error:

; Successful Response (event) <-
{
events : [ event ],
id : integer
}

There are a few events that OpenSimulator has implemented over the EventQueueGet cap.
So far they're;
* EnableSimulator
* CrossedRegion
* TeleportFinish

===EnableSimulator===
EnableSimulator is the event that tells the client to connect to a new simulator. We use it to inform clients that there is a neighbor region to the one that the avatar is currently in. This causes the client to attempt to connect to the region described in the EnableSimulator event.

{
body : {
SimulatorInfo : [
{
Handle : binary
IP : binary
Port : integer
}
],
message : 'EnableSimulator'
}

Remember, Handle is the regionhandle of the new simulator in BIG Endian format, base64 encoded.
IP is the IP Address of the new simulator as a byte array, base64 encoded.
Port is the UDP port of the new simulator UDP service.

Note:
The IP address (24.151.1.250) contains 4 bytes:
24
151
1
250

The regionhandle is a 64 bit representation of the X and Y cordinate of the 0,0 point of the new simulator
Where x is the uint X coordinate, and y is the uint Y coordinate, the formula for creating a regionhandle is:
ulong regionhandle = ((ulong)x << 32) | (ulong)y;

No info created for this yet, sorry. The best we have is [http://www.libsecondlife.org/wiki/EventQueueGet a page from lisecondlife.org].

Open Source Meeting/Agenda

Teravus Ousley — Wed, 08 Oct 2008 22:02:59 GMT

Teravus Ousley: /* Agenda */

< [[Open Source Meeting]]

Open source meeting - Thursday, 2pm PT.

[http://slurl.com/secondlife/Hippotropolis/248/15/25/ Teleport] to the Linden Open Source Project headquarters.

Please try to add your items as early as possible in the week to give Rob a chance to round up any Lindens that may be appropriate to the discussion. Please also bring large or contentious items up on [[SLDev]] before or concurrently with adding them as agenda items.

== Agenda ==

* Have spotted that DBUS has been added to the viewer in trunk, any news on this and plans for IPC? ([[User:Michelle2 Zenovka|Michelle2 Zenovka]])
* An update from WorkingOnIt Linden about [[http://jira.secondlife.com/browse/VWR-3943 VWR-3943]] Out of Memory in Smartheap Library errors. It has 148 votes, 55 watchers, and has been around since last year. If we could get more information about the progress, we might be able to help fix it. ([[User:Mm Alder|Mm Alder]] 13:03, 8 October 2008 (PDT))
* Exploit fix disclosure, private parties/NDA and associated issues
* Add your item(s) here...

Default agenda (barring agenda above):
* Update from the Lindens (standing item) - [[User:Rob Linden|Rob Linden]]
* Triage of issues listed here: http://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=11240

Open Source Meeting/Agenda

Teravus Ousley — Wed, 08 Oct 2008 22:01:49 GMT

Teravus Ousley: /* Agenda */

< [[Open Source Meeting]]

Open source meeting - Thursday, 2pm PT.

[http://slurl.com/secondlife/Hippotropolis/248/15/25/ Teleport] to the Linden Open Source Project headquarters.

Please try to add your items as early as possible in the week to give Rob a chance to round up any Lindens that may be appropriate to the discussion. Please also bring large or contentious items up on [[SLDev]] before or concurrently with adding them as agenda items.

== Agenda ==

* Have spotted that DBUS has been added to the viewer in trunk, any news on this and plans for IPC? ([[User:Michelle2 Zenovka|Michelle2 Zenovka]])
* An update from WorkingOnIt Linden about [[http://jira.secondlife.com/browse/VWR-3943 VWR-3943]] Out of Memory in Smartheap Library errors. It has 148 votes, 55 watchers, and has been around since last year. If we could get more information about the progress, we might be able to help fix it. ([[User:Mm Alder|Mm Alder]] 13:03, 8 October 2008 (PDT))
* Exploit disclosure, private parties/NDA,etc
* Add your item(s) here...

Default agenda (barring agenda above):
* Update from the Lindens (standing item) - [[User:Rob Linden|Rob Linden]]
* Triage of issues listed here: http://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=11240

User:Infinity Linden/OGP Trust Phase 0

Teravus Ousley — Wed, 24 Sep 2008 19:10:13 GMT

Teravus Ousley: /* Specific Issues With OpenSim Software */

=Introduction=

This page describes "near term" trust mechanisms for OGP protocol participants. The objective is not to define the ultimate trust or security system, or even to try to enumerate all trust issues; for that, please visit the [[User:Infinity_Linden/OGP_Trust_Model|OGP Trust Model Page]]. This page is intended to describe "near term" trust issues and how participants in the OGP Beta program may use features that currently exist to establish "trust" between region and agent domains. So.. the [[User:Infinity_Linden/OGP_Trust_Model|OGP Trust Model Page]] is where you will find information regarding Rights Expression Languages, revised permissions for in-world objects, distributed third-party authentication, integrating OpenID or SAML, etc. This page is where you'll find discussions regarding how client applications, agent domains and region domains establish a base level of trust through the use of X.509 certificates used in conjunction with TLS / HTTPS.

'''todo:''' continue fleshing out this section. maybe add links to "howtos" when we've reached agreement between LL, OpenSim, PyOGP

=How We Authenticate Protocol Actors=
[[Image:Sl2008 simplified trust 01.jpg|thumb|300px|simplified trust model]]

The diagram to the right shows how different protocol actors in OGP establish trust. The diagram shows the three major classes of protocol actors: client applications, agent domains and region domains. The objective of this section is to describe how actors establish trust in remote protocol participants. The concept of "trust" is intimately related to the authentication technology used by client and server software, but can be seen to be more than simple authentication. As we'll see in the section describing the proposed registration authority, authentication "reflects" trust, it does not create it.

==Authenticating Client Application Users to Agent Domain Servers==

Before an end user may enter the virtual world, they must authenticate themselves. This is just as true for automated systems as it is for human users. Three authentication techniques are described in the [[OGP_Authentication_Draft_3|authentication section of the OGP specification]]. When this document was written, only the hashed password authenticator was deployed on the OGP beta grid. It is also thought that for the "near term", Challenge Response and PKCS#5 PBKDF authenticators will not be deployed. It is important to note that the Second Life main grid and canonical Second Life viewer do not implement OGP at this time. Users will need to download the Open Grid Viewer from the [[Open_Grid_Public_Beta/Open_Grid_Beta_Viewers|Open Grid Beta Viewers page]].

Authentication begins with the user providing their password to the client application. The client application in turn constructs an agent_login message that it sends to the agent domain's LoginURI. The LoginURI for Linden Lab's OGP Beta is predefined as the default in the Open Grid Viewer. Users wishing to use a different Agent Domain may use the <code>--loginuri</code> option on the command line when invoking the viewer.

The details of how an avatar or account name and password are established between the end user and the agent domain is beyond the scope of this document. Linden Lab provides a web resource for account creation end users may access via a traditional web browser. Before Linden Lab will create an account, the end user must agree to a Terms of Service document and view any outstanding Critical Messages. Account Creation interactions take place over a HTTPS TLS-Encrypted transport. This is to ensure that eavesdroppers have a limited opportunity to intercept the new user's password.

Other Agent Domain operators are free to implement any policy they wish with respect to the security of agent credentials. But it should be noted that the use of HTTPS to transport agent_login requests is STRONGLY RECOMMENDED. Services deployed by Linden Lab will refuse to to agent_login requests that do not use HTTPS. As described later in this document, Linden Lab region domains may reject protocol messages from agent domains that do not require the use HTTPS for username/password establishment or for agent_login requests.

It is also important to note that the Open Grid Beta Viewer from Linden Lab will refuse to attempt to connect to non-https LoginURI. Agent domain operators who do not wish to use HTTPS based LoginURIs will need to distribute their own viewer application.

So... to recap. End users authenticate themselves to agent domains by using a username / password pair. How an agent domain establishes the trustworthiness of the end user is beyond the scope of this document. HTTPS is your friend. Linden Lab's servers may snub you if you don't like HTTPS.

==Authenticating Client Applications to Region Domain Servers==

Region domain servers SHOULD NOT make "sensitive" services available to unauthenticated clients.

Client Applications use the possession of a capability by the client as proof of authorization to perform a particular operation.

Ergo, if you operate a Region Domain, do not issue sensitive caps to a client directly. Give the sensitive cap to an agent domain and let it give the cap to the client.

==Authenticating Agent Domain Servers to Client Applications==

Hosts implementing the agent domain portion of OGP SHOULD make services available via HTTPS / TLS. As mentioned above, Linden Lab servers will reject some protocol interactions if they do not take place over HTTPS (or some other secure transport).

Before trusting an Agent Domain server, Client Applications SHOULD check the following to ensure that the server being communicated with is actually the Agent Domain server that it claims to be:

* if the server's server certificate uses an IP address as part of the X.509 Subject Name, is this the same IP address the peer is using? (i.e. - does the IP address of the server match the IP address in the X.509 Subject Name?)
* if the server's server certificate uses a DNS Fully Qualified Domain Name (FQDN) as part of the X.509 Subject Name, does the IP address of the peer match the A record retrieved when doing a reverse DNS lookup?
* is the server's server certificate valid? (i.e. - is the current date between the validFrom and validTo dates in the server's certificate and every certificate in the chain up to a trusted certificate.
* is the server's server certificate explicitly trusted for authentication? (i.e. - is the server's certificate or a certificate in the server's certificate's chain explicitly trusted for authentication?)

It should be noted that these are all common options with most (if not all) TLS implementations, including OpenSSL.

It also implies that:

* the Client Application SHOULD maintain a list of "authentication trust-points" or certificates identifying organizations explicitly trusted by the Client Application for the purpose of authentication.
* <strike>the Client Application SHOULD NOT accept certificates that contain a wild-card in the Subject Name field of the certificate</strike>

==Authenticating Agent Domain Servers and Region Domain Servers to Each Other==

Sensitive communications between agent domain hosts and region domain hosts MUST be over a secure transport like TLS / HTTPS.

When an agent domain host initiates communication with a region domain host, it must verify the identity of the region domain via the region domain host's server certificate. The process listed in the Client Application to Agent Domain section above should be followed for agent to region communications.

<strike>To authenticate the agent domain to the region, the agent domain should provide its client certificate to the region domain host. The region domain may then authenticate the agent domain using the same process as above.

When a region domain host initiates communication with an agent domain host, the process is reversed. The Agent Domain's server certificate is validated first (by the region domain host), then the region domain's client certificate is validated (by the agent domain host).</strike>

Agent Domains should access sensitive resources ONLY via capabilities issued by the region domain.

Clever readers will note that this implies:

* the ability for both the agent domain and the region domain to generate server certificates for their systems.
* (and) the ability for both agent and region domains to manage a list of "authentication trust points" in a certificate chain.

Fortunately, this is a relatively well known process (though, administratively, it can be "less than easy" with existing open source tools.)

=Specific Issues With Linden Lab Software=

'''note:''' this section introduces ideas for discussion. no decision has yet been made to implement this proposal. no decision to do so is likely without community discussion.

==Linden Lab Self Signed Certificate For Agent and Region Domain Authentication==

Blergh. Okay, you caught us. We're using self-signed certificates.

In an environment where we were the only ones offering region hosting, agent hosting and making viewer software, this was not an unreasonable choice. But now we have to open this process up to allow interoperability with trusted agent and region domains.

In terms of the OGP Beta, this is likely not too onerous an administrative task. ['''note:''' the person who just wrote that is not, in fact, the person who would be fulfilling service requests, so your mileage may vary.] In the OGP Beta, we are not (yet) attempting to transer potentially sensitive assets and there are a relatively small number of region and agent domain operators.

So... the proposal is we (the community in general) move beyond Self-Signed Certs except for testing purposes.

The simplest way to meet the "move beyond self-signed certificates" requirement is for Linden Lab to operate a registration authority for the purpose of beginning the certification process for external agent and region domain operators.

Or we could use some set of common well-known CAs, like Verisign or somebody. Although they like charge money.

'''todo:''' fill out this section a touch more, maybe describing the process of registering a peer agent or region domain.

=Specific Issues With OpenSim Software=
'''note:''' Terevus, Zha, et al. do you want to add a few notes here?

'''Teravus:''' One thing to note here, however.. is you'll need to add your '''CA''' to the client's '''app_settings/CA.pem''' until the Linden/Verisign/Other CA process is worked out sufficiently. The directions for setting it up are in *svn*/share/junkCA

Certain things don't work in SSL mode now. For example: teleporting from Vaak to a SSL enabled OpenSimulator region fails because Vaak rejects self signed certificates and upon reading the response, it terminates the connection. (So in OpenSimulator, you'll see Vaak invoke the cap, but it'll still fail because vaak doesn't read the response)

==Self Signed Certificates for Agent and Region Domain Authentication==
==Proposed Registration Authority for OpenSim Operators==

=Specific Issues With PyOGP Software=
'''Note:''' ''Tao... Sai... I know we discussed this a bit... but i'm blanking on what we said... so feel free to add stuff here, otherwise i'm going to add my best guess regarding how we want to handle it''
=Discussions=
*Gridnauts IRC
**Sepember [[User:Infinity_Linden/Gridnauts_2080913|13]]

[[Category:AW_Groupies]]
[[Category:Grid_Interoperability]]

User:Infinity Linden/OGP Trust Phase 0

Teravus Ousley — Wed, 24 Sep 2008 19:03:27 GMT

Teravus Ousley: /* Specific Issues With OpenSim Software */

'''Important Note'''
* This page describes the near term "trust objectives". In this context, "Near Term" means issues relating to features that already existed in Second Life in September 2008, and how they will be implemented to support non-Linden Agent and Region domains. Discussions regarding the future of Trust in OGP (including, but not limited to: Rights Expression Languages, revised permissions for in-world objects, distributed third-party authentication, integrating OpenID or SAML, etc.) should be directed towards [[User:Infinity_Linden/OGP_Trust_Model|the OGP Trust Model page]].
=Introduction=

'''todo:''' add introduction here. best done after the content is produced.

=How We Authenticate Protocol Actors=
[[Image:Sl2008 simplified trust 01.jpg|thumb|300px|simplified trust model]]

The diagram to the right shows how different protocol actors in OGP establish trust. The diagram shows the three major classes of protocol actors: client applications, agent domains and region domains. The objective of this section is to describe how actors establish trust in remote protocol participants. The concept of "trust" is intimately related to the authentication technology used by client and server software, but can be seen to be more than simple authentication. As we'll see in the section describing the proposed registration authority, authentication "reflects" trust, it does not create it.

==Authenticating Client Application Users to Agent Domain Servers==

Before an end user may enter the virtual world, they must authenticate themselves. This is just as true for automated systems as it is for human users. Three authentication techniques are described in the [[OGP_Authentication_Draft_3|authentication section of the OGP specification]]. When this document was written, only the hashed password authenticator was deployed on the OGP beta grid. It is also thought that for the "near term", Challenge Response and PKCS#5 PBKDF authenticators will not be deployed. It is important to note that the Second Life main grid and canonical Second Life viewer do not implement OGP at this time. Users will need to download the Open Grid Viewer from the [[Open_Grid_Public_Beta/Open_Grid_Beta_Viewers|Open Grid Beta Viewers page]].

Authentication begins with the user providing their password to the client application. The client application in turn constructs an agent_login message that it sends to the agent domain's LoginURI. The LoginURI for Linden Lab's OGP Beta is predefined as the default in the Open Grid Viewer. Users wishing to use a different Agent Domain may use the <code>--loginuri</code> option on the command line when invoking the viewer.

The details of how an avatar or account name and password are established between the end user and the agent domain is beyond the scope of this document. Linden Lab provides a web resource for account creation end users may access via a traditional web browser. Before Linden Lab will create an account, the end user must agree to a Terms of Service document and view any outstanding Critical Messages. Account Creation interactions take place over a HTTPS TLS-Encrypted transport. This is to ensure that eavesdroppers have a limited opportunity to intercept the new user's password.

Other Agent Domain operators are free to implement any policy they wish with respect to the security of agent credentials. But it should be noted that the use of HTTPS to transport agent_login requests is STRONGLY RECOMMENDED. Services deployed by Linden Lab will refuse to to agent_login requests that do not use HTTPS. As described later in this document, Linden Lab region domains may reject protocol messages from agent domains that do not require the use HTTPS for username/password establishment or for agent_login requests.

It is also important to note that the Open Grid Beta Viewer from Linden Lab will refuse to attempt to connect to non-https LoginURI. Agent domain operators who do not wish to use HTTPS based LoginURIs will need to distribute their own viewer application.

So... to recap. End users authenticate themselves to agent domains by using a username / password pair. How an agent domain establishes the trustworthiness of the end user is beyond the scope of this document. HTTPS is your friend. Linden Lab's servers may snub you if you don't like HTTPS.

==Authenticating Client Applications to Region Domain Servers==

Region domain servers SHOULD NOT make "sensitive" services available to unauthenticated clients.

Client Applications use the possession of a capability by the client as proof of authorization to perform a particular operation.

Ergo, if you operate a Region Domain, do not issue sensitive caps to a client directly. Give the sensitive cap to an agent domain and let it give the cap to the client.

==Authenticating Agent Domain Servers to Client Applications==

Hosts implementing the agent domain portion of OGP SHOULD make services available via HTTPS / TLS. As mentioned above, Linden Lab servers will reject some protocol interactions if they do not take place over HTTPS (or some other secure transport).

Before trusting an Agent Domain server, Client Applications SHOULD check the following to ensure that the server being communicated with is actually the Agent Domain server that it claims to be:

* if the server's server certificate uses an IP address as part of the X.509 Subject Name, is this the same IP address the peer is using? (i.e. - does the IP address of the server match the IP address in the X.509 Subject Name?)
* if the server's server certificate uses a DNS Fully Qualified Domain Name (FQDN) as part of the X.509 Subject Name, does the IP address of the peer match the A record retrieved when doing a reverse DNS lookup?
* is the server's server certificate valid? (i.e. - is the current date between the validFrom and validTo dates in the server's certificate and every certificate in the chain up to a trusted certificate.
* is the server's server certificate explicitly trusted for authentication? (i.e. - is the server's certificate or a certificate in the server's certificate's chain explicitly trusted for authentication?)

It should be noted that these are all common options with most (if not all) TLS implementations, including OpenSSL.

It also implies that:

* the Client Application SHOULD maintain a list of "authentication trust-points" or certificates identifying organizations explicitly trusted by the Client Application for the purpose of authentication.
* <strike>the Client Application SHOULD NOT accept certificates that contain a wild-card in the Subject Name field of the certificate</strike>

==Authenticating Agent Domain Servers and Region Domain Servers to Each Other==

Sensitive communications between agent domain hosts and region domain hosts MUST be over a secure transport like TLS / HTTPS.

When an agent domain host initiates communication with a region domain host, it must verify the identity of the region domain via the region domain host's server certificate. The process listed in the Client Application to Agent Domain section above should be followed for agent to region communications.

<strike>To authenticate the agent domain to the region, the agent domain should provide its client certificate to the region domain host. The region domain may then authenticate the agent domain using the same process as above.

When a region domain host initiates communication with an agent domain host, the process is reversed. The Agent Domain's server certificate is validated first (by the region domain host), then the region domain's client certificate is validated (by the agent domain host).</strike>

Agent Domains should access sensitive resources ONLY via capabilities issued by the region domain.

Clever readers will note that this implies:

* the ability for both the agent domain and the region domain to generate server certificates for their systems.
* (and) the ability for both agent and region domains to manage a list of "authentication trust points" in a certificate chain.

Fortunately, this is a relatively well known process (though, administratively, it can be "less than easy" with existing open source tools.)

=Specific Issues With Linden Lab Software=

'''note:''' this section introduces ideas for discussion. no decision has yet been made to implement this proposal. no decision to do so is likely without community discussion.

==Linden Lab Self Signed Certificate For Agent and Region Domain Authentication==

Blergh. Okay, you caught us. We're using self-signed certificates.

In an environment where we were the only ones offering region hosting, agent hosting and making viewer software, this was not an unreasonable choice. But now we have to open this process up to allow interoperability with trusted agent and region domains.

In terms of the OGP Beta, this is likely not too onerous an administrative task. ['''note:''' the person who just wrote that is not, in fact, the person who would be fulfilling service requests, so your mileage may vary.] In the OGP Beta, we are not (yet) attempting to transer potentially sensitive assets and there are a relatively small number of region and agent domain operators.

So... the proposal is we (the community in general) move beyond Self-Signed Certs except for testing purposes.

The simplest way to meet the "move beyond self-signed certificates" requirement is for Linden Lab to operate a registration authority for the purpose of beginning the certification process for external agent and region domain operators.

Or we could use some set of common well-known CAs, like Verisign or somebody. Although they like charge money.

'''todo:''' fill out this section a touch more, maybe describing the process of registering a peer agent or region domain.

=Specific Issues With OpenSim Software=
'''note:''' Terevus, Zha, et al. do you want to add a few notes here?

'''Teravus:''' One thing to note here, however.. is you'll need to add your '''CA''' to the client's '''app_settings/CA.pem''' until the Linden/Verisign/Other CA process is worked out sufficiently. The directions for setting it up are in *svn*/share/junkCA

Certain things don't work in SSL mode now. For example: teleporting from Vaak to a SSL enabled OpenSimulator region fails because Vaak rejects self signed certificates and upon reading the response, it terminates the connection. (So in OpenSimulator, you'll see Vaak invoke the cap, but it'll still fail because it doesn't read the response)

==Self Signed Certificates for Agent and Region Domain Authentication==
==Proposed Registration Authority for OpenSim Operators==

=Specific Issues With PyOGP Software=
'''Note:''' ''Tao... Sai... I know we discussed this a bit... but i'm blanking on what we said... so feel free to add stuff here, otherwise i'm going to add my best guess regarding how we want to handle it''
=Discussions=
*Gridnauts IRC
**Sepember [[User:Infinity_Linden/Gridnauts_2080913|13]]

[[Category:AW_Groupies]]
[[Category:Grid_Interoperability]]

User:Infinity Linden/OGP Trust Phase 0

Teravus Ousley — Wed, 24 Sep 2008 18:56:46 GMT

Teravus Ousley: /* Specific Issues With OpenSim Software */

'''Important Note'''
* This page describes the near term "trust objectives". In this context, "Near Term" means issues relating to features that already existed in Second Life in September 2008, and how they will be implemented to support non-Linden Agent and Region domains. Discussions regarding the future of Trust in OGP (including, but not limited to: Rights Expression Languages, revised permissions for in-world objects, distributed third-party authentication, integrating OpenID or SAML, etc.) should be directed towards [[User:Infinity_Linden/OGP_Trust_Model|the OGP Trust Model page]].
=Introduction=

'''todo:''' add introduction here. best done after the content is produced.

=How We Authenticate Protocol Actors=
[[Image:Sl2008 simplified trust 01.jpg|thumb|300px|simplified trust model]]

The diagram to the right shows how different protocol actors in OGP establish trust. The diagram shows the three major classes of protocol actors: client applications, agent domains and region domains. The objective of this section is to describe how actors establish trust in remote protocol participants. The concept of "trust" is intimately related to the authentication technology used by client and server software, but can be seen to be more than simple authentication. As we'll see in the section describing the proposed registration authority, authentication "reflects" trust, it does not create it.

==Authenticating Client Application Users to Agent Domain Servers==

Before an end user may enter the virtual world, they must authenticate themselves. This is just as true for automated systems as it is for human users. Three authentication techniques are described in the [[OGP_Authentication_Draft_3|authentication section of the OGP specification]]. When this document was written, only the hashed password authenticator was deployed on the OGP beta grid. It is also thought that for the "near term", Challenge Response and PKCS#5 PBKDF authenticators will not be deployed. It is important to note that the Second Life main grid and canonical Second Life viewer do not implement OGP at this time. Users will need to download the Open Grid Viewer from the [[Open_Grid_Public_Beta/Open_Grid_Beta_Viewers|Open Grid Beta Viewers page]].

Authentication begins with the user providing their password to the client application. The client application in turn constructs an agent_login message that it sends to the agent domain's LoginURI. The LoginURI for Linden Lab's OGP Beta is predefined as the default in the Open Grid Viewer. Users wishing to use a different Agent Domain may use the <code>--loginuri</code> option on the command line when invoking the viewer.

The details of how an avatar or account name and password are established between the end user and the agent domain is beyond the scope of this document. Linden Lab provides a web resource for account creation end users may access via a traditional web browser. Before Linden Lab will create an account, the end user must agree to a Terms of Service document and view any outstanding Critical Messages. Account Creation interactions take place over a HTTPS TLS-Encrypted transport. This is to ensure that eavesdroppers have a limited opportunity to intercept the new user's password.

Other Agent Domain operators are free to implement any policy they wish with respect to the security of agent credentials. But it should be noted that the use of HTTPS to transport agent_login requests is STRONGLY RECOMMENDED. Services deployed by Linden Lab will refuse to to agent_login requests that do not use HTTPS. As described later in this document, Linden Lab region domains may reject protocol messages from agent domains that do not require the use HTTPS for username/password establishment or for agent_login requests.

It is also important to note that the Open Grid Beta Viewer from Linden Lab will refuse to attempt to connect to non-https LoginURI. Agent domain operators who do not wish to use HTTPS based LoginURIs will need to distribute their own viewer application.

So... to recap. End users authenticate themselves to agent domains by using a username / password pair. How an agent domain establishes the trustworthiness of the end user is beyond the scope of this document. HTTPS is your friend. Linden Lab's servers may snub you if you don't like HTTPS.

==Authenticating Client Applications to Region Domain Servers==

Region domain servers SHOULD NOT make "sensitive" services available to unauthenticated clients.

Client Applications use the possession of a capability by the client as proof of authorization to perform a particular operation.

Ergo, if you operate a Region Domain, do not issue sensitive caps to a client directly. Give the sensitive cap to an agent domain and let it give the cap to the client.

==Authenticating Agent Domain Servers to Client Applications==

Hosts implementing the agent domain portion of OGP SHOULD make services available via HTTPS / TLS. As mentioned above, Linden Lab servers will reject some protocol interactions if they do not take place over HTTPS (or some other secure transport).

Before trusting an Agent Domain server, Client Applications SHOULD check the following to ensure that the server being communicated with is actually the Agent Domain server that it claims to be:

* if the server's server certificate uses an IP address as part of the X.509 Subject Name, is this the same IP address the peer is using? (i.e. - does the IP address of the server match the IP address in the X.509 Subject Name?)
* if the server's server certificate uses a DNS Fully Qualified Domain Name (FQDN) as part of the X.509 Subject Name, does the IP address of the peer match the A record retrieved when doing a reverse DNS lookup?
* is the server's server certificate valid? (i.e. - is the current date between the validFrom and validTo dates in the server's certificate and every certificate in the chain up to a trusted certificate.
* is the server's server certificate explicitly trusted for authentication? (i.e. - is the server's certificate or a certificate in the server's certificate's chain explicitly trusted for authentication?)

It should be noted that these are all common options with most (if not all) TLS implementations, including OpenSSL.

It also implies that:

* the Client Application SHOULD maintain a list of "authentication trust-points" or certificates identifying organizations explicitly trusted by the Client Application for the purpose of authentication.
* <strike>the Client Application SHOULD NOT accept certificates that contain a wild-card in the Subject Name field of the certificate</strike>

==Authenticating Agent Domain Servers and Region Domain Servers to Each Other==

Sensitive communications between agent domain hosts and region domain hosts MUST be over a secure transport like TLS / HTTPS.

When an agent domain host initiates communication with a region domain host, it must verify the identity of the region domain via the region domain host's server certificate. The process listed in the Client Application to Agent Domain section above should be followed for agent to region communications.

<strike>To authenticate the agent domain to the region, the agent domain should provide its client certificate to the region domain host. The region domain may then authenticate the agent domain using the same process as above.

When a region domain host initiates communication with an agent domain host, the process is reversed. The Agent Domain's server certificate is validated first (by the region domain host), then the region domain's client certificate is validated (by the agent domain host).</strike>

Agent Domains should access sensitive resources ONLY via capabilities issued by the region domain.

Clever readers will note that this implies:

* the ability for both the agent domain and the region domain to generate server certificates for their systems.
* (and) the ability for both agent and region domains to manage a list of "authentication trust points" in a certificate chain.

Fortunately, this is a relatively well known process (though, administratively, it can be "less than easy" with existing open source tools.)

=Specific Issues With Linden Lab Software=

'''note:''' this section introduces ideas for discussion. no decision has yet been made to implement this proposal. no decision to do so is likely without community discussion.

==Linden Lab Self Signed Certificate For Agent and Region Domain Authentication==

Blergh. Okay, you caught us. We're using self-signed certificates.

In an environment where we were the only ones offering region hosting, agent hosting and making viewer software, this was not an unreasonable choice. But now we have to open this process up to allow interoperability with trusted agent and region domains.

In terms of the OGP Beta, this is likely not too onerous an administrative task. ['''note:''' the person who just wrote that is not, in fact, the person who would be fulfilling service requests, so your mileage may vary.] In the OGP Beta, we are not (yet) attempting to transer potentially sensitive assets and there are a relatively small number of region and agent domain operators.

So... the proposal is we (the community in general) move beyond Self-Signed Certs except for testing purposes.

The simplest way to meet the "move beyond self-signed certificates" requirement is for Linden Lab to operate a registration authority for the purpose of beginning the certification process for external agent and region domain operators.

Or we could use some set of common well-known CAs, like Verisign or somebody. Although they like charge money.

'''todo:''' fill out this section a touch more, maybe describing the process of registering a peer agent or region domain.

=Specific Issues With OpenSim Software=
'''note:''' Terevus, Zha, et al. do you want to add a few notes here?

'''Teravus:''' One thing to note here, however.. is you'll need to add your '''CA''' to the client's '''app_settings/CA.pem''' until the Linden/Verisign/Other CA process is worked out sufficiently. The directions for setting it up are in *svn*/share/junkCA

==Self Signed Certificates for Agent and Region Domain Authentication==
==Proposed Registration Authority for OpenSim Operators==

=Specific Issues With PyOGP Software=
'''Note:''' ''Tao... Sai... I know we discussed this a bit... but i'm blanking on what we said... so feel free to add stuff here, otherwise i'm going to add my best guess regarding how we want to handle it''
=Discussions=
*Gridnauts IRC
**Sepember [[User:Infinity_Linden/Gridnauts_2080913|13]]

[[Category:AW_Groupies]]
[[Category:Grid_Interoperability]]

User:Infinity Linden/OGP Trust Phase 0

Teravus Ousley — Wed, 24 Sep 2008 18:50:21 GMT

Teravus Ousley: /* Specific Issues With OpenSim Software */

'''Important Note'''
* This page describes the near term "trust objectives". In this context, "Near Term" means issues relating to features that already existed in Second Life in September 2008, and how they will be implemented to support non-Linden Agent and Region domains. Discussions regarding the future of Trust in OGP (including, but not limited to: Rights Expression Languages, revised permissions for in-world objects, distributed third-party authentication, integrating OpenID or SAML, etc.) should be directed towards [[User:Infinity_Linden/OGP_Trust_Model|the OGP Trust Model page]].
=Introduction=

'''todo:''' add introduction here. best done after the content is produced.

=How We Authenticate Protocol Actors=
[[Image:Sl2008 simplified trust 01.jpg|thumb|300px|simplified trust model]]

The diagram to the right shows how different protocol actors in OGP establish trust. The diagram shows the three major classes of protocol actors: client applications, agent domains and region domains. The objective of this section is to describe how actors establish trust in remote protocol participants. The concept of "trust" is intimately related to the authentication technology used by client and server software, but can be seen to be more than simple authentication. As we'll see in the section describing the proposed registration authority, authentication "reflects" trust, it does not create it.

==Authenticating Client Application Users to Agent Domain Servers==

Before an end user may enter the virtual world, they must authenticate themselves. This is just as true for automated systems as it is for human users. Three authentication techniques are described in the [[OGP_Authentication_Draft_3|authentication section of the OGP specification]]. When this document was written, only the hashed password authenticator was deployed on the OGP beta grid. It is also thought that for the "near term", Challenge Response and PKCS#5 PBKDF authenticators will not be deployed. It is important to note that the Second Life main grid and canonical Second Life viewer do not implement OGP at this time. Users will need to download the Open Grid Viewer from the [[Open_Grid_Public_Beta/Open_Grid_Beta_Viewers|Open Grid Beta Viewers page]].

Authentication begins with the user providing their password to the client application. The client application in turn constructs an agent_login message that it sends to the agent domain's LoginURI. The LoginURI for Linden Lab's OGP Beta is predefined as the default in the Open Grid Viewer. Users wishing to use a different Agent Domain may use the <code>--loginuri</code> option on the command line when invoking the viewer.

The details of how an avatar or account name and password are established between the end user and the agent domain is beyond the scope of this document. Linden Lab provides a web resource for account creation end users may access via a traditional web browser. Before Linden Lab will create an account, the end user must agree to a Terms of Service document and view any outstanding Critical Messages. Account Creation interactions take place over a HTTPS TLS-Encrypted transport. This is to ensure that eavesdroppers have a limited opportunity to intercept the new user's password.

Other Agent Domain operators are free to implement any policy they wish with respect to the security of agent credentials. But it should be noted that the use of HTTPS to transport agent_login requests is STRONGLY RECOMMENDED. Services deployed by Linden Lab will refuse to to agent_login requests that do not use HTTPS. As described later in this document, Linden Lab region domains may reject protocol messages from agent domains that do not require the use HTTPS for username/password establishment or for agent_login requests.

It is also important to note that the Open Grid Beta Viewer from Linden Lab will refuse to attempt to connect to non-https LoginURI. Agent domain operators who do not wish to use HTTPS based LoginURIs will need to distribute their own viewer application.

So... to recap. End users authenticate themselves to agent domains by using a username / password pair. How an agent domain establishes the trustworthiness of the end user is beyond the scope of this document. HTTPS is your friend. Linden Lab's servers may snub you if you don't like HTTPS.

==Authenticating Client Applications to Region Domain Servers==

Region domain servers SHOULD NOT make "sensitive" services available to unauthenticated clients.

Client Applications use the possession of a capability by the client as proof of authorization to perform a particular operation.

Ergo, if you operate a Region Domain, do not issue sensitive caps to a client directly. Give the sensitive cap to an agent domain and let it give the cap to the client.

==Authenticating Agent Domain Servers to Client Applications==

Hosts implementing the agent domain portion of OGP SHOULD make services available via HTTPS / TLS. As mentioned above, Linden Lab servers will reject some protocol interactions if they do not take place over HTTPS (or some other secure transport).

Before trusting an Agent Domain server, Client Applications SHOULD check the following to ensure that the server being communicated with is actually the Agent Domain server that it claims to be:

* if the server's server certificate uses an IP address as part of the X.509 Subject Name, is this the same IP address the peer is using? (i.e. - does the IP address of the server match the IP address in the X.509 Subject Name?)
* if the server's server certificate uses a DNS Fully Qualified Domain Name (FQDN) as part of the X.509 Subject Name, does the IP address of the peer match the A record retrieved when doing a reverse DNS lookup?
* is the server's server certificate valid? (i.e. - is the current date between the validFrom and validTo dates in the server's certificate and every certificate in the chain up to a trusted certificate.
* is the server's server certificate explicitly trusted for authentication? (i.e. - is the server's certificate or a certificate in the server's certificate's chain explicitly trusted for authentication?)

It should be noted that these are all common options with most (if not all) TLS implementations, including OpenSSL.

It also implies that:

* the Client Application SHOULD maintain a list of "authentication trust-points" or certificates identifying organizations explicitly trusted by the Client Application for the purpose of authentication.
* <strike>the Client Application SHOULD NOT accept certificates that contain a wild-card in the Subject Name field of the certificate</strike>

==Authenticating Agent Domain Servers and Region Domain Servers to Each Other==

Sensitive communications between agent domain hosts and region domain hosts MUST be over a secure transport like TLS / HTTPS.

When an agent domain host initiates communication with a region domain host, it must verify the identity of the region domain via the region domain host's server certificate. The process listed in the Client Application to Agent Domain section above should be followed for agent to region communications.

<strike>To authenticate the agent domain to the region, the agent domain should provide its client certificate to the region domain host. The region domain may then authenticate the agent domain using the same process as above.

When a region domain host initiates communication with an agent domain host, the process is reversed. The Agent Domain's server certificate is validated first (by the region domain host), then the region domain's client certificate is validated (by the agent domain host).</strike>

Agent Domains should access sensitive resources ONLY via capabilities issued by the region domain.

Clever readers will note that this implies:

* the ability for both the agent domain and the region domain to generate server certificates for their systems.
* (and) the ability for both agent and region domains to manage a list of "authentication trust points" in a certificate chain.

Fortunately, this is a relatively well known process (though, administratively, it can be "less than easy" with existing open source tools.)

=Specific Issues With Linden Lab Software=

'''note:''' this section introduces ideas for discussion. no decision has yet been made to implement this proposal. no decision to do so is likely without community discussion.

==Linden Lab Self Signed Certificate For Agent and Region Domain Authentication==

Blergh. Okay, you caught us. We're using self-signed certificates.

In an environment where we were the only ones offering region hosting, agent hosting and making viewer software, this was not an unreasonable choice. But now we have to open this process up to allow interoperability with trusted agent and region domains.

In terms of the OGP Beta, this is likely not too onerous an administrative task. ['''note:''' the person who just wrote that is not, in fact, the person who would be fulfilling service requests, so your mileage may vary.] In the OGP Beta, we are not (yet) attempting to transer potentially sensitive assets and there are a relatively small number of region and agent domain operators.

So... the proposal is we (the community in general) move beyond Self-Signed Certs except for testing purposes.

The simplest way to meet the "move beyond self-signed certificates" requirement is for Linden Lab to operate a registration authority for the purpose of beginning the certification process for external agent and region domain operators.

Or we could use some set of common well-known CAs, like Verisign or somebody. Although they like charge money.

'''todo:''' fill out this section a touch more, maybe describing the process of registering a peer agent or region domain.

=Specific Issues With OpenSim Software=
'''note:''' Terevus, Zha, et al. do you want to add a few notes here?

'''Teravus:''' One thing to note here, however.. is you'll need to add your '''CA''' to the client's '''app_settings/CA.pem''' until the Linden/Verisign/Other CA process is worked out sufficiently. The directions for setting it up are in *svn*/contrib/junkCA

==Self Signed Certificates for Agent and Region Domain Authentication==
==Proposed Registration Authority for OpenSim Operators==

=Specific Issues With PyOGP Software=
'''Note:''' ''Tao... Sai... I know we discussed this a bit... but i'm blanking on what we said... so feel free to add stuff here, otherwise i'm going to add my best guess regarding how we want to handle it''
=Discussions=
*Gridnauts IRC
**Sepember [[User:Infinity_Linden/Gridnauts_2080913|13]]

[[Category:AW_Groupies]]
[[Category:Grid_Interoperability]]

User:Infinity Linden/OGP Trust Phase 0

Teravus Ousley — Wed, 24 Sep 2008 18:49:53 GMT

Teravus Ousley: /* Specific Issues With OpenSim Software */

'''Important Note'''
* This page describes the near term "trust objectives". In this context, "Near Term" means issues relating to features that already existed in Second Life in September 2008, and how they will be implemented to support non-Linden Agent and Region domains. Discussions regarding the future of Trust in OGP (including, but not limited to: Rights Expression Languages, revised permissions for in-world objects, distributed third-party authentication, integrating OpenID or SAML, etc.) should be directed towards [[User:Infinity_Linden/OGP_Trust_Model|the OGP Trust Model page]].
=Introduction=

'''todo:''' add introduction here. best done after the content is produced.

=How We Authenticate Protocol Actors=
[[Image:Sl2008 simplified trust 01.jpg|thumb|300px|simplified trust model]]

The diagram to the right shows how different protocol actors in OGP establish trust. The diagram shows the three major classes of protocol actors: client applications, agent domains and region domains. The objective of this section is to describe how actors establish trust in remote protocol participants. The concept of "trust" is intimately related to the authentication technology used by client and server software, but can be seen to be more than simple authentication. As we'll see in the section describing the proposed registration authority, authentication "reflects" trust, it does not create it.

==Authenticating Client Application Users to Agent Domain Servers==

Before an end user may enter the virtual world, they must authenticate themselves. This is just as true for automated systems as it is for human users. Three authentication techniques are described in the [[OGP_Authentication_Draft_3|authentication section of the OGP specification]]. When this document was written, only the hashed password authenticator was deployed on the OGP beta grid. It is also thought that for the "near term", Challenge Response and PKCS#5 PBKDF authenticators will not be deployed. It is important to note that the Second Life main grid and canonical Second Life viewer do not implement OGP at this time. Users will need to download the Open Grid Viewer from the [[Open_Grid_Public_Beta/Open_Grid_Beta_Viewers|Open Grid Beta Viewers page]].

Authentication begins with the user providing their password to the client application. The client application in turn constructs an agent_login message that it sends to the agent domain's LoginURI. The LoginURI for Linden Lab's OGP Beta is predefined as the default in the Open Grid Viewer. Users wishing to use a different Agent Domain may use the <code>--loginuri</code> option on the command line when invoking the viewer.

The details of how an avatar or account name and password are established between the end user and the agent domain is beyond the scope of this document. Linden Lab provides a web resource for account creation end users may access via a traditional web browser. Before Linden Lab will create an account, the end user must agree to a Terms of Service document and view any outstanding Critical Messages. Account Creation interactions take place over a HTTPS TLS-Encrypted transport. This is to ensure that eavesdroppers have a limited opportunity to intercept the new user's password.

Other Agent Domain operators are free to implement any policy they wish with respect to the security of agent credentials. But it should be noted that the use of HTTPS to transport agent_login requests is STRONGLY RECOMMENDED. Services deployed by Linden Lab will refuse to to agent_login requests that do not use HTTPS. As described later in this document, Linden Lab region domains may reject protocol messages from agent domains that do not require the use HTTPS for username/password establishment or for agent_login requests.

It is also important to note that the Open Grid Beta Viewer from Linden Lab will refuse to attempt to connect to non-https LoginURI. Agent domain operators who do not wish to use HTTPS based LoginURIs will need to distribute their own viewer application.

So... to recap. End users authenticate themselves to agent domains by using a username / password pair. How an agent domain establishes the trustworthiness of the end user is beyond the scope of this document. HTTPS is your friend. Linden Lab's servers may snub you if you don't like HTTPS.

==Authenticating Client Applications to Region Domain Servers==

Region domain servers SHOULD NOT make "sensitive" services available to unauthenticated clients.

Client Applications use the possession of a capability by the client as proof of authorization to perform a particular operation.

Ergo, if you operate a Region Domain, do not issue sensitive caps to a client directly. Give the sensitive cap to an agent domain and let it give the cap to the client.

==Authenticating Agent Domain Servers to Client Applications==

Hosts implementing the agent domain portion of OGP SHOULD make services available via HTTPS / TLS. As mentioned above, Linden Lab servers will reject some protocol interactions if they do not take place over HTTPS (or some other secure transport).

Before trusting an Agent Domain server, Client Applications SHOULD check the following to ensure that the server being communicated with is actually the Agent Domain server that it claims to be:

* if the server's server certificate uses an IP address as part of the X.509 Subject Name, is this the same IP address the peer is using? (i.e. - does the IP address of the server match the IP address in the X.509 Subject Name?)
* if the server's server certificate uses a DNS Fully Qualified Domain Name (FQDN) as part of the X.509 Subject Name, does the IP address of the peer match the A record retrieved when doing a reverse DNS lookup?
* is the server's server certificate valid? (i.e. - is the current date between the validFrom and validTo dates in the server's certificate and every certificate in the chain up to a trusted certificate.
* is the server's server certificate explicitly trusted for authentication? (i.e. - is the server's certificate or a certificate in the server's certificate's chain explicitly trusted for authentication?)

It should be noted that these are all common options with most (if not all) TLS implementations, including OpenSSL.

It also implies that:

* the Client Application SHOULD maintain a list of "authentication trust-points" or certificates identifying organizations explicitly trusted by the Client Application for the purpose of authentication.
* <strike>the Client Application SHOULD NOT accept certificates that contain a wild-card in the Subject Name field of the certificate</strike>

==Authenticating Agent Domain Servers and Region Domain Servers to Each Other==

Sensitive communications between agent domain hosts and region domain hosts MUST be over a secure transport like TLS / HTTPS.

When an agent domain host initiates communication with a region domain host, it must verify the identity of the region domain via the region domain host's server certificate. The process listed in the Client Application to Agent Domain section above should be followed for agent to region communications.

<strike>To authenticate the agent domain to the region, the agent domain should provide its client certificate to the region domain host. The region domain may then authenticate the agent domain using the same process as above.

When a region domain host initiates communication with an agent domain host, the process is reversed. The Agent Domain's server certificate is validated first (by the region domain host), then the region domain's client certificate is validated (by the agent domain host).</strike>

Agent Domains should access sensitive resources ONLY via capabilities issued by the region domain.

Clever readers will note that this implies:

* the ability for both the agent domain and the region domain to generate server certificates for their systems.
* (and) the ability for both agent and region domains to manage a list of "authentication trust points" in a certificate chain.

Fortunately, this is a relatively well known process (though, administratively, it can be "less than easy" with existing open source tools.)

=Specific Issues With Linden Lab Software=

'''note:''' this section introduces ideas for discussion. no decision has yet been made to implement this proposal. no decision to do so is likely without community discussion.

==Linden Lab Self Signed Certificate For Agent and Region Domain Authentication==

Blergh. Okay, you caught us. We're using self-signed certificates.

In an environment where we were the only ones offering region hosting, agent hosting and making viewer software, this was not an unreasonable choice. But now we have to open this process up to allow interoperability with trusted agent and region domains.

In terms of the OGP Beta, this is likely not too onerous an administrative task. ['''note:''' the person who just wrote that is not, in fact, the person who would be fulfilling service requests, so your mileage may vary.] In the OGP Beta, we are not (yet) attempting to transer potentially sensitive assets and there are a relatively small number of region and agent domain operators.

So... the proposal is we (the community in general) move beyond Self-Signed Certs except for testing purposes.

The simplest way to meet the "move beyond self-signed certificates" requirement is for Linden Lab to operate a registration authority for the purpose of beginning the certification process for external agent and region domain operators.

Or we could use some set of common well-known CAs, like Verisign or somebody. Although they like charge money.

'''todo:''' fill out this section a touch more, maybe describing the process of registering a peer agent or region domain.

=Specific Issues With OpenSim Software=
'''note:''' Terevus, Zha, et al. do you want to add a few notes here?
Teravus: One thing to note here, however.. is you'll need to add your '''CA''' to the client's '''app_settings/CA.pem''' until the Linden/Verisign/Other CA process is worked out sufficiently. The directions for setting it up are in *svn*/contrib/junkCA

==Self Signed Certificates for Agent and Region Domain Authentication==
==Proposed Registration Authority for OpenSim Operators==

=Specific Issues With PyOGP Software=
'''Note:''' ''Tao... Sai... I know we discussed this a bit... but i'm blanking on what we said... so feel free to add stuff here, otherwise i'm going to add my best guess regarding how we want to handle it''
=Discussions=
*Gridnauts IRC
**Sepember [[User:Infinity_Linden/Gridnauts_2080913|13]]

[[Category:AW_Groupies]]
[[Category:Grid_Interoperability]]

User:Dale Innis/Group IM in OGP

Teravus Ousley — Tue, 09 Sep 2008 12:21:12 GMT

Teravus Ousley: /* See Also */

This page is to capture thoughts about how Group IM will / should / might work in the [[Open Grid Protocol]]. It is seeded with some ideas extracted from recent Zero Linden office hours and AWGroupies meetings.

=Group Definition=

At this point it is not defined what groups exactly are in the [[Open Grid Protocol]] architecture. There are at least three possible group implementations to think of:
* RD wide groups
* AD wide groups
* Open Grid wide groups

RD groups are not likely to exist, since the Group IM features is most likely to be handled by the agent domain - still they might be a possible use case and thus be implemented as a specialization of AD groups (possibly with a filter).

=Use Cases=

* A group wants to do predefined-group IM very much like SL / OpenSim Group IM today, only cross-grid (cross-domain)
* A group wants to do adhoc-group IM (i.e. "Friends Conference") very much like SL / OpenSim Group IM today, only cross-grid (cross-domain)
* Bridging (in any of various detailed senses) between OGP-based Group IM in some virtual world domain(s), and group IM in other contexts (IRC channels on existing IRC servers, Jabber servers, AIM, etc, etc, etc)
* One-to-one IM as a limiting case of any and all of the above (i.e. can the various approaches to the Group IM use-cases also serve for person-to-person IM)
* Spatial chat (i.e. can any or all of the IM solutions above also handle spatial chat, where everyone within range can hear what's being said? The answer may be "no", or "yes, but it's not the best solution", or whatever)
* You are in a RD run, say, at your company for purposes of company research collaboration. You find one of your co-workers is on-line, but in some other sim, but in the research RD. You are in the middle of something where you are so you wish to IM her a question. I think you'd want that text to travel only with the RD servers, so that under those conditions, the company would feel secure that it is all "behind the firewall". So now the question is -- do we need to expose that the users in some way (I have to choose *how* to IM her) or is there a reasonable way we can route that automatically. We need a way, that if the ADs and RD agree, that an AV to AV, or even group IM, can go entirely via the RD. (From Zero, at [https://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/2008_September_04 2008 Sept 04 Office Hours].)

=Requirements=

* In at least many use-cases, someone viewing a Group IM message should know with high confidence that it was really sent by the apparent sender.
* In at least some use-cases, it will be desirable to allow messages where the sender is *not* known with high confidence, but the messages are still delivered, and marked as insecure-sender.
* In at least many use-cases, someone posting a Group IM message should know with high confidence that it will be delivered only to bona fide group members.
* The solution should scale to, at the very least, simple extrapolations of the current SL group IM usage patterns.
* The solution should not require providing grid user credentials (username, password) to any agency besides the user's Agent Domain.
* The solution should not create a nonredundant single point of failure for the entire intragrid group IM system.

=Approaches=

* Sai suggests that, as a very first experiment and proof of concept, we move Group IM into the AD (Agent Domain), and allow inter-domain IMs by using the AD as a relay point.
* Various people have suggested that, as the underlying IM infrastructure, we make use of IRC or Jabber or something else that already exists. This still leaves open various questions, such as how identities are mapped and authentication done, but it has been suggested that these are easy to solve. We will attempt to extract from those making these suggestions just how they see it working. Preferably without violating the Geneva Convention.
** Infinity suggests we investigate the possibility that for cross-grid interoperability, we include a way to get a reference to an existing IRC/{X|I}MPP/RTP/etc. gateway 'cause she things adding XMPP or whatever to OGP is a little heavy.
** Dale says that that's fine, but we still gotta figure out and write how authentication to / through an existing gateway would work! And no one gets to say it's trivial unless they've describe the steps.
* It has of course been suggested that the underlying group IM mechanism be pluggable. This is a fine idea, but we must still define the interface that a qualifying plugin has to implement.

=Using the AD as a simple relay=

=Thoughts on the interface to a general plugin=

=Specific thoughts on the applicability / scalability of existing IM systems=

==IRC==

(In his [https://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/2008_September_04 Office Hours for 2008 Sept 04], Zero comments that they looked at the requirements of using IRC for SL Group IM traffic, and due in particular to the large number of group IMs that each AV is potentially in at once, even a professional IRC service provider estimated that scaling to SL levels would require lots of hardware. Not initially clear how the scalability compares to any other, non-IRC, approach, but it seems that this would at least potentially be a strain on existing IRC infrastructures.)

==Jabber==

==A Simple Design Example==

Some preliminary thoughts on how an existing IM / group IM protocol, server, and client (libraries) might be used to satisfy the requirements of the use-cases, and implications for OGP.

In the simplest architecture, we take some existing IM / group IM protocol that uses a central logical server (probably implemented as a scalable cluster), and that includes username / password authentication (this is more likely to be available than a cap-based one).

Each participating AD registers each of its users with the central server, using a uniqueified version of the username (username_ADname or whatever), and a password that the AD generates and records internally for that user, as well as passing to the viewer. (The user's AD password is not used, to avoid exposing it to the central IM server, per the requirements above.) Note that the server has to be modified so that not just anyone can create the user DaleInnis_SecondLife; only the authenticated SecondLife AD can be allowed to do this.

When the user logs in or logs out, joins or leaves a group, or does a query for existing groups, the information flows directly between the viewer and the IM server, using the uniqueified username and the generated password; the AD is "copied" on information about what groups the user belongs to. Similarly actual messaging traffic flows between the IM server and the viewer, which acts like any other client for the IM system, presenting to the user a view of the IM activity that conforms to the overall UI to the VW in question.

In summary, the AD's only role is to generate and store a password, to register the user with the IM server when the user is first created (and presumably to deregister the user if the user leaves the AD), and to track the list of groups the user belongs to. All other information flows between the viewer and the IM server.

Where does this design fall short, what are the limitations and challenges?
* One problem is that the central IM server is a serious single point of failure for all IM. We can imagine instead that there are a potentially large number of IM servers (potentially one per AD, even), each handling some subset of the existing groups. (Each AD's own IM server, for instance, could handle the groups that are "native" to that AD.) The viewer and the AD would then co-operate to register the user with the IM servers corresponding to all of the groups that the user joins.
** Finding out what groups exist is an issue here. One approach would be to provide easy access to the groups that are "native" to the IM server associated with the user's own AD, and (how?) allow the user to specifically ask what groups are available from other IM servers if the user knows their names.
* The existing IM server and protocol might not provide all of the functions that we expect of our group system. Would it provide "Busy"? Would it provide some form of Group Notices? (Or perhaps Group Notices would be done by another channel entirely.) Would it provide correctly for group ownership control, ejecting users from closed groups, and so on? (Need to add some of these to the design example.)
* Need to add group creation and deletion to this design. Does that introduce any fundamental complexities?

What requirements does this design place on OGP?
* To first order, only the communication between the viewer and the AD as to the list of groups that the user belongs to, and the generated password under which the user is registered with them. All other communication takes place over the relevant IM protocol, between the IM-client code in the viewer and the IM server.
* Anything else?

=Loosely related, further ramblings=

Since this page was started there is news that should influence our thoughts on group messaging, messaging in general, and how it could (or should) be handled by future protocols.

* One of these news ist that LindenLabs announced a new lite viewer, [[ AW Groupies/Chat Logs/AWGroupies-2008-09-02| "a lightweight, voice-enabled instant messaging client that will allow you to communicate with your Second Life friends without logging in to the full viewer. "]]. This is one way to deal with things and IMHO a good one, especially when it comes to the now technology-wise closed voice chat. Still, there should be a way to open text and voice chat to webservices suitable for furure needs, either exising ones (IRC, see above), or not yet existing ones (one idea here would be to SIP enable voice chat, but there are many more).

* The other news would be from Eric Reuters saying that [http://secondlife.reuters.com/stories/2008/09/03/ibm-adds-virtual-worlds-support-to-lotus-sametime/ "IBM showcases an integration of Sametime chat into 3D worlds" ] which would bridge text chat from Sametime into 3D worlds, most noteably Second Life. This again emphasizes that there is some use case for integration of ('plugable') (web) services to a variety of systems suited for content and community management.

=Some of the most relevant chat transcripts=

* [[AW_Groupies/Chat_Logs/AWGroupies-2008-08-26|AW Groupies chatlog 2008/08/26]]
* [[AW Groupies/Chat Logs/AWGroupies-2008-09-02|AW Groupies chatlog 2008/09/02]]
* [[User:Zero_Linden/Office_Hours/2008_September_04|Zero Linden office hours chatlog 20080/09/04]]

=See Also=

* [[AW_Groupies]]
* [[Protecting content in an open grid]]
* [[Open Grid Protocol]]
* [[SLGOGP_Teleport_Strawman]] (old?)
* [https://wiki.secondlife.com/wiki/User:Infinity_Linden/OGP_Trust_Model OGP Trust Model]
* [https://wiki.secondlife.com/wiki/User:Infinity_Linden/OGP_Trust_Model_UseCases OGP Trust Model Use Cases]
* [http://opensimulator.org/wiki/Proposed_IM_Flow Proposed person-to-person IM flow] in OpenSimulator (Teravus Ousley)
* [http://xyzzyxyzzy.net/2008/05/27/splitting-opensims-chat-module/ Splitting OpenSim's Chat Module]

[[Category:AW Groupies]]
[[Category:Grid Interoperability]]

Open Grid Public Beta/Map Locations

Teravus Ousley — Sat, 30 Aug 2008 03:50:01 GMT

Teravus Ousley:

OpenSim regions cannot be placed directly adjacent to existing regions on aditi or vaak.

:[[User:Zha_Ewry|Zha Ewry]]: "Setup as a very basic stand alone opensim. set the default location and the location of your region to be the same value, and run only one region on the server. (ie. in OpenSim.ini, make sure you set default_loc_x and default_loc_y, and make them match the ones in the default.xml in the Regions subdirectory of you r bin directory in your install."

For clarity, please specify your OGP claim as well as what those would translate to in sim_location_x and sim_location_y. '''Remember, in OpenSimulator, your sim_location_x and sim_location_y is your OGP claim divided by 256.'''

Non-Linden Lab OpenSims should use default_loc_x and default_loc_y values greater than 4096.

Claim Map Locations Below

Open Grid Public(OGP) Claims that are not multiples of 256 will be marked in pink.

==[[User:Whump_Linden | Whump Linden ]]==

* 524288/524288 (OGP) - 2048/2048 (OpenSimulator)
* 589824/655360 (OGP) - 2304/2560 (OpenSimulator)

==[[User:Enus_Linden | Enus Linden ]]==

* 2304/2304

==[[User:Dahlia_Trimble | Dahlia Trimble ]]==

* 4096/4096
* 4352/4352
* 4608/4608

==[[User:Christophe003_Carter | Christophe003 Carter ]]==

* 4608/4608

==[[User:Pier_Tempel | Pier Tempel ]]==

* 5120/5120

==[[User:BlueWall Slade | Bluewall Slade]]==
*6400/6400 URI: http://ascent.bluewallgroup.com:9300

==[[User:Winne Woodget | Winne Woodget]]==

* 6912/6912

==[[User:Matias Carter | Matias Carter]]==

* 7168/7168

==[[User:Xugu Madison | Xugu Madison]]==

* 8192/8192

==[[User:Eddy Stryker | Eddy Stryker]]==

* 5888/5888

==[[User:Latif Khalifa | Latif Khalifa]]==

* 6144/6144

==[[User:Tracy Welles | Tracy Welles ]]==

* 4352/4352

==[[User:Bluecat Jun | Bluecat Jun ]]==

* 7424/7424

==[[User:Alynna Vixen | Alynna Vixen ]]==

* 4864/5120 - [http://kitsunet.net:9000/ Kitsuhana]

==[[User:Julie Wasserstrom | Julie Wasserstrom ]]==

* 5888/5888

==[[User:Chris Samtanko | Chris Samtanko ]]==

*4864/4864 - http://planck.vworlds.co.uk:9000
*2560256/2559488(OGP) 10001/9998 (OSGrid) - http://dirac.vworlds.co.uk:9000

==[http://mrtopf.de/blog Tao Takashi ]==

*6656/6656

==[[User:Jim Kupferberg | Jim Kupferberg ]]==

*6656/6400

==[[User:Emma Nowhere | Emma Nowhere ]]==

*5120/5120

==[[User:Gomez Bracken | Gomez Bracken ]]==

*8448/8448

==[[User:Ciemaar Flintoff | Ciemaar Flintoff ]]==

*6656/7680

==[[User:Media Hax | Media Hax ]]==

*5632/5632
==[[User:Twa Hinkle | Twa Hinkle ]]==

*7680/7680

==[[User:Vicero Lambert | Vicero Lambert ]]==

*5130/5130

==[[User:Whichway Janus | Whichway Janus ]]==

*6656/6912 Updated protocol sim - requires OGP Viewer build 94858 or higher.

==[[User:Stamo Stuer | Stamo Stuer ]]==

*5376/5376

==[[User:Patnad Babii | Patnad Babii ]]==

* <font color="pink">9728/9728</font>

==[[User:Torrid Luna | Torrid Luna ]]==

*6144/8448

==[http://blog.simgis.com Darb Dabney ]==

* 4608/4352

==[[User:Morph Wollongong | Morph Wollongong ]]==

* 6789/6789

==[[User:Estate Shepherd | Estate Shepherd ]]==

* 8704/8704

==[[User:Zerodog Witte | Zerodog Witte ]]==

* 8448/8448

==[[User:Lil Linden | Lil Linden]]==

* 2806/2806

==[[User:EriX Oh | EriX Oh]]==

* 4352/4864

==[[User:James Benedek | James Benedek]]==

* 7936/7936

==[[User:Hawk Carter | Hawk Carter]]==

* 9984/9984 - URI: http://81.169.130.81:10600 (UP)

==[[User:McCoy Ducatillon | McCoy Ducatillon]]==

* 8960/8960

==[[User:Laurent Bechir | Laurent Bechir]]==

* 9216/9216

==[[User:Economic Mip | Economic Mip]]==

* 9216/8960

==[[User:whyroc Slade | whyroc Slade]]==

* 10240/10240

==[[User:Bartholomew Kleiber | Bartholomew Kleiber]]==

* 10752/10752

==[[User:Arbitar Basiat | Arbitar Basiat]]==

* 13056/13056

==[[User:KustomKreator4u Inglewood | KustomKreator4u Inglewood]]==

* 11008/11008

==[[User:TheCoolLeader Boyer | TheCoolLeader Boyer ]]==

* 16384/16384

==[[User:Aidamina Hunt | Aidamina Hunt ]]==

* 25600/25600

==[[User:Stirling Allen|Stirling Allen]] 19:59, 4 August 2008 (PDT)==

*65536/65536 (ETA Friday 9 August)

==[[User:Sonof Marvin|Sonof Marvin]]==

*69683/69683

==[[User:Radioactive Rosca|Radioactive Rosca]]==

*4864/5376

==[[User:Jim Brock|Jim Brock]]==

* 9472/9472

==[[User:Jonit Ivory|Jonit Ivory]]==

* 11264/11264

==[[User:Ideia Boa|Ideia Boa]]==

* 4096/4608

==[[User:Athanasius Skytower|Athanasius Skytower]]==

* 5632/6656

==[[User:camilla Yosuke|camilla Yosuke]]==

* 6656/4352
==[[User:bonghit Schism|bonghit Schism]]==

* 12544/12544

==[[User:Elio Donat|Elio Donat]]==

* 6656/4353

==[[User: Just Dinkin|Just Dinkin]]==
* 11520/11520

==[[User: Miki Gymnast|Miki Gymnast]]==
* 8448/5632

==[[User: Jillian Taringa|Jillian Taringa]]==
* 11776/11776

==[[User: JB Kraft|JB Kraft]]==
* 6400/4608

==[[User: Wangxiang Tuxing|Wangxiang Tuxing]]==
* 9472/11264

==[[User: Tensai Hilra|Tensai Hilra]]==
* 12800/12800

==[[User: Mirt Tenk|Mirt Tenk]]==
* 5376/7680

==[[User: Maniac Choche|Maniac Choche]]==
* 5632/5888

==[[User: Kish Kas|Kish Kas]]==
* 6400/6656

==[[User: Bit2zero Planer|Bit2zero Planer]]==
* 6500/6656

==[[User: Trifile Toshi|Trifile Toshi]]==
* 20736/20736

==[[User: Micheil Merlin|Micheil Merlin]]==
* 4608/5120

==[[User: Yuu Nakamichi|Yuu Nakamichi]]==
* 9728/8960

==[[User: Norgan Torok|Norgan Torok]]==
* 6400/6400

==[[User: Master Huldschinsky|Master Huldschinsky]]==
* 16400/16400

==[[User: Giulio Perhaps|Giulio Perhaps]]==
* 16640/16640

==[[User: Lexa Sands|Lexa Sands]]==
* 6400/6144 - Lexania - URI: http://lexa.ath.cx:9000

==[[User:Junta Kohime | Junta Kohime ]]==

* 6400/5888 - Born To Learn - URI: http://borntolearn.dyndns.org:9000

==[[User: Strawberry Fride | Strawberry Fride]]==
* 17408/17408

==[[User: G2 Proto | G2 Proto]]==
* 17664/17664 http://www.reactiongrid.com http://reactiongrid.com:10500

==[[User: Kuraiko Yoshikawa|Kuraiko Yoshikawa]]==
*4096/4864 [http://zeitenwerk.de:9128 URI]

==[[User: Prometheus Dovgal|Prometheus Dovgal]]==
*17920/17920

==[[User: Cow Taurog|Cow Taurog]]==
* 16128/16128 - [http://cowtaurog.cjb.net:9000 The Pasture]

==[[User: Camus Omegamu|Camus Omegamu]]==
* 4608/8704

==[[User: m0rdred Veil|m0rdred Veil]]==
* 18176/18176 - La Isla West - URI: http://24.30.54.84:9000

==[[User: Kliger Dinkin|Kliger Dinkin]]==
* 13312/13312

==[[User: Audoa Giha|Audoa Giha]]==
* 19200/19200 Will be up/down for maint otherwise 24/7 URI: http://71.170.194.115:9010/

==[[User: Ceyna Indigo|Ceyna Indigo]]==
* 32768/32768
==[[User: Bulli Schumann|Bulli Schumann]]==
* 46080/46080 - Come visit if you like... still very barren... but it will prob. be expanded in a while: http://83.247.63.174:9000
* 46080/46336 - experimental region (well... aren't they all?)
* 46336/46080 - experimental region (well... aren't they all?)
* 46336/46336 - experimental region (well... aren't they all?)

==[[User: Ansel Gasparini|Ansel Gasparini]]==
* 4352/4608

==[[User: Xerbi Zerbino|Xerbi Zerbino]]==
* 12032/12032

==[[User: Siddhartha Fonda | Siddhartha Fonda]]==
* 22272/22272

==[[User: elmanytas Ferrentino | elmanytas Ferrentino]]==
* 2560/2304

==[[User:Mana Janus|Mana Janus]]==
* 5120/7680

==[[User:Easyfresh Auer|Easyfresh Auer]]==
* 1090048/1090048

==[[User:Nomad Ingwer|Nomad Ingwer]]==
* 27648/27648

==[[User:Quinlan Quimby|Quinlan Quimby]]==
* 28416/28416

==[[User:Woot Avro|Woot Avro]]==
* 4096/4608

==[[User:Herfulnerful Holsworthy|Herfulnerful Holsworthy]]==
* 8192/16384
* 8192/16640

==[[User:pb Qinan|pb Qinan]]==
* 9472/8960

==[[User:Tara5 Oh|Tara5 Oh]]==
*15616/15616 - Visit us at URI: ugotrade.net:9000

==[[User:Drax Lemieux|Drax Lemieux]]==
*16128/16128

==[[User:Opensource Obscure|Opensource Obscure]]==
*51200/51200

==[[User:Harleen Gretzky|Harleen Gretzky]]==
*5120/51200

==[[User:Lapsus Weinstein|Lapsus Weinstein]]==
* Experimental Sandbox on Physical and Mental Health
-loginuri http://grid.centromimir.it:9000 -loginpage http://grid.centromimir.it
* Garda Lake Open Simulation, Centro Mimir, Suburbia, Caffe Freud
* 17408/17408(ogp)
* 17408/17409(ogp)
* 17409/17408(ogp)
* 17409/17409(ogp)

==[[User:Amarillo Mertel|Amarillo Mertel]]==
*25600/25600

==[[User:Rasmusson Oranos|Rasmusson Oranos]]==
*18432/18432

==[[User:Tylor Ferraris|Tylor Ferraris]]==
*1054976/1054976

==[[User:Teravus Ousley|Teravus Ousley]]==
*1048832/1048832 (ogp) - 4097/4097 (OpenSimulator)

==[[User:EloiseJolie Capalini|EloiseJolie Capalini]]==
*46080/46080 (ogp) - URI: http://opensimgrid.com:9000

==[[User:Jabba_Gruppman | Jabba Gruppman]]==

* 5120/11264

==[[User:Cecelia Lewis | Cecelia Lewis]]==
* 25856/25856

==[[User:Albert Revolution|Albert Revolution]]==
*15872/15872 (ogp) - SOMBRALAND -
Accesible some hours at week. Spanish Time. I would like to test
importations from 3dMax Studio, Sculpties and building

==[[User:Dedric Mauriac | Dedric Mauriac]]==
*4352/5120

==[[User:Micky Jansma | Micky Jansma]]==
*28160/28160

==[[User:Burnman Bedlam | Burnman Bedlam]]==
*14848/14848

==[[User:Rancher Koenig | Rancher Koenig]]==
*5120/5120

==[[User:Fin Umarov | Fin Umarov]]==
*25344/25344

==[[User:Berry Steinhoff | Berry Steinhoff]]==
*13568/13568

==[[User:Kaly Mayako|Kaly Mayako]]==
*9666/9666 (ogp46) - URI: http://jukastream.com:9000
Open 10AM - 4PM French time

[[Category:Open_Grid_Public_Beta]]

Open Grid Public Beta/Map Locations

Teravus Ousley — Sat, 30 Aug 2008 03:24:11 GMT

Teravus Ousley: /* Enus Linden */

OpenSim regions cannot be placed directly adjacent to existing regions on aditi or vaak.

:[[User:Zha_Ewry|Zha Ewry]]: "Setup as a very basic stand alone opensim. set the default location and the location of your region to be the same value, and run only one region on the server. (ie. in OpenSim.ini, make sure you set default_loc_x and default_loc_y, and make them match the ones in the default.xml in the Regions subdirectory of you r bin directory in your install."

For clarity, please specify your OGP claim as well as what those would translate to in sim_location_x and sim_location_y. '''Remember, in OpenSimulator, your sim_location_x and sim_location_y is your OGP claim divided by 256.'''

Whump's region is at 2048 by 2048. To configure OpenSimulator to use that grid spot, he would configure his default.xml file like; default_loc_x="8" and default_loc_y="8" because 2048 divided by 256 is 8.

Non-Linden Lab OpenSims should use default_loc_x and default_loc_y values greater than 4096.

Claim Map Locations Below

Open Grid Public(OGP) Claims that are not multiples of 256 will be marked in pink.

==[[User:Whump_Linden | Whump Linden ]]==

* 524288/524288 (OGP) - 2048/2048 (OpenSimulator)
* 589824/655360 (OGP) - 2304/2560 (OpenSimulator)

==[[User:Enus_Linden | Enus Linden ]]==

* 2304/2304

==[[User:Dahlia_Trimble | Dahlia Trimble ]]==

* 4096/4096
* 4352/4352
* 4608/4608

==[[User:Christophe003_Carter | Christophe003 Carter ]]==

* 4608/4608

==[[User:Pier_Tempel | Pier Tempel ]]==

* 5120/5120

==[[User:BlueWall Slade | Bluewall Slade]]==
*6400/6400 URI: http://ascent.bluewallgroup.com:9300

==[[User:Winne Woodget | Winne Woodget]]==

* 6912/6912

==[[User:Matias Carter | Matias Carter]]==

* 7168/7168

==[[User:Xugu Madison | Xugu Madison]]==

* 8192/8192

==[[User:Eddy Stryker | Eddy Stryker]]==

* 5888/5888

==[[User:Latif Khalifa | Latif Khalifa]]==

* 6144/6144

==[[User:Tracy Welles | Tracy Welles ]]==

* 4352/4352

==[[User:Bluecat Jun | Bluecat Jun ]]==

* 7424/7424

==[[User:Alynna Vixen | Alynna Vixen ]]==

* 4864/5120 - [http://kitsunet.net:9000/ Kitsuhana]

==[[User:Julie Wasserstrom | Julie Wasserstrom ]]==

* 5888/5888

==[[User:Chris Samtanko | Chris Samtanko ]]==

*4864/4864 - http://planck.vworlds.co.uk:9000
*2560256/2559488(OGP) 10001/9998 (OSGrid) - http://dirac.vworlds.co.uk:9000

==[http://mrtopf.de/blog Tao Takashi ]==

*6656/6656

==[[User:Jim Kupferberg | Jim Kupferberg ]]==

*6656/6400

==[[User:Emma Nowhere | Emma Nowhere ]]==

*5120/5120

==[[User:Gomez Bracken | Gomez Bracken ]]==

*8448/8448

==[[User:Ciemaar Flintoff | Ciemaar Flintoff ]]==

*6656/7680

==[[User:Media Hax | Media Hax ]]==

*5632/5632
==[[User:Twa Hinkle | Twa Hinkle ]]==

*7680/7680

==[[User:Vicero Lambert | Vicero Lambert ]]==

*5130/5130

==[[User:Whichway Janus | Whichway Janus ]]==

*6656/6912 Updated protocol sim - requires OGP Viewer build 94858 or higher.

==[[User:Stamo Stuer | Stamo Stuer ]]==

*5376/5376

==[[User:Patnad Babii | Patnad Babii ]]==

* <font color="pink">9728/9728</font>

==[[User:Torrid Luna | Torrid Luna ]]==

*6144/8448

==[http://blog.simgis.com Darb Dabney ]==

* 4608/4352

==[[User:Morph Wollongong | Morph Wollongong ]]==

* 6789/6789

==[[User:Estate Shepherd | Estate Shepherd ]]==

* 8704/8704

==[[User:Zerodog Witte | Zerodog Witte ]]==

* 8448/8448

==[[User:Lil Linden | Lil Linden]]==

* 2806/2806

==[[User:EriX Oh | EriX Oh]]==

* 4352/4864

==[[User:James Benedek | James Benedek]]==

* 7936/7936

==[[User:Hawk Carter | Hawk Carter]]==

* 9984/9984 - URI: http://81.169.130.81:10600 (UP)

==[[User:McCoy Ducatillon | McCoy Ducatillon]]==

* 8960/8960

==[[User:Laurent Bechir | Laurent Bechir]]==

* 9216/9216

==[[User:Economic Mip | Economic Mip]]==

* 9216/8960

==[[User:whyroc Slade | whyroc Slade]]==

* 10240/10240

==[[User:Bartholomew Kleiber | Bartholomew Kleiber]]==

* 10752/10752

==[[User:Arbitar Basiat | Arbitar Basiat]]==

* 13056/13056

==[[User:KustomKreator4u Inglewood | KustomKreator4u Inglewood]]==

* 11008/11008

==[[User:TheCoolLeader Boyer | TheCoolLeader Boyer ]]==

* 16384/16384

==[[User:Aidamina Hunt | Aidamina Hunt ]]==

* 25600/25600

==[[User:Stirling Allen|Stirling Allen]] 19:59, 4 August 2008 (PDT)==

*65536/65536 (ETA Friday 9 August)

==[[User:Sonof Marvin|Sonof Marvin]]==

*69683/69683

==[[User:Radioactive Rosca|Radioactive Rosca]]==

*4864/5376

==[[User:Jim Brock|Jim Brock]]==

* 9472/9472

==[[User:Jonit Ivory|Jonit Ivory]]==

* 11264/11264

==[[User:Ideia Boa|Ideia Boa]]==

* 4096/4608

==[[User:Athanasius Skytower|Athanasius Skytower]]==

* 5632/6656

==[[User:camilla Yosuke|camilla Yosuke]]==

* 6656/4352
==[[User:bonghit Schism|bonghit Schism]]==

* 12544/12544

==[[User:Elio Donat|Elio Donat]]==

* 6656/4353

==[[User: Just Dinkin|Just Dinkin]]==
* 11520/11520

==[[User: Miki Gymnast|Miki Gymnast]]==
* 8448/5632

==[[User: Jillian Taringa|Jillian Taringa]]==
* 11776/11776

==[[User: JB Kraft|JB Kraft]]==
* 6400/4608

==[[User: Wangxiang Tuxing|Wangxiang Tuxing]]==
* 9472/11264

==[[User: Tensai Hilra|Tensai Hilra]]==
* 12800/12800

==[[User: Mirt Tenk|Mirt Tenk]]==
* 5376/7680

==[[User: Maniac Choche|Maniac Choche]]==
* 5632/5888

==[[User: Kish Kas|Kish Kas]]==
* 6400/6656

==[[User: Bit2zero Planer|Bit2zero Planer]]==
* 6500/6656

==[[User: Trifile Toshi|Trifile Toshi]]==
* 20736/20736

==[[User: Micheil Merlin|Micheil Merlin]]==
* 4608/5120

==[[User: Yuu Nakamichi|Yuu Nakamichi]]==
* 9728/8960

==[[User: Norgan Torok|Norgan Torok]]==
* 6400/6400

==[[User: Master Huldschinsky|Master Huldschinsky]]==
* 16400/16400

==[[User: Giulio Perhaps|Giulio Perhaps]]==
* 16640/16640

==[[User: Lexa Sands|Lexa Sands]]==
* 6400/6144 - Lexania - URI: http://lexa.ath.cx:9000

==[[User:Junta Kohime | Junta Kohime ]]==

* 6400/5888 - Born To Learn - URI: http://borntolearn.dyndns.org:9000

==[[User: Strawberry Fride | Strawberry Fride]]==
* 17408/17408

==[[User: G2 Proto | G2 Proto]]==
* 17664/17664 http://www.reactiongrid.com http://reactiongrid.com:10500

==[[User: Kuraiko Yoshikawa|Kuraiko Yoshikawa]]==
*4096/4864 [http://zeitenwerk.de:9128 URI]

==[[User: Prometheus Dovgal|Prometheus Dovgal]]==
*17920/17920

==[[User: Cow Taurog|Cow Taurog]]==
* 16128/16128 - [http://cowtaurog.cjb.net:9000 The Pasture]

==[[User: Camus Omegamu|Camus Omegamu]]==
* 4608/8704

==[[User: m0rdred Veil|m0rdred Veil]]==
* 18176/18176 - La Isla West - URI: http://24.30.54.84:9000

==[[User: Kliger Dinkin|Kliger Dinkin]]==
* 13312/13312

==[[User: Audoa Giha|Audoa Giha]]==
* 19200/19200 Will be up/down for maint otherwise 24/7 URI: http://71.170.194.115:9010/

==[[User: Ceyna Indigo|Ceyna Indigo]]==
* 32768/32768
==[[User: Bulli Schumann|Bulli Schumann]]==
* 46080/46080 - Come visit if you like... still very barren... but it will prob. be expanded in a while: http://83.247.63.174:9000
* 46080/46336 - experimental region (well... aren't they all?)
* 46336/46080 - experimental region (well... aren't they all?)
* 46336/46336 - experimental region (well... aren't they all?)

==[[User: Ansel Gasparini|Ansel Gasparini]]==
* 4352/4608

==[[User: Xerbi Zerbino|Xerbi Zerbino]]==
* 12032/12032

==[[User: Siddhartha Fonda | Siddhartha Fonda]]==
* 22272/22272

==[[User: elmanytas Ferrentino | elmanytas Ferrentino]]==
* 2560/2304

==[[User:Mana Janus|Mana Janus]]==
* 5120/7680

==[[User:Easyfresh Auer|Easyfresh Auer]]==
* 1090048/1090048

==[[User:Nomad Ingwer|Nomad Ingwer]]==
* 27648/27648

==[[User:Quinlan Quimby|Quinlan Quimby]]==
* 28416/28416

==[[User:Woot Avro|Woot Avro]]==
* 4096/4608

==[[User:Herfulnerful Holsworthy|Herfulnerful Holsworthy]]==
* 8192/16384
* 8192/16640

==[[User:pb Qinan|pb Qinan]]==
* 9472/8960

==[[User:Tara5 Oh|Tara5 Oh]]==
*15616/15616 - Visit us at URI: ugotrade.net:9000

==[[User:Drax Lemieux|Drax Lemieux]]==
*16128/16128

==[[User:Opensource Obscure|Opensource Obscure]]==
*51200/51200

==[[User:Harleen Gretzky|Harleen Gretzky]]==
*5120/51200

==[[User:Lapsus Weinstein|Lapsus Weinstein]]==
* Experimental Sandbox on Physical and Mental Health
-loginuri http://grid.centromimir.it:9000 -loginpage http://grid.centromimir.it
* Garda Lake Open Simulation, Centro Mimir, Suburbia, Caffe Freud
* 17408/17408(ogp)
* 17408/17409(ogp)
* 17409/17408(ogp)
* 17409/17409(ogp)

==[[User:Amarillo Mertel|Amarillo Mertel]]==
*25600/25600

==[[User:Rasmusson Oranos|Rasmusson Oranos]]==
*18432/18432

==[[User:Tylor Ferraris|Tylor Ferraris]]==
*1054976/1054976

==[[User:Teravus Ousley|Teravus Ousley]]==
*1048832/1048832 (ogp) - 4097/4097 (OpenSimulator)

==[[User:EloiseJolie Capalini|EloiseJolie Capalini]]==
*46080/46080 (ogp) - URI: http://opensimgrid.com:9000

==[[User:Jabba_Gruppman | Jabba Gruppman]]==

* 5120/11264

==[[User:Cecelia Lewis | Cecelia Lewis]]==
* 25856/25856

==[[User:Albert Revolution|Albert Revolution]]==
*15872/15872 (ogp) - SOMBRALAND -
Accesible some hours at week. Spanish Time. I would like to test
importations from 3dMax Studio, Sculpties and building

==[[User:Dedric Mauriac | Dedric Mauriac]]==
*4352/5120

==[[User:Micky Jansma | Micky Jansma]]==
*28160/28160

==[[User:Burnman Bedlam | Burnman Bedlam]]==
*14848/14848

==[[User:Rancher Koenig | Rancher Koenig]]==
*5120/5120

==[[User:Fin Umarov | Fin Umarov]]==
*25344/25344

==[[User:Berry Steinhoff | Berry Steinhoff]]==
*13568/13568

==[[User:Kaly Mayako|Kaly Mayako]]==
*9666/9666 (ogp46) - URI: http://jukastream.com:9000
Open 10AM - 4PM French time

[[Category:Open_Grid_Public_Beta]]

Open Grid Public Beta/Map Locations

Teravus Ousley — Sat, 30 Aug 2008 03:23:38 GMT

Teravus Ousley:

OpenSim regions cannot be placed directly adjacent to existing regions on aditi or vaak.

:[[User:Zha_Ewry|Zha Ewry]]: "Setup as a very basic stand alone opensim. set the default location and the location of your region to be the same value, and run only one region on the server. (ie. in OpenSim.ini, make sure you set default_loc_x and default_loc_y, and make them match the ones in the default.xml in the Regions subdirectory of you r bin directory in your install."

For clarity, please specify your OGP claim as well as what those would translate to in sim_location_x and sim_location_y. '''Remember, in OpenSimulator, your sim_location_x and sim_location_y is your OGP claim divided by 256.'''

Whump's region is at 2048 by 2048. To configure OpenSimulator to use that grid spot, he would configure his default.xml file like; default_loc_x="8" and default_loc_y="8" because 2048 divided by 256 is 8.

Non-Linden Lab OpenSims should use default_loc_x and default_loc_y values greater than 4096.

Claim Map Locations Below

Open Grid Public(OGP) Claims that are not multiples of 256 will be marked in pink.

==[[User:Whump_Linden | Whump Linden ]]==

* 524288/524288 (OGP) - 2048/2048 (OpenSimulator)
* 589824/655360 (OGP) - 2304/2560 (OpenSimulator)

==[[User:Enus_Linden | Enus Linden ]]==

* 2304/2304 (OGP) - 9/8 (OpenSimulator)

==[[User:Dahlia_Trimble | Dahlia Trimble ]]==

* 4096/4096
* 4352/4352
* 4608/4608

==[[User:Christophe003_Carter | Christophe003 Carter ]]==

* 4608/4608

==[[User:Pier_Tempel | Pier Tempel ]]==

* 5120/5120

==[[User:BlueWall Slade | Bluewall Slade]]==
*6400/6400 URI: http://ascent.bluewallgroup.com:9300

==[[User:Winne Woodget | Winne Woodget]]==

* 6912/6912

==[[User:Matias Carter | Matias Carter]]==

* 7168/7168

==[[User:Xugu Madison | Xugu Madison]]==

* 8192/8192

==[[User:Eddy Stryker | Eddy Stryker]]==

* 5888/5888

==[[User:Latif Khalifa | Latif Khalifa]]==

* 6144/6144

==[[User:Tracy Welles | Tracy Welles ]]==

* 4352/4352

==[[User:Bluecat Jun | Bluecat Jun ]]==

* 7424/7424

==[[User:Alynna Vixen | Alynna Vixen ]]==

* 4864/5120 - [http://kitsunet.net:9000/ Kitsuhana]

==[[User:Julie Wasserstrom | Julie Wasserstrom ]]==

* 5888/5888

==[[User:Chris Samtanko | Chris Samtanko ]]==

*4864/4864 - http://planck.vworlds.co.uk:9000
*2560256/2559488(OGP) 10001/9998 (OSGrid) - http://dirac.vworlds.co.uk:9000

==[http://mrtopf.de/blog Tao Takashi ]==

*6656/6656

==[[User:Jim Kupferberg | Jim Kupferberg ]]==

*6656/6400

==[[User:Emma Nowhere | Emma Nowhere ]]==

*5120/5120

==[[User:Gomez Bracken | Gomez Bracken ]]==

*8448/8448

==[[User:Ciemaar Flintoff | Ciemaar Flintoff ]]==

*6656/7680

==[[User:Media Hax | Media Hax ]]==

*5632/5632
==[[User:Twa Hinkle | Twa Hinkle ]]==

*7680/7680

==[[User:Vicero Lambert | Vicero Lambert ]]==

*5130/5130

==[[User:Whichway Janus | Whichway Janus ]]==

*6656/6912 Updated protocol sim - requires OGP Viewer build 94858 or higher.

==[[User:Stamo Stuer | Stamo Stuer ]]==

*5376/5376

==[[User:Patnad Babii | Patnad Babii ]]==

* <font color="pink">9728/9728</font>

==[[User:Torrid Luna | Torrid Luna ]]==

*6144/8448

==[http://blog.simgis.com Darb Dabney ]==

* 4608/4352

==[[User:Morph Wollongong | Morph Wollongong ]]==

* 6789/6789

==[[User:Estate Shepherd | Estate Shepherd ]]==

* 8704/8704

==[[User:Zerodog Witte | Zerodog Witte ]]==

* 8448/8448

==[[User:Lil Linden | Lil Linden]]==

* 2806/2806

==[[User:EriX Oh | EriX Oh]]==

* 4352/4864

==[[User:James Benedek | James Benedek]]==

* 7936/7936

==[[User:Hawk Carter | Hawk Carter]]==

* 9984/9984 - URI: http://81.169.130.81:10600 (UP)

==[[User:McCoy Ducatillon | McCoy Ducatillon]]==

* 8960/8960

==[[User:Laurent Bechir | Laurent Bechir]]==

* 9216/9216

==[[User:Economic Mip | Economic Mip]]==

* 9216/8960

==[[User:whyroc Slade | whyroc Slade]]==

* 10240/10240

==[[User:Bartholomew Kleiber | Bartholomew Kleiber]]==

* 10752/10752

==[[User:Arbitar Basiat | Arbitar Basiat]]==

* 13056/13056

==[[User:KustomKreator4u Inglewood | KustomKreator4u Inglewood]]==

* 11008/11008

==[[User:TheCoolLeader Boyer | TheCoolLeader Boyer ]]==

* 16384/16384

==[[User:Aidamina Hunt | Aidamina Hunt ]]==

* 25600/25600

==[[User:Stirling Allen|Stirling Allen]] 19:59, 4 August 2008 (PDT)==

*65536/65536 (ETA Friday 9 August)

==[[User:Sonof Marvin|Sonof Marvin]]==

*69683/69683

==[[User:Radioactive Rosca|Radioactive Rosca]]==

*4864/5376

==[[User:Jim Brock|Jim Brock]]==

* 9472/9472

==[[User:Jonit Ivory|Jonit Ivory]]==

* 11264/11264

==[[User:Ideia Boa|Ideia Boa]]==

* 4096/4608

==[[User:Athanasius Skytower|Athanasius Skytower]]==

* 5632/6656

==[[User:camilla Yosuke|camilla Yosuke]]==

* 6656/4352
==[[User:bonghit Schism|bonghit Schism]]==

* 12544/12544

==[[User:Elio Donat|Elio Donat]]==

* 6656/4353

==[[User: Just Dinkin|Just Dinkin]]==
* 11520/11520

==[[User: Miki Gymnast|Miki Gymnast]]==
* 8448/5632

==[[User: Jillian Taringa|Jillian Taringa]]==
* 11776/11776

==[[User: JB Kraft|JB Kraft]]==
* 6400/4608

==[[User: Wangxiang Tuxing|Wangxiang Tuxing]]==
* 9472/11264

==[[User: Tensai Hilra|Tensai Hilra]]==
* 12800/12800

==[[User: Mirt Tenk|Mirt Tenk]]==
* 5376/7680

==[[User: Maniac Choche|Maniac Choche]]==
* 5632/5888

==[[User: Kish Kas|Kish Kas]]==
* 6400/6656

==[[User: Bit2zero Planer|Bit2zero Planer]]==
* 6500/6656

==[[User: Trifile Toshi|Trifile Toshi]]==
* 20736/20736

==[[User: Micheil Merlin|Micheil Merlin]]==
* 4608/5120

==[[User: Yuu Nakamichi|Yuu Nakamichi]]==
* 9728/8960

==[[User: Norgan Torok|Norgan Torok]]==
* 6400/6400

==[[User: Master Huldschinsky|Master Huldschinsky]]==
* 16400/16400

==[[User: Giulio Perhaps|Giulio Perhaps]]==
* 16640/16640

==[[User: Lexa Sands|Lexa Sands]]==
* 6400/6144 - Lexania - URI: http://lexa.ath.cx:9000

==[[User:Junta Kohime | Junta Kohime ]]==

* 6400/5888 - Born To Learn - URI: http://borntolearn.dyndns.org:9000

==[[User: Strawberry Fride | Strawberry Fride]]==
* 17408/17408

==[[User: G2 Proto | G2 Proto]]==
* 17664/17664 http://www.reactiongrid.com http://reactiongrid.com:10500

==[[User: Kuraiko Yoshikawa|Kuraiko Yoshikawa]]==
*4096/4864 [http://zeitenwerk.de:9128 URI]

==[[User: Prometheus Dovgal|Prometheus Dovgal]]==
*17920/17920

==[[User: Cow Taurog|Cow Taurog]]==
* 16128/16128 - [http://cowtaurog.cjb.net:9000 The Pasture]

==[[User: Camus Omegamu|Camus Omegamu]]==
* 4608/8704

==[[User: m0rdred Veil|m0rdred Veil]]==
* 18176/18176 - La Isla West - URI: http://24.30.54.84:9000

==[[User: Kliger Dinkin|Kliger Dinkin]]==
* 13312/13312

==[[User: Audoa Giha|Audoa Giha]]==
* 19200/19200 Will be up/down for maint otherwise 24/7 URI: http://71.170.194.115:9010/

==[[User: Ceyna Indigo|Ceyna Indigo]]==
* 32768/32768
==[[User: Bulli Schumann|Bulli Schumann]]==
* 46080/46080 - Come visit if you like... still very barren... but it will prob. be expanded in a while: http://83.247.63.174:9000
* 46080/46336 - experimental region (well... aren't they all?)
* 46336/46080 - experimental region (well... aren't they all?)
* 46336/46336 - experimental region (well... aren't they all?)

==[[User: Ansel Gasparini|Ansel Gasparini]]==
* 4352/4608

==[[User: Xerbi Zerbino|Xerbi Zerbino]]==
* 12032/12032

==[[User: Siddhartha Fonda | Siddhartha Fonda]]==
* 22272/22272

==[[User: elmanytas Ferrentino | elmanytas Ferrentino]]==
* 2560/2304

==[[User:Mana Janus|Mana Janus]]==
* 5120/7680

==[[User:Easyfresh Auer|Easyfresh Auer]]==
* 1090048/1090048

==[[User:Nomad Ingwer|Nomad Ingwer]]==
* 27648/27648

==[[User:Quinlan Quimby|Quinlan Quimby]]==
* 28416/28416

==[[User:Woot Avro|Woot Avro]]==
* 4096/4608

==[[User:Herfulnerful Holsworthy|Herfulnerful Holsworthy]]==
* 8192/16384
* 8192/16640

==[[User:pb Qinan|pb Qinan]]==
* 9472/8960

==[[User:Tara5 Oh|Tara5 Oh]]==
*15616/15616 - Visit us at URI: ugotrade.net:9000

==[[User:Drax Lemieux|Drax Lemieux]]==
*16128/16128

==[[User:Opensource Obscure|Opensource Obscure]]==
*51200/51200

==[[User:Harleen Gretzky|Harleen Gretzky]]==
*5120/51200

==[[User:Lapsus Weinstein|Lapsus Weinstein]]==
* Experimental Sandbox on Physical and Mental Health
-loginuri http://grid.centromimir.it:9000 -loginpage http://grid.centromimir.it
* Garda Lake Open Simulation, Centro Mimir, Suburbia, Caffe Freud
* 17408/17408(ogp)
* 17408/17409(ogp)
* 17409/17408(ogp)
* 17409/17409(ogp)

==[[User:Amarillo Mertel|Amarillo Mertel]]==
*25600/25600

==[[User:Rasmusson Oranos|Rasmusson Oranos]]==
*18432/18432

==[[User:Tylor Ferraris|Tylor Ferraris]]==
*1054976/1054976

==[[User:Teravus Ousley|Teravus Ousley]]==
*1048832/1048832 (ogp) - 4097/4097 (OpenSimulator)

==[[User:EloiseJolie Capalini|EloiseJolie Capalini]]==
*46080/46080 (ogp) - URI: http://opensimgrid.com:9000

==[[User:Jabba_Gruppman | Jabba Gruppman]]==

* 5120/11264

==[[User:Cecelia Lewis | Cecelia Lewis]]==
* 25856/25856

==[[User:Albert Revolution|Albert Revolution]]==
*15872/15872 (ogp) - SOMBRALAND -
Accesible some hours at week. Spanish Time. I would like to test
importations from 3dMax Studio, Sculpties and building

==[[User:Dedric Mauriac | Dedric Mauriac]]==
*4352/5120

==[[User:Micky Jansma | Micky Jansma]]==
*28160/28160

==[[User:Burnman Bedlam | Burnman Bedlam]]==
*14848/14848

==[[User:Rancher Koenig | Rancher Koenig]]==
*5120/5120

==[[User:Fin Umarov | Fin Umarov]]==
*25344/25344

==[[User:Berry Steinhoff | Berry Steinhoff]]==
*13568/13568

==[[User:Kaly Mayako|Kaly Mayako]]==
*9666/9666 (ogp46) - URI: http://jukastream.com:9000
Open 10AM - 4PM French time

[[Category:Open_Grid_Public_Beta]]

Open Grid Public Beta/Map Locations

Teravus Ousley — Sat, 30 Aug 2008 02:43:53 GMT

Teravus Ousley:

OpenSim regions cannot be placed directly adjacent to existing regions on aditi or vaak.

:[[User:Zha_Ewry|Zha Ewry]]: "Setup as a very basic stand alone opensim. set the default location and the location of your region to be the same value, and run only one region on the server. (ie. in OpenSim.ini, make sure you set default_loc_x and default_loc_y, and make them match the ones in the default.xml in the Regions subdirectory of you r bin directory in your install."

For clarity, please specify your OGP claim as well as what those would translate to in sim_location_x and sim_location_y. '''Remember, in OpenSimulator, your sim_location_x and sim_location_y is your OGP claim divided by 256.'''

Whump's region is at 2048 by 2048. To configure OpenSimulator to use that grid spot, he would configure his default.xml file like; default_loc_x="8" and default_loc_y="8" because 2048 divided by 256 is 8.

Non-Linden Lab OpenSims should use default_loc_x and default_loc_y values greater than 4096.

Claim Map Locations Below

Open Grid Public(OGP) Claims that are not multiples of 256 will be marked in pink.

==[[User:Whump_Linden | Whump Linden ]]==

* 2048/2048 (OGP) - 8/8 (OpenSimulator)
* 2304/2560 (OGP) - 10/10 (OpenSimulator)

==[[User:Enus_Linden | Enus Linden ]]==

* 2304/2304 (OGP) - 9/8 (OpenSimulator)

==[[User:Dahlia_Trimble | Dahlia Trimble ]]==

* 4096/4096
* 4352/4352
* 4608/4608

==[[User:Christophe003_Carter | Christophe003 Carter ]]==

* 4608/4608

==[[User:Pier_Tempel | Pier Tempel ]]==

* 5120/5120

==[[User:BlueWall Slade | Bluewall Slade]]==
*6400/6400 URI: http://ascent.bluewallgroup.com:9300

==[[User:Winne Woodget | Winne Woodget]]==

* 6912/6912

==[[User:Matias Carter | Matias Carter]]==

* 7168/7168

==[[User:Xugu Madison | Xugu Madison]]==

* 8192/8192

==[[User:Eddy Stryker | Eddy Stryker]]==

* 5888/5888

==[[User:Latif Khalifa | Latif Khalifa]]==

* 6144/6144

==[[User:Tracy Welles | Tracy Welles ]]==

* 4352/4352

==[[User:Bluecat Jun | Bluecat Jun ]]==

* 7424/7424

==[[User:Alynna Vixen | Alynna Vixen ]]==

* 4864/5120 - [http://kitsunet.net:9000/ Kitsuhana]

==[[User:Julie Wasserstrom | Julie Wasserstrom ]]==

* 5888/5888

==[[User:Chris Samtanko | Chris Samtanko ]]==

*4864/4864 - http://planck.vworlds.co.uk:9000
*2560256/2559488(OGP) 10001/9998 (OSGrid) - http://dirac.vworlds.co.uk:9000

==[http://mrtopf.de/blog Tao Takashi ]==

*6656/6656

==[[User:Jim Kupferberg | Jim Kupferberg ]]==

*6656/6400

==[[User:Emma Nowhere | Emma Nowhere ]]==

*5120/5120

==[[User:Gomez Bracken | Gomez Bracken ]]==

*8448/8448

==[[User:Ciemaar Flintoff | Ciemaar Flintoff ]]==

*6656/7680

==[[User:Media Hax | Media Hax ]]==

*5632/5632
==[[User:Twa Hinkle | Twa Hinkle ]]==

*7680/7680

==[[User:Vicero Lambert | Vicero Lambert ]]==

*5130/5130

==[[User:Whichway Janus | Whichway Janus ]]==

*6656/6912 Updated protocol sim - requires OGP Viewer build 94858 or higher.

==[[User:Stamo Stuer | Stamo Stuer ]]==

*5376/5376

==[[User:Patnad Babii | Patnad Babii ]]==

* <font color="pink">9728/9728</font>

==[[User:Torrid Luna | Torrid Luna ]]==

*6144/8448

==[http://blog.simgis.com Darb Dabney ]==

* 4608/4352

==[[User:Morph Wollongong | Morph Wollongong ]]==

* 6789/6789

==[[User:Estate Shepherd | Estate Shepherd ]]==

* 8704/8704

==[[User:Zerodog Witte | Zerodog Witte ]]==

* 8448/8448

==[[User:Lil Linden | Lil Linden]]==

* 2806/2806

==[[User:EriX Oh | EriX Oh]]==

* 4352/4864

==[[User:James Benedek | James Benedek]]==

* 7936/7936

==[[User:Hawk Carter | Hawk Carter]]==

* 9984/9984 - URI: http://81.169.130.81:10600 (UP)

==[[User:McCoy Ducatillon | McCoy Ducatillon]]==

* 8960/8960

==[[User:Laurent Bechir | Laurent Bechir]]==

* 9216/9216

==[[User:Economic Mip | Economic Mip]]==

* 9216/8960

==[[User:whyroc Slade | whyroc Slade]]==

* 10240/10240

==[[User:Bartholomew Kleiber | Bartholomew Kleiber]]==

* 10752/10752

==[[User:Arbitar Basiat | Arbitar Basiat]]==

* 13056/13056

==[[User:KustomKreator4u Inglewood | KustomKreator4u Inglewood]]==

* 11008/11008

==[[User:TheCoolLeader Boyer | TheCoolLeader Boyer ]]==

* 16384/16384

==[[User:Aidamina Hunt | Aidamina Hunt ]]==

* 25600/25600

==[[User:Stirling Allen|Stirling Allen]] 19:59, 4 August 2008 (PDT)==

*65536/65536 (ETA Friday 9 August)

==[[User:Sonof Marvin|Sonof Marvin]]==

*69683/69683

==[[User:Radioactive Rosca|Radioactive Rosca]]==

*4864/5376

==[[User:Jim Brock|Jim Brock]]==

* 9472/9472

==[[User:Jonit Ivory|Jonit Ivory]]==

* 11264/11264

==[[User:Ideia Boa|Ideia Boa]]==

* 4096/4608

==[[User:Athanasius Skytower|Athanasius Skytower]]==

* 5632/6656

==[[User:camilla Yosuke|camilla Yosuke]]==

* 6656/4352
==[[User:bonghit Schism|bonghit Schism]]==

* 12544/12544

==[[User:Elio Donat|Elio Donat]]==

* 6656/4353

==[[User: Just Dinkin|Just Dinkin]]==
* 11520/11520

==[[User: Miki Gymnast|Miki Gymnast]]==
* 8448/5632

==[[User: Jillian Taringa|Jillian Taringa]]==
* 11776/11776

==[[User: JB Kraft|JB Kraft]]==
* 6400/4608

==[[User: Wangxiang Tuxing|Wangxiang Tuxing]]==
* 9472/11264

==[[User: Tensai Hilra|Tensai Hilra]]==
* 12800/12800

==[[User: Mirt Tenk|Mirt Tenk]]==
* 5376/7680

==[[User: Maniac Choche|Maniac Choche]]==
* 5632/5888

==[[User: Kish Kas|Kish Kas]]==
* 6400/6656

==[[User: Bit2zero Planer|Bit2zero Planer]]==
* 6500/6656

==[[User: Trifile Toshi|Trifile Toshi]]==
* 20736/20736

==[[User: Micheil Merlin|Micheil Merlin]]==
* 4608/5120

==[[User: Yuu Nakamichi|Yuu Nakamichi]]==
* 9728/8960

==[[User: Norgan Torok|Norgan Torok]]==
* 6400/6400

==[[User: Master Huldschinsky|Master Huldschinsky]]==
* 16400/16400

==[[User: Giulio Perhaps|Giulio Perhaps]]==
* 16640/16640

==[[User: Lexa Sands|Lexa Sands]]==
* 6400/6144 - Lexania - URI: http://lexa.ath.cx:9000

==[[User:Junta Kohime | Junta Kohime ]]==

* 6400/5888 - Born To Learn - URI: http://borntolearn.dyndns.org:9000

==[[User: Strawberry Fride | Strawberry Fride]]==
* 17408/17408

==[[User: G2 Proto | G2 Proto]]==
* 17664/17664 http://www.reactiongrid.com http://reactiongrid.com:10500

==[[User: Kuraiko Yoshikawa|Kuraiko Yoshikawa]]==
*4096/4864 [http://zeitenwerk.de:9128 URI]

==[[User: Prometheus Dovgal|Prometheus Dovgal]]==
*17920/17920

==[[User: Cow Taurog|Cow Taurog]]==
* 16128/16128 - [http://cowtaurog.cjb.net:9000 The Pasture]

==[[User: Camus Omegamu|Camus Omegamu]]==
* 4608/8704

==[[User: m0rdred Veil|m0rdred Veil]]==
* 18176/18176 - La Isla West - URI: http://24.30.54.84:9000

==[[User: Kliger Dinkin|Kliger Dinkin]]==
* 13312/13312

==[[User: Audoa Giha|Audoa Giha]]==
* 19200/19200 Will be up/down for maint otherwise 24/7 URI: http://71.170.194.115:9010/

==[[User: Ceyna Indigo|Ceyna Indigo]]==
* 32768/32768
==[[User: Bulli Schumann|Bulli Schumann]]==
* 46080/46080 - Come visit if you like... still very barren... but it will prob. be expanded in a while: http://83.247.63.174:9000
* 46080/46336 - experimental region (well... aren't they all?)
* 46336/46080 - experimental region (well... aren't they all?)
* 46336/46336 - experimental region (well... aren't they all?)

==[[User: Ansel Gasparini|Ansel Gasparini]]==
* 4352/4608

==[[User: Xerbi Zerbino|Xerbi Zerbino]]==
* 12032/12032

==[[User: Siddhartha Fonda | Siddhartha Fonda]]==
* 22272/22272

==[[User: elmanytas Ferrentino | elmanytas Ferrentino]]==
* 2560/2304

==[[User:Mana Janus|Mana Janus]]==
* 5120/7680

==[[User:Easyfresh Auer|Easyfresh Auer]]==
* 1090048/1090048

==[[User:Nomad Ingwer|Nomad Ingwer]]==
* 27648/27648

==[[User:Quinlan Quimby|Quinlan Quimby]]==
* 28416/28416

==[[User:Woot Avro|Woot Avro]]==
* 4096/4608

==[[User:Herfulnerful Holsworthy|Herfulnerful Holsworthy]]==
* 8192/16384
* 8192/16640

==[[User:pb Qinan|pb Qinan]]==
* 9472/8960

==[[User:Tara5 Oh|Tara5 Oh]]==
*15616/15616 - Visit us at URI: ugotrade.net:9000

==[[User:Drax Lemieux|Drax Lemieux]]==
*16128/16128

==[[User:Opensource Obscure|Opensource Obscure]]==
*51200/51200

==[[User:Harleen Gretzky|Harleen Gretzky]]==
*5120/51200

==[[User:Lapsus Weinstein|Lapsus Weinstein]]==
* Experimental Sandbox on Physical and Mental Health
-loginuri http://grid.centromimir.it:9000 -loginpage http://grid.centromimir.it
* Garda Lake Open Simulation, Centro Mimir, Suburbia, Caffe Freud
* 17408/17408(ogp)
* 17408/17409(ogp)
* 17409/17408(ogp)
* 17409/17409(ogp)

==[[User:Amarillo Mertel|Amarillo Mertel]]==
*25600/25600

==[[User:Rasmusson Oranos|Rasmusson Oranos]]==
*18432/18432

==[[User:Tylor Ferraris|Tylor Ferraris]]==
*1054976/1054976

==[[User:Teravus Ousley|Teravus Ousley]]==
*1048832/1048832 (ogp) - 4097/4097 (OpenSimulator)

==[[User:EloiseJolie Capalini|EloiseJolie Capalini]]==
*46080/46080 (ogp) - URI: http://opensimgrid.com:9000

==[[User:Jabba_Gruppman | Jabba Gruppman]]==

* 5120/11264

==[[User:Cecelia Lewis | Cecelia Lewis]]==
* 25856/25856

==[[User:Albert Revolution|Albert Revolution]]==
*15872/15872 (ogp) - SOMBRALAND -
Accesible some hours at week. Spanish Time. I would like to test
importations from 3dMax Studio, Sculpties and building

==[[User:Dedric Mauriac | Dedric Mauriac]]==
*4352/5120

==[[User:Micky Jansma | Micky Jansma]]==
*28160/28160

==[[User:Burnman Bedlam | Burnman Bedlam]]==
*14848/14848

==[[User:Rancher Koenig | Rancher Koenig]]==
*5120/5120

==[[User:Fin Umarov | Fin Umarov]]==
*25344/25344

==[[User:Berry Steinhoff | Berry Steinhoff]]==
*13568/13568

==[[User:Kaly Mayako|Kaly Mayako]]==
*9666/9666 (ogp46) - URI: http://jukastream.com:9000
Open 10AM - 4PM French time

[[Category:Open_Grid_Public_Beta]]

Open Grid Public Beta/Map Locations

Teravus Ousley — Sat, 30 Aug 2008 02:36:57 GMT

Teravus Ousley: /* Enus Linden */

OpenSim regions cannot be placed directly adjacent to existing regions on aditi or vaak.

:[[User:Zha_Ewry|Zha Ewry]]: "Setup as a very basic stand alone opensim. set the default location and the location of your region to be the same value, and run only one region on the server. (ie. in OpenSim.ini, make sure you set default_loc_x and default_loc_y, and make them match the ones in the default.xml in the Regions subdirectory of you r bin directory in your install."

For clarity, please specify your OGP claim as well as what those would translate to in sim_location_x and sim_location_y. '''Remember, in OpenSimulator, your sim_location_x and sim_location_y is your OGP claim divided by 256.''' Whump's region is at 2048 by 2048. To configure OpenSimulator to use that grid spot, he would configure his default.xml file like; default_loc_x="8" and default_loc_y="8" because 2048 divided by 256 is 8.

Non-Linden Lab OpenSims should use default_loc_x and default_loc_y values greater than 4096.

Claim Map Locations Below

Claims that are not multiples of 256 will be marked in pink.

==[[User:Whump_Linden | Whump Linden ]]==

* 2048/2048 (OGP) - 8/8 (OpenSimulator)
* 2304/2560 (OGP) - 10/10 (OpenSimulator)

==[[User:Enus_Linden | Enus Linden ]]==

* 2304/2304 (OGP) - 9/8 (OpenSimulator)

==[[User:Dahlia_Trimble | Dahlia Trimble ]]==

* 4096/4096
* 4352/4352
* 4608/4608

==[[User:Christophe003_Carter | Christophe003 Carter ]]==

* 4608/4608

==[[User:Pier_Tempel | Pier Tempel ]]==

* 5120/5120

==[[User:BlueWall Slade | Bluewall Slade]]==
*6400/6400 URI: http://ascent.bluewallgroup.com:9300

==[[User:Winne Woodget | Winne Woodget]]==

* 6912/6912

==[[User:Matias Carter | Matias Carter]]==

* 7168/7168

==[[User:Xugu Madison | Xugu Madison]]==

* 8192/8192

==[[User:Eddy Stryker | Eddy Stryker]]==

* 5888/5888

==[[User:Latif Khalifa | Latif Khalifa]]==

* 6144/6144

==[[User:Tracy Welles | Tracy Welles ]]==

* 4352/4352

==[[User:Bluecat Jun | Bluecat Jun ]]==

* 7424/7424

==[[User:Alynna Vixen | Alynna Vixen ]]==

* 4864/5120 - [http://kitsunet.net:9000/ Kitsuhana]

==[[User:Julie Wasserstrom | Julie Wasserstrom ]]==

* 5888/5888

==[[User:Chris Samtanko | Chris Samtanko ]]==

*4864/4864 - http://planck.vworlds.co.uk:9000
*2560256/2559488(OGP) 10001/9998 (OSGrid) - http://dirac.vworlds.co.uk:9000

==[http://mrtopf.de/blog Tao Takashi ]==

*6656/6656

==[[User:Jim Kupferberg | Jim Kupferberg ]]==

*6656/6400

==[[User:Emma Nowhere | Emma Nowhere ]]==

*5120/5120

==[[User:Gomez Bracken | Gomez Bracken ]]==

*8448/8448

==[[User:Ciemaar Flintoff | Ciemaar Flintoff ]]==

*6656/7680

==[[User:Media Hax | Media Hax ]]==

*5632/5632
==[[User:Twa Hinkle | Twa Hinkle ]]==

*7680/7680

==[[User:Vicero Lambert | Vicero Lambert ]]==

*5130/5130

==[[User:Whichway Janus | Whichway Janus ]]==

*6656/6912 Updated protocol sim - requires OGP Viewer build 94858 or higher.

==[[User:Stamo Stuer | Stamo Stuer ]]==

*5376/5376

==[[User:Patnad Babii | Patnad Babii ]]==

* <font color="pink">9728/9728</font>

==[[User:Torrid Luna | Torrid Luna ]]==

*6144/8448

==[http://blog.simgis.com Darb Dabney ]==

* 4608/4352

==[[User:Morph Wollongong | Morph Wollongong ]]==

* 6789/6789

==[[User:Estate Shepherd | Estate Shepherd ]]==

* 8704/8704

==[[User:Zerodog Witte | Zerodog Witte ]]==

* 8448/8448

==[[User:Lil Linden | Lil Linden]]==

* 2806/2806

==[[User:EriX Oh | EriX Oh]]==

* 4352/4864

==[[User:James Benedek | James Benedek]]==

* 7936/7936

==[[User:Hawk Carter | Hawk Carter]]==

* 9984/9984 - URI: http://81.169.130.81:10600 (UP)

==[[User:McCoy Ducatillon | McCoy Ducatillon]]==

* 8960/8960

==[[User:Laurent Bechir | Laurent Bechir]]==

* 9216/9216

==[[User:Economic Mip | Economic Mip]]==

* 9216/8960

==[[User:whyroc Slade | whyroc Slade]]==

* 10240/10240

==[[User:Bartholomew Kleiber | Bartholomew Kleiber]]==

* 10752/10752

==[[User:Arbitar Basiat | Arbitar Basiat]]==

* 13056/13056

==[[User:KustomKreator4u Inglewood | KustomKreator4u Inglewood]]==

* 11008/11008

==[[User:TheCoolLeader Boyer | TheCoolLeader Boyer ]]==

* 16384/16384

==[[User:Aidamina Hunt | Aidamina Hunt ]]==

* 25600/25600

==[[User:Stirling Allen|Stirling Allen]] 19:59, 4 August 2008 (PDT)==

*65536/65536 (ETA Friday 9 August)

==[[User:Sonof Marvin|Sonof Marvin]]==

*69683/69683

==[[User:Radioactive Rosca|Radioactive Rosca]]==

*4864/5376

==[[User:Jim Brock|Jim Brock]]==

* 9472/9472

==[[User:Jonit Ivory|Jonit Ivory]]==

* 11264/11264

==[[User:Ideia Boa|Ideia Boa]]==

* 4096/4608

==[[User:Athanasius Skytower|Athanasius Skytower]]==

* 5632/6656

==[[User:camilla Yosuke|camilla Yosuke]]==

* 6656/4352
==[[User:bonghit Schism|bonghit Schism]]==

* 12544/12544

==[[User:Elio Donat|Elio Donat]]==

* 6656/4353

==[[User: Just Dinkin|Just Dinkin]]==
* 11520/11520

==[[User: Miki Gymnast|Miki Gymnast]]==
* 8448/5632

==[[User: Jillian Taringa|Jillian Taringa]]==
* 11776/11776

==[[User: JB Kraft|JB Kraft]]==
* 6400/4608

==[[User: Wangxiang Tuxing|Wangxiang Tuxing]]==
* 9472/11264

==[[User: Tensai Hilra|Tensai Hilra]]==
* 12800/12800

==[[User: Mirt Tenk|Mirt Tenk]]==
* 5376/7680

==[[User: Maniac Choche|Maniac Choche]]==
* 5632/5888

==[[User: Kish Kas|Kish Kas]]==
* 6400/6656

==[[User: Bit2zero Planer|Bit2zero Planer]]==
* 6500/6656

==[[User: Trifile Toshi|Trifile Toshi]]==
* 20736/20736

==[[User: Micheil Merlin|Micheil Merlin]]==
* 4608/5120

==[[User: Yuu Nakamichi|Yuu Nakamichi]]==
* 9728/8960

==[[User: Norgan Torok|Norgan Torok]]==
* 6400/6400

==[[User: Master Huldschinsky|Master Huldschinsky]]==
* 16400/16400

==[[User: Giulio Perhaps|Giulio Perhaps]]==
* 16640/16640

==[[User: Lexa Sands|Lexa Sands]]==
* 6400/6144 - Lexania - URI: http://lexa.ath.cx:9000

==[[User:Junta Kohime | Junta Kohime ]]==

* 6400/5888 - Born To Learn - URI: http://borntolearn.dyndns.org:9000

==[[User: Strawberry Fride | Strawberry Fride]]==
* 17408/17408

==[[User: G2 Proto | G2 Proto]]==
* 17664/17664 http://www.reactiongrid.com http://reactiongrid.com:10500

==[[User: Kuraiko Yoshikawa|Kuraiko Yoshikawa]]==
*4096/4864 [http://zeitenwerk.de:9128 URI]

==[[User: Prometheus Dovgal|Prometheus Dovgal]]==
*17920/17920

==[[User: Cow Taurog|Cow Taurog]]==
* 16128/16128 - [http://cowtaurog.cjb.net:9000 The Pasture]

==[[User: Camus Omegamu|Camus Omegamu]]==
* 4608/8704

==[[User: m0rdred Veil|m0rdred Veil]]==
* 18176/18176 - La Isla West - URI: http://24.30.54.84:9000

==[[User: Kliger Dinkin|Kliger Dinkin]]==
* 13312/13312

==[[User: Audoa Giha|Audoa Giha]]==
* 19200/19200 Will be up/down for maint otherwise 24/7 URI: http://71.170.194.115:9010/

==[[User: Ceyna Indigo|Ceyna Indigo]]==
* 32768/32768
==[[User: Bulli Schumann|Bulli Schumann]]==
* 46080/46080 - Come visit if you like... still very barren... but it will prob. be expanded in a while: http://83.247.63.174:9000
* 46080/46336 - experimental region (well... aren't they all?)
* 46336/46080 - experimental region (well... aren't they all?)
* 46336/46336 - experimental region (well... aren't they all?)

==[[User: Ansel Gasparini|Ansel Gasparini]]==
* 4352/4608

==[[User: Xerbi Zerbino|Xerbi Zerbino]]==
* 12032/12032

==[[User: Siddhartha Fonda | Siddhartha Fonda]]==
* 22272/22272

==[[User: elmanytas Ferrentino | elmanytas Ferrentino]]==
* 2560/2304

==[[User:Mana Janus|Mana Janus]]==
* 5120/7680

==[[User:Easyfresh Auer|Easyfresh Auer]]==
* 1090048/1090048

==[[User:Nomad Ingwer|Nomad Ingwer]]==
* 27648/27648

==[[User:Quinlan Quimby|Quinlan Quimby]]==
* 28416/28416

==[[User:Woot Avro|Woot Avro]]==
* 4096/4608

==[[User:Herfulnerful Holsworthy|Herfulnerful Holsworthy]]==
* 8192/16384
* 8192/16640

==[[User:pb Qinan|pb Qinan]]==
* 9472/8960

==[[User:Tara5 Oh|Tara5 Oh]]==
*15616/15616 - Visit us at URI: ugotrade.net:9000

==[[User:Drax Lemieux|Drax Lemieux]]==
*16128/16128

==[[User:Opensource Obscure|Opensource Obscure]]==
*51200/51200

==[[User:Harleen Gretzky|Harleen Gretzky]]==
*5120/51200

==[[User:Lapsus Weinstein|Lapsus Weinstein]]==
* Experimental Sandbox on Physical and Mental Health
-loginuri http://grid.centromimir.it:9000 -loginpage http://grid.centromimir.it
* Garda Lake Open Simulation, Centro Mimir, Suburbia, Caffe Freud
* 17408/17408(ogp)
* 17408/17409(ogp)
* 17409/17408(ogp)
* 17409/17409(ogp)

==[[User:Amarillo Mertel|Amarillo Mertel]]==
*25600/25600

==[[User:Rasmusson Oranos|Rasmusson Oranos]]==
*18432/18432

==[[User:Tylor Ferraris|Tylor Ferraris]]==
*1054976/1054976

==[[User:Teravus Ousley|Teravus Ousley]]==
*1048832/1048832 (ogp) - 4097/4097 (OpenSimulator)

==[[User:EloiseJolie Capalini|EloiseJolie Capalini]]==
*46080/46080 (ogp) - URI: http://opensimgrid.com:9000

==[[User:Jabba_Gruppman | Jabba Gruppman]]==

* 5120/11264

==[[User:Cecelia Lewis | Cecelia Lewis]]==
* 25856/25856

==[[User:Albert Revolution|Albert Revolution]]==
*15872/15872 (ogp) - SOMBRALAND -
Accesible some hours at week. Spanish Time. I would like to test
importations from 3dMax Studio, Sculpties and building

==[[User:Dedric Mauriac | Dedric Mauriac]]==
*4352/5120

==[[User:Micky Jansma | Micky Jansma]]==
*28160/28160

==[[User:Burnman Bedlam | Burnman Bedlam]]==
*14848/14848

==[[User:Rancher Koenig | Rancher Koenig]]==
*5120/5120

==[[User:Fin Umarov | Fin Umarov]]==
*25344/25344

==[[User:Berry Steinhoff | Berry Steinhoff]]==
*13568/13568

==[[User:Kaly Mayako|Kaly Mayako]]==
*9666/9666 (ogp46) - URI: http://jukastream.com:9000
Open 10AM - 4PM French time

[[Category:Open_Grid_Public_Beta]]

Open Grid Public Beta/Map Locations

Teravus Ousley — Sat, 30 Aug 2008 02:36:00 GMT

Teravus Ousley:

OpenSim regions cannot be placed directly adjacent to existing regions on aditi or vaak.

:[[User:Zha_Ewry|Zha Ewry]]: "Setup as a very basic stand alone opensim. set the default location and the location of your region to be the same value, and run only one region on the server. (ie. in OpenSim.ini, make sure you set default_loc_x and default_loc_y, and make them match the ones in the default.xml in the Regions subdirectory of you r bin directory in your install."

For clarity, please specify your OGP claim as well as what those would translate to in sim_location_x and sim_location_y. '''Remember, in OpenSimulator, your sim_location_x and sim_location_y is your OGP claim divided by 256.''' Whump's region is at 2048 by 2048. To configure OpenSimulator to use that grid spot, he would configure his default.xml file like; default_loc_x="8" and default_loc_y="8" because 2048 divided by 256 is 8.

Non-Linden Lab OpenSims should use default_loc_x and default_loc_y values greater than 4096.

Claim Map Locations Below

Claims that are not multiples of 256 will be marked in pink.

==[[User:Whump_Linden | Whump Linden ]]==

* 2048/2048 (OGP) - 8/8 (OpenSimulator)
* 2304/2560 (OGP) - 10/10 (OpenSimulator)

==[[User:Enus_Linden | Enus Linden ]]==

* 2304/2304 (OGP - 9/8 (OpenSimulator)

==[[User:Dahlia_Trimble | Dahlia Trimble ]]==

* 4096/4096
* 4352/4352
* 4608/4608

==[[User:Christophe003_Carter | Christophe003 Carter ]]==

* 4608/4608

==[[User:Pier_Tempel | Pier Tempel ]]==

* 5120/5120

==[[User:BlueWall Slade | Bluewall Slade]]==
*6400/6400 URI: http://ascent.bluewallgroup.com:9300

==[[User:Winne Woodget | Winne Woodget]]==

* 6912/6912

==[[User:Matias Carter | Matias Carter]]==

* 7168/7168

==[[User:Xugu Madison | Xugu Madison]]==

* 8192/8192

==[[User:Eddy Stryker | Eddy Stryker]]==

* 5888/5888

==[[User:Latif Khalifa | Latif Khalifa]]==

* 6144/6144

==[[User:Tracy Welles | Tracy Welles ]]==

* 4352/4352

==[[User:Bluecat Jun | Bluecat Jun ]]==

* 7424/7424

==[[User:Alynna Vixen | Alynna Vixen ]]==

* 4864/5120 - [http://kitsunet.net:9000/ Kitsuhana]

==[[User:Julie Wasserstrom | Julie Wasserstrom ]]==

* 5888/5888

==[[User:Chris Samtanko | Chris Samtanko ]]==

*4864/4864 - http://planck.vworlds.co.uk:9000
*2560256/2559488(OGP) 10001/9998 (OSGrid) - http://dirac.vworlds.co.uk:9000

==[http://mrtopf.de/blog Tao Takashi ]==

*6656/6656

==[[User:Jim Kupferberg | Jim Kupferberg ]]==

*6656/6400

==[[User:Emma Nowhere | Emma Nowhere ]]==

*5120/5120

==[[User:Gomez Bracken | Gomez Bracken ]]==

*8448/8448

==[[User:Ciemaar Flintoff | Ciemaar Flintoff ]]==

*6656/7680

==[[User:Media Hax | Media Hax ]]==

*5632/5632
==[[User:Twa Hinkle | Twa Hinkle ]]==

*7680/7680

==[[User:Vicero Lambert | Vicero Lambert ]]==

*5130/5130

==[[User:Whichway Janus | Whichway Janus ]]==

*6656/6912 Updated protocol sim - requires OGP Viewer build 94858 or higher.

==[[User:Stamo Stuer | Stamo Stuer ]]==

*5376/5376

==[[User:Patnad Babii | Patnad Babii ]]==

* <font color="pink">9728/9728</font>

==[[User:Torrid Luna | Torrid Luna ]]==

*6144/8448

==[http://blog.simgis.com Darb Dabney ]==

* 4608/4352

==[[User:Morph Wollongong | Morph Wollongong ]]==

* 6789/6789

==[[User:Estate Shepherd | Estate Shepherd ]]==

* 8704/8704

==[[User:Zerodog Witte | Zerodog Witte ]]==

* 8448/8448

==[[User:Lil Linden | Lil Linden]]==

* 2806/2806

==[[User:EriX Oh | EriX Oh]]==

* 4352/4864

==[[User:James Benedek | James Benedek]]==

* 7936/7936

==[[User:Hawk Carter | Hawk Carter]]==

* 9984/9984 - URI: http://81.169.130.81:10600 (UP)

==[[User:McCoy Ducatillon | McCoy Ducatillon]]==

* 8960/8960

==[[User:Laurent Bechir | Laurent Bechir]]==

* 9216/9216

==[[User:Economic Mip | Economic Mip]]==

* 9216/8960

==[[User:whyroc Slade | whyroc Slade]]==

* 10240/10240

==[[User:Bartholomew Kleiber | Bartholomew Kleiber]]==

* 10752/10752

==[[User:Arbitar Basiat | Arbitar Basiat]]==

* 13056/13056

==[[User:KustomKreator4u Inglewood | KustomKreator4u Inglewood]]==

* 11008/11008

==[[User:TheCoolLeader Boyer | TheCoolLeader Boyer ]]==

* 16384/16384

==[[User:Aidamina Hunt | Aidamina Hunt ]]==

* 25600/25600

==[[User:Stirling Allen|Stirling Allen]] 19:59, 4 August 2008 (PDT)==

*65536/65536 (ETA Friday 9 August)

==[[User:Sonof Marvin|Sonof Marvin]]==

*69683/69683

==[[User:Radioactive Rosca|Radioactive Rosca]]==

*4864/5376

==[[User:Jim Brock|Jim Brock]]==

* 9472/9472

==[[User:Jonit Ivory|Jonit Ivory]]==

* 11264/11264

==[[User:Ideia Boa|Ideia Boa]]==

* 4096/4608

==[[User:Athanasius Skytower|Athanasius Skytower]]==

* 5632/6656

==[[User:camilla Yosuke|camilla Yosuke]]==

* 6656/4352
==[[User:bonghit Schism|bonghit Schism]]==

* 12544/12544

==[[User:Elio Donat|Elio Donat]]==

* 6656/4353

==[[User: Just Dinkin|Just Dinkin]]==
* 11520/11520

==[[User: Miki Gymnast|Miki Gymnast]]==
* 8448/5632

==[[User: Jillian Taringa|Jillian Taringa]]==
* 11776/11776

==[[User: JB Kraft|JB Kraft]]==
* 6400/4608

==[[User: Wangxiang Tuxing|Wangxiang Tuxing]]==
* 9472/11264

==[[User: Tensai Hilra|Tensai Hilra]]==
* 12800/12800

==[[User: Mirt Tenk|Mirt Tenk]]==
* 5376/7680

==[[User: Maniac Choche|Maniac Choche]]==
* 5632/5888

==[[User: Kish Kas|Kish Kas]]==
* 6400/6656

==[[User: Bit2zero Planer|Bit2zero Planer]]==
* 6500/6656

==[[User: Trifile Toshi|Trifile Toshi]]==
* 20736/20736

==[[User: Micheil Merlin|Micheil Merlin]]==
* 4608/5120

==[[User: Yuu Nakamichi|Yuu Nakamichi]]==
* 9728/8960

==[[User: Norgan Torok|Norgan Torok]]==
* 6400/6400

==[[User: Master Huldschinsky|Master Huldschinsky]]==
* 16400/16400

==[[User: Giulio Perhaps|Giulio Perhaps]]==
* 16640/16640

==[[User: Lexa Sands|Lexa Sands]]==
* 6400/6144 - Lexania - URI: http://lexa.ath.cx:9000

==[[User:Junta Kohime | Junta Kohime ]]==

* 6400/5888 - Born To Learn - URI: http://borntolearn.dyndns.org:9000

==[[User: Strawberry Fride | Strawberry Fride]]==
* 17408/17408

==[[User: G2 Proto | G2 Proto]]==
* 17664/17664 http://www.reactiongrid.com http://reactiongrid.com:10500

==[[User: Kuraiko Yoshikawa|Kuraiko Yoshikawa]]==
*4096/4864 [http://zeitenwerk.de:9128 URI]

==[[User: Prometheus Dovgal|Prometheus Dovgal]]==
*17920/17920

==[[User: Cow Taurog|Cow Taurog]]==
* 16128/16128 - [http://cowtaurog.cjb.net:9000 The Pasture]

==[[User: Camus Omegamu|Camus Omegamu]]==
* 4608/8704

==[[User: m0rdred Veil|m0rdred Veil]]==
* 18176/18176 - La Isla West - URI: http://24.30.54.84:9000

==[[User: Kliger Dinkin|Kliger Dinkin]]==
* 13312/13312

==[[User: Audoa Giha|Audoa Giha]]==
* 19200/19200 Will be up/down for maint otherwise 24/7 URI: http://71.170.194.115:9010/

==[[User: Ceyna Indigo|Ceyna Indigo]]==
* 32768/32768
==[[User: Bulli Schumann|Bulli Schumann]]==
* 46080/46080 - Come visit if you like... still very barren... but it will prob. be expanded in a while: http://83.247.63.174:9000
* 46080/46336 - experimental region (well... aren't they all?)
* 46336/46080 - experimental region (well... aren't they all?)
* 46336/46336 - experimental region (well... aren't they all?)

==[[User: Ansel Gasparini|Ansel Gasparini]]==
* 4352/4608

==[[User: Xerbi Zerbino|Xerbi Zerbino]]==
* 12032/12032

==[[User: Siddhartha Fonda | Siddhartha Fonda]]==
* 22272/22272

==[[User: elmanytas Ferrentino | elmanytas Ferrentino]]==
* 2560/2304

==[[User:Mana Janus|Mana Janus]]==
* 5120/7680

==[[User:Easyfresh Auer|Easyfresh Auer]]==
* 1090048/1090048

==[[User:Nomad Ingwer|Nomad Ingwer]]==
* 27648/27648

==[[User:Quinlan Quimby|Quinlan Quimby]]==
* 28416/28416

==[[User:Woot Avro|Woot Avro]]==
* 4096/4608

==[[User:Herfulnerful Holsworthy|Herfulnerful Holsworthy]]==
* 8192/16384
* 8192/16640

==[[User:pb Qinan|pb Qinan]]==
* 9472/8960

==[[User:Tara5 Oh|Tara5 Oh]]==
*15616/15616 - Visit us at URI: ugotrade.net:9000

==[[User:Drax Lemieux|Drax Lemieux]]==
*16128/16128

==[[User:Opensource Obscure|Opensource Obscure]]==
*51200/51200

==[[User:Harleen Gretzky|Harleen Gretzky]]==
*5120/51200

==[[User:Lapsus Weinstein|Lapsus Weinstein]]==
* Experimental Sandbox on Physical and Mental Health
-loginuri http://grid.centromimir.it:9000 -loginpage http://grid.centromimir.it
* Garda Lake Open Simulation, Centro Mimir, Suburbia, Caffe Freud
* 17408/17408(ogp)
* 17408/17409(ogp)
* 17409/17408(ogp)
* 17409/17409(ogp)

==[[User:Amarillo Mertel|Amarillo Mertel]]==
*25600/25600

==[[User:Rasmusson Oranos|Rasmusson Oranos]]==
*18432/18432

==[[User:Tylor Ferraris|Tylor Ferraris]]==
*1054976/1054976

==[[User:Teravus Ousley|Teravus Ousley]]==
*1048832/1048832 (ogp) - 4097/4097 (OpenSimulator)

==[[User:EloiseJolie Capalini|EloiseJolie Capalini]]==
*46080/46080 (ogp) - URI: http://opensimgrid.com:9000

==[[User:Jabba_Gruppman | Jabba Gruppman]]==

* 5120/11264

==[[User:Cecelia Lewis | Cecelia Lewis]]==
* 25856/25856

==[[User:Albert Revolution|Albert Revolution]]==
*15872/15872 (ogp) - SOMBRALAND -
Accesible some hours at week. Spanish Time. I would like to test
importations from 3dMax Studio, Sculpties and building

==[[User:Dedric Mauriac | Dedric Mauriac]]==
*4352/5120

==[[User:Micky Jansma | Micky Jansma]]==
*28160/28160

==[[User:Burnman Bedlam | Burnman Bedlam]]==
*14848/14848

==[[User:Rancher Koenig | Rancher Koenig]]==
*5120/5120

==[[User:Fin Umarov | Fin Umarov]]==
*25344/25344

==[[User:Berry Steinhoff | Berry Steinhoff]]==
*13568/13568

==[[User:Kaly Mayako|Kaly Mayako]]==
*9666/9666 (ogp46) - URI: http://jukastream.com:9000
Open 10AM - 4PM French time

[[Category:Open_Grid_Public_Beta]]

Open Grid Public Beta/Map Locations

Teravus Ousley — Tue, 19 Aug 2008 02:45:44 GMT

Teravus Ousley: /* Teravus Ousley */

OpenSim regions cannot be placed directly adjacent to existing regions on aditi or vaak.

:[[User:Zha_Ewry|Zha Ewry]]: "Setup as a very basic stand alone opensim. set the default location and the location of your region to be the same value, and run only one region on the server. (ie. in OpenSim.ini, make sure you set default_loc_x and default_loc_y, and make them match the ones in the default.xml in the Regions subdirectory of you r bin directory in your install. Make sure your X and Ys are multiples of 256."

Non-Linden Lab OpenSims should use default_loc_x and default_loc_y values greater than 4096.

Claim Map Locations Below

Claims that are not multiples of 256 will be marked in pink.

==[[User:Whump_Linden | Whump Linden ]]==

* 2048/2048
* 2304/2560

==[[User:Enus_Linden | Enus Linden ]]==

* 2304/2304

==[[User:Dahlia_Trimble | Dahlia Trimble ]]==

* 4096/4096
* 4352/4352
* 4608/4608

==[[User:Christophe003_Carter | Christophe003 Carter ]]==

* 4608/4608

==[[User:Pier_Tempel | Pier Tempel ]]==

* 5120/5120

==[[User:BlueWall Slade | Bluewall Slade]]==
*6400/6400 URI: http://ascent.bluewallgroup.com:9300

==[[User:Winne Woodget | Winne Woodget]]==

* 6912/6912

==[[User:Matias Carter | Matias Carter]]==

* 7168/7168

==[[User:Xugu Madison | Xugu Madison]]==

* 8192/8192

==[[User:Eddy Stryker | Eddy Stryker]]==

* 5888/5888

==[[User:Latif Khalifa | Latif Khalifa]]==

* 6144/6144

==[[User:Tracy Welles | Tracy Welles ]]==

* 4352/4352

==[[User:Bluecat Jun | Bluecat Jun ]]==

* 7424/7424

==[[User:Julie Wasserstrom | Julie Wasserstrom ]]==

* 5888/5888

==[[User:Chris Samtanko | Chris Samtanko ]]==

*4864/4864

==[http://mrtopf.de/blog Tao Takashi ]==

*6656/6656

==[[User:Jim Kupferberg | Jim Kupferberg ]]==

*6656/6400

==[[User:Emma Nowhere | Emma Nowhere ]]==

*5120/5120

==[[User:Gomez Bracken | Gomez Bracken ]]==

*8448/8448

==[[User:Ciemaar Flintoff | Ciemaar Flintoff ]]==

*6656/7680

==[[User:Media Hax | Media Hax ]]==

*5632/5632
==[[User:Twa Hinkle | Twa Hinkle ]]==

*7680/7680

==[[User:Vicero Lambert | Vicero Lambert ]]==

*5130/5130

==[[User:Whichway Janus | Whichway Janus ]]==

*6656/6912

==[[User:Stamo Stuer | Stamo Stuer ]]==

*5376/5376

==[[User:Patnad Babii | Patnad Babii ]]==

* <font color="pink">9728/9728</font>

==[[User:Torrid Luna | Torrid Luna ]]==

*6144/8448

==[http://blog.simgis.com Darb Dabney ]==

* 4608/4352

==[[User:Morph Wollongong | Morph Wollongong ]]==

* 6789/6789

==[[User:Estate Shepherd | Estate Shepherd ]]==

* 8704/8704

==[[User:Zerodog Witte | Zerodog Witte ]]==

* 8448/8448

==[[User:Lil Linden | Lil Linden]]==

* 2806/2806

==[[User:EriX Oh | EriX Oh]]==

* 4352/4864

==[[User:James Benedek | James Benedek]]==

* 7936/7936

==[[User:Hawk Carter | Hawk Carter]]==

* 9984/9984

==[[User:McCoy Ducatillon | McCoy Ducatillon]]==

* 8960/8960

==[[User:Laurent Bechir | Laurent Bechir]]==

* 9216/9216

==[[User:Economic Mip | Economic Mip]]==

* 9216/8960

==[[User:whyroc Slade | whyroc Slade]]==

* 10240/10240

==[[User:Bartholomew Kleiber | Bartholomew Kleiber]]==

* 10752/10752

==[[User:Arbitar Basiat | Arbitar Basiat]]==

* 13056/13056

==[[User:KustomKreator4u Inglewood | KustomKreator4u Inglewood]]==

* 11008/11008

==[[User:TheCoolLeader Boyer | TheCoolLeader Boyer ]]==

* 16384/16384

==[[User:Aidamina Hunt | Aidamina Hunt ]]==

* 25600/25600

==[[User:Stirling Allen|Stirling Allen]] 19:59, 4 August 2008 (PDT)==

*65536/65536 (ETA Friday 9 August)

==[[User:Sonof Marvin|Sonof Marvin]]==

*69683/69683

==[[User:Radioactive Rosca|Radioactive Rosca]]==

*4864/5376

==[[User:Jim Brock|Jim Brock]]==

* 9472/9472

==[[User:Jonit Ivory|Jonit Ivory]]==

* 11264/11264

==[[User:Ideia Boa|Ideia Boa]]==

* 4096/4608

==[[User:Athanasius Skytower|Athanasius Skytower]]==

* 5632/6656

==[[User:camilla Yosuke|camilla Yosuke]]==

* 6656/4352
==[[User:bonghit Schism|bonghit Schism]]==

* 12544/12544

==[[User:Elio Donat|Elio Donat]]==

* 6656/4353

==[[User: Just Dinkin|Just Dinkin]]==
* 11520/11520

==[[User: Miki Gymnast|Miki Gymnast]]==
* 8448/5632

==[[User: Jillian Taringa|Jillian Taringa]]==
* 11776/11776

==[[User: JB Kraft|JB Kraft]]==
* 6400/4608

==[[User: Wangxiang Tuxing|Wangxiang Tuxing]]==
* 9472/11264

==[[User: Tensai Hilra|Tensai Hilra]]==
* 12800/12800

==[[User: Mirt Tenk|Mirt Tenk]]==
* 5376/7680

==[[User: Maniac Choche|Maniac Choche]]==
* 5632/5888

==[[User: Kish Kas|Kish Kas]]==
* 6400/6656

==[[User: Bit2zero Planer|Bit2zero Planer]]==
* 6500/6656

==[[User: Trifile Toshi|Trifile Toshi]]==
* 20736/20736

==[[User: Micheil Merlin|Micheil Merlin]]==
* 4608/5120

==[[User: Yuu Nakamichi|Yuu Nakamichi]]==
* 9728/8960

==[[User: Norgan Torok|Norgan Torok]]==
* 6400/6400

==[[User: Master Huldschinsky|Master Huldschinsky]]==
* 16400/16400

==[[User: Giulio Perhaps|Giulio Perhaps]]==
* 16640/16640

==[[User: Lexa Sands|Lexa Sands]]==
* 6400/6144 - Lexania - URI: http://lexa.ath.cx:9000

==[[User:Junta Kohime | Junta Kohime ]]==

* 6400/5888 - Born To Learn - URI: http://borntolearn.dyndns.org:9000

==[[User: Strawberry Fride | Strawberry Fride]]==
* 17408/17408

==[[User: G2 Proto | G2 Proto]]==
* 17664/17664 http://www.reactiongrid.com http://reactiongrid.com:10500

==[[User: Kuraiko Yoshikawa|Kuraiko Yoshikawa]]==
*4096/4864 [http://zeitenwerk.de:9128 URI]

==[[User: Prometheus Dovgal|Prometheus Dovgal]]==
*17920/17920

==[[User: Cow Taurog|Cow Taurog]]==
* 3328/3328 - [http://cowtaurog.cjb.net:9000 The Pasture]

==[[User: Camus Omegamu|Camus Omegamu]]==
* 4608/8704

==[[User: m0rdred Veil|m0rdred Veil]]==
* 18176/18176 - La Isla West - URI: http://24.30.54.84:9000

==[[User: Kliger Dinkin|Kliger Dinkin]]==
* 13312/13312

==[[User: Audoa Giha|Audoa Giha]]==
* 19200/19200 Will be up/down for maint otherwise 24/7 URI: http://71.164.172.52:9000/

==[[User: Ceyna Indigo|Ceyna Indigo]]==
* 32768/32768
==[[User: Bulli Schumann|Bulli Schumann]]==
* 46080/46080 - Come visit if you like... still very barren... but it will prob. be expanded in a while: http://80.60.232.130:9000

==[[User: Ansel Gasparini|Ansel Gasparini]]==
* 4352/4608

==[[User: Xerbi Zerbino|Xerbi Zerbino]]==
* 12032/12032

==[[User: Siddhartha Fonda | Siddhartha Fonda]]==
* 22272/22272

==[[User: elmanytas Ferrentino | elmanytas Ferrentino]]==
* 2560/2304

==[[User:Mana Janus|Mana Janus]]==
* 5120/7680

==[[User:Easyfresh Auer|Easyfresh Auer]]==
* 1090048/1090048

==[[User:Nomad Ingwer|Nomad Ingwer]]==
* 27648/27648

==[[User:Quinlan Quimby|Quinlan Quimby]]==
* 28416/28416

==[[User:Woot Avro|Woot Avro]]==
* 4096/4608

==[[User:Herfulnerful Holsworthy|Herfulnerful Holsworthy]]==
* 8192/16384
* 8192/16640

==[[User:pb Qinan|pb Qinan]]==
* 9472/8960

==[[User:Tara5 Oh|Tara5 Oh]]==
*15616/15616 - Visit us at URI: ugotrade.net:9000

==[[User:Drax Lemieux|Drax Lemieux]]==
*16128/16128

==[[User:Opensource Obscure|Opensource Obscure]]==
*51200/51200

==[[User:Harleen Gretzky|Harleen Gretzky]]==
*5120/51200

==[[User:Lapsus Weinstein|Lapsus Weinstein]]==
*17408/17408

==[[User:Amarillo Mertel|Amarillo Mertel]]==
*25600/25600

==[[User:Rasmusson Oranos|Rasmusson Oranos]]==
*18432/18432

==[[User:Tylor Ferraris|Tylor Ferraris]]==
*1054976/1054976

==[[User:Teravus Ousley|Teravus Ousley]]==
*1048832/1048832 (ogp) - 4097/4097 (OpenSimulator)

[[Category:Open_Grid_Public_Beta]]

Open Grid Public Beta/Map Locations

Teravus Ousley — Tue, 19 Aug 2008 02:45:18 GMT

Teravus Ousley: /* Teravus Ousley */

OpenSim regions cannot be placed directly adjacent to existing regions on aditi or vaak.

:[[User:Zha_Ewry|Zha Ewry]]: "Setup as a very basic stand alone opensim. set the default location and the location of your region to be the same value, and run only one region on the server. (ie. in OpenSim.ini, make sure you set default_loc_x and default_loc_y, and make them match the ones in the default.xml in the Regions subdirectory of you r bin directory in your install. Make sure your X and Ys are multiples of 256."

Non-Linden Lab OpenSims should use default_loc_x and default_loc_y values greater than 4096.

Claim Map Locations Below

Claims that are not multiples of 256 will be marked in pink.

==[[User:Whump_Linden | Whump Linden ]]==

* 2048/2048
* 2304/2560

==[[User:Enus_Linden | Enus Linden ]]==

* 2304/2304

==[[User:Dahlia_Trimble | Dahlia Trimble ]]==

* 4096/4096
* 4352/4352
* 4608/4608

==[[User:Christophe003_Carter | Christophe003 Carter ]]==

* 4608/4608

==[[User:Pier_Tempel | Pier Tempel ]]==

* 5120/5120

==[[User:BlueWall Slade | Bluewall Slade]]==
*6400/6400 URI: http://ascent.bluewallgroup.com:9300

==[[User:Winne Woodget | Winne Woodget]]==

* 6912/6912

==[[User:Matias Carter | Matias Carter]]==

* 7168/7168

==[[User:Xugu Madison | Xugu Madison]]==

* 8192/8192

==[[User:Eddy Stryker | Eddy Stryker]]==

* 5888/5888

==[[User:Latif Khalifa | Latif Khalifa]]==

* 6144/6144

==[[User:Tracy Welles | Tracy Welles ]]==

* 4352/4352

==[[User:Bluecat Jun | Bluecat Jun ]]==

* 7424/7424

==[[User:Julie Wasserstrom | Julie Wasserstrom ]]==

* 5888/5888

==[[User:Chris Samtanko | Chris Samtanko ]]==

*4864/4864

==[http://mrtopf.de/blog Tao Takashi ]==

*6656/6656

==[[User:Jim Kupferberg | Jim Kupferberg ]]==

*6656/6400

==[[User:Emma Nowhere | Emma Nowhere ]]==

*5120/5120

==[[User:Gomez Bracken | Gomez Bracken ]]==

*8448/8448

==[[User:Ciemaar Flintoff | Ciemaar Flintoff ]]==

*6656/7680

==[[User:Media Hax | Media Hax ]]==

*5632/5632
==[[User:Twa Hinkle | Twa Hinkle ]]==

*7680/7680

==[[User:Vicero Lambert | Vicero Lambert ]]==

*5130/5130

==[[User:Whichway Janus | Whichway Janus ]]==

*6656/6912

==[[User:Stamo Stuer | Stamo Stuer ]]==

*5376/5376

==[[User:Patnad Babii | Patnad Babii ]]==

* <font color="pink">9728/9728</font>

==[[User:Torrid Luna | Torrid Luna ]]==

*6144/8448

==[http://blog.simgis.com Darb Dabney ]==

* 4608/4352

==[[User:Morph Wollongong | Morph Wollongong ]]==

* 6789/6789

==[[User:Estate Shepherd | Estate Shepherd ]]==

* 8704/8704

==[[User:Zerodog Witte | Zerodog Witte ]]==

* 8448/8448

==[[User:Lil Linden | Lil Linden]]==

* 2806/2806

==[[User:EriX Oh | EriX Oh]]==

* 4352/4864

==[[User:James Benedek | James Benedek]]==

* 7936/7936

==[[User:Hawk Carter | Hawk Carter]]==

* 9984/9984

==[[User:McCoy Ducatillon | McCoy Ducatillon]]==

* 8960/8960

==[[User:Laurent Bechir | Laurent Bechir]]==

* 9216/9216

==[[User:Economic Mip | Economic Mip]]==

* 9216/8960

==[[User:whyroc Slade | whyroc Slade]]==

* 10240/10240

==[[User:Bartholomew Kleiber | Bartholomew Kleiber]]==

* 10752/10752

==[[User:Arbitar Basiat | Arbitar Basiat]]==

* 13056/13056

==[[User:KustomKreator4u Inglewood | KustomKreator4u Inglewood]]==

* 11008/11008

==[[User:TheCoolLeader Boyer | TheCoolLeader Boyer ]]==

* 16384/16384

==[[User:Aidamina Hunt | Aidamina Hunt ]]==

* 25600/25600

==[[User:Stirling Allen|Stirling Allen]] 19:59, 4 August 2008 (PDT)==

*65536/65536 (ETA Friday 9 August)

==[[User:Sonof Marvin|Sonof Marvin]]==

*69683/69683

==[[User:Radioactive Rosca|Radioactive Rosca]]==

*4864/5376

==[[User:Jim Brock|Jim Brock]]==

* 9472/9472

==[[User:Jonit Ivory|Jonit Ivory]]==

* 11264/11264

==[[User:Ideia Boa|Ideia Boa]]==

* 4096/4608

==[[User:Athanasius Skytower|Athanasius Skytower]]==

* 5632/6656

==[[User:camilla Yosuke|camilla Yosuke]]==

* 6656/4352
==[[User:bonghit Schism|bonghit Schism]]==

* 12544/12544

==[[User:Elio Donat|Elio Donat]]==

* 6656/4353

==[[User: Just Dinkin|Just Dinkin]]==
* 11520/11520

==[[User: Miki Gymnast|Miki Gymnast]]==
* 8448/5632

==[[User: Jillian Taringa|Jillian Taringa]]==
* 11776/11776

==[[User: JB Kraft|JB Kraft]]==
* 6400/4608

==[[User: Wangxiang Tuxing|Wangxiang Tuxing]]==
* 9472/11264

==[[User: Tensai Hilra|Tensai Hilra]]==
* 12800/12800

==[[User: Mirt Tenk|Mirt Tenk]]==
* 5376/7680

==[[User: Maniac Choche|Maniac Choche]]==
* 5632/5888

==[[User: Kish Kas|Kish Kas]]==
* 6400/6656

==[[User: Bit2zero Planer|Bit2zero Planer]]==
* 6500/6656

==[[User: Trifile Toshi|Trifile Toshi]]==
* 20736/20736

==[[User: Micheil Merlin|Micheil Merlin]]==
* 4608/5120

==[[User: Yuu Nakamichi|Yuu Nakamichi]]==
* 9728/8960

==[[User: Norgan Torok|Norgan Torok]]==
* 6400/6400

==[[User: Master Huldschinsky|Master Huldschinsky]]==
* 16400/16400

==[[User: Giulio Perhaps|Giulio Perhaps]]==
* 16640/16640

==[[User: Lexa Sands|Lexa Sands]]==
* 6400/6144 - Lexania - URI: http://lexa.ath.cx:9000

==[[User:Junta Kohime | Junta Kohime ]]==

* 6400/5888 - Born To Learn - URI: http://borntolearn.dyndns.org:9000

==[[User: Strawberry Fride | Strawberry Fride]]==
* 17408/17408

==[[User: G2 Proto | G2 Proto]]==
* 17664/17664 http://www.reactiongrid.com http://reactiongrid.com:10500

==[[User: Kuraiko Yoshikawa|Kuraiko Yoshikawa]]==
*4096/4864 [http://zeitenwerk.de:9128 URI]

==[[User: Prometheus Dovgal|Prometheus Dovgal]]==
*17920/17920

==[[User: Cow Taurog|Cow Taurog]]==
* 3328/3328 - [http://cowtaurog.cjb.net:9000 The Pasture]

==[[User: Camus Omegamu|Camus Omegamu]]==
* 4608/8704

==[[User: m0rdred Veil|m0rdred Veil]]==
* 18176/18176 - La Isla West - URI: http://24.30.54.84:9000

==[[User: Kliger Dinkin|Kliger Dinkin]]==
* 13312/13312

==[[User: Audoa Giha|Audoa Giha]]==
* 19200/19200 Will be up/down for maint otherwise 24/7 URI: http://71.164.172.52:9000/

==[[User: Ceyna Indigo|Ceyna Indigo]]==
* 32768/32768
==[[User: Bulli Schumann|Bulli Schumann]]==
* 46080/46080 - Come visit if you like... still very barren... but it will prob. be expanded in a while: http://80.60.232.130:9000

==[[User: Ansel Gasparini|Ansel Gasparini]]==
* 4352/4608

==[[User: Xerbi Zerbino|Xerbi Zerbino]]==
* 12032/12032

==[[User: Siddhartha Fonda | Siddhartha Fonda]]==
* 22272/22272

==[[User: elmanytas Ferrentino | elmanytas Ferrentino]]==
* 2560/2304

==[[User:Mana Janus|Mana Janus]]==
* 5120/7680

==[[User:Easyfresh Auer|Easyfresh Auer]]==
* 1090048/1090048

==[[User:Nomad Ingwer|Nomad Ingwer]]==
* 27648/27648

==[[User:Quinlan Quimby|Quinlan Quimby]]==
* 28416/28416

==[[User:Woot Avro|Woot Avro]]==
* 4096/4608

==[[User:Herfulnerful Holsworthy|Herfulnerful Holsworthy]]==
* 8192/16384
* 8192/16640

==[[User:pb Qinan|pb Qinan]]==
* 9472/8960

==[[User:Tara5 Oh|Tara5 Oh]]==
*15616/15616 - Visit us at URI: ugotrade.net:9000

==[[User:Drax Lemieux|Drax Lemieux]]==
*16128/16128

==[[User:Opensource Obscure|Opensource Obscure]]==
*51200/51200

==[[User:Harleen Gretzky|Harleen Gretzky]]==
*5120/51200

==[[User:Lapsus Weinstein|Lapsus Weinstein]]==
*17408/17408

==[[User:Amarillo Mertel|Amarillo Mertel]]==
*25600/25600

==[[User:Rasmusson Oranos|Rasmusson Oranos]]==
*18432/18432

==[[User:Tylor Ferraris|Tylor Ferraris]]==
*1054976/1054976

==[[User:Teravus Ousley|Teravus Ousley]]==
*1048832/1048832 (ogp) 4097/4097 OpenSimulator

[[Category:Open_Grid_Public_Beta]]

Open Grid Public Beta/Map Locations

Teravus Ousley — Tue, 19 Aug 2008 01:42:28 GMT

Teravus Ousley:

OpenSim regions cannot be placed directly adjacent to existing regions on aditi or vaak.

:[[User:Zha_Ewry|Zha Ewry]]: "Setup as a very basic stand alone opensim. set the default location and the location of your region to be the same value, and run only one region on the server. (ie. in OpenSim.ini, make sure you set default_loc_x and default_loc_y, and make them match the ones in the default.xml in the Regions subdirectory of you r bin directory in your install. Make sure your X and Ys are multiples of 256."

Non-Linden Lab OpenSims should use default_loc_x and default_loc_y values greater than 4096.

Claim Map Locations Below

Claims that are not multiples of 256 will be marked in pink.

==[[User:Whump_Linden | Whump Linden ]]==

* 2048/2048
* 2304/2560

==[[User:Enus_Linden | Enus Linden ]]==

* 2304/2304

==[[User:Dahlia_Trimble | Dahlia Trimble ]]==

* 4096/4096
* 4352/4352
* 4608/4608

==[[User:Christophe003_Carter | Christophe003 Carter ]]==

* 4608/4608

==[[User:Pier_Tempel | Pier Tempel ]]==

* 5120/5120

==[[User:BlueWall Slade | Bluewall Slade]]==
*6400/6400 URI: http://ascent.bluewallgroup.com:9300

==[[User:Winne Woodget | Winne Woodget]]==

* 6912/6912

==[[User:Matias Carter | Matias Carter]]==

* 7168/7168

==[[User:Xugu Madison | Xugu Madison]]==

* 8192/8192

==[[User:Eddy Stryker | Eddy Stryker]]==

* 5888/5888

==[[User:Latif Khalifa | Latif Khalifa]]==

* 6144/6144

==[[User:Tracy Welles | Tracy Welles ]]==

* 4352/4352

==[[User:Bluecat Jun | Bluecat Jun ]]==

* 7424/7424

==[[User:Julie Wasserstrom | Julie Wasserstrom ]]==

* 5888/5888

==[[User:Chris Samtanko | Chris Samtanko ]]==

*4864/4864

==[http://mrtopf.de/blog Tao Takashi ]==

*6656/6656

==[[User:Jim Kupferberg | Jim Kupferberg ]]==

*6656/6400

==[[User:Emma Nowhere | Emma Nowhere ]]==

*5120/5120

==[[User:Gomez Bracken | Gomez Bracken ]]==

*8448/8448

==[[User:Ciemaar Flintoff | Ciemaar Flintoff ]]==

*6656/7680

==[[User:Media Hax | Media Hax ]]==

*5632/5632
==[[User:Twa Hinkle | Twa Hinkle ]]==

*7680/7680

==[[User:Vicero Lambert | Vicero Lambert ]]==

*5130/5130

==[[User:Whichway Janus | Whichway Janus ]]==

*6656/6912

==[[User:Stamo Stuer | Stamo Stuer ]]==

*5376/5376

==[[User:Patnad Babii | Patnad Babii ]]==

* <font color="pink">9728/9728</font>

==[[User:Torrid Luna | Torrid Luna ]]==

*6144/8448

==[http://blog.simgis.com Darb Dabney ]==

* 4608/4352

==[[User:Morph Wollongong | Morph Wollongong ]]==

* 6789/6789

==[[User:Estate Shepherd | Estate Shepherd ]]==

* 8704/8704

==[[User:Zerodog Witte | Zerodog Witte ]]==

* 8448/8448

==[[User:Lil Linden | Lil Linden]]==

* 2806/2806

==[[User:EriX Oh | EriX Oh]]==

* 4352/4864

==[[User:James Benedek | James Benedek]]==

* 7936/7936

==[[User:Hawk Carter | Hawk Carter]]==

* 9984/9984

==[[User:McCoy Ducatillon | McCoy Ducatillon]]==

* 8960/8960

==[[User:Laurent Bechir | Laurent Bechir]]==

* 9216/9216

==[[User:Economic Mip | Economic Mip]]==

* 9216/8960

==[[User:whyroc Slade | whyroc Slade]]==

* 10240/10240

==[[User:Bartholomew Kleiber | Bartholomew Kleiber]]==

* 10752/10752

==[[User:Arbitar Basiat | Arbitar Basiat]]==

* 13056/13056

==[[User:KustomKreator4u Inglewood | KustomKreator4u Inglewood]]==

* 11008/11008

==[[User:TheCoolLeader Boyer | TheCoolLeader Boyer ]]==

* 16384/16384

==[[User:Aidamina Hunt | Aidamina Hunt ]]==

* 25600/25600

==[[User:Stirling Allen|Stirling Allen]] 19:59, 4 August 2008 (PDT)==

*65536/65536 (ETA Friday 9 August)

==[[User:Sonof Marvin|Sonof Marvin]]==

*69683/69683

==[[User:Radioactive Rosca|Radioactive Rosca]]==

*4864/5376

==[[User:Jim Brock|Jim Brock]]==

* 9472/9472

==[[User:Jonit Ivory|Jonit Ivory]]==

* 11264/11264

==[[User:Ideia Boa|Ideia Boa]]==

* 4096/4608

==[[User:Athanasius Skytower|Athanasius Skytower]]==

* 5632/6656

==[[User:camilla Yosuke|camilla Yosuke]]==

* 6656/4352
==[[User:bonghit Schism|bonghit Schism]]==

* 12544/12544

==[[User:Elio Donat|Elio Donat]]==

* 6656/4353

==[[User: Just Dinkin|Just Dinkin]]==
* 11520/11520

==[[User: Miki Gymnast|Miki Gymnast]]==
* 8448/5632

==[[User: Jillian Taringa|Jillian Taringa]]==
* 11776/11776

==[[User: JB Kraft|JB Kraft]]==
* 6400/4608

==[[User: Wangxiang Tuxing|Wangxiang Tuxing]]==
* 9472/11264

==[[User: Tensai Hilra|Tensai Hilra]]==
* 12800/12800

==[[User: Mirt Tenk|Mirt Tenk]]==
* 5376/7680

==[[User: Maniac Choche|Maniac Choche]]==
* 5632/5888

==[[User: Kish Kas|Kish Kas]]==
* 6400/6656

==[[User: Bit2zero Planer|Bit2zero Planer]]==
* 6500/6656

==[[User: Trifile Toshi|Trifile Toshi]]==
* 20736/20736

==[[User: Micheil Merlin|Micheil Merlin]]==
* 4608/5120

==[[User: Yuu Nakamichi|Yuu Nakamichi]]==
* 9728/8960

==[[User: Norgan Torok|Norgan Torok]]==
* 6400/6400

==[[User: Master Huldschinsky|Master Huldschinsky]]==
* 16400/16400

==[[User: Giulio Perhaps|Giulio Perhaps]]==
* 16640/16640

==[[User: Lexa Sands|Lexa Sands]]==
* 6400/6144 - Lexania - URI: http://lexa.ath.cx:9000

==[[User:Junta Kohime | Junta Kohime ]]==

* 6400/5888 - Born To Learn - URI: http://borntolearn.dyndns.org:9000

==[[User: Strawberry Fride | Strawberry Fride]]==
* 17408/17408

==[[User: G2 Proto | G2 Proto]]==
* 17664/17664 http://www.reactiongrid.com http://reactiongrid.com:10500

==[[User: Kuraiko Yoshikawa|Kuraiko Yoshikawa]]==
*4096/4864 [http://zeitenwerk.de:9128 URI]

==[[User: Prometheus Dovgal|Prometheus Dovgal]]==
*17920/17920

==[[User: Cow Taurog|Cow Taurog]]==
* 3328/3328 - [http://cowtaurog.cjb.net:9000 The Pasture]

==[[User: Camus Omegamu|Camus Omegamu]]==
* 4608/8704

==[[User: m0rdred Veil|m0rdred Veil]]==
* 18176/18176 - La Isla West - URI: http://24.30.54.84:9000

==[[User: Kliger Dinkin|Kliger Dinkin]]==
* 13312/13312

==[[User: Audoa Giha|Audoa Giha]]==
* 19200/19200 Will be up/down for maint otherwise 24/7 URI: http://71.164.172.52:9000/

==[[User: Ceyna Indigo|Ceyna Indigo]]==
* 32768/32768
==[[User: Bulli Schumann|Bulli Schumann]]==
* 46080/46080 - Come visit if you like... still very barren... but it will prob. be expanded in a while: http://80.60.232.130:9000

==[[User: Ansel Gasparini|Ansel Gasparini]]==
* 4352/4608

==[[User: Xerbi Zerbino|Xerbi Zerbino]]==
* 12032/12032

==[[User: Siddhartha Fonda | Siddhartha Fonda]]==
* 22272/22272

==[[User: elmanytas Ferrentino | elmanytas Ferrentino]]==
* 2560/2304

==[[User:Mana Janus|Mana Janus]]==
* 5120/7680

==[[User:Easyfresh Auer|Easyfresh Auer]]==
* 1090048/1090048

==[[User:Nomad Ingwer|Nomad Ingwer]]==
* 27648/27648

==[[User:Quinlan Quimby|Quinlan Quimby]]==
* 28416/28416

==[[User:Woot Avro|Woot Avro]]==
* 4096/4608

==[[User:Herfulnerful Holsworthy|Herfulnerful Holsworthy]]==
* 8192/16384
* 8192/16640

==[[User:pb Qinan|pb Qinan]]==
* 9472/8960

==[[User:Tara5 Oh|Tara5 Oh]]==
*15616/15616 - Visit us at URI: ugotrade.net:9000

==[[User:Drax Lemieux|Drax Lemieux]]==
*16128/16128

==[[User:Opensource Obscure|Opensource Obscure]]==
*51200/51200

==[[User:Harleen Gretzky|Harleen Gretzky]]==
*5120/51200

==[[User:Lapsus Weinstein|Lapsus Weinstein]]==
*17408/17408

==[[User:Amarillo Mertel|Amarillo Mertel]]==
*25600/25600

==[[User:Rasmusson Oranos|Rasmusson Oranos]]==
*18432/18432

==[[User:Tylor Ferraris|Tylor Ferraris]]==
*1054976/1054976

==[[User:Teravus Ousley|Teravus Ousley]]==
*1048832/1048832

[[Category:Open_Grid_Public_Beta]]

Viewer Authentication

Teravus Ousley — Thu, 10 Jan 2008 07:43:59 GMT

Teravus Ousley: /* See also */

{{Alert Box|
<b>Note:</b> If you would like to discuss the changes stated in this page, please use the discussion tab at the top. We are reading it and answering your questions there and will update the wiki as needed. Thank you!

<b>Note:</b> This page primarily describes Linden employees' view on the issue that some open source developers have expressed concerns against. If you want to know the open source developers' view or related backgrounds, you are advised to read not just this page but also the [[Talk:Viewer Authentication|associated discussion page]] and [[Viewer Authentication Critique]] page.

<b>Note:</b> The first note above was written by a Linden, and the word "we" refers "Linden employees". The second note (as well as this note) was added by a resident {{User|Alissa Sabre}} for clarification.
}}
= Viewer Authentication =

Fairly soon, Linden Lab is going to introduce new form of logging in. The current process requires an xml-rpc call from your viewer to our servers that runs along an inflexible code-path that is difficult to maintain. This process will change to a web-based path that is easier to maintain and will allow us easier access to tools for making logins smarter and furthering our anti-fraud efforts.

== What Changes For You? ==

You will see one change when this is released. The viewer's login page will be web-based. It actually won't look that different from the current interface and allows all the same functionality.

(Note: The optional "Go Inworld!" page mentioned here before will be a part of a separate release as it requires more work.)

Keep in mind that if you are developing a third-party application to access Second Life, we will be keeping our old login methods intact until you catch up with the new process - at which point we will shut down the old pathways.

== Frequently Asked Questions ==

==="On the viewer's login screen, I'm given the choice of where I want to log into. Will I still have that option?"===
Yes. This functionality will be the same both in the viewer's login and on the website's login.

==="I use Second Life from a computer that is not mine. How does this affect me?"===
Everything works the same as before.

==="Why aren't you fixing bugs? I don't care about login!"===
Linden Lab has a team of developers who are constantly fixing bugs in Second Life. However, we also have developers who work on the website, the servers, and specific issues such as security, billing, and fraud prevention. Viewer Authentication is being developed in order to extend the ability of our logins such that they can take advantage of new fraud prevention measures, future account security measures, and be placed in a more flexible and easier to access code-path. Fixes to the website's login can be instantly ported to the viewer's login and vice versa.

==="What happens when I want to use the First Look client or some other third-party application?"===
Until they are brought up to speed with the new login process, these extra applications will still be able to use our old login procedure.

== Technical Overview ==
===In order to maintain backward compatibility, there will initially be several ways to log in:===

* Login from legacy viewer using current XUI and name/password.
** Until they are brought up to speed with the new login process, other clients will still be able to use our old login procedure. This transition is expected to complete by beginning of February, at which point a mandatory update will be required.
* Login from a new viewer from login screen
** Login form removed from screen XUI
** Web login modules added to login screen splash page
** Splash screen saves and passes web login key in a [[SLURL]] to viewer using a redirect
** Viewer logs in with name/web_login_key
** May be deprecated eventually, but because of pushback from sldev, we decided not to
* Login from InWorld page on Second Life website (https://secondlife.com/inworld/index.php)
** Go Inworld generates and persists web_login_key, returns it coded into secondlife:// url.
** OS launches viewer associated with secondlife:// (last used viewer, or last installed viewer).
** Viewer parses url, logs in with name/sid

===The common web mechanism is as follows:===
* Website confirms (cookie) that resident is logged in by filling in user name fields if they are
* Website also takes many query parameters to automatically fill in fields in the form
* The known query parameters are the following;
** '''firstname or username'''. Both get mapped to the first name of the avatar.
** '''lastname''' - avatar's last name
** '''location''' -
** '''region''' - Typed region name of the simulator the avatar desires to go once logged in
** '''grid''' - the Grid that the agent is logging into. some valid options are Agni, Aditi, Other
** '''channel''' - The client type that you're using. (SecondLife WindLight or Release Client)
** '''version''' - The version of the client you're using
** '''lang''' - The language set that you're using on the client.
** '''save_password''' - Exists when the save password checkbox is checked.
* Upon receiving POST, website generates a temporary, single use web_login_key and persists it to web_login_key web store on central backbone
* Website redirects to the continuation url provided, and appending web_login_key as a query argument at the end
** For login via website, continuation url: secondlife://viewer/login?firstname=;lastname=;session_id=;location=?'
** For login via viewer, continuation url: about:blank?redirect-http-hack=($URLENCODE(secondlife://viewer/login?firstname=;lastname=;session_id=;location=?'))
* Viewer catches or launches and uses user name and web_login_key to send to login.cgi using [[Current_login_protocols]](in the future LLSD)
* login.cgi checks session id and allows the user in

===Additional Note:===
* The public login forms on secondlife send a [[SLURL]] like, secondlife:///app/login?first_name='''firstname'''&last_name='''lastname'''&location='''location'''&grid='''Agni'''&web_login_key='''LLUUID'''
* the viewer sends the same address but encapsulates it in an about:blank page parameter - about:blank?redirect-http-hack=secondlife:///app/login?first_name='''firstname'''&last_name='''lastname'''&location='''location'''&grid='''Agni'''&web_login_key='''LLUUID'''

===Additional info:===
* Logging into a custom/internal grid appears to require two secondlife.exe parameters;
** -loginpage <URL>, the login page displayed to the client
** -loginuri <URI>, the address that the client should look for the login.cgi

== See also ==

[[Login Protocol]] - general summary of login protocols

[[Viewer_Authentication_Form_Example]] - Example Login form geared for the Viewer

Viewer Authentication Form Example

Teravus Ousley — Thu, 10 Jan 2008 07:42:57 GMT

Teravus Ousley: /* Example Viewer Authentication Form */

= Example Bare-Bones Viewer Authentication Form=

<code>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="cache-control" content="no-cache">
<meta http-equiv="Pragma" content="no-cache">
<title>Second Life Login</title>

<body><div id="login_box">
<form action="/go.cgi" method="POST" id="login-form">
<div id="message"></div>

<fieldset id="firstname"><legend>First Name:</legend><input type="text" id="firstname_input" size="15" maxlength="100" name="username" value="" /></fieldset>

<fieldset id="lastname"><legend>Last Name:</legend><input type="text" size="15" maxlength="100" name="lastname" value="" /></fieldset>

<fieldset id="password"><legend>Password:</legend>

<input type="password" size="15" maxlength="100" name="password" value="" />
<input type="checkbox" name="remember_password" id="remember_password" value="" checked style="margin-left:0px;"/>

<label for="remember_password">Remember password</label>
</fieldset>

<input type="hidden" id="grid" name="grid" value="" />

<div id="submitbtn"><input class="input_over" type="submit" value="Connect" /></div>

<div id="helplinks"></div>
<div id="channelinfo"> | =</div>
</form>
<script language="JavaScript">document.getElementById('firstname_input').focus();</script>

</div>
</div>

</body></html>

</code>

User:Teravus Ousley

Teravus Ousley — Thu, 10 Jan 2008 07:07:53 GMT

Teravus Ousley:

{{Jira Reporter}}
Greetings. If you're reading this then you've probably seen some of the updates to the Wiki, or issues reported in Jira and are looking for a bit more information about me.

Generally i'm quiet, relaxed, approachable and friendly. So, if you have questions, comments or feedback please send them my way. Sometimes I can be found in world, sometimes, i'm on IRC on freenode in #opensim-dev. My in world IMs get capped quite quickly, so those wouldn't be an adequate way to get in contact with me.

I have affiliations with, Daryth Kennedy's Isle of Wyrms, and OpenSim (the Open Source Simulator project)

Viewer Authentication Critique

Teravus Ousley — Thu, 10 Jan 2008 06:49:59 GMT

Teravus Ousley: /* Cons */

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.]

== Note ==

It was not explicit in the original article what the motivations behind LL's proposed new authentication system are. The goals (Security, Flexibility, Persistence) and benefits listed here are what SLDev believed them to be based on the original description and e-mail discussions. One of the less stated but said higher priority goals[https://lists.secondlife.com/pipermail/sldev/2007-October/005546.html] is that of anti-fraud measures, but it is not practical to critique unpublicized or miscommunicated anti-fraud plans. This article, therefore, still lacks an essential critique about fraud prevention/detection as possibly desired when solicited.

== Summary ==

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 in that it would acclimatise users to starting the viewer via a web page. At present most password compromises are probably due to weaknesses in the current protocol challenge response, due to allowing weak passwords, due to security compromises in the LL websites 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 synchronize 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. A relatively simpler mod to the web site could prevent the account details for a different alt displaying when the account menu options are selected in the client. There is an argument that separating the passwords and logon for the forums would actually improve security.

The suggestion of providing an embedded way of displaying the web form within the viewer so that you will not have to always start the viewer from a web browser is a non-starter, not just because of problems with the current code in handling web proxies, but because it would be very easy for the embedded web form handling code to log the form data before POSTing to the web site thus undermining any benefits gained.

Overall, the additional development time both for 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 ==

=== Benefits Stated By LL ===
* 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.
* To consolidate the authentication implementation in order to support back-end anti-fraud work

=== 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.
<br>
* 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.
<br>
* 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
*** Just a comment here: The latest release client logs into OpenSim Successfully - [[User:Teravus Ousley|Teravus Ousley]] 22:49, 9 January 2008 (PST)
<br>
* It is suggested that the viewer will embed the web form within the viewer -
** This escalates the importance of addressing a number of current problems with llmozlib in the current viewer code:
*** there are problems compiling llmozlib on the Linux platform
*** proxies are not supported
** In any case, a modded client easily log the form data before submitting it to the webform, i.e. all the concerns about clients grabbing passwords would still apply!
<br>
* 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)
* For considation have a single backend web service which does the actual authentication - but which is fronted by GUI frontends (e.g. in the viewer) and web frontends (e.g. for accessing the web based account pages etc.)
* 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
<br>
* Log of successful or failed login attempts including ip address (or at least a notice of the last attempt)
* Black, White or Greylist IP (specific or > network ranges)- This would allow someone with a static, or semi-static IP to prevent client logons to their account unless they appear on the Whitelist of approved IP's. Greylisting would allow one login attempt every 5-10 minutes and could be used when traveling. > IP's on the blacklist would not be able to log into the account at all
** Question: how many people have, or even know they have, static or semi static IPs?
* Lock account if too many consecutive logon requests (to prevent automated dictionary attacks) - a user should be able to unlock an account via the website using additional validation such as CAPTCHA's and providing additional information on file such as date of birth.
<br>
* 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
*** Note that the proposed authentication mechanism via a web form might prevent any attempt at implementing a challenge-response mechanism
** Dictionary check to reject insecure passwords

== Flexibility ==

=== Benefits Stated By LL ===
* 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.
<br>
* 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
<br>
* 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 ==

=== Benefits Stated By LL ===
* 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".
* There is an argument that the forum logon should be seperated from the SL account logon
** This would fit the practice of those using alts, when they only use one account on the forums but would need to check the account details of various alts.
** Having seperate passwords would isolate security compromises in the forums software from compromising the SL account itself.

== 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) (Please see my notes: [https://lists.secondlife.com/pipermail/sldev/2007-October/005605.html] [https://lists.secondlife.com/pipermail/sldev/2007-October/005615.html])
* [[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)
* [[User:Whoops Babii|Whoops Babii]] 05:29, 1 October 2007 (PDT)
* [[User:Feep Larsson|Feep Larsson]] 06:29, 1 October 2007 (PDT)
* [[User:Gibson Willis|Gibson Willis]] 07:11, 1 October 2007 (PDT)
* [[User:Grazer Kline|Grazer Kline]] 10:34, 1 October 2007 (PDT)
* [[User:Odysseus Fairymeadow|Odysseus Fairymeadow]] 13:58, 1 October 2007 (PDT)
* [[User:Melanie Milland|Melanie Milland]] 16:23, 2 October 2007 (PDT)
* [[User:Seg Baphomet|Seg Baphomet]] 09:33, 8 October 2007 (PDT)
* [[User:Ahzzmandius Werribee|Ahzzmandius Werribee]] 10:06, 6 December 2007 (PST)
* [[User:Henri Beauchamp|Henri Beauchamp]] 00:40, 7 December 2007 (CET)

Talk:Viewer Authentication

Teravus Ousley — Thu, 10 Jan 2008 06:42:38 GMT

Teravus Ousley: /* Alternative grids are usable with the RC Client */

{{Talk}}

== Account hijacking ==
I am sorry but the incidences of account hijacking from persistant logins is going to be FAR greater than incidences from phishing.

How you can actually write something like "So long as you are logged into the website on someone's else computer, they will be able to gain access to your account" and then continue on with the idea /at all/ is astonishing.

Log into web site and launch SL? That's fine by itself. "There" worked that way and it was ok, not as good from a pure usability standpoint but ok..., but it it /cannot/ be persistant. We are talking about real money theft here. This is a lowering of security not an increase in it. And I know that other people do it and there is a "remember password" checkbox on the viewer but that doesn't excuse this. If increasing security is actually the goal, persistant logins anywhere are an about face to it. -- {{unsigned|Farallon Greyskin}} 04:14, 29 September 2007

== Security through browsers ==
This is like snogging SARS patients to improve your health.

Web based UIs are the #1 tool for phishing. The most commonly used web browser in the world is not just insecure, it has security holes that can not even in theory be fixed. It has been a running gag for 10 years now. And if you're worried about people using open source software for phishing, the popular open source browsers are actually MORE secure than the native ones on BOTH Windows and OS X.

On Linux, ALL the browsers are open-source.

This change will reduce reliability, reduce security, and reduce people's confidence in SL. If anything, you should be centralizing logins in the client and have it handle authenticating the browser, not the other way around. -- [[User:Argent Stonecutter|Argent Stonecutter]] 22:09, 28 September 2007 (PDT)

PS: you also need to fix the proxy support in SL before you even THINK of making it use that splash screen for logging in, because that bad boy never even shows up if you're behind a proxy. -- [[User:Argent Stonecutter|Argent Stonecutter]] 22:18, 28 September 2007 (PDT)

== Long beta ==
This should go long intense beta (release candidate) before switching. Things like proxies, network, and a thousand other variants will break this and make it impossible for people to log in.

For example for some debugging scenarios I'm compiling the viewer without llmozlib. If anything, the web communication in the first iteration should happen through libcurl.

[[User:Nicholaz Beresford|Nicholaz]]

== Keylogging, XSS, TAN, Secondary Passwords ==
The weakest point in the approach however is that a malicious viewer can do anything it needs, once logged in. And when started it can simply install a keystroke logger.

Even a web based application (promising to do whatever would appeal to people) could redirect to the SecondLife page for login, either spoofing the SL page or just grabbing the legit login token and then do something else with it.

The only way I see in order to increase security in relation to transactions and valuable assets is to protect these transactions with disposable passwords or one time transaction numbers (TANs), which is an established procedure in the bank industry. But even then a viewer could simply catch the TAN and execute a different transaction instead.

Another approach would be to issue secondary passwords with limited power, so that a viewer logged in with that, will never be able to execute power transactions.
[[User:Nicholaz Beresford|Nicholaz]]

== Usability ==
As I understand it from reading the wiki and a portion of the developer discussion, this would not only constrain a resident to be logged in on the same account website/inworld, but also make it impossible to be inworld with more than one account at once (from one workstation login session). Please correct me if wrong.

If the above is true, I think you will find that the marginal security improvement is far outweighed by the negative usability impact of this change. It impacts residents who bring commerce into SL the most, since estate owners and businessfolks generally use one account for website transactions, and a small set of alts to manage their inworld lives.

Builders and scripters will also find this impossibly awkward, since they often need to have two accounts logged in at once for testing.

Forum users will also be negatively impacted; I leave the forum logged in all day on one account, regardless of which alt I am using inworld. If any.

Please reconsider. (Nika Talaj)

Why not use DNS based security as an optional extra on a residents account settings?
I use another website and to protect the login you can restrict it to the reversed looked-up domain name. So if you always login through an ip address/range that the reverse dns says xxx.myisp.com then you can lock the account to only be possible to login from that ISP. This helps a lot against phishing attacks because the phisher is unlikely to be using the same ISP. To bypass the dns name restriction incase you are logging in from another location, you have to go through the password recovery options via email. This would seem a better solution to protect against phishing. [[User:Jonash Vanalten|Jonash Vanalten]] 07:00, 7 December 2007 (PST)

== Formal critique ==

There's a group collaborating on a formal critique at [[Viewer Authentication Critique]]. This will help Linden Lab have a more organized response and hopefully make sure we don't miss anything. -- [[User:Rob Linden|Rob Linden]] 12:09, 29 September 2007 (PDT)

Could Linden Labs provide a similar page explaining why this is believed to be necessary and what problems they are trying to solve? -- [[User:Argent Stonecutter|Argent Stonecutter]] 13:33, 29 September 2007 (PDT)
:: I see someone added that inline. Could you verify that this is LL's position and goals? -- [[User:Argent Stonecutter|Argent Stonecutter]] 14:07, 29 September 2007 (PDT)

== Bad Idea ==

I'm sorry, but this is another very bad idea, Rob. It causes far more problems than it solves...if it solves any except letting you tie into Open ID.

Please do NOT implement access to SL through the SL website! [[User:Lindal Kidd|Lindal Kidd]] 14:09, 1 October 2007 (PDT)

== But this is an *installed* programme, not a website! ==

''"it is possible to create a clone of the Second Life viewer"'' is, quite clearly, totally true. '''''However''''' SL is something you install on your local machine; it isn't run in Java (or whatever) inside a web browser window. As such you are *fully aware* that you are downloading and installing the ''official'' client. This new mechanism would appear to be sensible for non-official clients, but for the official one it makes no sense at all as it is clearly superfluous. --[[User:Alison Wheels|AlisonW]] 13:07, 2 October 2007 (PDT)

== Please don't! ==

I absolutely hate this browser-centric world view. I do not wish to run a browser in connection with the Second Life client, which, refreshingly, was a program without too much web-tie-in until now.
I am not afraid of using an open source client, I compile my own! It is already hard enough to compile, don't make it harder!
Also, I keep my concierge account logged in on the web site, but use alts to work inworld. This would break that mode of working.

[[User:Melanie Milland|Melanie Milland]] 16:21, 2 October 2007 (PDT)

== Grids other than agni ==

It appears the Release Candidate viewer that uses this scheme is unable to log in to any grid other than agni.lindenlab.com. Is the login page hard-coded to https://secure-web14.secondlife.com/app/login/?show_login_form=True or is there a way to direct it to another grid's login page? [[User:Day Oh|Day Oh]] 17:55, 5 December 2007 (PST)

== Alternative grids are usable with the RC Client==

Alternative grids are usable now with the RC client. The one nuance is you must specify -loginpage and -loginuri on the commandline and bring up the client before loading a SLURL

Another thing to note, an alternative client should be able to avoid the whole login without the mozilla lib issue by responding to a SLURL generated by [https://secure-web14.secondlife.com/inworld/index.php The Go In World Page]

[[User:Teravus Ousley|Teravus Ousley]] 22:42, 9 January 2008 (PST)

Talk:Viewer Authentication

Teravus Ousley — Thu, 10 Jan 2008 06:37:37 GMT

Teravus Ousley: /* RC and Windlight still unable to connect to alternative grids */

Viewer Authentication

Teravus Ousley — Thu, 10 Jan 2008 06:33:49 GMT

Teravus Ousley: /* Technical Overview */

Viewer Authentication

Teravus Ousley — Thu, 10 Jan 2008 00:05:46 GMT

Teravus Ousley: /* Technical Overview */

{{Alert Box|
<b>Note:</b> If you would like to discuss the changes stated in this page, please use the discussion tab at the top. We are reading it and answering your questions there and will update the wiki as needed. Thank you!

<b>Note:</b> This page primarily describes Linden employees' view on the issue that some open source developers have expressed concerns against. If you want to know the open source developers' view or related backgrounds, you are advised to read not just this page but also the [[Talk:Viewer Authentication|associated discussion page]] and [[Viewer Authentication Critique]] page.

<b>Note:</b> The first note above was written by a Linden, and the word "we" refers "Linden employees". The second note (as well as this note) was added by a resident {{User|Alissa Sabre}} for clarification.
}}
= Viewer Authentication =

Fairly soon, Linden Lab is going to introduce new form of logging in. The current process requires an xml-rpc call from your viewer to our servers that runs along an inflexible code-path that is difficult to maintain. This process will change to a web-based path that is easier to maintain and will allow us easier access to tools for making logins smarter and furthering our anti-fraud efforts.

== What Changes For You? ==

You will see one change when this is released. The viewer's login page will be web-based. It actually won't look that different from the current interface and allows all the same functionality.

(Note: The optional "Go Inworld!" page mentioned here before will be a part of a separate release as it requires more work.)

Keep in mind that if you are developing a third-party application to access Second Life, we will be keeping our old login methods intact until you catch up with the new process - at which point we will shut down the old pathways.

== Frequently Asked Questions ==

==="On the viewer's login screen, I'm given the choice of where I want to log into. Will I still have that option?"===
Yes. This functionality will be the same both in the viewer's login and on the website's login.

==="I use Second Life from a computer that is not mine. How does this affect me?"===
Everything works the same as before.

==="Why aren't you fixing bugs? I don't care about login!"===
Linden Lab has a team of developers who are constantly fixing bugs in Second Life. However, we also have developers who work on the website, the servers, and specific issues such as security, billing, and fraud prevention. Viewer Authentication is being developed in order to extend the ability of our logins such that they can take advantage of new fraud prevention measures, future account security measures, and be placed in a more flexible and easier to access code-path. Fixes to the website's login can be instantly ported to the viewer's login and vice versa.

==="What happens when I want to use the First Look client or some other third-party application?"===
Until they are brought up to speed with the new login process, these extra applications will still be able to use our old login procedure.

== Technical Overview ==
In order to maintain backward compatibility, there will initially be several ways to log in:

* Login from legacy viewer using current XUI and name/password.
** Until they are brought up to speed with the new login process, other clients will still be able to use our old login procedure. This transition is expected to complete by beginning of February, at which point a mandatory update will be required.
* Login from a new viewer from login screen
** Login form removed from screen XUI
** Web login modules added to login screen splash page
** Splash screen saves and passes web login key to viewer using a redirect
** Viewer logs in with name/web_login_key
** May be deprecated eventually, but because of pushback from sldev, we decided not to
* Login from InWorld page on Second Life website (https://secondlife.com/inworld/index.php)
** Go Inworld generates and persists web_login_key, returns it coded into secondlife:// url.
** OS launches viewer associated with secondlife:// (last used viewer, or last installed viewer).
** Viewer parses url, logs in with name/sid

The common web mechanism is as follows:
* Website confirms (cookie) that resident is logged in by filling in user name fields if they are
* Website also takes many query parameters to automatically fill in fields in the form
* Upon receiving POST, website generates a temporary, single use web_login_key and persists it to web_login_key web store on central backbone
* Website redirects to the continuation url provided, and appending web_login_key as a query argument at the end
** For login via website, continuation url: secondlife://viewer/login?firstname=;lastname=;session_id=;location=?'
** For login via viewer, continuation url: about:blank?redirect-http-hack=($URLENCODE(secondlife://viewer/login?firstname=;lastname=;session_id=;location=?'))
* Viewer catches or launches and uses user name and web_login_key to send to login.cgi
* login.cgi checks session id and allows the user in

Additional info:
* Logging into a custom/internal grid appears to require two secondlife.exe parameters;
** -loginpage <URL>, the login page displayed to the client
** -loginuri <URI>, the address that the client should look for the login.cgi equivalent

Additional Note:
* The public login forms on secondlife seem to send something like, secondlife:///app/login?first_name=*firstname*&last_name=*lastname*&location=*location*&grid=Agni&web_login_key=*UUID*
** The asterix are used to note the parts of the URL that are filled in with an actual value

== See also ==

[[Login Protocol]] - general summary of login protocols

Viewer Authentication

Teravus Ousley — Thu, 10 Jan 2008 00:03:51 GMT

Teravus Ousley: /* Technical Overview */

{{Alert Box|
<b>Note:</b> If you would like to discuss the changes stated in this page, please use the discussion tab at the top. We are reading it and answering your questions there and will update the wiki as needed. Thank you!

<b>Note:</b> This page primarily describes Linden employees' view on the issue that some open source developers have expressed concerns against. If you want to know the open source developers' view or related backgrounds, you are advised to read not just this page but also the [[Talk:Viewer Authentication|associated discussion page]] and [[Viewer Authentication Critique]] page.

<b>Note:</b> The first note above was written by a Linden, and the word "we" refers "Linden employees". The second note (as well as this note) was added by a resident {{User|Alissa Sabre}} for clarification.
}}
= Viewer Authentication =

Fairly soon, Linden Lab is going to introduce new form of logging in. The current process requires an xml-rpc call from your viewer to our servers that runs along an inflexible code-path that is difficult to maintain. This process will change to a web-based path that is easier to maintain and will allow us easier access to tools for making logins smarter and furthering our anti-fraud efforts.

== What Changes For You? ==

You will see one change when this is released. The viewer's login page will be web-based. It actually won't look that different from the current interface and allows all the same functionality.

(Note: The optional "Go Inworld!" page mentioned here before will be a part of a separate release as it requires more work.)

Keep in mind that if you are developing a third-party application to access Second Life, we will be keeping our old login methods intact until you catch up with the new process - at which point we will shut down the old pathways.

== Frequently Asked Questions ==

==="On the viewer's login screen, I'm given the choice of where I want to log into. Will I still have that option?"===
Yes. This functionality will be the same both in the viewer's login and on the website's login.

==="I use Second Life from a computer that is not mine. How does this affect me?"===
Everything works the same as before.

==="Why aren't you fixing bugs? I don't care about login!"===
Linden Lab has a team of developers who are constantly fixing bugs in Second Life. However, we also have developers who work on the website, the servers, and specific issues such as security, billing, and fraud prevention. Viewer Authentication is being developed in order to extend the ability of our logins such that they can take advantage of new fraud prevention measures, future account security measures, and be placed in a more flexible and easier to access code-path. Fixes to the website's login can be instantly ported to the viewer's login and vice versa.

==="What happens when I want to use the First Look client or some other third-party application?"===
Until they are brought up to speed with the new login process, these extra applications will still be able to use our old login procedure.

== Technical Overview ==
In order to maintain backward compatibility, there will initially be several ways to log in:

* Login from legacy viewer using current XUI and name/password.
** Until they are brought up to speed with the new login process, other clients will still be able to use our old login procedure. This transition is expected to complete by beginning of February, at which point a mandatory update will be required.
* Login from a new viewer from login screen
** Login form removed from screen XUI
** Web login modules added to login screen splash page
** Splash screen saves and passes web login key to viewer using a redirect
** Viewer logs in with name/web_login_key
** May be deprecated eventually, but because of pushback from sldev, we decided not to
* Login from InWorld page on Second Life website (https://secondlife.com/inworld/index.php)
** Go Inworld generates and persists web_login_key, returns it coded into secondlife:// url.
** OS launches viewer associated with secondlife:// (last used viewer, or last installed viewer).
** Viewer parses url, logs in with name/sid

The common web mechanism is as follows:
* Website confirms (cookie) that resident is logged in by filling in user name fields if they are
* Website also takes many query parameters to automatically fill in fields in the form
* Upon receiving POST, website generates a temporary, single use web_login_key and persists it to web_login_key web store on central backbone
* Website redirects to the continuation url provided, and appending web_login_key as a query argument at the end
** For login via website, continuation url: secondlife://viewer/login?firstname=;lastname=;session_id=;location=?'
** For login via viewer, continuation url: about:blank?redirect-http-hack=($URLENCODE(secondlife://viewer/login?firstname=;lastname=;session_id=;location=?'))
* Viewer catches or launches and uses user name and web_login_key to send to login.cgi
* login.cgi checks session id and allows the user in

Additional info:
* Logging into a custom/internal grid appears to require two secondlife.exe parameters;
** -loginpage <URL>, the login page displayed to the client
** -loginuri <URI>, the address that the client should look for the login.cgi equivalent

Additional Note:
* The public login forms on secondlife seem to send something like, secondlife:///app/login?first_name=*firstname*&last_name=*lastname*&location=*location*&grid=Agni&web_login_key=*UUID*

== See also ==

[[Login Protocol]] - general summary of login protocols

Talk:Friends

Teravus Ousley — Sat, 29 Dec 2007 01:28:20 GMT

Teravus Ousley: Document not accessable to the public

== Document not accessable to the public ==

Just a FYI, the friends document isn't available to the general public. It's located on a Linden Labs internal server that requires a Linden Username and password.

Talk:Viewer Authentication

Teravus Ousley — Tue, 25 Dec 2007 04:34:49 GMT

Teravus Ousley: New section: RC and Windlight still unable to connect to alternative grids

{{Talk}}

== Account hijacking ==
I am sorry but the incidences of account hijacking from persistant logins is going to be FAR greater than incidences from phishing.

How you can actually write something like "So long as you are logged into the website on someone's else computer, they will be able to gain access to your account" and then continue on with the idea /at all/ is astonishing.

Log into web site and launch SL? That's fine by itself. "There" worked that way and it was ok, not as good from a pure usability standpoint but ok..., but it it /cannot/ be persistant. We are talking about real money theft here. This is a lowering of security not an increase in it. And I know that other people do it and there is a "remember password" checkbox on the viewer but that doesn't excuse this. If increasing security is actually the goal, persistant logins anywhere are an about face to it. -- {{unsigned|Farallon Greyskin}} 04:14, 29 September 2007

== Security through browsers ==
This is like snogging SARS patients to improve your health.

Web based UIs are the #1 tool for phishing. The most commonly used web browser in the world is not just insecure, it has security holes that can not even in theory be fixed. It has been a running gag for 10 years now. And if you're worried about people using open source software for phishing, the popular open source browsers are actually MORE secure than the native ones on BOTH Windows and OS X.

On Linux, ALL the browsers are open-source.

This change will reduce reliability, reduce security, and reduce people's confidence in SL. If anything, you should be centralizing logins in the client and have it handle authenticating the browser, not the other way around. -- [[User:Argent Stonecutter|Argent Stonecutter]] 22:09, 28 September 2007 (PDT)

PS: you also need to fix the proxy support in SL before you even THINK of making it use that splash screen for logging in, because that bad boy never even shows up if you're behind a proxy. -- [[User:Argent Stonecutter|Argent Stonecutter]] 22:18, 28 September 2007 (PDT)

== Long beta ==
This should go long intense beta (release candidate) before switching. Things like proxies, network, and a thousand other variants will break this and make it impossible for people to log in.

For example for some debugging scenarios I'm compiling the viewer without llmozlib. If anything, the web communication in the first iteration should happen through libcurl.

[[User:Nicholaz Beresford|Nicholaz]]

== Keylogging, XSS, TAN, Secondary Passwords ==
The weakest point in the approach however is that a malicious viewer can do anything it needs, once logged in. And when started it can simply install a keystroke logger.

Even a web based application (promising to do whatever would appeal to people) could redirect to the SecondLife page for login, either spoofing the SL page or just grabbing the legit login token and then do something else with it.

The only way I see in order to increase security in relation to transactions and valuable assets is to protect these transactions with disposable passwords or one time transaction numbers (TANs), which is an established procedure in the bank industry. But even then a viewer could simply catch the TAN and execute a different transaction instead.

Another approach would be to issue secondary passwords with limited power, so that a viewer logged in with that, will never be able to execute power transactions.
[[User:Nicholaz Beresford|Nicholaz]]

== Usability ==
As I understand it from reading the wiki and a portion of the developer discussion, this would not only constrain a resident to be logged in on the same account website/inworld, but also make it impossible to be inworld with more than one account at once (from one workstation login session). Please correct me if wrong.

If the above is true, I think you will find that the marginal security improvement is far outweighed by the negative usability impact of this change. It impacts residents who bring commerce into SL the most, since estate owners and businessfolks generally use one account for website transactions, and a small set of alts to manage their inworld lives.

Builders and scripters will also find this impossibly awkward, since they often need to have two accounts logged in at once for testing.

Forum users will also be negatively impacted; I leave the forum logged in all day on one account, regardless of which alt I am using inworld. If any.

Please reconsider. (Nika Talaj)

Why not use DNS based security as an optional extra on a residents account settings?
I use another website and to protect the login you can restrict it to the reversed looked-up domain name. So if you always login through an ip address/range that the reverse dns says xxx.myisp.com then you can lock the account to only be possible to login from that ISP. This helps a lot against phishing attacks because the phisher is unlikely to be using the same ISP. To bypass the dns name restriction incase you are logging in from another location, you have to go through the password recovery options via email. This would seem a better solution to protect against phishing. [[User:Jonash Vanalten|Jonash Vanalten]] 07:00, 7 December 2007 (PST)

== Formal critique ==

There's a group collaborating on a formal critique at [[Viewer Authentication Critique]]. This will help Linden Lab have a more organized response and hopefully make sure we don't miss anything. -- [[User:Rob Linden|Rob Linden]] 12:09, 29 September 2007 (PDT)

Could Linden Labs provide a similar page explaining why this is believed to be necessary and what problems they are trying to solve? -- [[User:Argent Stonecutter|Argent Stonecutter]] 13:33, 29 September 2007 (PDT)
:: I see someone added that inline. Could you verify that this is LL's position and goals? -- [[User:Argent Stonecutter|Argent Stonecutter]] 14:07, 29 September 2007 (PDT)

== Bad Idea ==

I'm sorry, but this is another very bad idea, Rob. It causes far more problems than it solves...if it solves any except letting you tie into Open ID.

Please do NOT implement access to SL through the SL website! [[User:Lindal Kidd|Lindal Kidd]] 14:09, 1 October 2007 (PDT)

== But this is an *installed* programme, not a website! ==

''"it is possible to create a clone of the Second Life viewer"'' is, quite clearly, totally true. '''''However''''' SL is something you install on your local machine; it isn't run in Java (or whatever) inside a web browser window. As such you are *fully aware* that you are downloading and installing the ''official'' client. This new mechanism would appear to be sensible for non-official clients, but for the official one it makes no sense at all as it is clearly superfluous. --[[User:Alison Wheels|AlisonW]] 13:07, 2 October 2007 (PDT)

== Please don't! ==

I absolutely hate this browser-centric world view. I do not wish to run a browser in connection with the Second Life client, which, refreshingly, was a program without too much web-tie-in until now.
I am not afraid of using an open source client, I compile my own! It is already hard enough to compile, don't make it harder!
Also, I keep my concierge account logged in on the web site, but use alts to work inworld. This would break that mode of working.

[[User:Melanie Milland|Melanie Milland]] 16:21, 2 October 2007 (PDT)

== Grids other than agni ==

It appears the Release Candidate viewer that uses this scheme is unable to log in to any grid other than agni.lindenlab.com. Is the login page hard-coded to https://secure-web14.secondlife.com/app/login/?show_login_form=True or is there a way to direct it to another grid's login page? [[User:Day Oh|Day Oh]] 17:55, 5 December 2007 (PST)

== RC and Windlight still unable to connect to alternative grids ==

It appears that the loginuri parameter which should work in tandom with the loginpage parameter is not.
See: http://jira.secondlife.com/browse/VWR-4021

Viewer Authentication

Teravus Ousley — Tue, 25 Dec 2007 04:27:08 GMT

Teravus Ousley: /* Technical Overview */

{{Alert Box|
<b>Note:</b> If you would like to discuss the changes stated in this page, please use the discussion tab at the top. We are reading it and answering your questions there and will update the wiki as needed. Thank you!

<b>Note:</b> This page primarily describes Linden employees' view on the issue that some open source developers have expressed concerns against. If you want to know the open source developers' view or related backgrounds, you are advised to read not just this page but also the [[Talk:Viewer Authentication|associated discussion page]] and [[Viewer Authentication Critique]] page.

<b>Note:</b> The first note above was written by a Linden, and the word "we" refers "Linden employees". The second note (as well as this note) was added by a resident {{User|Alissa Sabre}} for clarification.
}}
= Viewer Authentication =

Fairly soon, Linden Lab is going to introduce new form of logging in. The current process requires an xml-rpc call from your viewer to our servers that runs along an inflexible code-path that is difficult to maintain. This process will change to a web-based path that is easier to maintain and will allow us easier access to tools for making logins smarter and furthering our anti-fraud efforts.

== What Changes For You? ==

You will see one change when this is released. The viewer's login page will be web-based. It actually won't look that different from the current interface and allows all the same functionality.

(Note: The optional "Go Inworld!" page mentioned here before will be a part of a separate release as it requires more work.)

Keep in mind that if you are developing a third-party application to access Second Life, we will be keeping our old login methods intact until you catch up with the new process - at which point we will shut down the old pathways.

== Frequently Asked Questions ==

==="On the viewer's login screen, I'm given the choice of where I want to log into. Will I still have that option?"===
Yes. This functionality will be the same both in the viewer's login and on the website's login.

==="I use Second Life from a computer that is not mine. How does this affect me?"===
Everything works the same as before.

==="Why aren't you fixing bugs? I don't care about login!"===
Linden Lab has a team of developers who are constantly fixing bugs in Second Life. However, we also have developers who work on the website, the servers, and specific issues such as security, billing, and fraud prevention. Viewer Authentication is being developed in order to extend the ability of our logins such that they can take advantage of new fraud prevention measures, future account security measures, and be placed in a more flexible and easier to access code-path. Fixes to the website's login can be instantly ported to the viewer's login and vice versa.

==="What happens when I want to use the First Look client or some other third-party application?"===
Until they are brought up to speed with the new login process, these extra applications will still be able to use our old login procedure.

== Technical Overview ==
In order to maintain backward compatibility, there will initially be several ways to log in:

* Login from legacy viewer using current XUI and name/password.
** Until they are brought up to speed with the new login process, other clients will still be able to use our old login procedure. This transition is expected to complete by beginning of February, at which point a mandatory update will be required.
* Login from a new viewer from login screen
** Login form removed from screen XUI
** Web login modules added to login screen splash page
** Splash screen saves and passes web login key to viewer using a redirect
** Viewer logs in with name/web_login_key
** May be deprecated eventually, but because of pushback from sldev, we decided not to
* Login from InWorld page on Second Life website (https://secondlife.com/inworld/index.php)
** Go Inworld generates and persists web_login_key, returns it coded into secondlife:// url.
** OS launches viewer associated with secondlife:// (last used viewer, or last installed viewer).
** Viewer parses url, logs in with name/sid

The common web mechanism is as follows:
* Website confirms (cookie) that resident is logged in by filling in user name fields if they are
* Website also takes many query parameters to automatically fill in fields in the form
* Upon receiving POST, website generates a temporary, single use web_login_key and persists it to web_login_key web store on central backbone
* Website redirects to the continuation url provided, and appending web_login_key as a query argument at the end
** For login via website, continuation url: secondlife://viewer/login?firstname=;lastname=;session_id=;location=?'
** For login via viewer, continuation url: about:blank?redirect-http-hack=($URLENCODE(secondlife://viewer/login?firstname=;lastname=;session_id=;location=?'))
* Viewer catches or launches and uses user name and web_login_key to send to login.cgi
* login.cgi checks session id and allows the user in

Additional info:
* Logging into a custom/internal grid appears to require two secondlife.exe parameters;
** -loginpage <URL>, the login page displayed to the client
** -loginuri <URI>, the address that the client should look for the login.cgi equivalent

Another note;
* This is probably an oversight however, First Look Windlight and 1.18.6 Release Candidate are missing the functionality required to connect to an alternative grid. There doesn't appear to be a way to tell it to connect to a grid outside of a small hard coded array of them.
* I posted the following bug: [http://jira.secondlife.com/browse/VWR-4021 JIRA: VWR-4021 - Even after doing the necessary steps to get the viewer to respond to -loginpage, it continuously tries to log-in to Agni or LL's dmz loginURI]

== See also ==

[[Login Protocol]] - general summary of login protocols

Viewer Authentication

Teravus Ousley — Mon, 24 Dec 2007 22:08:44 GMT

Teravus Ousley: /* Technical Overview */

{{Alert Box|
<b>Note:</b> If you would like to discuss the changes stated in this page, please use the discussion tab at the top. We are reading it and answering your questions there and will update the wiki as needed. Thank you!

<b>Note:</b> This page primarily describes Linden employees' view on the issue that some open source developers have expressed concerns against. If you want to know the open source developers' view or related backgrounds, you are advised to read not just this page but also the [[Talk:Viewer Authentication|associated discussion page]] and [[Viewer Authentication Critique]] page.

<b>Note:</b> The first note above was written by a Linden, and the word "we" refers "Linden employees". The second note (as well as this note) was added by a resident {{User|Alissa Sabre}} for clarification.
}}
= Viewer Authentication =

Fairly soon, Linden Lab is going to introduce new form of logging in. The current process requires an xml-rpc call from your viewer to our servers that runs along an inflexible code-path that is difficult to maintain. This process will change to a web-based path that is easier to maintain and will allow us easier access to tools for making logins smarter and furthering our anti-fraud efforts.

== What Changes For You? ==

You will see one change when this is released. The viewer's login page will be web-based. It actually won't look that different from the current interface and allows all the same functionality.

(Note: The optional "Go Inworld!" page mentioned here before will be a part of a separate release as it requires more work.)

Keep in mind that if you are developing a third-party application to access Second Life, we will be keeping our old login methods intact until you catch up with the new process - at which point we will shut down the old pathways.

== Frequently Asked Questions ==

==="On the viewer's login screen, I'm given the choice of where I want to log into. Will I still have that option?"===
Yes. This functionality will be the same both in the viewer's login and on the website's login.

==="I use Second Life from a computer that is not mine. How does this affect me?"===
Everything works the same as before.

==="Why aren't you fixing bugs? I don't care about login!"===
Linden Lab has a team of developers who are constantly fixing bugs in Second Life. However, we also have developers who work on the website, the servers, and specific issues such as security, billing, and fraud prevention. Viewer Authentication is being developed in order to extend the ability of our logins such that they can take advantage of new fraud prevention measures, future account security measures, and be placed in a more flexible and easier to access code-path. Fixes to the website's login can be instantly ported to the viewer's login and vice versa.

==="What happens when I want to use the First Look client or some other third-party application?"===
Until they are brought up to speed with the new login process, these extra applications will still be able to use our old login procedure.

== Technical Overview ==
In order to maintain backward compatibility, there will initially be several ways to log in:

* Login from legacy viewer using current XUI and name/password.
** Until they are brought up to speed with the new login process, other clients will still be able to use our old login procedure. This transition is expected to complete by beginning of February, at which point a mandatory update will be required.
* Login from a new viewer from login screen
** Login form removed from screen XUI
** Web login modules added to login screen splash page
** Splash screen saves and passes web login key to viewer using a redirect
** Viewer logs in with name/web_login_key
** May be deprecated eventually, but because of pushback from sldev, we decided not to
* Login from InWorld page on Second Life website (https://secondlife.com/inworld/index.php)
** Go Inworld generates and persists web_login_key, returns it coded into secondlife:// url.
** OS launches viewer associated with secondlife:// (last used viewer, or last installed viewer).
** Viewer parses url, logs in with name/sid

The common web mechanism is as follows:
* Website confirms (cookie) that resident is logged in by filling in user name fields if they are
* Website also takes many query parameters to automatically fill in fields in the form
* Upon receiving POST, website generates a temporary, single use web_login_key and persists it to web_login_key web store on central backbone
* Website redirects to the continuation url provided, and appending web_login_key as a query argument at the end
** For login via website, continuation url: secondlife://viewer/login?firstname=;lastname=;session_id=;location=?'
** For login via viewer, continuation url: about:blank?redirect-http-hack=($URLENCODE(secondlife://viewer/login?firstname=;lastname=;session_id=;location=?'))
* Viewer catches or launches and uses user name and web_login_key to send to login.cgi
* login.cgi checks session id and allows the user in

Additional info:
* Logging into a custom/internal grid appears to require two secondlife.exe parameters;
** -loginpage <URL>, the login page displayed to the client
** -loginuri <URI>, the address that the client should look for the login.cgi equivalent

== See also ==

[[Login Protocol]] - general summary of login protocols

RequestObjectPropertiesFamily

Teravus Ousley — Fri, 16 Nov 2007 01:34:16 GMT

Teravus Ousley:

{{ProtocolNav}}
==Message Layout==
<pre width=80>
{
RequestObjectPropertiesFamily Medium NotTrusted Zerocoded
{
AgentData Single
{ AgentID LLUUID }
{ SessionID LLUUID }
}
{
ObjectData Single
{ RequestFlags U32 }
{ ObjectID LLUUID }
}
}

</pre>
==Usage and Notes==
The client sends this message when a user hovers their mouse over a prim. It's purpose is to ask the sim for specific properties of the object that the user has their mouse hovering over.

So far in my experimentation, RequestFlags is always (uint) 0. ObjectID is the asset LLUUID of the object that the client is requesting the properties of

The sim sends back an [[ObjectPropertiesFamily]] packet

[[Category:Messages]]

ObjectPropertiesFamily

Teravus Ousley — Fri, 16 Nov 2007 01:33:31 GMT

Teravus Ousley: /* Usage and Notes */

{{ProtocolNav}}
==Message Layout==
<pre width=80>
{
ObjectPropertiesFamily Medium Trusted Zerocoded
{
ObjectData Single
{ RequestFlags U32 }
{ ObjectID LLUUID }
{ OwnerID LLUUID }
{ GroupID LLUUID }
{ BaseMask U32 }
{ OwnerMask U32 }
{ GroupMask U32 }
{ EveryoneMask U32 }
{ NextOwnerMask U32 }
{ OwnershipCost S32 }
{ SaleType U8 }
{ SalePrice S32 }
{ Category U32 }
{ LastOwnerID LLUUID }
{ Name Variable 1 }
{ Description Variable 1 }
}
}

</pre>
==Usage and Notes==

This packet is generated by the sim in response to the [[RequestObjectPropertiesFamily]] packet from the client.

In the client, it's used to populate the yellow pop-tip messages that you get when you hover over an object

* ObjectID is the LLUUID of the asset in world
* CreatorID is the LLUUID of the object's original creator
* OwnerID is the LLUUID of the object's current Owner
* GroupID is the LLUUID of the group that the object is assigned to (for group permission)
* OwnerMask is the ObjectFlags (bit vector) containing the permissions that the owner has over the object. (ex: edit, copy)
* GroupMask is the ObjectFlags (bit vector) containing the group permissions for that object
* EveryoneMask is the ObjectFlags (bit vector) containing the 'everyone else' permissions for that object
* NextOwnerMask is the ObjectFlags (bit vector) containing what permissions get applied to the object when it moves to the next owner (via purchase or transfer)
* SaleType is a byte containing the type of sale the object is currently set to (byte) 0 is 'no sale'
* SalePrice is the amount of Lindens that the object is priced at
* Category corresponds to the category drop down in the client
* OwnerShipCost(?)
* LastOwnerID (?) is presumably the LLUUID of the avatar who owned it before the avatar that owns it now
* Name is the Name(up to 255 characters) of the prim that you're hovering over.
* Description is the Description (up to 255 characters) of the prim that you're hovering over.

[[Category:Messages]]

ObjectProperties

Teravus Ousley — Fri, 16 Nov 2007 01:29:05 GMT

Teravus Ousley: /* Usage and Notes */

{{ProtocolNav}}
==Message Layout==
<pre width=80>
{
ObjectProperties Medium Trusted Zerocoded
{
ObjectData Variable
{ ObjectID LLUUID }
{ CreatorID LLUUID }
{ OwnerID LLUUID }
{ GroupID LLUUID }
{ BaseMask U32 }
{ OwnerMask U32 }
{ GroupMask U32 }
{ EveryoneMask U32 }
{ NextOwnerMask U32 }
{ OwnershipCost S32 }

{ SaleType U8 }
{ SalePrice S32 }
{ AggregatePerms U8 }
{ AggregatePermTextures U8 }
{ AggregatePermTexturesOwner U8 }
{ Category U32 }
{ InventorySerial S16 }
{ ItemID LLUUID }
{ FolderID LLUUID }
{ FromTaskID LLUUID }
{ LastOwnerID LLUUID }
{ Name Variable 1 }
{ Description Variable 1 }
{ TouchName Variable 1 }
{ SitName Variable 1 }
{ TextureID Variable 1 }
}
}

</pre>
==Usage and Notes==
[[Category:Messages]]

RequestObjectPropertiesFamily

Teravus Ousley — Fri, 16 Nov 2007 01:19:12 GMT

Teravus Ousley:

RequestObjectPropertiesFamily

Teravus Ousley — Fri, 16 Nov 2007 01:16:30 GMT

Teravus Ousley: /* Usage and Notes */

{{ProtocolNav}}
==Message Layout==
<pre width=80>
{
RequestObjectPropertiesFamily Medium NotTrusted Zerocoded
{
AgentData Single
{ AgentID LLUUID }
{ SessionID LLUUID }
}
{
ObjectData Single
{ RequestFlags U32 }
{ ObjectID LLUUID }
}
}

</pre>
==Usage and Notes==
The client sends this message when a user hovers their mouse over a prim. It's purpose is to ask the sim for specific properties of the object that the user has their mouse hovering over.

The sim sends back an [[ObjectProperties]] packet

[[Category:Messages]]

ObjectProperties

Teravus Ousley — Fri, 16 Nov 2007 01:12:28 GMT

Teravus Ousley:

ObjectProperties

Teravus Ousley — Fri, 16 Nov 2007 01:07:00 GMT

Teravus Ousley: /* Usage and Notes */