Category Archives: Hypergrid

Content protection: an incomplete proposal

This post comes on the heels of a conversation Ubit and I had about protecting content on the Hypergrid. As all of you know, content protection, in general, is a big problem, and not just for the Hypergrid. Even for closed grids that can enforce permissions, content theft happens via modified viewers: a sufficiently skilled developer can grab the source code of any of the legit viewers and add modifications to it that allows them to copy all the content they see, and alter their permissions on the copies. The Hypergrid opens up yet another avenue for abuse: when an avatar travels to another grid, their appearance and the inventory items on their Suitcase folder become available to the destination grid. If the owner of that destination grid is a decent developer but a bad actor, they can add modules to OpenSim that grab copies of those items and change their permissions on the database.

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, 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.

Towards HG 2.0

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.

Continue reading →

New diva distro for OpenSim 0.7.2 featuring W2W Friends

Hi everyone! I finally had the time to put together a new diva distro release corresponding to OpenSim 0.7.2 — plus a few minor bug fixes over that. If you already have a d2 world, you know the drill: run Update.exe. Otherwise, grab the zip, unzip it and take it from the README file. If you’re upgrading, I highly recommend running the Configure tool on the new installation, and you’ll see why.

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!

Friends and IM over the Hypergrid

Over the past few weeks I have been working on mechanisms for making friends and instant message work across the Hypergrid. These social functions have been a goal since the beginning of the Hypergrid. The big rearchitecture work we did in OpenSimulator 0.7 that strengthened security was also meant to support these functions, but, of course, we weren’t really sure how well the new architecture would hold when these functions were actually implemented. Well, now I know — it handles it just fine. Let me explain how friends and IM work over the HG, the challenges, and the current limitations. Keep in mind that these new functions are still experimental, and subject to changes and improvements.

Continue reading →

New D2 and Wifi for OpenSim 0.7.1


It has been a while since I made a D2 + Wifi releases. I had been waiting for OpenSim 0.7.1; the changes between and 0.7.1 were such that I didn’t want to risk making a release in between. OpenSim 0.7.1 finally happened earlier this week, so here is the much awaited D2! Technically, it corresponds to OpenSim r15402, which is a couple of commits after the official release — I found a couple of bugs in the official release related to the Library, so I fixed them.

Continue reading →

Diva Distro for 0.7: Introducing Wifi

It took a long time, but OpenSim 0.7 is finally here! It’s quite difficult to explain the value of refactorings and of  re-conceptualizations of the software, which is what happened to OpenSimulator between 0.6.x and 0.7. Those things tend to be intangible at first (“WTF? This does the same thing! And it has bugs that it didn’t have before!”, etc.); the ROI only shows up later.

Continue reading →

90-Degree Course Adjustment

The news came yesterday after lunch: major layoffs at Linden Lab, as much as 30% of their employees. Lindens who had been there from early on, respected engineers, all laid off. All of those who had, at some point, been involved in the idea of virtual world interoperability — gone. Then the new vision: Second Life on a browser, accessible to the masses via well-known social networks. Wow. This is what I call a 90-degree course adjustment.

Clearly, I know nothing about the internal situation at Linden Lab. Probably their VC money has dried off, maybe their revenue is not enough to pay so many people. Who knows what’s behind a 30% ‘rightsizing’… But the new vision is an indication that this is not just about balancing the budget sheet; it’s about redefining what Second Life is. LL’s CEO wants it to be more like FarmVille than like World of Warcraft. Too many people have commented on his vision, I’m not going to do it. He’s the head of the company, he should try to make his vision come to life.

What I want to talk about here is what this 90-degree course adjustment entails for OpenSim. I confess yesterday I had that familiar feeling of having reached the point of having to stand and lead. Not me, personally. But the OpenSim project, as a whole. The torch is on us. Let me explain.

Continue reading →

Serverless grids

There is a new diva distribution available. It is packaged out of the bleeding edge OpenSim, revision 11056. If you have the previous release installed, you can simply run Update.exe.

In the past 2 weeks there has been a lot of plumbing in OpenSim, and things have improved considerably. First and foremost, we have identified and eliminated a memory leak that was causing OpenSim to use all memory over time, and eventually crash. Now OpenSim runs on much more reasonable memory footprint, and stays within that limit [for much longer].

Second, we have rewritten the grid service from scratch. The grid service is the part of OpenSim that manages region registration and lookup. All OpenSim installations have a grid service, even if they are standalones. In fact this distinction between standalone and “grid mode” is becoming fuzzier and fuzzier. So much so that it is now possible to have grids by stitching together standalone installations of OpenSim — without having to run any other servers!

Continue reading →

Standalone but Join the Party

It’s no secret that I love OpenSim standalone installations more than “grids”. For most things I envision doing with virtual worlds, including installations in my university, I can’t see the value of having a huge virtual space that is both shared between several tenants and centrally managed. The things I like to do fit perfectly in a few regions managed and controlled by me. The UCI Grid is about to become a web of hypergrided standalones. I suspect that many people are on the same boat. It used to be the case that standalones were solitary worlds that didn’t connect to anything or anyone; with the Hypergrid, that has changed. Standalones now can connect to the rest of the Metaverse — OSGrid, ReactionGrid, your friend’s standalones, etc. It’s a big world out there, and you can access it from your own small world.

I’m happy to announce Metaverse Ink’s “Diva Distribution”– a lean and mean OpenSim distribution targeting hypergrided standalones that comes preconfigured and that is very easy to keep up to date with newer releases of OpenSim. The Diva distribution is, literally, my personal preferences using the many configuration options of OpenSim. Here is what it consists of:

  • MySQL as the DB backend. I used SQLite for a long time. SQLite is really easy to use, it requires no installation, it’s great for beginners. However, it’s clear that SQLite doesn’t scale well for long-term worlds. Moreover, using a MySQL server on the backend enables very interesting hybrid architectures that I will be talking about soon. The diva distribution requires some expertise for setting up MySQL, but it’s worth it. The instructions that come on the distribution make the MySQL setup for OpenSim really easy.
  • ODE Physics. Easy choice here. Even the official OpenSim distribution is about to change to ODE as the default physics engine.
  •  XEngine as the scripting engine, and lsl as the scripting language. XEngine is the most stable of the scripting engines we currently have, and lsl is the most widely used scripting language. All other language support is still experimental and fairly insecure.
  • One Megaregion of 512×512 meters. That’s right! Megaregions just made it into OpenSim, thanks to Teravus, and they are working great. With megaregions there are no border crossings, everything is very smooth.
  • MetaverseInk Search. If you want to make your world searcheable, mark your parcels “Show in search”, and they will be listed on MISearch’s engine. Others can teleport to your world from search results. Everyone can do this on their OpenSim by setting a certain configuration variable; the diva distribution has that preconfigured.

Over time we plan to add more goodies to the diva distribution, so stay tuned.

Additionally, the diva distribution contains two tools that make it really easy to configure and update your installation. They are:

  • Configure: this is the tool you should run after unziping the first distribution. Be ready to tell it (a) the name you want to call your world; (b) the password for the MySql DB opensim account; (3) your externally visible IP address or domain name. Once you answer these questions, Configure will do all necessary configurations for you. You don’t need to edit any .ini files.
  • Update: once you get the first installation set up, updating it is as easy as running the Update tool. Update asks no questions from you, it just does the right thing.

While the diva distribution comes preconfigured with my own preferences, it is possible to change these preferences to yours. For example, if you want more than a 512×512 megaregion, you can add more regions. The instructions for how to do that come in the documentation that is included in the distribution.

So where can you get it? Get it at — the file to download is called, which is listed at the bottom of that page.
Unzip it, read README, and follow the instructions from there.

Let me finish this post by reminding everyone that the current version of the Hypergrid, which we call HG1, is fairly insecure. Don’t take your favorite avatar to places that you don’t trust. HG2 is coming, but it’s not here yet.