[Opensim-dev] Implementing Experience System

[Nicky Perian]

I use https://www.irccloud.com/
It is $5.00 per month and I find it works very well.
No more client searching for me.

On Sat, Jul 22, 2017 at 5:38 PM, Haravikk <opensim at haravikk.me> wrote:

> 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:
>
>
>    1. *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).
>    2. *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.
>    3. *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
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20170723/67320a69/attachment.html>