Here’s three screen shots from a OpenSim demo that DeepThink is working on to exhibit at Virtual World Expo in LA. If you want to see more, you will just have to come show up at the OpenSim booth and play around with it in real time. (We’ll also put it up online somewhere after the conference is over).

If you are very familiar with the operation of OpenSim (actual developers will be prioritized here) I have a couple of free tickets available for people to man the booths with. Contact me for details.

This one comes up a lot - I hear it in quite a few places “Well, shame it’s in C#.”, it’s usually followed by some nebulous statement about Microsoft, followed by patent threats, embrace extend extinguish, etc etc.

So let’s start with the basics -

• C# is a ECMA and ISO standardized language. It went through the review procedures of ECMA and ISO in a standard fashion (unlike OOXML). Download the ECMA Spec here and the ISO Spec here.
• Yes, the base library is included in that standardization. The primary exceptions are, ADO.NET, ASP.NET, Web Services and Win Forms. Many of these exceptions are however separately covered via Microsoft’s Open Standards Patent program, although we’ve moved to avoiding them entirely in the standard release. (Extensions which use them are however available on the third-party utilities forge)
• The ECMA standard also includes the CIL byte code format.
• If Microsoft decide to add new extensions onto .NET (which they have done with every major release), the OpenSim developers are content to wait until those extensions are available under Mono (which moves fast enough that it isn’t a major problem).
• Microsoft is not known for breaking backwards compatibility to “extinguish” things - the mere fact you can still run Win3.1 applications on Windows Vista should give some assurances there. Microsoft is yet to make any kind of retroactive change to the .NET standard - all .NET 1.1 applications should still run under .NET 3.5 without changes. (and the cost to them of making a change like that would be significant in terms of people using applications under Windows)
• There are two completely F/OSS implementations of C#/.NET and the standard library. Mono (Licensing Concerns Addressed Here) and the FSF’s DotGNU PNET. OpenSim is regularly tested for compatibility under Mono (in fact our automated testing environment uses it). DotGNU is significantly less popular and has not been properly tested with due to not being feature complete yet. There is also a third source-availible implementation from Microsoft called Rotor, however it is not under a OSI-approved license.
• Microsoft maintains a reasonably healthy relationship with the Mono developers and has been known to collaborate in the past (such as for the development of the specialised Moonlight runtime).

The next question usually is “Well, why not write it in Java then?” the answer is multi pronged and highly likely to generate a flame war on the subject - the biggest reason is that coding the same thing in Java would probably take significantly longer to do.

Java is a beast of a language that has had layers of gunk added in every revision resulting in a hodge-podge of inconsistently named items in the standard library that may, or may not address what you want. The second major reason is that the C# standard library is both larger and more functional - the amount of time and effort the Base Class Library has saved is astonishing. Wikipedia has a nice article detailing the differences between the two languages.

However, since both Java and C# share a very similar byte code language - it is possible to do a machine driven cross-compilation so you could run OpenSim under the JVM runtime if you so wish. Source translation between the languages is also reasonably possible however requires a degree of manual work.

Some concluding facts which may actually surprise some people

• One of the largest contributors and users of the project is IBM. One of the first groups inside of IBM to get involved was IBM’s Linux Technology Center. All[?] of the IBM developers are using Linux, Emacs and Mono to develop and test.
• Approximately half the developers working on OpenSim are running under Linux/BSD. As a user base, Linux users represent approximately 80-90% of the casual testers and operators. (Windows is however much better represented in people running commercial operations)
• Our compatibility targets are Mono 1.2.5 (latest is 1.9) and .NET 2.0 - we dont use features which supercede these (although we may raise that to Mono 2.0 once it is out of beta).

Justin recently wrote an article about the likelihood of the concept of a “Grid” to vanish fairly completely. I think he’s bang on there and I expect to see things play out fairly similar to how he describes. The reason for this is that the concept of a “Grid” is completely and utterly irrelevant in the long term.

What?

I suspect in the long term, some of the models presented by alternate virtual worlds (Croquet in particular) are largely correct. While the ability to “load balance” a larger 3D space across multiple servers by partitioning the geometry accordingly is a very valid feature - it restricts you to creating giant contiguous landmasses.

And I dont think this is something either users nor companies want.

The analogue with the traditional web is the concept of somewhere like Geocities - under the contiguous space model, every user from geocities has their webspace crammed right next to someone elses, and you can see it whether you like it or not.

If someone makes any parallels here with the Second Life™ Mainland, you are probably right on target - it’s probably one of the reasons that Private Islands in Second Life eclipse the number of mainland regions. Now that’s not to say that users wont want to congregate together on occasion - consider the Steampunk themed Caledon sims - but in that occasion it is strictly by choice, and not representative of the majority of users.

Supporting both is of course a priority - but I suspect in the long term that the abitrary collections of regions wont be crammed together. Most will be linked by the same technologies that link the internet today - IP and DNS, and any organisation will be built ontop of that rather than the concept of the grid itself.

So what about users?

Right now - the single most inconvenient factor to visiting the OpenSim grids today is the requirement that you create a user account before visiting. Unlike email where you can login with a single username and send a message anywhere - you need a seperate account for each server you want to visit.

If we seperate these out (as the AWG OGP spec does) we get to the point where your username comes from someone like an email provider (ISP, Free Hosting site, etc), and the regions are seperate things that you can connect to like visiting a webpage.

In this case, grids become groups of commonly themed regions that are visitable with either commonly themed URLs (ogp://grid.com/regionname/x/y/z/) or contiguous landmasses and not much more.

One of the beauties of the internet’s design is that you only need a single number to represent every server connected (an IP address), there’s millions of servers connected each with their own address - if you tried to organize those millions of servers into a set of finite artificial constructs, you would probably fail - the operators of those servers tend to like to run their own environments and not be reliant on other people for stability and uptime (there’s a bit of a commercial incentive there).

Why proposing things that rely on grids is probably a bad idea

There’s been a lot of suggestions lately about things like content enforcement being locked to a specific grid for example. The catch here is that there’s potentially one “grid” for every independent region online under the AWG spec. Only places such as the Caledon-equivilents are forming grids with multiple servers in them.

In this case the question becomes - if grids are not a good analogue for the operator group, what is? The answer here is probably the hosting companies. While I don’t have a firm number here - I’d say that probably 50-80% of the web hosting on the internet today is done by a small group of companies and their resellers (1and1, GoDaddy, etc) - and those are the groups you will want to get contracts for enforcement with.

The remainder may sign onto the contracts, but you can easily get the large groups with a smaller amount of effort just by hitting the hosting companies.

Usual disclaimer: This is a personal opinion piece, it represents my views alone and may not represent that of any colleagues. It’s fairly long and rambling too.

No, I’m not going to be discussing DRM / Copy protection’s feasibility again - I’ve done that enough lately, and really there’s not a whole lot new to say on the matter - if you can put it in a contract, you can then enforce it. I’ve spelled that one out before.

This post is to explore some options for some permissions that can realistically survive other people hosting regions for themselves, and stand a reasonable chance of being respected. The inspiration to this post being a musing on the validity of ‘no-mod’ and ‘no-copy’, in both cases these permissions tend to stick in the way of what a consumer wants to do with a piece of content, and in both cases the permissions are fairly arbitrary.

I’m looking a lot at the past for ideas here - the web itself actually has some very strong analogues to where virtual worlds are heading, and surprisingly enough these kinds of permission games have been played out before there.

As with everything there is a bit of a balance here - evading the permissions model is always going to be fairly trivial for someone with a few skills, video game piracy still occurs - even when the copy protection schemes get so onerous that there have been claims it’s physically damaged hardware. If one makes the permissions too tight, it’s going to dissuade legitimate consumers, and inspire others to break it.

Thou shalt not modify.

Let’s start with no-mod, and first examine why creators use this permission. There are two big reasons that seem to spring up when discussing this permission with content creators. First - any object with mod permissions can be cloned via scripts (or manual copy-by-numbers), and Second - the creators have a desire to develop a brand image around their products being recognizable, or have a secondary market for product modifications.

The first reason is more of a problem for “no-copy” - I’m going to leave that for when I touch on no-copy, since it’s fundamentally that trait they want, not denying consumer customization rights. The second is potentially more understandable - consider the example of a major motion picture company offering free content - for their intents they want it to stay the same, keep logos and trademarks, etc.

So what can you replace this with? Well first the potential exists for marking whether something is original or not - that much can be done with a form of ‘object hashing’ (or fingerprinting), determining whether something is identical to as it was shipped is actually a lot easier than determining if something is a derivative of it.

This means that potentially if you ‘travel’ with the modified component, recipient servers can say “Hey, this looks unauthorized. I’m not letting you bring that in here”. These checks being easy and hopefully efficient enough to do.

When on a users own server in their own environment however this one is effectively unenforceable - trying to prevent users modifying content on their own servers is akin to trying to prevent someone from modifying an image that’s stored on your local machine.

Sure modifying it might be more difficult than the original creation (without layered source files, etc), but all the pieces are there and certainly a degree of blunt force can be applied.

On the inverse however - I’d like to suggest that perhaps this isn’t something you actually want to do 90% of the time. Returning to my analogues - let’s assume you are producing landscaping objects, something to decorate a scene with. The closest equivalent is that of the website template or stock imagery. While the composition is an important factor in the development of the scene, most people are going to want to customize it slightly - the best users are going to be the ones who do major customizations and bring their own flair into the design. It’s possible to then point to these customized versions in your own marketing (Hey you can do this!).

So expressing this in permissions, we have a few new options potentially for legitimizing user behavior while at the same time marking what the creator will/will not allow.

Please note - by suggesting these I am not saying anything different to what I have before. Permissions are at their heart completely unenforceable without legally binding contracts dictating their use, in which case those contracts are enforceable, not the permissions.

• Plain No Modifications Allowed - This one is pretty broad, but it’s still somewhat valid in it’s construction. Enforcement requires some legal magic - but technical enforcement alone is a toothless tiger.
• No Transmit Modify - Consider this the situation above where you can customize it on your own space legitimately. The permission is you cant transmit it to other servers or users in a modified state.
• Attribution Required - Modified objects must contain an original creator tag that can be examined by visitors and observers. Any attribution built into the objects themselves should not be removed.
• Modification Limited To - A list of attributes on the object which can be modified (such as say color, size/dimensions, etc) but leaves the rest of it marked as no-mod.

Thou shalt not copy.

This one is a little tougher to enforce, and I’ve gone into great detail about copy protection before. The heart of this permission is to make sure that content is licensed for a single usage at a time - traditionally there is two types of enforcement on this in Second Life: “no-copy+trans”, being there is a singular copy of this item which can be transfered to another user and “copy+no-trans” the inverse, you are allowed unlimited copies, but not allowed to transmit them to other users - in both cases the goal being that only one user can use the content at a time, and if more want it they need to pay for it.

It’s possible here to think of some new permissions which actually fit these roles better - consider the idea of a license. You have a license to use piece of content X. This license can be transfered to another user, however you then lose the ability to use “X” until you acquire another license.

No-copy doesn’t have many analogues with the web itself, the major reason being that on digital computers it’s actually impossible to “move” something. “Moving” is actually “make a copy, then delete one”, enforcing singular copies of a license is very difficult.

The closest we can find is content protection used on Video, Audio and similar - be it through iTunes or somewhere else. In this case, the analogue isn’t very good since in those cases you are explicitly denied from transferring the content to another user. Full stop, end of discussion.

Perhaps a better analogue comes from cryptographic keys - companies such as VeriSign maintain something called a “Key Revocation List” which is the list of keys that they have removed from active service - while those keys still work, if someone does a look on the KRL for it they will say “Hey wait a moment, that’s not valid.”

Licenses then become something that is authorized through a monolithic provider (either run or contracted by the original copyright holder to handle the licenses). If you wish to transfer a piece of content, you let the provider know you are transferring it to X. The provider revokes your license and grants a new one to the new holder - licenses can be checked before content is transmitted to a new server, and the server can decide whether to accept it or not based on the results of the license server’s check. (Of course the server might just ignore those results too.)

It is also possible to consider some alternate “no copy” bits here too - such as allowing the content to be licensed on a “per-server” rather than “per-user” basis. Certainly commercial content is likely to be licensed in such a manner since it handles ‘group usage’ better.

Potential permissions?

• Singular Usage Only - Only a single copy of the item may exist. To enforce this serial numbers will be required on the item (This is #17). This is equivalent to the “no-copy+trans” permission in SL today, of course there is the concern about content being deleted accidentally, etc, so mechanisms need to exist to replace lost content.
• Singular User Only - This content is licensed to a single specific named user. No other users may use this license, however this use may make copies for their personal use.
• Singular Server Only - This content is licensed to server the server located at W.X.Y.Z, or addresses in the range W.X.Y.Z/24. In English - a single server or group of servers only. Transferring out of this range is explicitly not allowed. Within this range unlimited copies may be allowed.

Thou shalt not transfer.

The last permission is the concept of transferring your license to other users. Secondary resale markets, etc. Certainly a number of creators embrace the resale model and provide bulk packs of content for resellers.

This is pretty simple and I’ve described it above. The permission is pretty simple too - and potentially you could enforce more complex licenses (such as say a viral license) through this mechanism.

The permissions here?

• Transfer not allowed - License transfer is expressly forbidden.
• Unmodified Transfer Allowed - License transfer forbidden if content is modified
• Modified Transfer Allowed - License transfer only allowed if the content is sufficiently modified (the “stock photos” license)
• Transfer allowed only under these terms - You cannot modify the permissions if you wish to transfer his item.

On the inability to express every scenario with permissions

One of the problems with the above is that you simply cannot express every possible legal license with a few check boxes. While it does make it easy to generate a license from these (in the way that Creative Commons does with 3 check boxes), in these cases it would be nice to be able to provide a custom string that can let you define custom permissions and actions and have it interpreted on the server.

At risk of seeing everything a nail (if all one has is a hammer) - a highly limited interpreted programming language may actually be a more flexible solution here. Especially if the language is close enough to English that it’s understandable to the casual observer.

Consider something akin to the following paragraph

COPY:
   IF USER HAS LICENSE AND
      COUNT OF OBJECT IN REGION IS LESS THAN TEN AND
      TODAY IS MONDAY
   THEN
      ALLOW
   ELSE
      DENY

MODIFY:
   DENY

TRANSFER:
   IF OBJECT IS MODIFIED
   THEN
      DENY
   ELSE
      ALLOW

While slightly less than perfect English - it’s relatively understandable. Copying of the object is allowed on Monday and only if you have less than ten copies of the object in this region. Modification of the object is always denied, and transfer is limited only to the original unmodified object.

In this manner, a complex license such as the GPL could have a programatically interpreted helper to assist in license enforcement (although the legal bindings behind the GPL are the real teeth). Such a license would look very simple: “COPY: ALLOW, MODIFY: ALLOW, TRANSFER: ONLY UNDER THESE TERMS: ALLOW.”

Server side Enforcement

Servers ultimately have the final abitration on whether to enforce these or not. If Joes server decides not to use these permissions, well there’s not much you can do if you dont have a contract with Joe forcing him to. (Of course if he gets your content unlicensed - then that’s copyright infringement.)

It should be noted that it should be possible to design a server that will also expressely refuse content marked under certain permissions. (That is it will not rez), for instance if the server is unable to prevent someone from modifying something, then the server may say “Well, I’m not going to touch anything that could get me in legal trouble - public domain content is the only type accepted here.”

There’s actually a number of reasons why people would want to be able to mark those kinds of permissions - the legal angle is definitely one, ideological is another - a group may want to only allow Public Domain or F/OSS content. Another group might want to avoid the problems with viral licenses and simply deny access to virally licensed content, ultimately the flexibility to decide should be in place.

At the heart with this issue - flexibility is king. Permissions managers, etc should be designed under the implication that they need to support a wide variety of models - and ultimately it will be the market and users that decide which models succeed and which do not, there is probably going to be a lot of ideas surfacing over the next 12 months on how to handle this. This is merely one of them.

What this competition is about

For the upcoming Virtual Worlds 2008 conference in LA, myself and some of the other OpenSim contributors and developers have decided to sponsor a large booth, and we’d like to cover it with screen shots of the best and most innovative uses of OpenSim out there today.

What we need

We need high resolution screen shots from your builds, ideally these should be captured at a minimum of 1600×1200 pixels (if you are using the Second Life™ viewer, the “High Resolution Screen shots” option works well). All settings should be set to maximum, ideally with anti aliasing, screen shots should have a minimal amount of adjustment (limited to cropping, brightness) and originals should be provided.

The Specifics

• High Resolution - We’re printing onto a 300 DPI surface, this means we absolutely need the highest possible resolution when printing to make sure we have crisp clean non-blurry images. While there isnt a definition of what is or isnt high resolution - try submit screenshots at least 1600×1200, higher is preferred.
• Submit in a lossless format - We need images provided in either 24-bit PNG, TIFF or BMP. As these files tend to be rather large, please zip or rar them with maximum compression.
• If you are submitting a manipulated image, the original is required as well. There is no guarantee that the manipulated version will be used. (We are trying to provide accurate but nifty portrayals of what OpenSim can do.)
• Deadline - submit your images before Wednesday, 27th August 2008. Sooner is appreciated as we will begin incorporating images into the layout as soon as they are received.
• How to submit images - Please use a service such as yousendit.com to transfer the archived files, send your message to “adam@deepthink.com.au”. My inbox will reject files larger than 10mb, so please do not send these directly.
• Judging will be done by myself in conjunction with the other people sponsoring the booth. Decisions whether to utilize an image will be based on constraints such as whether or not we can work them into the larger montage and do so in a way which highlights OpenSim in a positive way.
• Some tips - People/avatars always look good. Eye candy is always a plus. Showing scenes where this is in production and potentially useful for people interested in using it are also going to be in demand.

What you get?

Accepted and utilized images will get 6 months free standard-class region hosting from DeepThink to a grid of your choice. The Judges may provide hosting for images of excellent quality which are unable to be used, however this is soley at the discretion of the judges.

I’ve got this switched over to adamfrisby.com now - the previous domain will still work of course, but this was the intended URL from the start (just had some minor fun getting that all transfered and setup).

If you have any links or whatever going to the previous URL they will still work and be redirected to the appropriate site on the new domain without issue.

Let’s run through the quick checklist for the recently semi-announced “LivePlace“, who claims to do some pretty nifty things with distributed server side rendering.

• Buzzwords like “Cloud Computing” and “Virtual Worlds”? Check.
• VC Capital Funding? Check.
• Implausible Technology that doesn’t stand up to basic analysis by an industry professional? Check.

Say hello to serverside cloud based renderered virtual worlds. Somehow, against all odds a small unheard of Silicon Valley company has developed a real time renderer that not only exceeds the current best of breed distributed real-time rendering research projects by huge margins - does so in a way that’s scalable to deploy a major concurrent project on.

Doesn’t anyone in Silicon Valley do basic fact checking with a technical adviser before giving capital?

Assuming this company has actually succeeded in developing such a renderer (big if) isn’t there the additional problem of bandwidth? Let’s be kind and say the average user has a 1024×768x32 screen - that’s 24mbit of data that needs sending 30 frames a second (720mbit/sec), now yes you can use some video encoding to cut that down significantly - but that’s a heck of a lot of data, and the compression is going to induce processor load seizures too.

The answer to the above question is apparently not.

There is a big reason we do client-side rendering today, and that is it distributes the load better than any “cloud”. 100,000 clients = 100,000 processors, 100,000 graphics accellerators, etc. Yes some of them suck and can’t do pretty graphics (Intel I’m looking squarely in your general direction), but the rendering they can do is going to be better than what a foreign service can do for you, and it’s going to be speedier - not only do you not have to wait 200ms ping and a x megabyte download to happen before you see the results of your movement.

While I am not claiming that this technology couldnt be made to work - it’s just not going to be pretty, I dont believe it will scale anywhere near effectively, and the bandwidth requirements alone are going to cause some very tough questions to be asked about whether this will run at all. (After all - anyone with a internet connection fast enough to support this is going to probably have a decent video card anyway.)

Count me very skeptical.

Shouts to Belaya for adding to the snark contained within this post.

Sources are availible from the usual location:

http://forge.opensimulator.org/gf/project/xenki/frs/?action=FrsReleaseBrowse&frs_package_id=6

This is the rewritten version of the XBAP Viewer known as Xenki - this release has support for IRendering-style meshers, Terrain rendering and more.

I have added a password to a post listed earlier on this blog. As stated within that post, I do not enjoy writing negatively about people, products, groups, etc - and getting into arguments on the interwebs wins you nothing, but is great at wasting time.

In this post I made certain specific claims about a group and their public behaviour, that group has agreed to me to be more careful about what claims they make publically and improve general behaviour, and in doing so I have agreed to withdraw that post from the public domain. A password is now required to view the post and attached discussion - if you have a legitimate reason to want to read that discussion, my contact details are on this site.

While I still hold that the substantial portion of the original claims are reasonably correct - these claims are between myself (and certain specific developers) and the group, and a degree of confusion about the topic at hand has lead to an agreement that despite being cliched, there was a good deal of misunderstanding involved, one that if it is to be posted at all now, it should be posted in a terse clarified form which I will post if there is ever a need.

I’m glad to hear a little sanity coming from the New York Times on this matter (via Slashdot) - typing your password into someone elses website should always be consider a absolute no-no. It’s a phishers dream come true.

Why not? Because the companies see the many ways that the password-based log-on process, handled elsewhere, could be compromised. They do not want to take on the liability for mischief originating at someone else’s site.

If someone wants to design an OpenID-like solution the best answer is to do some form of challenge/authenticate redirect. IE - User visits site A to post a blog comment, wants to use their ID, They click ‘Authenticate me’ and enter the URL to the site that will authenticate them - the user is redirected to that site, SSL certificates should verify you are actually speaking with your authenticator, you login - then redirect back with an appropriate token matching the challenge written by the original site.

It’s a bit more complex than “Enter your password on Joe Shmoes website” - but the security benefits are considerably higher given you can verify you are sending your password only to Joe.

The rest of the times article is a discourse over whether we should abandon Passwords in favour of secret cryptographic keys - I believe the problem here is that ‘he who has the keys, has your account’ this means you either need to use one computer only (and forget about logging into your email from another persons machine), or you need to start carrying your crypto keys around with you and prevent someone from nabbing them.

The downside to passwords is however that they are incredibly weak security measures - a 1024bit RSA private key is a lot stronger than a 128bit password (8 ASCII chars) (each additional bit is a doubling in strength, so a 129 bit password doubles the number of possible combinations - 896 doublings is a lot stronger yet).

The best solutions are of course hybrids - when strong security is required (banking, etc) having some form of USB key that can perform RSA encryption for you within the token without revealing your key may be worthwhile - although it means you need to start carrying it around wherever you wish to do banking - however to activate the device some kind of password would be essential too to prevent someone from stealing it.