Implementing Experience System

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Implementing Experience System

Haravikk
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
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev



_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev