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 <[email protected]> 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 > [email protected] > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > >
_______________________________________________ Opensim-dev mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
