So I know I've already posted a topic (Validating IP and Region) but I wanted
to introduce myself; some may have encountered me in Second Life before as
Haravikk Mistral, which is the same name I'll be using on osgrid and elsewhere.
After one too many fallings out with Lindens and their backwards way of doing
things (and extortionate pricing for simulators, about 20 times more than
they're worth by my estimate) I'm through with Second Life and looking to help
out with OpenSimulator however I can. My interests for now are largely focused
on scripting as that's a big part of what I want to do, but I may branch out
into other areas in future.
To start off with I'm going to be looking for any of the smaller LSL functions
and bugs that I can help with (recommendations welcome, otherwise I'll be
trawling the bug tracker)!
However, one particular area I'm interested in is porting the Second Life
Experience system; I know it's a bigger project, and I don't intend to jump in
for a little while, but I'm curious to know if anyone has done any initial work
or design yet? It's something I've found very handy in SL, but protested
vehemently against due to the premium account requirement, even though I've
always had one, as I hated that new features were being restricted to premium
accounts only; however, this is not an issue that Open Simulator would have.
Anyway, I've been thinking about what it would take to implement, and while
there's a fair bit of work that may be needed, it doesn't seem too complex. All
it should really need is a new grid service for the "experience server", plus
tie-ins for the GUI side in the viewer and of course the nitty gritty of the
unique functions, as well as automatically granted permissions. If no-one is
working on this then I'd like to take a look at doing a preliminary pass of
what exactly is needed, and to work up a design document.
The only real area of difficulty that I can think of initially (and that I'd
love to discuss) is the issue of protecting experience keys. As you may know,
the experience system in SL is predicated on trusting that the keys assigned to
objects remain private; no-mod objects may have a key assigned by the creator
that should never be revealed, while modifiable objects can have an experience
key of your choice added, but in both cases the key will never leave the region
unless you have permission to see it. Now, this is fine for static objects
within a region where you own land, as you presumably already trust that
region, but it becomes more complex when you consider that attachments can also
have experience keys that they will carry around with them.
So far I've thought of two options:
Hope for the Best: Since malicious regions can already potentially do quite a
bit of harm, there's an argument to be made for not worrying about it too much
and just reproducing the SL system as precisely as possible. The issue here is
that once a key is leaked that's it, and trust in an experience is potentially
broken (leading to a risk of the key being revoked, black-listed etc.,
requiring all legitimate devices to obtain a new key).
Disallow Experience Key Travel: This is a bit restrictive, but is the simplest
alternative I can think of. Basically the idea is that the experience key
assigned to an object is locked to the current estate, any attempt to remove
the object from the estate (including by teleporting while wearing it, or
taking it into inventory) will result in a warning that doing so will cause the
key to be removed, leaving you with an experience disabled version of the
device. If you want to reenable it you would then need to re-add the key
yourself, if able, so a bit inconvenient.
Key Aliasing: Instead of one basic key that's at risk, there could be a system
of key "aliasing" used. Basically what this means is that instead of applying
your experience's "root key", an alias is generated and issued, which the
experience server can track internally. The most powerful version of this
system could issue unique alias keys to each estate (or region); when you
attempt to take an experience enabled device to a new estate/region, the
experience server will issue a new alias for the destination. This way, at
worst all that can be stolen is a per-region/estate version of your experience
key, which cannot be applied to objects (as it's not a root key). The tricky
part with this system is handling how keys pass through the GUI; if
communication is always between the viewer and the current region then the
region will still receive a root key whenever you do anything experience
related in the GUI, either that or the GUI would need to work with the current
region's alias (even more complex, but theoretically possible)! Taking an item
into inventory raises some question marks, especially with hyper-grid and
import/export support; it's possible the key could be encrypted somehow, thus
the experience server would give an encrypted alias that only it can decrypt
when the object attempts to resume experience support.
If anyone has any other ideas, or has done any work towards this then I'd love
to hear about it! Like I say, I think it's too early for me to jump in on
something so involved, but because there's a lot to do it's probably a good
idea to start now and begin planning the details ASAP.
I'll be making an appearance on IRC at some point; been a long time since I
used it for anything so will need to pick out a Mac client that I like
(recommendations welcome!) but I'm in the UK and tend to have sporadic
availability, so I tend to prefer mailing lists and forums for this sort of
thing.
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
