DoS/SRO attack suggestion

The issue with SRO DoS attacks SL is that replicating scripts are, by nature, not a bad thing in SL and probably do useful things most of the time. That would be why, I'm guessing, it's allowed at all.

I'm sure straight object duplication/rez/ handoff is pretty easy to trap and has been made impractical. I would imagine it's to the point now where replicating objects and their scripts are being permuted.

My suggestion seems pretty simple to me, which indicates that it's probably already something you've considered and may have been ruled out for some reason I can't see, but here goes:

- A script can rez objects but has an allowance on how many it may create. A quota or tokens, if you will.
- This quota can be whatever the author wants it to be -- even fairly high -- to a reasonable ceiling.
- Creational or other tokens can be handed from a parent to a child object to support functions that have a distinct lifecycle.
- These tokens are bound to an av and can't be systematically created -- once an object is so endowed tokens can only be handed off or discarded.
- This (may be) further tailored by providing some handoff/timing limits that even may be balanced -- minutes/hours vs. generational limits, etc.
- The token idea provides an extra traceability axis, as well, and it may be worth preventing tokens from different av's from comingling in an object, etc.

Of course, having to *manually* endow objects/scripts with execution tokens would be kind of cumbersome and would wreck everything in SL right now.

So, to take this further, treat execution tokens is like prims or tier. I.e., existing scripts run as-is, but when a script starts it deducts an execution token either:

(a) from its parent script if that's been given an explicit allocation or
(b) more likely(if we're talking about an unmodified, current script), directly from the av's budget of tokens or
(c) if a parcel has a pile of tokens the owner's set aside (as I mentioned above) for group activities, etc.

The added bennie would be, like prims, the av has means of tracking where/how their tokens are being consumed, and optionally cleaning them up.

Just another unbidden thought I won't be upset if these are off the mark, however, just trying to help.

Artificial life projects require unlimited replication.

Well, not precisely.

If you want to work an artificial life project, purchase a hoot-load of execution tokens for your av or (if implemented that way) parcel. Even artificial life projects need to bounded, and the approach I suggest is a budget of tokens that are consumed (a) as scripts are executed but (b) are returned to the av/parcel once/if the script completes. In other words, a pool.

So, for example, if you want to run up to 1000 scripts in parallel, purchase 1000 tokens. I'm implying that they're pretty cheap (compared to prims) because they're already so essential. The key there is that they are bounded at all and that this token adds an extra degree of traceability, perhaps even making it easier for an av to locate and control scripts manually.

If a legitimate project maxes out a pool such as that, it probably needs to be re-examined anyway. Naturally, a sim owner ought to have more latitude or some large base of tokens by virtue of owning the hardware (more or less), so concerted efforts like svarga would have an inherent edge.

The remaining issue for artificial life exercises is a fallback strategy if a new script can not be launched from an old one, but that's also a very sensible thing to watch for anyway.

Another variation on this theme are purchased items that are script-laden. Replicating the item and its contents should be as now, but the scripts within execute within the context of the current (new) owner's token pool. There may have to be some extra scripting plumbing to make this work exactly right, but it also could be transparent.