Some time back, Melanie added a new flag to items, the “Export” flag, which some viewers started to support. The Export flag allows creators of content to mark them as exportable or not exportable — meaning ok to export to other grids or not. That gives some level of flexibility to content creators, but it doesn’t solve the problem. If an item is marked “No copy” but “Exportable”, a bad grid operator can easily change the permissions on it. So, at the moment, our recommendation to viewer developers is that they only allow to mark the “Export” flag when the item is fully “free”: no constraints on copy, transfers, and modifications. This is so people don’t get a wrong sense of security.

I should note that there are no reports of Hypergrid thefts, even though they are technically possible. As far as I know, most copy-botted content comes from using altered viewers on closed, non-HG grids; those loots are then imported into other OpenSim-based grids via those viewers too. So altered viewers, not HG thefts, are the main problem. Nevertheless, the fact that the HG opens additional doors for abuse has been a deterrent for commerce on the Hypergrid, so much so that we recommend “Export” only for freebies. It would be nice to change that perception. The incomplete proposal I have here solves the problem not just for the Hypergrid but also for viewer-based thefts in closed grids, even if those grids don’t ever want to connect to the Hypergrid. It solves the problem so thoroughly that, if implemented, it would allow commerce on the Hypergrid to bloom. The problem is in the implementation; hence, the “incomplete” in the title of this post…

The proposal, in a nutshell: ledgers.
Specifically for the Hypergrid: distributed, decentralized ledgers. Yes, blockchain, but minus the coin.

How it works, birds-eye view

Let’s ignore implementation details for a moment. I’ll cover them at the end.

Here is the main idea of a ledger: every time an item changes hands (from one avatar to another) a record about the transaction should be entered on a database. The information should include: the item ID, the time of original creation of the item, the timestamp of the transaction, the owner ID, the receiver ID, and the item’s permissions at the time of the transaction. Ledgers are append-only databases: they hold the historical record of all transactions since the beginning of time. (A side note to mention that OpenSim already has append-only databases: the assets.) So if any item’s origin is ever in question, the ledger can be queried for the ground truth.

Next, I will go through various theft scenarios, and explain how the ledger gives honest grid operators the technical justification for punitive action against thieves, and how it it will help identify (and, hopefully, socially isolate) dishonest grid operators.

Detecting theft within a closed grid

Let’s ignore the HG for a moment, and focus on centralized ledgers.

Let’s consider the viewer-based theft scenario in closed grids: some bad actor logs in with an altered viewer and copies all content that it sees into this bad actor’s inventory, changing permissions, and even authorship, along the way. This bad actor goes on to sell this content as their own on that same grid. Nothing in this proposal prevents this from happening. However, if and when the original creator detects this shenanigan, they can file a complain with the grid, who now is armed with the ledger, the historical record of all transactions. A simple query on the ledger can find out when the items in question were first transactioned; the offender’s item’s timestamp will be later than the original creator’s item’s timestamp. If the items are, indeed, similar, as per the original creator’s complaint, then the timestamps, and the lack of a transaction chain between the items, are proof that there was a theft, and who the offender was. The grid owner can act swiftly.

Detecting theft across grids

Let’s continue to ignore HG for a little longer.

Let’s consider the same viewer-based theft scenario, but now the bad actor imports the stolen content from closed grid X into another closed grid Y via the altered viewer. Assume both grids have their own separate ledgers, and both grid operators are honest. Again, this proposal doesn’t prevent theft from happening. It’s only when suspicion of theft is raised that the matter can be investigated.

In this scenario, suppose the bad actor with the altered viewer imports the stolen content into grid Y as their own. Grid Y will store the item as if it was legitimately created by this person at time T1, when it was imported there. It knows nothing about its true origin. Some time later, there is a complain from the original creator who first created this item in grid X at time T0 < T1. Both grids can easily investigate by agreeing that the items are, indeed, very similar, and by checking their own ledgers independently. If they find that T0 < T1, then it’s clear theft was at play, and who the thief was. They can act.

Detecting theft between a closed grid and OSGrid

Continuing to ignore HG, let’s focus on hybrids like OSG: in OSG-like grids, many independent people control their regions, but they are all connected to central grid services operated by osgrid.org, specifically inventory; this ledger would be another grid-wide service. Assume the region operators may be bad actors, but that the grid services operators are honest.

In this scenario, a bad actor, armed with an altered viewer, logs in to a closed commercial grid, steals content via the viewer, and then imports it to OSG using their own region, where they not only have God-like powers but can also alter the simulator code. They have a lot more opportunities to tamper with the timestamps of creation, ownership, etc. But that doesn’t matter much, as long as inventory and ledger are centralized services of the grid, and are capable of correcting any region-sent information. When suspicion of theft is raised, both grids can check their ledgers for timestamps.

Managing transactions across the Hypergrid

Having separate ledgers is fine for grids that trust each other, but in the Hypergrid, some grid operators may be bad actors themselves, and they control their grid’s ledgers. If they steal something, they can then enter those items on their own databases as having been created in a date that is sufficiently in the past to escape proof of theft, or, even worse, to harass the original content creators! “I created this before you did!” That’s bad.

For this to work on the Hypergrid, we need to establish a distributed, decentralized ledger system, blockchain style. Here is how it works.

Every time an item changes hands (from one avatar to another) a record about the transaction should be entered onto the distributed ledger. The distributed ledger is a kind of replicated database over a peer-to-peer network, but where peers can independently verify the veracity of the information that is sent to them — sometimes directly and sometimes via some voting algorithm. If we trust the information on the distributed, replicated ledger, rather than on any single node, then we can always verify whether something was stolen or not across grids that are part of the network.

The weak link of decentralized ledgers is false information. How can we prevent false information from entering the ledger? Here are a couple of scenarios of false information:

• Problem: a bad grid operator creates a false record of a transaction between a visiting avatar and a local avatar. That is, they send to the ledger “HG visitor A gave a copy of item H to local avatar B at time T1″ when that transaction never happened.
  Solution: any transactions between avatars should always take place on the grid of origin of the avatar that gives the item. In other words, visitors can get things, but should not give things. All transactions should be local to the originator avatar. This can easily be checked at ledger-entry time by verifying that the issuer grid is the grid of the originator avatar. If it isn’t, nodes of the distributed ledger won’t accept the transaction.
  (We can implement non-local transactions, too, but that will complicate the giving procedure substantially, as it will require confirmation from the originator when it comes back to their grid)
• Problem: a bad grid operator changes the items’ creation time to the past. For example, they import stolen content with an altered viewer, and then they send the following record to the ledger “Item H was created in 12/12/2012.”
  Solution: ledger nodes need to verify that the timestamps of a creation record are credible.

Implementation Issues: Where Things May Come to a Halt

While the general idea will definitely be the best solution for protecting content, implementing it in practice for the Hypergrid is not a trivial matter.

Ledgers are append-only databases; their size can grow very large. This is a common problem of all blockchain solutions. For example, the Bitcoin ledger currently 275G, and it will continue to increase forever. In our case, we could either do some garbage collection when items are removed from inventory, or we could do what blockchain operators do: archive old records into separate, slower, databases. But these solutions aren’t very good for the Hypergrid, where a large number of single person grids exist, many of them running in people’s home networks. Those small shops would end up having to deal with a very large database, most of which is irrelevant to them; they would get it just because they would be part of this ledger network.

We can estimate how large a distributed ledger for the HG would be, and how fast it would grow based on the current estimates of people’s inventories. One thing that will definitely contribute to the large size of the ledger is if we enter every inventory item on the ledger: if anything created in inventory, whether it will be passed around or not, is entered into the ledger, the ledger will become unsustainably large very quickly. For reference, there are hundreds of millions of entries in OSGrid’s inventory service, and probably billions of items have been created there. Multiply that by 1000 grids. This would quickly grow to be a terabyte-size database.

We could focus only on the items that are transferred from one avatar to another, and use the timestamp of the first transaction as a proxy for time of creation. This approximation will fail to detect thefts if the item is stolen before the first transaction happens, and then the thief quickly makes a first transaction themselves. This should be rare, and people could be aware and compensate for it. It will definitely decrease the size of the ledger by several orders of magnitude, as the vast majority of items in people’s inventories aren’t passed to another avatar.

Still, even with optimizations, the ledger will be large, and this will be a problem for small standalone grids.

Perhaps the right thing to do is to decouple the ledger from the grids. We can implement a distributed ledger system that is operated by a few trusted people in the community, with access to enough resources, and that ledger can hold the transactions of everyone who wants to ensure the use of legitimate content in their grids. Any grid not on this ledger will be suspicious; social pressure will make them look bad.

Of course, nothing prevents a single entity from creating a centralized ledger for many independent grids, as a service. That will require complete trust in the ledger operator.

Anyway, I hope this post will trigger some discussion and maybe even some action, as it is clear that without a mechanism for content protection, commerce on the Hypergrid will never take off, and the nice professionally-created items will not be available to those with good intentions, such as Universities.

As promised at OSCC’15, here is a post explaining how to configure OpenSim in order to experiment with the OnLook viewer.

OnLook experiments with two orthogonal UX features: (1) the user’s representation inworld; and (2) the GUI. I’ll talk about them separately.

Camera-Only Mode

Description: The camera-only mode, as the name suggests, presents a view of the virtual environment without the user’s self-avatar. In other words, it’s a just a camera into the world. You can move the camera using the arrow keys, more or less like you would move the avatar. In reality, the user avatar is in the world, and others will see it; but it’s just standing there, without moving, and the person operating that avatar won’t see him/herself. (This could potentially be expanded to also remove other avatars except, perhaps, NPCs, but I haven’t done that yet)

Implementation: The server-side implementation of this mode is under OpenSim/Region/OptionalModules/ViewerSupport/CameraOnlyModeModule.cs

Configuration: Add this somewhere in your ini files:

[CameraOnlyModeModule]
     enabled = true
     ;; Users with UserLevel equal or less than this will be sent this mode.
     ;; Others above will not. 
     UserLevel = 0

Special UI Module

Description: The special UI module allows us to control the buttons shown on the bottom of the viewer. It also hides the top menu bar.

Implementation: the server-side implementation of this mode is under OpenSim/Region/OptionalModules/ViewerSupport/SpecialUIModule.cs

Configuration: There are two parts to the configuration. First you need to define the buttons you want to show in an XML file that is sent to the viewer when the user connects to your sim, then you need to turn the mode on.

I have an XML file that you can use as a starting point: get it from here and place it under your OpenSim bin/ViewerSupport. You can then do your own research and experimentation, comparing that file with the default one, for purposes of defining what buttons you want to show to, and hide from, your users.

To turn this on, add this somewhere in your ini files:

[SpecialUIModule]
    enabled = true
    ;; Users with UserLevel equal or less than this will be sent this mode.
    ;; Others above will not. 
    UserLevel = 0

Final Remarks

I want to stress that the purpose of this is NOT to design any one alternative UX/UI, so please don’t comment on the set of buttons that I chose to hide in the example XML file for the bottom panel. That’s besides the point. The point here is that YOU, as operator of an OpenSim environment, can decide which buttons to show and which buttons hide when users visit your world. And people will get different UX/UI as they visit different worlds.

Finally, OnLook is not a separate viewer project; it’s a proof-concept on configurable UX/UI using Singularity. It served to guide me through the study of how easy/hard it will be to do it for real with any existing SL-derived viewer.

Existing Documentation

• Coding standards.
  Summary: it’s the C# coding standards plus a couple of extra rules
• Code base overview. (credit: Justin)
  A lot more could be said, but documenting the framework properly is a huge amount of work. More below.
• Submitting patches.
  Summary: small is beautiful. I highlight the following paragraph:
  “Please put only one logical change in a patch at a time. Patches that contain more than one logical change tend to be larger, more complex and hence take more time to be applied. At worse, developers will tend not to look at them because it’s hard to disentangle all the possible effects. Multiple logical changes can be in a patch if they only affect a single feature (like, for example, the feature the patch enables).“

Major Acceptance/Rejection Criteria

The pointers above give the easy reasons for why patches may be rejected. For example, patches that don’t follow the C# coding conventions or that are trying to do many things at the same time will likely be either ignored, rejected or pushed back to the contributors with requests for improvements. But these are easy-to-spot problems. There are other problems that aren’t so easy to spot, but that are even more important: whether or not a patch follows the architectural principles of the project.

This may be a foreign concept to to many, so here is an introduction to software architecture. There are many definitions for what software architecture is. I like Dick Taylor‘s definition:

“A system’s architecture is the set of principal design decisions made during its development and any subsequent evolution”

Given this definition, software architecture is usually implicit in the code and present only in the minds of the developers, unless an explicit effort is made to externalize it, which is very rare in open source projects. That’s why it’s so critical that people who want to make non-trivial contributions to open source projects like OpenSimulator join the developers in their day-to-day conversations in order understand the dynamics of design decisions. Alternatively, they may develop a working relationship with one or more developers. In the case of OpenSimulator, most of the action happens in the IRC (irc.freenode.net #opensim-dev); all core developers are there most of the time.

Before explaining the high-level design decisions of OpenSimulator, let me continue to be academic for a moment and point to a wonderful effort made by a colleague in Delft with the goal of (1) teaching students about software architecture and (2) contribute to open source projects in the process. Please follow this link (it will open in another tab):

Delft Students On Software Architecture 2015

As you can see, it took teams of 3-4 students 10 weeks in order to document each of the projects. I won’t do it in one post. But I can explain the very high-level architectural themes of OpenSimulator:

• The core developers are the major stakeholders. Each one of us has high stakes in the code base. We are not the only stakeholders, obviously, there are many more. The large community of users also has a stake in the project; but they don’t have as much power as the core developers or even as the non-core developers. In OpenSimulator, people who contribute code have more power over its evolution than those who don’t. See for example the Power/Interest grid of Jekyll; OpenSimulator has a similar grid.
• The project is a *framework* packaged together with a default application, SL-ish. It’s really important to understand what software frameworks are, with their hot and frozen spots. Two consequences come from OpenSimulator being a framework, rather than a regular application:
  • Patches that touch frozen spots unnecessarily are likely to be rejected. OpenSim.Region.Framework, OpenSim.Framework.Servers, OpenSim.Server, OpenSim.Services.Interfaces, OpenSim.ApplicationPlugins.RegionModulesController and OpenSim itself are the major frozen spots. Everything else is a hot spot.
  • We encourage the encapsulation of new features in region modules (the plugins of the simulator), which extend/replace hot spots. If that implementation proves difficult, we’d like to know why it is difficult; we’ll gladly change the APIs when they prove to be getting in the way of doing things, but it requires discussion.
• We may or may not take in new plugins into the core distribution, depending on how important we think they are for the stakeholders. When we don’t take them in, we encourage their developers to maintain them and make them available to everyone, either by hosting the code in some open source repository or by distributing binary versions of their plugin.
• The existing plugins in the core distribution reflect a certain level of performance, operations and security that the core developers deem acceptable wrt usability and vulnerabilities. Alternatives to these implementations may change levels of performance and security (up or down), and sometimes those changes have tradeoffs in terms of usability and vulnerability. We may or may not accept those new tradeoffs in core. Patches that increase performance and security without any changes to usability and no additional vulnerabilities are usually very welcome and accepted immediately. Patches that move the levels of usability and exposure to vulnerabilities need a serious assessment. If we deem them unacceptable, we continue to encourage the developers to maintain their own implementations and even make them available to others; we just don’t want to have them in the core distribution.
• We encourage the community to develop and maintain their own plugins. Several core developers have their own alternative implementations of many of the core plugins in their own usage of OpenSimulator, as well as lots of additional features developed as plugins. That’s the whole point of having a framework. The core distribution reflects a certain balance in a large spectrum of implementation options that we believe benefit a large portion of the stakeholders, but possibly not all.

Examples of Accepted and Rejected Patches

Here are some examples of patches that have been recently accepted and rejected. For each, I give a brief reason for the decision:

• 7254. Status: accepted. Reason: very small patch, harmless change to existing Robust plugin.
• 7673. Status: accepted. Reason: small bug fix patch to frozen spot, confirmation of resolution by users.
• 7682. Status: accepted. Reason: very small patch, harmless bug fix to Linden client plugin.
• 7345: Status: accepted after discussion. Reason: very small patch for fixing annoying bug in AttachmentsModule plugin. Issue of discussion: hard-coded sleeps and placement of the code.
• 7676. Status: rejected.  Reason: very small patch, but with unacceptable downtime for existing grids.
• 7677. Status: rejected. Reason: very small patch, but with unacceptable change in security of one of the Hypergrid plugins vs. usability.
• 7653. Status: rejected as is, waiting for improvement. Reason: very large patch trying to do too many things at the same time, and with unnecessary intrusion in frozen spots of the framework. Part of it should be rewritten as a plugin, other parts could also be rewritten as a (different) plugin.

As I’ve announced at OSCC’14, I am working with Liru on a Singularity-based viewer whose main goal is to make the viewer’s UI as programmable as possible server-side. You know, more like Web browsers.

The idea here is to allow OpenSim operators to have more control over the experience that their users will have; specifically, I want to be able to design much simpler user interfaces that are more appropriate for people who have no experience with Second Life and/or may be even uncomfortable with seeing themselves as avatars. But more importantly that any specific UI, I want to be able to provide those UI specifications dynamically as the user enters the simulator, rather than being hard-coded during the viewer’s build process. This way, we can change the UI without forcing users to install new versions of the viewer. And no one needs to agree on any specific UI.

I’m happy to announce that the very first alpha release of OnLook is now available for testing! Without the server-side UI specs, OnLook behaves exactly like Singularity, so you won’t see any difference when you login to your world. In order to help people test it, I have deployed a small test world that can be accessed via the Hypergrid. So here is a description of the steps that you can do to test this, along with pictures of what you’ll see.

Step 1. Install OnLook

Here is the link to the installer in Windows and the link to the dmg for Mac. (Thanks to Cinder Biscuits for the Mac version)

Step 2. Login to your HG-enabled world

Login to your world somewhere. It needs to be HG-enabled. Once you login, the interface will be exactly like Singularity.

Step 3. Teleport to my Test world

Pull up the map and search for http://ucigrid01.nacs.uci.edu:8002. Teleport there.

Once you land, notice the new UI: The top menu disappears, and the bottom toolbar changes to show only a few options. This is a simplified UI that I’m defining and sending from the server. Others may want to send a different UI.

Next, click on Destinations and choose Epic Castle:

Step 4. Teleport to Epic Castle

Click to teleport to Epic Castle, which is another region on this same test grid.

This region is configured in “camera-only” mode. What this means is that your avatar will be invisible. For this alpha release, you will still see your attachments, if you have them, but we are working to make them invisible too, to make it truly “camera-only”. (Since I wrote this post, this has been fixed, so now your avatar will be completely transparent, attachments and all)

Notice that the controls are completely different too. If you press the arrow keys, your avatar stays in the same place, but the camera moves. Shift+arrows gives you more movements of the camera. Shift+Esc brings the camera to its original position. In any case, the avatar’s position stays unchanged when in this mode.

The objects in the scene are still interactive. See that yellow sphere? You can click it.

This mode is something that I wanted to do for a long time in order to make these wonderful worlds accessible to people who don’t like to see themselves as avatars. Encitra is going to use this mode in urban planning applications, as these environments become more like the modeling tools that urban planners are familiar with.

Before you leave this region, you may want to play with the options under the Settings button.

Step 5. Go back

The camera-only mode is very restrictive; you can’t even use keyboard shortcuts. In order to go back, pull up the Destinations guide and choose Convention Center.

That will take you to the first region you visited on this test grid. Your avatar will be visible again.

Finally, press Cntrl+Shift+h to go back to your home world. Once you arrive, notice the full-fledged Singularity UI coming back.

That’s it! Thanks for testing!

Final Words

OnLook is available in Github and the server-side modules are already in OpenSim(Dev), undocumented for now. Once they stabilize, I promise I will write documentation for how to use them. One thing to know is that these UI modes can be defined on a user level basis, meaning that you can have builders login with the default UI, and regular users login with a much simpler/restrictive UI.

This work has been supported by Encitra.

As all of you probably already know, we are organizing the first OpenSimulator Community Conference on the first full weekend of September, 7-8. This event has been in the making since, roughly, March. But it took us a couple of years before that to actually convince ourselves that it was worth doing it. Here are all the reasons why I think this event a great thing, and why everyone who uses OpenSimulator should be involved in some way.

Reason #1: Dramatic Improvements to OpenSimulator Performance

When we started planning this in March and we faced the prospect of a 200 people event, we went “omg!” Although we had never even tried, we knew that we could not host a 200 people event with OpenSimulator as it was in March — period. The maximum number of people we had ever attempted was 52, and in that test, lag started lurking in at 20, and never went away;we hit 52 people, but no one could move and chat was laggy as hell; the simulator eventually crashed. That test was back in 2009, too, a long time ago. Apart from Intel and its Distributed Scene Graph work, which takes a drastically different  architectural approach, none of us has ever paid much attention to core simulator performance.  It was clear that if we were going to attempt a 200 people event, we would need to invest a lot of our time in making OpenSimulator perform not just as well as the Second Life simulators, but… better.

Well, 4 months and 926 commits later, we have now taken the performance of OpenSimulator to levels that it has never seen before. In recent load tests, we have had as many as 117 avatars distributed over a 4-sim corner, with one of the sims usually hosting close to 60 avatars. After initial arrival of avatars, which is still a heavy load, the CPU usage on those simulators stays well under 100%. There’s very little to no chat lag and people can walk around without freezing neither the sim nor their own viewers. (Although we ask people to sit, because that’s the scenario for the conference)

A sim with 10 people standing around and chatting, which is a typical scenario for these virtual environments, now uses as little as 15% CPU — you can practically hear it yawn!

Reason #2: Dramatic Improvements to the Stability of Existing Features

Just to name three: the Hypergrid, teleports in general and Groups.

The Conference Center grid is hosted in a special-purpose server that is completely independent from any existing grid; it’s its own grid. Account creation on that grid is limited, by design. Except for conference staff, it doesn’t make much sense to host user accounts and their corresponding inventory in the Conference Center grid, because this is just a one-time event. It makes more sense for participants to come from their own persistent home worlds. Indeed, in all of the load tests that we have been making, the vast majority of avatars come from other grids — 33 grids so far! Consequently, a few bugs and poor performance in the Hypergrid had to be fixed…

In chasing bugs, we realized that what we were doing with teleports was not exactly in accordance to what the viewer was expecting. So we completely rewrote the Teleport protocol. The new protocol conforms with what the Linden grid does, as far as we can tell. As a consequence, teleports are now more solid than they ever were.

As for Groups (V2), even though I added this to OpenSimulator back in February, it had never been tested at scale. In using groups in the Conference Center grid, it was clear that there were some major issues in there that had been inherited from the Flotsam groups implementation. One of the major ones was in Group chat, which was very laggy and.. well, wrong. Group chat is now fixed. In the last load test we had 100+ people chatting (abusing) over the Load Test group with no additional CPU usage, no duplicate messages and generally no noticeable bugs. We also plan to make heavy use of groups for access control and permissions. Our smaller tests indicate that this can now be safely done.

Reason #3: Increased Synergy with Viewer Developers

This has, perhaps, been the best surprise of the process: we have had an increasing synergy with some of the viewer developers, specifically Singularity. So much so that we are planning to release a version of Singularity that is branded for the conference event. Some of the Singularity developers have been part of the load tests, and they have been extremely responsive to information and change requests that make the whole system work better. For example, thanks to lkalif, I was able to make the edit beams work in OpenSim (have you ever noticed that in OpenSim the edit beams were gone?). Another example, because of the new way that the viewers handle the map tiles, the map was useless after an Hypergrid Teleport; thanks also to lkalif, this has now been fixed in Singularity!

I see a whole new world of possibilities now…

Reason #4: New Features in D2 Wifi

Q: how would sponsors bring their content to the Conference Center grid, especially those whose grids aren’t Hypergrid-enabled?
A: add a feature to Wifi that allows users to upload IARs.

Done. It will be part of the next release of Wifi.

Reason #5:  Community Building

The OpenSimulator core developers are a bunch of radically independent nerds that have shown more talent to code than to do community management. That’s an unalterable fact. Luckily for this conference, we’ve engaged with AvaCon, a non-profit whose sole purpose is to help foster communities in the Metaverse. It’s been great to see the volunteers and presentation proposals coming in, managed by them! Now that I see it, I can’t wait to hear what people have been doing with OpenSim!

Reason #6: The Program!

Finally, conferences can be fun to attend. The program is shaping up to be very interesting, starting with Grady Booch’s keynote and ending with the breakout sessions and 3rd party social events.  The panels are interesting, the presentations I’ve seen being proposed are also interesting. As the program goes, the conference looks like a serious real world conference, as far as I can tell. (The final  program will be announced soon!)

I don’t think I ever attended a virtual conference like this before, so this is a first! If we are really able to pull this off in September, we might see more conferences going virtual instead of contributing to waste the ozone layer!

So here are some ways for you to get involved and help in this multi-purpose activity:

• We are still in need of inworld volunteers. Consider volunteering to help during the conference. You’ll get an inworld ticket, and those are limited!
• Don’t have much time to volunteer or cannot attend the conference? Consider being a sponsor, even if at the lowest level (US$50). While a virtual conference is 80x cheaper than a RL world one, it is not free of costs entirely. These sponsorships help defray the costs that we are incurring in.
• Come participate in the load tests. We have one every Tuesday at noon PST. There is also a special load test this Saturday, where we hope to get close to 200 avatars — the real deal. Be part of a major milestone in the history of OpenSim/Second Life.

It’s been a while since I last posted about HG 2, but it’s finally coming to life! HG 2 is all about letting grid operators define policies for access control to their grid’s assets and users. I thought I’d show how it is taking shape, so that you’ll be ready for it in the next OpenSim release.

HG Inventory

Inventory is much more secure than in HG 1.5, and the My Suitcase folder is playing an even more important role in that.

The first difference you will notice is that this folder is now under the root folder — see picture on the left. In HG 1.5, My Suitcase was at the same level as the root folder. That posed some issues, because the viewers can’t really handle that. So we had to make up Web applications (like D2 Wifi) to make inventory manipulations between the Suitcase and the other folders. Kind of hacky. That’s not happening anymore. In HG 2, My Suitcase is inside your normal inventory tree, so you can easily copy items back and forth between that folder and others.

Like in HG 1.5, the My Suitcase folder is special: it is the folder tree that receives objects you collect while you are visiting other grids. But now it is even more special: it is the only folder tree that is accessible to you (and therefore to the rest of the Internet) while you are traveling. Period.

Look at how your inventory will look like in HG 2 when you are outside your home world — see picture on the left. As the picture shows, all your folders except My Suitcase are shown as (Unavailable). You can still see them, and unfold them. You may even be able to access items that are already cached in your viewer’s cache (textures, notecards, etc.). But if you try to access any items outside My Suitcase that aren’t cached in your viewer while you are outside your home world, the operation will fail. For example, rezzing objects from those folders will fail.

Items inside My Suitcase, however, will be available. My Suitcase will also be the tree where all the items collected while traveling  will go. Once you are back home you can then move them into other folders.

In short: the Suitcase is now really the only thing you’ll have available while traveling (but keep on reading for some exceptions). That means that it is also only the only thing that is available for rogue grids to mess with. Treat it as your own real-world suitcase: it may be stolen or badly damaged. But the rest of your belongings are safe in your home world.

[UPDATE 9/23] I should be more clear. The existing HG1.5 inventory service, which lets users still access their entire inventory abroad, will still be available in the future. Grids can continue to use that. They can even use the normal inventory service (HG1.0 style) on the Hypergrid, which has no restrictions whatsoever about inventory manipulation. Both of these, however, especially the normal inventory service, are horribly insecure and expose users to all sorts of risks regarding their inventory. Unless the networked grids have 100% trust in each other, I don’t recommend using them.

Appearance

Appearance in SL/OpenSim is a very tricky thing. Your appearance as an avatar consists of two things: wearables (shape, clothes, etc.) and attachments (prim hair, etc.), which can be arbitrarily complex objects with textures, scripts, etc. Additionally, the viewer “bakes” all the wearables into a set of textures, and those are the ones that are actually passed around between your viewer and the viewers of all other people around you. To make things even more complicated, the attachments have a nasty dependency with your inventory — they are objects that must be somewhere in your inventory, and the viewer must know about them being attached to you.

Why am I telling this? So that you understand some of the challenges regarding inventory access and asset access control related to your appearance.

Your appearance’s assets will be copied to the worlds that you are visiting, even if the items that you are wearing are not in the Suitcase folder. If we didn’t do that, you’d always have to switch into an appearance whose items would be in your Suitcase, and that would be a pain. So, your appearance items (your clothes, body parts and attachments) are the only exceptions to the rule “the only items available outside are items under the My Suitcase folder.”  They are copied, and, as such, assume that they will be publicly available.

But this is not good enough for some grids. Suppose you are a user of a commercial grid wearing a very expensive avatar. That grid may not want any of its assets to be exported to other grids, including the avatar that you are wearing — that refusal of service can now be done (read on). But if you arrive at the destination without any wearables and attachments, you will be seen there as Ruth, even if you see yourself wearing the same expensive avatar because it is cached in your viewer as you travel. Projecting a Ruth image to others is not something we consider a good user experience, so we had to fix this somehow.

There is a configuration variable that grids can set regarding the use of “allowed appearances for Hypergriding.” That is, grids can create one or more appearances with assets that they don’t mind being publicly shared, and then force their users to wear one of those appearances before hypergriding out. The picture on the left shows the warning message when a user is wearing something that is not part of the allowed HG appearance assets, in this case, it was the sphere attachment.

Unfortunately, due the lack of appropriate viewer features, the appearance switch has to be done explicitly by the user, it can’t be done automatically. So if the user gets this warning message when she’s trying to HG TP, she needs to replace her outfit with one of the official ones. In the case in the picture, it’s a folder called HGOutfit.

 Assets Access Control

The access to a grid’s assets in the Hypergrid is done via a service called the HG Asset Service. Grid owners can now configure that service by specifying policies for exporting their grid’s assets to the outside world. For example, they can say that it’s ok for others to access textures and sounds but not scripts or meshes, or any other combination — the policy specification language takes the entire set of asset types. Grid owners can also specify which kinds of assets the grid can import from other grids.

The specification is done under the section [HGAssetService], something like this:

[HGAssetService]
    HomeURI = "http://127.0.0.1:9000"
    ;; The asset types that will never be exported
    DisallowExport ="LSLText, LSLBytecode"
    ;; The asset types that will never be imported
    DisallowImport ="LSLBytecode"

When these policies are specified, those types of assets will never be imported/exported, no matter what users and the rest of the world may do.

Going one step deeper into content protection, commercial grids with protected content may want to physically separate their internal asset server from their HG asset server, i.e. they can operate over completely different databases. Their internal asset server can continue to be behind the firewall. With the Robust architecture, this has been possible for a while. But now it is possible to make that physical separation meaningfully regarding the user’s Suitcase folder. When that separation is in place, the assets for the Suitcase items will be stored in the HG asset server database, and users cannot copy items back and forth between the Suitcase and the other folders. The items in the Suitcase folder will be  unavailable in the users’ home world, and become available only when the user is traveling. This may be a desired feature, as commercial grids may not like the import of freebies from the outside. This requires some advanced configuration, but that’s the kind of security barriers that need to be in place for commercial grids to start experimenting with the HG.

For the time being, asset access control is done in bulk, based on asset types, and specified by the grid operator. There is no fine-grain asset access control [yet]. What this means is that grid users cannot express their own policies regarding their own objects, they are at the mercy of the grid operator. Bringing that specification up to the users will require some User Interface work (possibly on the viewers) that isn’t done yet. We’ll leave that for HG 2.5.

Users Access Control

In an HG Teleport, there are always two independent authorities involved: the home world of the user and the destination world. These can now be configured, also independently, regarding HG travels. It is now possible to control who goes where. This is the basis for the emergence of HG sub-networks — groups of grids connected to each other, but not to everyone, via the HG.

Incoming HG visitors

The control of which kinds of users can visit our world is done in a service called the Gatekeeper. It is now possible to specify whether the grid accepts foreign users or not, and, if it does, from which domains those users should be. When a user tries to HG TP to a grid in which she is not allowed, she gets a message like the one seen on the picture on the left “Destination does not allow users from your world.”

The configuration looks like this:

[GatekeeperService]
...
  ; ForeignAgentsAllowed = true
  ;;

  ;; If ForeignAgentsAllowed is true, make exceptions using AllowExcept.
  ;; Leave blank or commented for no exceptions.
  AllowExcept = "http://griefer.com:8002, http://enemy.com:8002"
  ;;
  ;; If ForeignAgentsAllowed is false, make exceptions using DisallowExcept
  ;; Leave blank or commented for no exceptions.
  ; DisallowExcept = "http://myfriendgrid.com:8002, http://myboss.com:8002"

The fine-grain control of specific users can continue to be done with ban lists and other mechanisms that already exist. The kind of control we added in HG 2.0 is domain-based, so all users from those domains will / will not be allowed in. That is what allows the emergence of HG sub-networks.

Outgoing local users

Conversely, the home world of users also has a say about where the users can and cannot go. That is done in a service called User Agents. When a user tries to HG TP to a grid which her home world doesn’t want her to go, she gets a message like the one seen on the picture on the left “Your world does not allow you to visit the destination.”

On this side of things, the policy specifications are based on the user-level. That is, users at different levels may be subjected to different restrictions.

The configuration looks like this:

[UserAgentService]
...

;; Are local users allowed to visit other grids?

;; What user level? Use variables of this forrm:
 ;; ForeignTripsAllowed_Level_<UserLevel> = true | false
 ;; For example:
 ForeignTripsAllowed_Level_0 = false
 ForeignTripsAllowed_Level_10 = true ; true is default
 ;;
 ;; If ForeignTripsAllowed is true, make exceptions using AllowExcept.
 ;; Leave blank or commented for no exceptions.
 AllowExcept_Level_10 = "http://griefer.com:8002, http://enemy.com:8002"
 ;;
 ;; If ForeignTripsAllowed is false, make exceptions using DisallowExcept
 ;; Leave blank or commented for no exceptions.
 DisallowExcept_Level_0 = "http://myfriendgrid.com:8002, http://myboss.com:8002"

I usually don’t write about the future, I prefer to write about things that are already done and working. But I’m going to make an exception, because people are starting to ask about configurations of the Hypergrid that pertain to the next level; we’re almost there, but not yet. I am going to give an overview of what’s in the works right now that will result in the next big bump in the HG number: the big two-point-oh.

As usual, some context first.

The very first version of the Hypergrid, HG 1.0, was done back at the end of 2008, and continued through 2009 and 2010. That first version was just an exercise in feasibility and in interacting with the opaque, black box viewer. Could I trick the viewer to think that it was still on the same grid while in reality sending the user to a different grid? — that was the humble goal of HG 1.0. HG 1.0 was not concerned with security at all, as the main goal was to figure out how to use the viewer in ways for which it had not be designed. Once I mastered the signaling of agent teleports, it was time to take the HG to next level: more security all around.

The next version was HG 1.5. The conceptual work for it started in early 2009, although the actual coding only happened much later. This was because in order to implement the Hypergrid as a collection of additional, optional services that don’t interfere with the simplest configuration, OpenSimulator itself had to be considerably refactored. That took a long time. HG1.5 came with OpenSim 0.7 in July of 2010. It featured identity security as well as a semi-secure (or semi-insecure, depending on whether you are an optimism or a pessimist) Hypergrid inventory. It also had all the right architecture for enabling HG Instant Message and Friends. That’s where we are right now.

So let me explain what we’re working on for HG 2.0

Inventory

Hypergrid Inventory is going to be 100% secure and the Suitcase will finally be usable without external Web apps. This required some heavy hacking in order to understand how to further trick the viewer into submission (i.e. use it beyond its specs), but we did it. Here is what will happen. When a user goes out, her entire home inventory tree will be removed from the viewer and replaced with the Suitcase folder tree only. That’s the only portion of the user’s inventory that will be exposed to the outside and to the user while the user is hypergriding. That way, the user’s home inventory will be out of reach and completely protected. Once the user returns to the home grid, the Suitcase wannabe-root folder is replaced by the user’s real inventory tree again.

Depending on configuration, the Suitcase folder may or may not be available to the user when she is in her home grid. When it is available, it will be a regular folder under “My Inventory”; the user can then move stuff from/to the Suitcase to/from other folders using the viewer.  But some grids may not want their users to bring in stuff from the outside, they want to continue to segregate content, so availability of the Suitcase folder in the home grid will be configurable.

Appearance

The appearance that a traveling user has may or may not be the same as the appearance that she had when she left the home grid. Again, this will be configurable. But the idea here is that  some grids don’t want to allow the export of appearance assets at all, so they may provide generic appearances to their traveling users, and dress them with their appearances when they come back. Other grids may not care about this, and appearance will be preserved.

User Access Control

There will be a means to specify several policies of access control: who can go out and where, who can come in and from where. These policies are based on several pieces of information about the users themselves and about their grids of origin.

So for example, it will be possible to specify that only users of a certain level can Hypergrid out, while others under that level can’t (a requirement often heard in educational settings). It will also be possible to specify a limited set of grids that the users can visit; or a set of grids that the users cannot visit.

On the receiving end, it will be possible to specify only a limited set of grids whose users are allowed in; or a set of grids whose users are not allowed in; or no foreigners allowed in at all.

Assets Access Control

There will be a means to specify whether the grid allows asset exports to other grids, and which grids, as a whole. HG 2.0 will not support the specification of fine-grained asset exports, i.e. I can’t say that this particular set of assets can go out, while that other can’t. This will require a means for people to be able to express that, and we don’t have that means yet.

≈

What this amounts to is that the Hypergrid will be able to support different policies that better reflect different levels of comfort that people have regarding opening up their worlds. Grids that deal with protected content will be able to continue to protect that content while allowing their users to visit other grids, and even collect items there, and allowing foreign users to come in and mingle — without any asset ever being exported or imported from/into their main storage. Grids that deal with kids will be able to block them from hypergriding while allowing certain privileged staff to go out and get content and knowledge from other grids. Secretive grids will be able to prevent foreign visitors while allowing their users to go out. Grids can have only one or two regions available to foreigners, while the rest is off-limits. Communities can make up small networks of worlds that allow Hypergrid exchanges only among themselves. Etc.

I hope this clarifies where we’re going with the Hypergrid!

I know that the first question that everyone will ask is: when? My guess: sometime this summer, hopefully early.

There are many improvements in OpenSim, most notably the new LSL NPC stuff — this allows you to create and manipulate Non-Player Characters (bots) directly from scripts. Really cool!

Hypergrid-wise, the most noteworthy development is the support for Friends across the Hypergrid. As explained in a previous post, I have created a world-to-world social network platform in OpenSim! Diaspora, anyone? Well, I get to actually do it and deploy it in  your worlds

Have fun!

P.S. I also made a new release for Wifi that works with Robust 0.7.2. Enjoy!

As the title says.

Over the weekend, I added the machinery for the new V2 map to work with vanilla OpenSim. If you want to try it out, watch out for the several changes in configuration files, especially those in .ini.example’s — make a diff to see what changed.

Note that viewer 2 is even more radical than viewer 1 when it comes to regions placed above 2,048. Most likely, the map won’t work there at all. (I haven’t tried it)

Also note that, for the time being, V2 map will get considerably confused on HG teleports. The first step was to make the map work. The next step is fixing the map for the Hypergrid. There’s a brute-force way of doing it, and there’s an elegant way of doing it. The elegant way of doing it requires collaboration with viewer developers. Let’s see what we can do together…

Enjoy!

UPDATE 6/10/2011: It turns out that the map breakage starts at 2,048, not 4,096.

Let me start by the observable consequences of this “bug.” (btw, I’m quoting this word because, as you will see, I came to realize that this is not a bug) There are at least two observable consequences:

1. The first observable consequence was first reported here 3 years ago in the context of OGP work between SL and OpenSim. In short: if you try to teleport between regions that are more than 4,096 cells apart in either X or Y, the teleport succeeds, but the viewer is blanked out. No crashes, but nothing rezzes. This issue, also known as the “long jump” issue, doesn’t just affect  interoperability mechanisms such as OGP and the Hypergrid; it affects teleports within the same grid too. As long as the regions are more than 4,096 cells apart, the viewer blanks out.
2. The second observable issue is a lot more subtle and more difficult to notice, but it’s there for those who care to notice. Here is the map of OSGrid around Wright Plaza: Do you notice something strange? No? Look again. After waiting several minutes, we get only the -4/+4 map tiles around Wright Plaza. There’s regions beyond that, in fact the whole space around Wright Plaza is filled with regions; but the map doesn’t show them… unless we explicitly click on one of those water tiles — that gets us another -4/+4 around that tile that we clicked. (depending on which version the sim you’re on is running, this may be +/-8 instead of +/-4).
   This happens because OSGrid is placed around 10,000-10,000 in grid coordinates. For grids whose coordinates are below 4,096 2,048 the map is always complete as far as there are regions in cells.

Very likely there are other subtle consequences of these numbers 4,096 and 2,048 which I haven’t come across yet.

Now that I described the observable consequences, you may want to know why this happens. I don’t know the answer to that question, I have just a few clues and hypotheses. Here’s what I know.

First of all, this is not an OpenSim issue, it’s a Second Life issue. It happens to affect OpenSim only because we use the Second Life viewers while deviating from how Linden Lab uses their servers. In Second Life, all the regions are placed between 0 and 4,096 in both dimensions. In OpenSim, for unawareness of any limitations, grid operators started placing their grids in arbitrary coordinates above 4,096. The main culprit was OSGrid, and then other grids followed.

I wish I knew the exact technical explanation for this issue, but I don’t know. It seems to be related to how the viewer represents region coordinates, but that doesn’t quite add up. Here’s the Math. The viewer represents grid coordinates using 64-bit unsigned integers which are, in essence, two 32-bit unsigned integers concatenated together, one for X and one for Y. Each number represents a point on the map in meters. So for example, the SW-most point of cell 1,000-1,000 is point 256,000-256,000. In principle, we ought to have 32 bits to represent these dimensions, which would give us 2^24 cells in each dimension (that’s 2^32 divided by 2^8 (=256), the size of regions in meters). Instead, we seem to be hitting the ceiling at 2^12 cells (4,096). There’s a tempting relation here — 12 is half of 24. Where that halving comes from… I don’t know. Maybe some optimization of Second Life. Perhaps some viewer developer could shed some light here having seen the viewer code?

Whatever the issue is, it seems to pervade the viewer code base in profound ways. Even though this issue has been know for 3 years, no viewer has it fixed. At least a couple of viewer developers have attempted fixing it; one even submitted a patch to Linden Lab (see the original bug report which still contains that patch). Unfortunately, I heard that that patch proved to break other things. In talking with Imprudence devs briefly, they mentioned that they, too, attempted to fix the issue in the viewer and came to the conclusion that the changes were so many that it wasn’t worth the trouble.

I made peace with the issue a few weeks ago. My peace with it started when I noticed, in horror, the second observable effect — the missing map tiles. It turns out that OpenSim has a horrible hack to cope with this behavior, that’s why we see +/-4 regions around, otherwise we would see only the current region and nothing else. It’s a horrible hack, and it’s there just because OSGrid is placed above 4,096-4,096. If we didn’t have the hack there, OSGrid would have no map! This horror was the beginning of my coming to terms with what’s going on.

The issue is not a bug at all. It’s a fundamental design decision of Second Life. Second Life assumes that a grid will never be larger than 4,096×4,096 regions. That design decision is reflected pervasively in the viewer code to the point that very smart developers don’t think it’s worth the trouble changing it. If you think about it, this is not an unreasonable assumption. That’s 16,777,216 regions! Would anyone in their right mind ever operate a virtual world with 16 million SL-like regions?! Very unlikely.

The argument so far for calling it a “bug” seems to have been this: “well, if this is the basis for the 3D web, then clearly there will be more than 16 million regions, just like there are more than 16 million web servers.” True. But not on the same map! Not under the same authority! Seeing the map as one single shared space between all virtual worlds is just… wrong! The map is a grid resource; different virtual worlds should have their own maps. They should be able to have regions on the same coordinates — region placement should not require global coordination. Sure, there are interesting things that one can do with shared maps, but in my view of things, the starting point for interoperability is 1 grid = 1 map. As opposed to all grids = 1 map.

So, having finally realized that this is not a bug, but a not-unreasonable design decision of Second Life, I came to peace with it. It won’t be “fixed” because that would require rewriting the viewers to the point of being unmergeable with the official SL viewer. It would be nice if Linden Lab hadn’t made this assumption. But they did, and we have to live with it.

It turns that “living with it” is not a big deal at all. It’s as simple as placing all the regions between 0-0 and 4,096-4,096 2,048-2,048, because that’s what the viewers expect. What could possibly make this an undesirable situation?

Perhaps OSGrid will have a hard time coordinating this change, precisely because it uses a global resource (the map) shared among hundreds of people. (This comes to prove what a bad idea that is…) I hope the OSGrid administrators will also come to terms on this, and force the coordinates change, so that we can finally have an open Metaverse free of hicups.