In Light of Recent Events

Diva just blogged about the Linden Labs layoffs, and what the recent change of course for Second Life could mean to the Open Simulator project.

Funnily, I had just decided to blog along the same lines.

For some time, I have coined what's happening with general-purpose virtual spaces "consolidation by biting dust".

To me, the picture is quite clear. The general-purpose 3D worlds domain has not provided compelling enough content and services to reach the critical threshold needed for the technology to reach and secure mainstream adoption. For this hype cycle, that is; there will be a next one. But for this time, it's toast. And no quick-fix facebook integration or web embedding will change that.

Now it's about digging in and waiting for the next wave of technology convergence.

Allow me to elaborate: Technologies come and go, wax and wane. All technologies develop in 'clusters' together with other technologies - and more often than not, the maturity of these supporting technologies are more or less out of synch.

One example: internet (as in ARPANET) has been around since forever. Hypermedia too. The first version of html and the http protocol was defined in 1990.

But what else would be needed? An communications protocol stack simple enough to implement that the network hardware was affordable for consumers. Cheap enough bandwith to enough companies and households. Enough potential viewers (PC's) installed to motivate spending efforts on creating content and integrating services to the media. Enough flatbed scanners around to facilitate transfer of legacy 2D content and production of new digital content using old analogue sources. A dominating Operating System paradigm that provided a 2D GUI, and affordable (free) text and graphics manipulation programs available.

And of course, the promise to do away with costly and time-consuming transportation of tons and tons of paper with ink on it.

I would argue that the timing for the web was right - the supporting technology cluster was there - and the technology rode the hype cycle and by the end there was compelling content and services. Had any number of the supporting technologies been in a lesser state of maturity, we would probably not have seen the web as it is today - but my point is: eventually, it would have been inevitable.

Enter Second Life. General-purpose 3D. Again. Now with a social media flavour. User Generated Content. Hell, it was the Matrix, or Neal Stephensons Metaverse. Second Life was supposed to be the torch bearer in this brave new world - attracting lots of bright people with lots of good ideas.

The genius central idea of Second Life, the thing that would make it thrive, is also the thing that will lead to its commercial downfall: there is no plot.

If you were there when the web started, you heard the same question over and over "but what's the POINT?" - and the answer always was "that's the brilliant thing about it, it can be anything to anyone."

The problem is, you can't run a company around that. At least not with mainstream customers. A company will always want to force the customers in one direction or the other, to make them make each others pay more. Stifle innovation, if innovation would lead the customer astray.

Case in point - fast forward to 2006 when I joined Second Life; was enamoured, created interactive 3D content for the first time, because it was SO EASY, like coding html in notepad and get stuff to <blink>. I was awesome.

But after doing my first big Second Life project for my then employer - a big web community site that wanted to mash their web content with this new and exciting media - I come to realize that Second Life would never cut it. There was just too few integration points. The experience was not brandable. We were in a co-opetition deadlock with SL, its API and its TOS. We had user integrity and security issues. We were supposed to ship our customers off to Second Life and loose precious screen time. It was a no-win situation.

It was at this time, when my then employer was starting to pull out of Second Life that I met Darren in #libsl, him saying "I have this rough proof of concept for a Second Life server made in C#"

This was the answer to the problems I saw with SL, why SL would never be anything but an AOL in a world that was ready for the web.

But it was more than that. We quickly realized that what we would have to do, was not to build an SL clone, but rather, wait for the compelling content and services that promised to come, and let those dictate the protocols and implementations that would be needed. Or put it in another way; we all saw that Second Life would fail to deliver the 3D web - but we had no clear idea of what the 3D web would actually look like, or why anybody would want to use it, so we set out to build a framework for those who might come up with the right ideas so that they could proof of concept and implement their services with less effort.

The proof is in the pudding, as they say. I can't say that this approach has paid off. Most efforts has been around cloning Second Life, the content and services that one could find there, but within own organizational boundaries. Which is okay, since that was one of my original pains with Second Life.

But; here's the kicker: it will come. The 3D web will come. Bandwith will rise, there is a number of technologies emerging that will simplify and lower cost for layman 3D media production and there will be services that leverage the richer environment that is 3D to the point where we think, again, "how is it possible that we ever used to enjoy this thing not in 3D?"

And at that point, there will be a need for a configurable and robust platform to deliver rich, shared and highly dynamic 3D scenes in an optimized and user-friendly manner. Probably more like an embedded interactive continuous video stream than like an embedded casual flash game.

That platform will not be Second Life. But it might be Open Simulator. This depends on where the OpenSim community decide to take the platform. It also depends on the service developers, the innovators that has left Second Life, or are currently pulling their hairs over how the platform is step by step bereaving them of the degrees of freedom that is necessary for their success.

Will we meet on the other side of the next wave?

/Stefan

Disclosure: I'm one of the founders of Open Simulator. I also had a company trying to capitalize on Second Life/OpenSim that went belly up. Thus, I'm equipped with kick-ass 20-20 hindsight.

Update: Diva did an excellent follow-up blog that's a must-read.

Update: Rob Knop wrote a great blog that fills in a bit more on why the LL change of direction is a change of direction away from the 3D web.

OpenSim unfinished symphony

Odd thing this; falling out of OpenSim development I feel like I imagine HAL did, parts of my self falling off and in the end I will probably do the programmer equivalent of droning "daaaisssyyy, daaaaaaiiisss..." and come to a grinding halt.

Before that actually happens, I'll just make sure to squeeze out this blog, listing the projects (aka 'really good and low hanging fruit kind of ideas') I wanted to do with OpenSim, but never got a chance to. If only for posterity. Here goes:

Identifying assets with URL, not GUID

The main idea would be to implement a model where the viewer and region communicated guids as asset id's, but that the regions communicated urls as asset identifiers to the back ends. This would lead to general awesomeness, as assets could truly be served by simple web servers. The region would then simply serve as an asset streamed redistribution cache, fetching data in arbitrary format and converting them locally to the format best suited for the given client. Of course, in the case of the LL stack, because asset data can reference other assets, you would have to substitute guids to urls and back in the asset data: the region would thus have to have a system to keep track of guid<->url mapping, but it is my firm belief that this is doable.

Status: I did start on this in trunk, but stopped; now it's been removed, but I believe I proved the guid substitution in asset data approach is doable.

Avatar Appearance defined by URL, not GUID

A companion to the above, the avatar appearance would be defined as a http endpoint; an xml file outlining the appearance pointing to assets by urls instead of a guids. The content could then either be assembled procedural, thru a database, or as a simple published xml file. If this would then be expanded to an "aar" (avatar archive) file format that encapsulates all the assets involved, this would take avatar portability home.

Status: Pure dreamland, but probably not that hard given the appearance is already fetched over http with guids, and OpenSim already have oars and iars.

Virtual Inventory Nodes

Each inventory node would be identified with an url, not a guid; this would lead to being able to distribute a users inventory over several services - allowing for services to update inventory nodes in real time, for example after a service upgrade of some inventory asset, interacting with a web page or changing to premium services. Think of the inventory a bit like 3d web 'favorites' links to content that still can change.

Status: Pure dreamland, and the feature could get pretty messy real fast. Still, it's probably the way to go. Arguably not that hard either given that inventory is communicated as xml over http in OpenSim today.

Unified UI Toolbox

The main idea would be to implement a shell executable that loads Mono.Addins for functionality separated from user interface, where the latter can be implemented for any environment (winforms, silverlight, ajax, gtk, you name it) whilst sharing the functionality (intelligent ini configuration, connectivity troubleshooter, region launching and monitoring, console command<->gui mapping, log file config and analysis, various launcher url schemes, database management et c) - this model would help developers cooperate on shared functionality and environment-specific UI separately.

Status: Proof of concept lying around on my harddrive, just editing a few ini settings in a WinForm gui. It works, and it's cool as heck.

Tribal One Viewports

In Tribal One, we had a 'viewport', which was a scene object defining a cube, in which content was governed by a http endpoint. In OpenSim, one could do a first implementation by implementing a non-backed up scene object that would "load xml" or "load oar" its content, rotated and displaced with the 'viewport'. The viewport also 'snapped' to other surfaces which let you for example define that a picture always hung on a vertical surface, or that a lamp always was aligned standing on the horizontal surface below it. Pure awesomeness taking building from generic objects so much easier. The idea was that content in a region would be 'assembled' from a great number of web sources, most of them probably programatically generated, procedurally or from databases, and other just simple static xml files.

Status: As with all Tribal One code, based on ~r2000 code, so a total mess to bring up to date.

On-demand regions

Basically, it would not be that hard to have OpenSim turn the solid-state running-region paradigm around, and allowing for on-demand regions that were started and loaded from database when somebody tried to teleport to them, and that closed down when nobody was around in them. This would mean the cpu capacity is not connected to land mass but to land use. Combined with the viewports, we're starting to look at something truly like a modern web page, where a region is started and generated in a response to a user need; you and I might be in very similar regions, but mine is subtly different because I wanted something subtly different.

Status: We did this in Tribal One, but all regions were started and served in one single instance, so didn't scale. Still, the result was amazing. In PIM, we had a 'pool' of region processes that were re-configured (re-loaded) as people wanted access to different 'class rooms'.

Binary de-duplication and scavenging

The idea is to split the asset table as so to extract the actual binary data out of it and into a separate table, with a foreign key. This way, you could make sure to do a SHA-256 hash on all new binary data and normalize the tables by making multiple assets point to the same binary data row and removing the duplicate. The process that computes SHA-256 and normalizes the asset table could run as a separate tool, or as a ROBUST service. On frequent archive (re-)loading, you would still have massive duplication of data rows, but at least the binary storage wouldn't swell just as fast.

Status: There's already a sha field in the asset database, this approach has been discussed back and forth, but nothing general has yet surfaced.

Epilogue: If anybody thinks any of this is a good idea, and want to know more of the thoughts behind it, I'd be more than happy to share. Same goes for code.

Open Source has its place

In his must-read article "The 'wisdom of crowds' loses steam" Matt Asay makes a number of good points:

• As open source projects mature, scarcity of "easy fixes" and heightened thresholds for contributing (as quality and form is being prioritized over features) leads to volunteers leaving.
• A handful of paid programmers can deliver better than a dispersed "community".
• How you treat your "community" is not that different from how a corporation would treat their "partners" and "customers".
• Companies relying on "community" to code for them is a bad idea.
• "Communities" relying on companies to code for them is a bad idea.

What I feel Matt fails to point out is that all his examples shows initiatives that at some time relied on volunteers to a high degree to get started, then slowly tranformed into various corporate-like structures. In effect, there is a "volunteer phase" in some initiatives which get them to market faster. One could argue that some initiatives would probably not get to market at all if it weren't for this phase.

A project does not consist of programmers alone; testers, evangelists, documentators, third party application programmers - with some of these roles you actually want a large and varied group that can approach issues from different angles.

Another point that is not clearly communicated is that there is two different perspectives on open source development communities; whether you're a company like MySql partly crowdsourcing your production, or if you're part of an community, where there is no clear corporate interest in, or control over, the community itself. Or to put it another way, If you're on the outside peeking in (possibly thru agents), or if you're on the inside looking out.

In the case of OpenSimulator, the Open Source project I know best, I would translate this article to the following recommendations:

• As a commercial interest, you cannot rely on the community to function as your development department. If you need development, you need to secure dev resources for yourself.
• As a member of the OpenSim community, you are essentially customer and partner to yourself.
• In the far future, if and when the product has matured, OpenSim will eventually need some kind of governance, and the rate of volunteer effort will dwindle.
• Key is to be getting the balance right between governance and volunteer effort, and getting a sound mix of dependencies on commercial sources. At the time being, I'd say the project have a healthy mix of large and small commercial and non-commercial interests.

Do you agree?

Stepping down from OpenSim core

I've decided to step down from OpenSim core.

Since Tribal Media keeled over, my life situation simply does not allow me neither to participate in the dev community regularly nor contribute code. I have committed exactly three characters since we moved to git.

What I have come to respect the most in OpenSim is the disrespectful attitude against 'talk'.

OpenSim has always been about participating thru effort; testing, promoting, writing, coding, building. So while discussion has always been welcome, any kind of demands have always been met with "do it yourself, or pay someone to do it". A harsh sentiment, but ultimately the only viable attitude in a project like this.

Sean Dague disliked the term 'founding four', feeling that just because you were among the first didn't automatically give you authority. Back then, I didn't agree; for some time now, I have.

So rather than lingering, I'm leaving.

I wish to thank all core devs, past and present; thank you all gridnauts, testers, hosts, customers and partners - It's been an immensely satisfying ride. Hope to see you all on the 3D Web.

Best regards,
Stefan Andersson aka lbsa71

The OpenSim lightweight Release Cycle

This is the current (as of the 0.6.5 release) OpenSim lightweight Release Cycle recipe.

The goal is to run a cycle that churns out recommended code snapshots with reasonably regular intervals, and with a minimum of work for any one human resource. It should be a community effort, and anyone should be able to move the cycle forward.

If you're not acquainted with svn revision numbering schemes, see "On revisions, tags and branches" for additional info.

The Cycle: 

1. Developers and Testers work on /trunk ("testers" being defined as "users feeding off trunk", also lovingly known as "trunkheads")
2. Developers and Testers identify suitable release candidate revisions, from the repository history. (for example, people on osgrid.org  discuss this on their weekly meet-ups)
3. This revision is branched off as a "release candidate" (to /branches/0.6.5-rc1 in this case), and the version number is upped and committed only to this branch. We don't want to up the version number in trunk until we know we have a release.
4. Testers now switch their focus to running the rc until they can give feedback on whether "rc sux" or "rc rox".
   Key issues:
   • Has all version numbers been updated?
   • Does it play well with last version? Do we need to up the interface version as well?
   • Does it feel better or worse than last version?
   • Any critical errors that needs fixing first?
5. If any critical but fixable errors are found, these are fixed in trunk and the fixing revision is merged into the release candidate branch. (or vice versa, if that works out better)
6. If, even after this, testers agree that "rc sux" the project goes back to 1) to wait and look for the next rc (thusly named rc2)
7. If testers agree that "rc rox" the current rc revision is tagged as "-release" (to /tags/0.6.5-release in this case)
8. The "-rc1" branch is renamed to "-post-fixes"  (to /branches/0.6.5-post-fixes in this case) for continued service awaiting the next cycle. The svn rename lets us keep the revision history back thru the rc branch history.
9. The version number (and optionally interface version) uppage is merged back into trunk. (this is a minor merge which will probably always succeed without conflict)
10. The project goes back to 1)

The output of this would be named revisions for each of these user categories:

• Grid/Region owners running services in production
  Feed off "-post-fixes" if they want stability first, or off "-release" if they want a known 'upgrade track'.
• Developers
  Feed off /trunk, or off -rc or -post-fixes if they want some stability while hunting bugs or doing protoyping.
• Testers
  Testers are committed to helping the devs find bugs at the prize of instabilities, crashes and loss of data. They therefore feed off the /trunk development branch or -rc depending on whether there is an RC pending release or not. (ie, is the latest version an RC, use that, if not, use /trunk)
  Everyone feeding off /trunk are collectively labeled 'testers', and any installation running on anything but a 'release' or 'post-fixes' revision is considered a 'test installation'.

Tribes and Tribulations

Tribal Media has gone out of the Virtual Worlds business. Quite simply, we never could get a sustainable income out of it so finally we decided to close shop.

Darren and I have now reverted to being 'just' lbsa71 and MW, and we will both continue working with the OpenSim community.

I would like to extend my heart-felt gratitute to the prospects, clients, peers and partners we've had that made the last two years such an exciting ride - and I'm especially thankful for all the 3D webnauts that joined us in Tribal Net. You guys rocked!

Also, I'd like to extend a big thank you to Darren for working so hard with me to make our visions come to life - as head of R&D he produced some pretty amazing stuff that one can only hope will see the light of day some day - and to Jim, who believed in us and our vision so deeply he put his money where our mouth was.

Together, we wrote what will surely be a chapter in the metaverse saga.

On Multi-protocol

From the Not-Invented-Here Dept. 

With the recent breakthroughs in OpenSim with (theoretically) supporting multiple protocols, the question of 'How do you transfer Object of protocol X over protocol Y' and 'how do you change SecondLife(tm) prims into MXP objects and vice versa?

I got a revelation the other day that "Maybe you don't".

 One of the problems with any viewer approach is that any multi-protocol viewer has to support a multitude of protocols to be interesting. Very much a discussion like the one on video streaming and video streaming clients.

So, I propose the following;

On the server side, all objects are stored natively; Second Life compatible Objects are stored as that, X3D objects as X3D objects, and MXP objects as MXP objects.

They collaborate on the server by exposing the same set of behavioural functions (Exposing meshes for the Physics engine, and functions to add, move and change some basic set of attributes) 

All protocols are implemented as "codecs", on the server side they will very much look like OpenSim 'modules'; these codecs

a) set up protocol-specific endpoints for native clients

b) register factories to create protocol-specific instances of core objects

c) register abstracted endpoints for multiplexed transfer over what I chose to call the "Real Time Scene Transfer Protocol"

On the viewer side, each protocol is also implemented as a 'codec'; here, the codec is responsible for implementing the transformation of protocol-specific stream data into scene changes.

Now, when a client connects to a Scene, it has the choice of connecting to a native endpoint, or to the RTSTP Endpoint

If it connects to the native endpoint, it will use only that codec, which means all scene changes will go thru that protocol, and the server codec will do its best to transform content from one protocol standard to another, optionally by chaining other server codecs.

But; if it connects to the RTSTP Endpoint, it will be served a stream that is a multiplexed interleave of the output of the different protocol payloads.

If a new object should be created, it's ether going to be recieved as an SL UDP ObjectAdd Packet payload or thru an MXP Object add - depending on what type of object is added on the server.

The Stream Demultiplexer then splits the packets and sens them to the according codec, which is then responsible for adding it to the viewers local scenegraph for rendering.

One central point is that the native endpoints should probably implement the same interfaces as the multiplexed payload endpoint, so an SL EndPoint should be split into the SL UDP Transport layer and the SL Packet layer, where the native endpoint would use one, and the RTSTP multiplexer the other.

The control stream, ie, the information of user intentions, like keyboard presses and avatar navigation, can (probably?) be thought of either being multiplexed into the various protocol tunnels, or as a separate 'control pipe' funnel.

Of course, all this is very half-baked, and I'm definitively not the man to start drawing up formal proposals. I just realized I had a solution for what I foresee as a very real problem in a multi-protocol multi-standard 3D client-server model. In essence, you need a network transfer, a session, an interleaved stream and the different content streams

So, anybody has good already-existing protocols to handle this? SIP or RTSP to negotiate EndPoints configuration? OGG or Matroska for stream interleaving?

Best Regards,

Stefan Andersson aka lbsa71

Hacking Trees

From the Under-the-Hood dept.

Today, I thought I'd show you how to attach a LSL/OSSL script to a tree, and in the process touch on some interesting concepts.

The first thing you need to know is that tree and grass are really just prims with a special 'PCode' that tells the viewer to render them differently. In theory, you would be able to attach scripts to trees and grass in Second Life™ - with OpenSim, theory becomes practise!

• set up an empty region
• create a Tree, call it 'My Tree' or something so you can identify it later
• create a Box, call it 'My Box'
• create a script in the box, call it 'Tree Script'.
• on the opensim region console, issue the command
  save xml2 test.xml
• the file will be saved in the OpenSim root /bin directory as test.xml. Open it up, preferrably, in an xml-savvy editor for readablity.
• inspect the xml code. It's a mouthful, but after some careful scrutiny, you will start to understand some of the nodes. You're now looking at the under-the-hood representation of objects in OpenSim, which incidentally is based on the binary data protocol that the viewer and region uses to communicate. Doesn't look anything like the numbers you see in the edit object tabs, right? That's because the viewer is trying to present stuff in a way that you as a user will feel more familiar with.
• Now copy the full <Shape>...</Shape> node block of 'My Tree' and paste it over the full <Shape>...</Shape> node block of 'My Box', replacing it. This is the tricky part, but done right, you've replaced the box shape values with the tree shape values, turning the box definition into a tree definition.
• Save the modified test.xml file to disk.
• Delete 'My Box' and 'My Tree' from the region, making room for importing the new hacked versions.
• Issue the command
  load xml2 test.xml
• Hey Presto! You will have two trees, probably of wildly differing sizes. (If so, this is because the <Scale> of 'My Box' was different from that of 'My Tree'.)
• Now, right click on 'My Tree', and chose 'Open' (not 'Edit'!) from the Pie menu - In OpenSim you can actually Open the contents of a tree - in Second Life™, this pie option woul be grayed out. In 'My Tree' the content is empty.
• Now, right click on the tree called 'My Box', and chose 'Open' - we still have our script there!
• Now, script away, you can basically do anything with the tree/grass that you can do with any other prim - set the params, size, position, communicate, do http requests. Go wild!
• Here's a little demo script to get you started: it toggles the tree position and size every second, while saying 'timer' every tick.

integer toggle = 0;
default
{
    state_entry()
    {
        llSay(0, "Script running");
       
        llSetTimerEvent( 1.0 );
    }
   
    timer()
    {
        toggle = 2-toggle;                      

        float newval = toggle + 3;                      

        llSay(0, "timer");
       
        list rules = [ PRIM_SIZE, < newval, newval, newval >, PRIM_POSITION, < 128+newval, 128+newval, 30+newval >];
       
        llSetPrimitiveParams( rules );
    }
}

• You can now take this object to inventory, clone it and give it to your fellow man.

For extra credit:

• The <State> field of the tree prim represents the tree type*.
• Explore changing the TextureEntry, Particle Systems, SculptTexture, CollisionSound of a tree - does it do anything? Please report back to me.
• What with defining sit targets, attaching to link sets, defining touch_start() events? Can you find a way to interact with the trees in interesting ways?
• Can you add other objects into the content? Make a wishing tree where people can actually 'Open' the tree and pillage the goodies?
• How about "Megatrees"? Find the <Scale> nodes and create a 100 meter Tolkien forest? (There are two but only one of them needs changing, figure out which)
• What fun can be had with 'grass'? (Create and save 'My Grass' and inspect the xml.)
• How would one go about to export the scripted trees to other grids, where you don't have console access?
• Is there an even simpler way to do this? Can Prims Rez trees from inventory, give them active scripts, and if so, can trees Rez their spawn? Please report back with your findings, or blog about them.
• Take screenshots of the steps along the way, and send them to me so I can illustrate this article better.

Thank you for taking your time reading all of this. I hope that you have learned at least something about Prims, Trees, Grass, Love, OpenSim, the xml2 format and life in general.

Best regards,

Stefan Andersson aka lbsa71

*       Pine1 = 0,
        Oak = 1,
        TropicalBush1 = 2,
        Palm1 = 3,
        Dogwood = 4,
        TropicalBush2 = 5,
        Palm2 = 6,
        Cypress1 = 7,
        Cypress2 = 8,
        Pine2 = 9,
        Plumeria = 10,
        WinterPine1 = 11,
        WinterAspen = 12,
        WinterPine2 = 13,
        Eucalyptus = 14,
        Fern = 15,
        Eelgrass = 16,
        SeaSword = 17,
        Kelp1 = 18,
        BeachGrass1 = 19,
        Kelp2 = 20

Working with the Hypergrid

A recent and exciting development in OpenSim is support for what is called 'hypergridding' or 'hyper-linking'

In effect, what it does, is just to let avatars ('guests') teleport into 'foreign' regions (on other grids) and in the process inform the target region where to look for inventory and assets for that guest - in theory, allowing for free teleports between grids.

Now, how have drm issues been solved, you wonder? The short answer: "we haven't".

As of this moment, you are adviced to think of 'hypergridding' as one big security and drm vulnerability. It is actually the very lax security of the OpenSim OGS protocol (Open Grid Services) that has allowed for the hypergrid to emerge.

It still has some heavy benefits, but more in the 'weak protection needed for loading a webpage' corner than the 'strong protection needed for participating in interchange within an economic system based on artificial scarceness' one.

So, how would you, as a grid owner, concerned for your users, work with this? I suggest something like this;

First of all, set a completely isolated Hypergrid standalone DMZ 'island' up parallell with your 'main grid', like thus:

By specifying gridmode=false in your OpenSim.ini and setting the standalone region to use a private database in the [Standalone] section.

Make sure you specify/create an dmz region 'master avatar' on startup, otherwise you will not have any account with permissions to modify the region once it's up. If you just start the region up from scratch, the startup procedure will ask you to create a master avatar account. Choose a strong password.

What this setup gives you is the opportunity to start trying hypergrid interlinking out, while ensuring none of your main grid data or content leaks out. Again, if you decide to use a shared database server, make sure you specify a new database clearly separated from your main grid database on that server.

I would suggest you create what I call a 'storefront' on this region, non-drm sensitive demo and pr content that ushers prospective users onto to your main grid through the grid registration page. The point here is to keep the hypergrid region air-tightly separated from your main grid whilst still allowing you to expose content that people can make part of their own grids. A '3D banner exchange program', if you will.

Do note that the only way to work with or access this dmz region is to either log on as the specified master avatar (if you specified one) or to hyperjump into it. And the only editing options is either to log on as the master avatar, or to turn perms off.

After familiarizing yourself with the hypergrid, we can start thinking of how to start sharing user data and content with the main grid, whilst retaining basic drm security. This I will cover in my next 'Working with the Hypergrid' blog.

(If all this sounds interesting, but you don't have a clue as of how to do all this, visit the opensimulator.org web site, join the #opensim irc channel on freenode, or send me an e-mail.)