[sldev] Plugin Archatecture

Kamilion kamilion at gmail.com
Mon Feb 26 00:52:07 PST 2007

Well, apparently, the last time I sent this to the list in January, a
few hours after the viewer was open sourced, nobody was on the list
yet. So here we go a second time.
(Edit: After checking the list archives, it appears my message was
never posted... I think this was because I was trying to be smaert and
subscribed as Kamilion+sldev at gmail.com instead of Kamilion at gmail.com,
and the message was moderated out because I "wasn't" subscribed to the
list. Here's the message again, dated 1/11/2007, 3:42PM.

>> On 1/11/2007 3:42 PM, Kamilion The Great wrote:

It's my feeling that the simplest way to implement a pluggable
architecture in SL and remain agnostic would be to implement three
phased designs...

The first would be clientside; and basically open a local TCP stream
port, netcat/telnet style.
This port would accept LLSD serialized commands to be executed on
behalf of an external application, including such functions as:

#1: Packet interception and routing/rerouting: Register a callback
when certain packet types arrive, or certain caps are active.

#2: Chat interception and transmission on positive and negative
channels: for instance, MYLSLMonitorDump.sh asks SecondLife.exe to
pass a note to the server asking for traffic on channel - 1276384, and
when traffic of this type is received, passed on to the application.

#3: Specific status messages, and sideband control commands:  Console
messages can be redirected, as well as internal status counters and
graphs such as Fast Timers and it's friends. Specific commands could
also be targeted at subsystems, such as flipping DebugSettings (within
reason, we'd likely want to keep a DebugSetting of
AllowLLSDPluginHosts  = as a default)

#4: Inventory Control commands: Enumerating the inventory list,
performing actions on the enumerated list, Item information requests
and item transfer requests. (This data really should be cached most of
the time, and we should just ask if it's changed instead of asking for
the data)

#5: Control level commands: Sending movement and camera commands to
the client. Such a thing would be utilized for many different kinds of
human interfaces, ranging from a P5 data glove to even a wiimote, game
pad or HMD visor head tracker.

That takes care of most of the interfacing.

Now comes the serverside:

Linden Labs needs to start a certification authority; Certificates
should be free and instantly available by going to something like

Certificates can be used for many many things, just like SSL
certificates -- they're basically  bytestamps that can be *revoked*.
Other than that, they're really just unique public keys.

Things this could be used for:

Signing Plugin Aggregation proxies; When a LLSD client connects to
SecondLife.exe, SL should ask for a certificate ID, which it can then
verify as not being revoked, and allow the client aggregation proxy to
connect. Other more specific 'plug ins' can connect to the proxy in
any nessicary protocol (for instance, an aggregation plug in might
connect to SecondLife.exe, and link to the chat and inventory
functions, perform inventory functions internally, and provide
*another* port on 6667 for an IRC client to connect (like bitlbee) to
interface with chat, or XMPP  for a jabber client.)

Signing Scripts -- One or many certificates can be an object type in
SL, like a calling card. This can be 'applied' to a script for
specific functionality... For instance, without the proper level of
certificate, you cannot use llRezObject more than 10 times per minute.
Should you need to perform rezzing faster than this, apply for a
certificate, receive it instantly or provisionally, and apply your
certificate to a script.  If you go out and do harm with it, for
instance, use it to generate grey goo,  then the certificate can be
revoked and the script will be again limited to no more than 10 times
per minute.

Participation certificates:  Let's say I went to SLCC '06. (I did.)
While I was at SLCC '06, I got a badge, which means I had to register
for it. During this registration process, say a linden (we'll use our
favorite Watermelinden in this case...) adds a certificate for someone
who shows up; and now I've got an SLCC '06 participation certificate.

A neat way to show this off would be listing active, expired, and
revoked certificates in the profile, with different color codes.
Finding a scripter with multiple red certificates might be a warning
sign that you'd want to stay away from them.

-- That takes care of authentication.

And the third step -- SCRIPT PRIORITIES & CERTIFICATION (once we have
the Mono VM).

I run a vendor system, which has quite a few servers. I'd like to
apply for a certificate so that my vendor servers would run in my sim
with a raised priority.

Also, I'd also like to apply for a certificate that would allow me to
run scripts with a *dropped* priority, simply by dropping my
certificate on the script. This would be very handy for simple scripts
that I use everywhere, for instance, the lights in my sim that turn on
and off at dawn. They really don't need to have very high priority at
all. It would also be useful for many other things to have dropped
priority such as certain scripts in my vendor for instance (the
advertising display comes to mind)... Now this doesn't necessarily
have to require certificates, but it seems like the easiest way to
agree on and set properties on something securely -- as well as being
extensible in the future if 3rd party servers are ever allowed in the
simulator cloud, while still keeping control in Linden Labs' hands.

This could be extended as well, for instance, "Bob" has an OpenSIM
server he runs on his personal linux server in a datacenter somewhere.
Bob gets a certificate to connect to the simulator cloud. Bob decides
he'd like some money, so he decides to modify his sim to funnel more
money than he's really paid in his personal space.  Well, this is
quite unacceptable, and one of these transfers is noticed! Oh no,
Bob's certificate has just been revoked, and now his simulator cannot
interact with the cloud (or interacts in a more loose way, such as now
disabling monitary transfers in the region entirely, while still
allowing it to connect).  Or, Bob could decide he'd like to write an
automated script to spam people.

Most of this hinges on keeping people honest, while still allowing
full access to the service with a minimum of hassle. It really
shouldn't be too hard to open your web browser at 3:17 in the morning,
surf to secondlife.com, login, and head to certs.secondlife.com to
register for a specific privilege.

The key factor here is the ability to revoke these
certificates/capibilites -- giving people Carte Blanche to work on
their products until they do something wrong.

It also becomes much easier to punish residents for transgressions,
once we have some kind of a courthouse system...

Anyway, that's just my two cents.

-- Kamilion Schnook

This concludes the message that would have been posted a while back
had I not attempted to amuse myself with gmail's filters.... Good
thing I kept the message, eh?

Anyway, A lot of people seem to have had the same ideas as I did; but
I think I might have originated the certificate idea. It goes well in
conjunction with everything -- as long as they're free and easy to
obtain without too much hassle.

Interested to see what responses people have to this, now that it's
actually being read.
(Man, I feel like a goof now.)

-- Kamilion Schnook (Graham Cantin)

More information about the SLDev mailing list