RLV Plugin API

[Kittin Ninetails]

Proposal

Provide an API for communicating with 3rd party plugin applications. The API should provide for custom messages intended for a plugin but outside the RLV specification. E.g., @plugin=<keyword>|<message>

One suggestion is to provide a TCP port in the Viewer for 3rd Party apps to connect and listen for events. The RRInterface would then write certain or echo all RLV commands to that port, alerting all subscribed apps who then could react accordingly.

This would be a classic Observer pattern: http://en.wikipedia.org/wiki/Observer_pattern.

Examples of use:

RLVibe - My own app that got this idea started. Rather than exposing a HTTP port on the user's PC to receive events, RLVibe could connect directly to the Viewer. Example: @plugin=rlvibe|speed:90

Restriction monitor - Similar to that built into Firestorm and Restrained Love Viewers that show a list of currently active restrictions.

Script debugging - Rather than having chat spammed, a plugin could be designed to enhance management of RLV messages.

Responses from the Plugin

Would these be necessary? Would there be value in them? Status codes or custom messages?

[Marine Kelley]

This is a tough subject... In essence, what you describe is a way for a script to send and receive messages to and from an external software or hardware device, run on or connected to the user's computer (or even on their network), via their RLV which acts as a proxy. In this case, "plugin" would not be an appropriate name, it would make the RLV a gateway, so this issue would be better off called "RLV network gateway".

I'm just throwing out ideas here, but in my opinion it would work like this :

• The RLV connects as a client or as a server, through TCP/IP, to a known IP address + port + password (*)
• Define a set of commands to be sent to and received from the device located at that address
• Tell the script through some kind of @get RLV command which commands are known to that particular device (there could be several devices)
• Script sends a RLV command like @sendcmd_<device_name>:command=force or something like that
• Script receives RLV data through @getdata_<device_name>:data=2222 or something like that
• Script gets notified through @notify:<device_name>=2222 for push-like events coming from the device

Your "RLVibe" example is a good one, this is an USB vibrator that your API connects to, and lets a script control it directly from SL. It works through HTTP, but there are other applications that could require more speed and less delay so I think TCP/IP would be better suited.

This is a very interesting issue. Probably too technical for me to handle, but it's worth discussing and I'm sure someone (probably you, but maybe even me) would come up with a rock-solid design and implementation :)

(*) I am very much aware of the potential vulnerabilities there, and they should be addressed, as well as made clear to the user what risk they would be subjecting themselves to, when allowing their RLV to connect to some external device.

[Former user]

Yes, like with any software, there's definitely the potential for security risk. I am certainly not a security expert, so more discussion about potential risks and how to protect against them would be great. There will always be some risk, I'm sure...which is one reason I chose to make my project opensource.

One thing that could be possible is a ruleset that specifies what commands a 3rd app could use. Like a text file that listed all commands RLV will send/receive to the 3rd party app and ignore anything outside of that list.

3rd party app developers would have to provide the rules to be added to this file. Otherwise, RLV will ignore the 3rd app.

So, for example:

# app name | command | acceptable values in a regex expression
rlvibe | speed | [A-Z0-9][0-9]+

This would mean RLV will only send either a single letter and/or t 0 to 999 for values. It would not be allowed to send 'GG' or 'reboot' or anything else.

[Kittin Ninetails]

Whoops, forgot to sign in before posting that. =^.^=