Talk:LSL Protocol/Restrained Love Open Relay Group/key

Should the key be deleted/inactivated after a take over? If not, there is the possibility for the session to be stolen another time, by replaying the message. If it is, then, it should be explicitly said in the spec!

On the other hand, it would be interesting if the session key completely superseded the controller key. Then there would be the possibility for a bunch of controllers to share a session (one being able to change restriction from another, with no real takeover/handover). Of course we would want to add some security so that only authorized device could join the session (combining with !x-channel could help some). Maybe also we would want to make a difference between session key and session password. --Satomi Ahn 00:36, 28 October 2010 (UTC)

The key is not deleted or inactivated after a takeover; if the session was negociated with !x-channel on a private communication channel, the key is private. Of course, after a takeover, the controller can renegociate a new key by sending a new !x-key command: the new key must supersede the old one. --Dahlia Orfan 20:35, 1 November 2010 (UTC)

Version 003

I rewrote some aspects of the specification. LSL_Protocol/Restrained_Love_Open_Relay_Group/key/003_draft

Most notably !x-nopingclear became !x-noping/clear and I added requirements concerning privacy (and llRegionSayTo). Consistently, refrences to !x-channel were removed.

Also I removed the paragraph about !x-email, since I am also modifying this one to be have more consistently with over x-tensions such as key and forward.

I did not understand the paragraph about reseat too... So I removed it :P. In my understanding, resitting has always been the responsibility of the relay.

Any comment?

Yes, your relay does not resit a captured avatar as I had in mind when I wrote this paragraph; my relay does. There is clearly a misunderstanding and I re-add the paragraph.

--Dahlia Orfan 10:51, 9 June 2011 (PDT)

Ah... my relay is actually supposed to resit, but there is a bug right now. The resitting part is in the basic specification.

--Satomi Ahn 12:53, 9 June 2011 (PDT)

I do not know any other relay but mine which resits the captured avatar (so execution of a @sit:uuid=force) after a refresh/relog except mine; so I am very surprised to discover that it is in the basic specification. Are you sure, there is no misunderstanding ? By resit, I do not mean just llOwnerSay("@unsit=add") after a refresh/relog but also llOwnerSay("@sit:uuid=force")... And the uuid key is not necessarily the one of the grabber; test with tkPBA: the relay resits the avatar on the grabber, not on the chair I was before relogging. --Dahlia Orfan 17:16, 9 June 2011 (PDT)

Other topic: ok, I understand that !x-noping and !x-key are to be considered like restricting, in the sense they require authorization from the wearer. But a nuance should be made here. To me there are "transient" and "persistant" restricting commands.

Both transient and persistant would live through till the end of the session, but transient ones would not hold the gate open (keep the session open) if no truly persistant restricting command was also currently living. They would just vanish and close the session after some timeout.

But I digress. This is something we should add to the core requirements. Then I believe !x-noping and !x-key should be transient as they have no use when there is no actual and concrete restriction. This would make of !x-noping the first transient restricting meta-command with a /clear version... Is that fine?

--Satomi Ahn 08:55, 9 June 2011 (PDT)

!x-key is not a restriction; !x-key transmits the UUID key of the session to the relay, and only once; And in my relay, !x-noping is implemented as any restricting command and I do not see the interest to do a so subtle distinction: your idea is just more complicated to program with an additional timer. After all, if the grabber wants to remove the noping restriction, it sends a !x-noping/clear. The command !release also cancels !x-noping...

--Dahlia Orfan 10:51, 9 June 2011 (PDT)