Remove llGiveInventory

Well the red-wings incident tells us they don't yet have it under control. But yes, you hit it on the head, they *are* trying to get this under control.

The removal of tools that are being abused by a minority results in the dwindling of the very thing that makes SL worth our time. This is a place where we generate the content. As the tools to make that content are limited, the content becomes more limited. SL will never, ever "take over the world" unless we are given the powerful tools we need to create the next great thing.

There are other and better ways of dealing with the few jerks and fools that deliberatly abuse these tools and better ways of dealing with those who accidentally abuse them, or those whove abused them out of some temporary passion.

Your arguments that such limits have been nessesary in other MMORPGs fail here, as SL isn't intended to have a lifetime like those other games are where it's ok to scale tools back since the game will eventually become boring and lose its audience anyway.
The stated goal for SL is to be the platform from which all sorts of things will emerge - games, commerce, communications of all sorts. Again, things that cannot happen if the tools are restricted.

The current restrictions on many of the tools are terribly frustrating. I have many legitimate projects that I've abandoned because these throttlings make them needlessly difficult or outright impossible. The restrictions that can be gotten around only mean extra work - work, I might add, that any greifer can also do, making the restriction nothing more than an annoyance to legitimate users and nothing more.

I do not support the idea of taking away or retarding tools for legitimate users for any reason! I can't fathom why you do.

Thank you Jillian for your thoughtful and intelligent response.

Here's mine:

The reason why the throttling of our tools is so frustrating is because the community isn't given a chance to propose intelligent ways to implement appropiate throttling.

LindenLabs simply has decided that they don't want to engage the community in dealing with these problems and would rather go off into a corner and figure it out for themselves.

I can't blame them - I certainly wouldn't want to be getting into discussions with some of the people on these threads (not you, Jillian) either.

However, even though we're not being engaged, throttling of our capability is going to occur.

It's a fundamental fact of platform design that you need to keep one user from ruining it for the rest, and threat of banishment has never proven to work anywhere.

The solution must be proactive, not reactive. This has been proven time and time again and LL has certainly not indicated they are going to do anything differently.

So the question is not: do we do throttle llGiveInventory? And the question certainly is not: Is LL going to try to solve the problem of llGiveInventory?

The question is: how can we get involved in the solution so that it is done right and not in a way that frustrates our ability as a community to do meaningful things.

Not so. Though the threat fails to have effect, the actuall banning does. In the few places I've participated where the powers that be have the patients to continually re-ban the insistent, they eventually go for easier prey - the communities falure came from other places (like running out of money to run the service).

Where? From where I sit, the proactive solutions that work at all are all on the social side of things. Ethics, mores, and taboo. The failures are the removal of tools from legitimate uses.

We haven't even tried a good social engineering project yet. Diving straight for the limitation of the tools strikes me as draconian.

I'd like to hear from the Lindens directly about the intended limitations - and I'd love to know WHY you'd cut of your noses to spite your faces, if indded that's what is intended?

Actually, I *would* encourage a social engineering approach.

However, I don't think simply threatening to ban people is compelling enough to keep people from misusing tools.

How about a certification process for developers?

Developers need to either journeymen or they need to prove their mettle by test or over time to show that they are qualified to access more powerful capabilities.

This isn't, btw, without precedent. A lot of web service platforms require developers to be certified before they are allowed to call routines which have the capability of costing someone a significant amount of money.

There is another solution here that hasn't been mentioned. And i guarantee it will be a good deterrent. Money. LL has your credit card number. LL is a hosting company. Most hosting companies charge you for the resources you use. So... If you grind the grid to a halt, LL charges you for it. This would very quickly solve the problem of griefing in just about all forms.

Greifer comes in assaults the system, gets charged 1000$ US.

Lets just hope this doesn't come to pass as it isn't a friendly way of doing business.

Perhaps not, but actually banning them does. What's wrong with this solution?

That's not how credit cards work over the internet where you haven't signed anything.

Forcing a chargeback on a small internet company like LindenLabs for a charge like that with no signature would be pretty trivial. It would also likely cause LindenLabs to lose their merchant account privileges.

They could force you to fax in a contract (with driver license / passport picture) that you have to sign before you used certain LSL commands, and they probably could enforce that on your credit card.

Ok lets say some guy from india logs in from a internet cafe with a stolen credit card number. How does banning this guy do anything?

Blaze, I can't possibly see how you can confront the non-virtual world... So many harmful things freely available... I think a better question to ask is why should I be allowed to buy gas for my car when I can fill a bottle with it, stuff a rag in and torch some building?

*shrug* He annoys the grid a little, the Lindens nuke his account. Sure, he can come back with another stolen CC#... he'll just get nuked again. If he gets too persistent (I can't see someone being that determined, but hey, there's all sorts of kooks out there) I imagine they'd temporarily block the IP range. I daresay decent fraud detection is a good thing, too.

Don't get me wrong, I hope Linden Labs does have systems in place to detect run-away self-replicators, because they are obnoxious. From what I've heard others discussing in the thread, they already have at least prototypes of such systems in place. I'd prefer to see the system itself be hardened against abuse, not remove those useful tools of ours that can be misused for abuse.

Jack, such an individual would go to jail, potentially get the death sentence if enough people died and they did it with a certain amount of forethought.

In SL you can pretty much take down the grid, log off, with zero consequences. The analogy does not stand, as far as I can see.

That is absurd. You are suggesting that people stealing credit card numbers are going to bother taking down an interactive database while exposing themselves in the process; and that this is all common place (not the credit card theft but the stuff after it). You have just described a terrorist.

So accentually you are demanding we give up our rights so you can feel more secure against terrorists. I am sorry, I do not feel this way.

As this is even less likely then someone actually trying to take everything down, I do not think this would happen.


I totally agree with what Chris said, i just wish i could have said it that way (as that is the definition of loose the argument i was using).


Anyway if this is where this topic is going then I'm dropping out of it. I knew this was a can of worms when i first posted. I know I can be a bit of a troll at times but I usually don't exhibit this unless provoked. I believe my handling of the situation has been reasonable and my explanations of my actions appropriate. You have driven away one of the loudest voices for a compromise. Good job Mr open discussion.

Hey blaze, guess what, back in 1.1 christopher omega took down half the grid on purpose, and no one even noticed...

Blaze... I (accidently) created some objects with physics which I quickly came to realize were crashing the sim whenever I rezzed them (which is why I don't rez them anymore).

Would you like to cripple physics too, since these objects could be used for mischief in the hands of someone so inclined?

- Ace

We're all missing the real issue here.

The issue is not - is throttling going to happen. It is. You can't give everyone the infinite capability to self-replicate and give pictures / virii loaded objects to everyone in the world.

The issue is - are we, as a community, going to have a say in how SL throttles our capabilities or not?

No, I've just described a typical SL script kiddy:

http://www.dragonscoveherald.com/blog/index.php?p=589#more-589

Fixed that for ya.

Shh fewl, I bet your own of these people that would like all push commands to beremoved to stop push guns.

I want to experiment with replication - in fact that is my main interest in SL. But, being a new scripter here (I have not yet written anything, in fact) although a very experienced RL programmer, I fear I might accidently do something that would cause problems for people, and worse, if it caused LL to restrict the ability to do replication.

How easy is it to accidently cause serious problems? It seem to be too easy, from what I have read, and in fact, you have to go out of your way to avoid problems. This is the opposite of what the system should be doing. It should be that you have to go out of your way to cause problems. If we can do that, then it is more likely that if you cause problems, you are intending to cause problems, and then we have to deal with such people by applying social engineering or legal restrictions/consequences.

There are plenty of examples of coding constraints already built-in to LSL to avoid problems. The question is only which constraints do we want to impose so that it is still possible to do all the interesting, powerful and useful things while avoiding unintended (or intended) problems This is not an easy question to answer, as there are often many possible solutions each with a different set of tradeoffs. E.g. removing llGiveInventory because it can result in massive replication would eliminate the problem but it would also eliminate so much more that we value.

In general, I think the approach to avoiding problems is to look directly at the problem being caused without jumping to conclusions about the cause. It might sound like I am saying we should treat the symptoms and not the cause of the problem, but I am not saying that. I'm saying that in a complex system there are many contributing factors to any outcome, and thus it is incorrect to say that there is one cause.

Self-replicating objects can easily overload sims, but the problem is the overload (resulting in either severe lag or crashing), and not necessarily the replication itself. We could choose to eliminate replication, but I hope we don't. If we allow replication, then we must impose some balance between how much replication is going on and what load the sim can tolerate. And we want to do it in a way that is otherwise unconstrained, to allow all the interesting, powerful, and useful things that replication allows.

Given my limited knowledge of how SL works (I am only 5 days old) I can't offer any specific suggestion about how to constrain replication, but here are a few wild ideas that might be relevant. A throttle on replication could be minimal at first and increase over time, or based on the number of replicated objects in the sim. How does the system know which objects are replicated? Maybe it doesn't have to - maybe it should just track the number of objects owned by a particular player (or group?) regardless of how they were created. (This would deal with problems not related to replication that still cause the same problem of overloading sims.) For each sim, a player might have a different limit on the number of objects they may create, directly or indirectly, and this limit might be not a hard limit but once you reach it, it takes increasingly long to create more objects. There should be a hard upper limit as well but it could be several times larger than the throttle limit and still be safe. As part of this, there should be tools to help people monitor and manage the objects they have created.

Well, that's my thoughts on this matter, so far, but it really is a complex issue. Maybe this should be the start of a new thread that focuses on the solution rather than whether there is a problem. I'm looking forward to reading your comments.

Honestly, script abuse is an endless game of whack-a-mole; remove one means to do something, and commonly people will find another way to do so.

This thread needs to die.

Hmm, if you are responding to my post, then I should clarify a couple things. I wasn't suggesting removing just one means to avoid a problem but a different way of looking at the problem. The problem is really overloaded sims, not specifically replication and certainly not llGiveInventory. A solution that prevents the overloading of sims by constraining the number of objects would avoid a whole class of causes. Rather than whack-a-mole, this would be like nuke-the-moles.

That's not to say that there would not be side effects of any change, or that all problems would be solved. But we would be that much closer to SL bliss.


The argument over whether there is a problem should die, because there certainly is a problem, even if it is infrequent. If it is infrequent, the problem deserves a lower priority (relative to other problems) but I would suggest that ANY problem that crashes sims is very severe anyway, and thus deserves higher priority.

No, it was not a direct response. As for "thread needs to die," the original is three months old and I don't feel simply "remove llGiveInventory" as being the problem.

A simpler solution would be a boolean, such that llGiveInventory and llAllowInventoryDrop cannot exist within the same primitive.

However, that removes several, legitimate uses for this function, which leads to my point - no matter what, people compelled to do so will always look for ways to use the tools available to create a bad time for others. This is better solved by disincenting people to do so and, rarely, by removing the systemic means if it can be isolated. Isolating the problem, and disincentives, are the way to go here.

I have to agree, this thread needs to die. When i saw it back at the top i thought "what troll had the nerve to bring this topic back to life".

If your interested in my opinion you can read it from my previous posts in this thread

Considering that anything of large scale magnitude that disrupted the service could be construed as a crime; thus prosecutable under the law in California. I don't worry.

It wouldn't be difficult to clean up after. Find the key of the object & script and perge them from the asset server, this operation taking maybe 10 -> 15 min tops.

The issue was that replication can cause problems in SL. If you wish to debate that point .. well, this is all I have:

+ Read the secondlife herald where every second or third poster has a way to blow up the entire grid and is getting on SL with stolen credit cards.
+ Study the history of the internet and what replication (eg: viruses and worms) have done to it.
+ Check out the "grey goo" problem that most theoretical scientists are concerned about.
+ Read anything about viruses or cancer in human beings, and pretty much how they operate. It's precisely the same way replication will go out of control in SL.
+ Study any chain reaction in nature, any recursive function in mathematics, and you'll appreciate how the magnitude of simple replication can turn out to be an explosive issue.


If you still think it's not a problem, IM me, and I'll send you my short ten line program that can (and has) replicated into the entire grid.


So, the fact is, it's a problem. What do we do about it?

We can either

+ Wait til SL decides to do something about it
+ We can try to think it through pro-actively and provide them with some intelligent discourse on the various pros and cons of what can be done.

Strife and Jeffrey, to their credit, attempted to do the second thing a little bit.

I think the solutions revolve around:

+ moving across sim borders (strife's idea, which was good)
+ social engineering (only give certain developers access to certain commands)
+ a throttle at the asset server (does every rez go to the asset server? probably not)

I like the idea of moving across Sim Borders the most as it implies unless you own property in the SIM or that's where you rezzed, then your access to the grid at large becomes limited.

It makes sense from a lot of different perspectives.

Also, re-open a thread Zeno. For whatever reason, I don't see it, I have done nothing but attract interpersonal comment after interpersonal comment in this thread.