It was more than a year ago when developers from theÂ Avination grid and the Singularity viewer got together and created a new permission for OpenSim, the export permission. Since then, no major grid has adopted it, not even Avination itself.
Until now. But it’s not Avination rolling out the export permission, or one of the smaller hypergrid-enabled commercial grids, or Kitely, which has its own version not supported by any viewers.
It isÂ InWorldz, arguably the most successful commercial grid, and the one with the most to lose.
Adding the export functionality has been seen as a risky move, a potential security issue, or something that might scare away merchants and creators.
And InWorldz is the most popular grid by traffic numbersÂ — it has as many active users as the next five grids combined Â as well as the most developed internal economy. But it is alreadyÂ testing the export permission on its beta grid.
The primary reason for implementing the export permission, according toÂ InWorldz partner David Daeschler, is to clearly define the content that residents are allowed to download from the grid using a viewer’s built-in export function. Several viewers allow users to download objects as XML, OXP or Collada files either to keep as a local backups, or to take them to other grids.
“Right now many third-party viewersÂ will allowÂ exportsÂ of any content that has full permissions by default for OpenSim grids, but require the user be the creator of all nested content whenÂ exportingÂ from Second Life,”Â Daeschler toldÂ Hypergrid Business.
According to InWorldz developer Jim Tarber, there are cases in which creators want to distribute their content on InWorldz with full permissions, but don’t want to see the content leaving the grid.
So, in its initial implementation, adding the export permission would allow InWorldz to actually reduce the amount of content thatÂ is allowed to leave the grid.
But, eventually, the export permission could allow new kinds of exports, as well.
“We do intend to use this functionality at some point in the future to support theÂ exportÂ of region backup files in OAR and other formats,” said Daeschler.
Currently, InWorldz allows selective OAR region exports on a case-by-case basis, via support tickets. An export permission would allow the grid to offer automated region or inventory exports that automatically filter out all non-exportable content. This would make it easy for residents to make backups of entire regions, or entire inventory folders.
The InWorldz Beta grid has already implemented full support for the export setting, and it may be included in the next update of the main InWorldz grid if testing goes well, said Tarber in a recent comment.
A working export setting has also been seen as a prerequisite to allowing a commercial grid to enable hypergrid connectivity, as Kitely did late last month.
So is hypergrid now on the agenda for InWorldz?
“We have no plans for hypergrid or other connectivity protocols on the work list at this point,” said Daeschler. “We simply have too much other work going on.”
The only other grid that has something close to an export permission is Kitely, butÂ itÂ does not use the Avination-Singularity code. Instead, this permission is only accessible to creators in the Kitely Market interface, and cannot be changed in-world.
“We started development of our export control system before Avination and Singularity announced they’re working on their own implementation,” Kitely CEO Ilan Tochner told Hypergrid Business. “Prior to implementing hypergrid we investigated the state of the viewer-based export permission and found that it wasn’t fully implemented. We therefore decided to utilize the Kitely Market export system which provides a lot more functionality than just a yes or no export flag. For example, if a buyer does a chargeback all copies of the bought item immediately become non exportable. If the chargeback is reversed Â then the bought items revert back to the proper exportability setting.”
Tocher admits that their approach means that the export permission setting can’t be modified via the viewer.
“But the one provided through Kitely Market is a lot more advanced than the viewer-based system,” he said. “As we already have a better system via Kitely Market, we’re not going to spend time fixing the unfinished system that exists in OpenSim. That said, if someone else does so we’ll evaluate whether to harmonize our system to work with it and if so how.”
However, that still leaves open the question of how the “export” permission should work with the other permissions. Should items marked exportable be full-perms in all other ways as well?
“The question of what the default export permission should be differs greatly between a hypergrid-enabled grid such as Kitely and one which has a closed garden mindset,” said Tochner.
One issue is that exportability has a different meaning when it comes to downloading something from the viewer, or taking it with you on a hypergrid trip.
Say, for example, a user buys a shirt that is no copy, no modify, no transfer, but allows exports. This setting makes limited sense on the hypergrid — the user can now wear the shirt on hypergrid visits to other grids. But once the user downloads the shirt as a file to her computer, then the other permission settings instantly become meaningless — the download itself is a copy, it can be easily emailed to anybody, and once uploaded back into a grid, become, in effect, full perm for whoever uploaded it.
Of course, permission settings can be evaded on the hypergrid as well. For example, a user can teleport to a grid where they have “God powers” and change the permission settings, or change the setting directly in the asset database of a grid or region under their control. Or they can use copybot viewers to do pretty much anything they want on any grid anywhere, hypergrid or no hypergrid.
It’s a thorny issue that, right now, has no obvious solution.