The IBM interoperability Blog post got me thinking... Opinions wanted.

When reading the interoperability announcement on the blog I had a strange brainstorm hit me. (I hate when that happens) I was wondering what you all thought of the idea. I have no idea if it is possible or even practical for that matter but here it is.


Create a new level of Premium Account, that for a fee (say $10.00/mo) this Enhanced Premium account would include their own privately run microSim.

This microSim would be housed on the users local PC, and would cover an area of say 16k m2, with the full number of prims allotted for that space.

Now I know that these sims would need to have restrictions that other sims would not have.

Such as:

1. Only be active when the User is logged in.
2. Not be searchable / Mapable
3. Not available for landmarking (Only way to get to the sim is by direct TP invite from the sim owner.
4. Have an avatar limit of say 10~20
5. Be non transferable
6. Be intended for Private Residential use only

Now I also know that this could in many ways cause an extreme load problem on the asset servers if not done correctly. SO to limit the load effect on the asset servers each of these microsims would be handled by the asset servers in much the same way that a prim box that you use to store items is, i.e. it has its own UUID, and everything that is on that microsim is handled as the contents of that UUID. Im not really sure from a technical point of view how this would best be handled.

While my thoughts on this are very incomplete, I was hoping to get your opinions both positive and negative on this "Dream" concept. I have no delusions that LL would ever implement such a plan, but it was just something that popped into my head.

It'd probably be easier to keep things at 65k m2, just in case things depend on that.

I imagine that LL will indeed allow us to do what you're talking about some day. The biggest problem right now, I think, is how to keep private sim owners from making copies of every piece of content that makes it to their sim. And, worse, getting them back onto the main grid and selling them...

Now that standalone OpenSource sims are available I think it's likely LL wil be forced to follow suite. They would be in a strong position on this, since it could include full inventory transfer and all the latest LL features. If the LL standalone is superior to the competition, then a small charge could be made for downloading it, plus a bigger charge to put it online through SL. I would envisage L$ transactions being disabled and, of course, the standalone would only be online when the owner is online. So it wouldn't compete with private islands too much.

I would see no need for a super-Premium account, this could be done through a normal Premium.

On the OpenSource website, the number of OS online grids is growing, from the big ones like Open Life and Central Grid to tiny ones with a handful of sims.

But I still love my home in Yosu and visiting all my favourite clubs and making corny jokes in chat so SL is my first love.

If they make it so that you CAN live on them etc - and it's looking quite likely from the blurb about TP from SL to an Open Sim - then I'll be interested. As is stands just having a sim which is so limited, if I understand correctly, seems pretty pointless.

I like your idea a lot ... but I have a question, oh OP - how do you pronounce your name? lol

Sindy:

As for the content protection, what is in my mind is that the local machine would not "store" the object information persa, but maybe just a set of UUID/Location/rotation information. All details about the object would be handled just as it is now via the normal asset server system. SO there would be no additional exposure than there is currently.

Conifer:

MY intent was not for these "microSims" to be true standalones, being as they only exist when the client is connected to the LL Grid.

My intention was not really for these to compete with full notmal sims, but just as a bonus retreat/safe haven/ or private work area.

I love my OpenSim Standalone, as well as my little home on the water in Oryx, but until the OpenSim has the exact same functionality that an SL Sim has it will never be anything more than a novelty.

Cherry:

The reason I mentioned those restrictions mainly is that the microSim will be running on shared hardware (shared with what? who knows) and given the fact that there are so many variations in the hardware that people use to connect to SL it seemed prudent to not go overboard with what the microSim is intended for. Besides with them only existing when the client was connected to the SL Grid, they would not be suited for a shop or Club environment, that is what Mainland and Islands are for, with their dedicated hardware.


As for how to pronounce my name, hehe. I have heard DJ's murder it many times, most people just call me Myhrr. As for saying it is sounds like Mur Leen.

I'm not sure what that buys you. Once the local sim is sent enough info to show you what an object looks like, or to do an animation or make you the right shape or just about anything, what's to prevent it from making a full-perm copy?

The problem is that once LL puts something on the internet, people will stick a packet monitor on and reverse-engineer it. Right now, they can only do that with info that's sent to the viewer. If LL lets people run their own sims, the door opens a lot wider.

With the current free standlone sims you can make copies - presumably you could copy one, complete with all your builds and avatar settings onto a memory stick and load it onto someone elses computer, where they can alter the copy without affecting your original. It might even be possible to e-mail the standalone folder to someone.

All of the information you can see in SL is sent to the viewer. The only possible data that could be stolen from a locally hosted sim, that couldn't be stolen from the existing system, is scripts. This could be avoided by saying that the locally hosted sim can't run scripts.

This opens a whole lot of extra possibilities, though. For example, a "snapshot" of a full sim could be sold as a single asset. Double-click on the asset in your inventory and the sim snapshot is unpacked onto your private server and you teleport there. Instant free backdrops for any social activity you like, with no need to buy land based on their size. This would be a fantastic innovation as it would bring SL into parity with IMVU and Whirled, which already offer this function.

Very few functional sims have no scripts at all. As a private work area that would never be suitable for me, even as a person wanting to host content many ordinary items have scripts of some sort and so again it would not be useful. I think scripts would have to be necessary.
I like the idea of having a loader sim though, but I would want to have it available offline as well, use it locally when you want privacy and on the grid when you want to invite people over.

The SIM server operates as the asset server: it does own the information locally (scripts, objects... the whole rest), these information are "copied" into the asset server when they are retrieved into the inventory or moved outside the SIM to another SIM (derez/rez).
So when you rez something into a SIM, all the object information are retreived from the asset server and copied into the simulator server, so anyone can make a full perm copy of that content (if he has control of the SIM software/source).
The only way to prevent this (apart changing how second life works), is to release a "trusted server" (closed source; that won't connect to the grid if it's not certified), *but* the risk wouldn't be completely eliminated because the hacks would be around the corner.
This is what happens currently, in example, with the game servers connected to the Xbox Live: you have a storage server owned by Microsoft, or you can have your own backend server connected to XBL *but* certified by Microsoft that can access to the network via certified API's.
Whatever they willl decide to do.. it would be a very hard task to protect the asset server contents with a grid interoperability.