This year has been especially rough. April saw a huge drop in availability, the worst month we’d had in a long time. June is seeing its own trouble, with downtime or severe stability issues every single day for the last 12 days [as of 6/10/08; source]. March was my all-time best month of sales, but in April my sales dropped to more than 30% below normal levels. I know this wasn’t just my products, but a trend that affected many retailers in SL. April’s availability drop also brought with it a huge number of failed transactions and lost inventory, with frequent warnings from LL to “avoid transactions as necessary” during database trouble. The bottom line: customer confidence is way down, and many customers and retailers are losing money, while LL scrambles to keep the grid afloat.

I have two ideas that could alleviate the situation, which I’ll present below.

About “Suggestions”

I’ve been in SL for almost three and a half years now. I’ve seen my share of rockiness, downtime, failed transactions, miscellaneous brokenness, bugfixes that introduce new bugs, and bugfixes for THOSE bugs introducing MORE bugs, all of which break at least some of my content. I’ve seen a heck of a lot of complaining that LL engineering is incompetent, and I have just one thing to say to that: bullshit. Just go look at the comments on LL’s blog, and you’ll see that it’s very easy to talk about how LL is full of incompetent morons, and if they’d just do X, Y, or Z, then all of our grid problems would go away, and since they’re not, they clearly should all be fired because they don’t have a single functioning neuron among them. Techies are often especially prone to fall into this, because we know just enough to make valid-sounding suggestions, and we can use that to illustrate that obviously LL is made of idiots because they haven’t done what we suggested.

It’s much harder to actually build a virtual world like Second Life, much less make it scale. I’ve always had a lot of respect for LL, simply because they’ve created the world as it stands. I have no doubt in my mind that LL is full of a bunch of incredibly bright, talented, and experienced programmers, because if it wasn’t, then the virtual world as we know it would not exist. So when I see people make ridiculous suggestions (“you should use Clustering^TM!”), I get really frustrated, because there’s a very big chance that either someone in LL has already thought about that and determined it wasn’t feasible, or it doesn’t even apply to the situation, or LL has already been doing it for years. In any case, they’re not stupid, and if someone can think of it within 5 minutes looking from the outside, it’s almost certain that someone at LL already has.

I also know that abusing LL doesn’t make much sense. It’s like whipping a horse when what you really need is ten more. You have to remember that these employees are actual people, and like I said above, they’re also very bright people. Telling them they’re stupid is not only wrong, it’s counterproductive.

With that in mind, I’m not making the suggestions below lightly. If someone in LL has already thought of them, then just take this as a vote in the “for” column. While I’ve become pretty frustrated with the way LL has been run of late, I will not fall into the crowd that rants and screams and calls them stupid. It’s not constructive.

Suggestion #1: Gridwide Transaction Kill-Switch

On to the actual suggestions. The first one stems from that common phrase I’ve learned to dread, “Please refrain from transactions until we give an all-clear.” There are several variations, including the ever-helpful “We’re experiencing database problems, please refrain from transactions as necessary”. How do you know what’s necessary? If your transaction just failed, refrain from it :P

LL makes these recommendations through their blog and in-world announcements. The blog announcements used to be on the main LL blog, but that blog was becoming so clogged with announcements of instability that they created a special Grid Status Reports Blog. In-world announcements take the form of those easy-to-miss blue boxes in the upper right, which often don’t go through during times of grid instability. The people this message needs to reach, the Residents, aren’t getting it.

This is a huge disconnect. On the one side, you’ve got LL Operations, and maybe an Operations Liason(?) who actually posts on the blog. These people know that transactions WILL fail. Their job is to get them going as fast as possible, not to worry about making sure people know they’re not working. On the other side, you’ve got Residents, both customers and retailers, who really need this information. Customers need to know that they shouldn’t buy things or rez their no-copy items, and as a retailer, I’d love to be able to incorporate some kind of automated off-switch in my vendors to prevent transactions during grid instability. In the middle is the SL Support Team, which is getting flooded with angry Residents who demand refunds and whatnot. They (I think) make an announcement or two in-world, mostly to get some of the heat off them, I suspect.

My proposal is that if LL knows transactions will fail, don’t allow them. I’ve outlined my proposal in VWR-4431 on the public JIRA. The idea is that, rather than posting a message somewhere that transactions will fail, instead enforce a blanket ban on sensitive transactions at either the client or server level. Kill-switches like this already exist for the profile Web tab and streaming media, where LL can shut these off grid-wide in case a vulnerability is found in Mozilla Firefox.

This would prevent customers from losing money when their purchases aren’t delivered or losing inventory when they try to rez no-copy items. It would also limit load on the system, which might well aid in fixing the problem. It’s much easier to fix a broken pipe when you turn off the water first.

Most importantly, it would go a long way to restoring customer confidence. Right now, people are afraid to purchase items. Everyone’s experienced inventory loss and failed item deliveries. As evidenced by the huge drop in sales across the market, many people have grown frustrated and simply stopped purchasing. Ultimately, transactions should be made more reliable in and of themselves, but at the very least, with a kill-switch, customers would feel a lot safer.

Suggestion #2: Limit Growth in the Userbase

My second suggestion is a tried and true method of managing growth in online services, first demonstrated (I believe) by LiveJournal. Livejournal’s userbase was growing much faster than its server architecture could handle, so they implemented an invitation system to manage growth while they scaled up the server architecture [LJ’s invitation system]. New users could only join LiveJournal if they received an invitation from an existing user or paid for an account. By limiting the number of invitations users could send, LiveJournal controlled growth. In my opinion, LL could greatly benefit from such a system.

I won’t go so far as to say that LL should not have opened the grid to free accounts, and I definitely don’t feel that the grid should be limited to only Premium accounts. I am a Basic account user. I contribute monthly to the payment for a sim, and I’ve produced and released quite a few open source tools. I know that if it weren’t for Basic accounts, I and a lot of other people who positively contribute to SL would not have joined.

On the other hand, there’s been an explosion of growth in the user base dating back to the announcement of free accounts. SL’s popularity has “tipped”, and while LL has made some pretty huge steps toward scalability, every step seems to be immediately subsumed by the growing numbers of users. Concurrency is on the rise, while avaibility and reliability are decreasing. Something needs to be done.

The best part about this kind of invitation system, as demonstrated spectacularly by Google’s Gmail, is that, rather than curbing the popularity of a service, it can create a furor. Suddenly invitations are a hot commodity. When you tell people they’ll have to wait their turn to get in, they start to realize that they should want to get in. And when you do finally open the floodgates after making the system more robust, users will flood in.

Along with a boost due to exclusivity, sugh a system would improve user satisfaction. Right now, new users join SL in droves, but they also leave in droves. Retention is low. Users who join during the current instability might well get frustrated and turn around, and all they’ll remember of SL is that it’s unstable, unreliable, frustrating, and possibly even a waste of their money. It will be a long time before they’re willing to give it another try. On the other hand, with an invitation system, they’ll learn about SL, decide to give it a chance, and get turned away at the door. They might be a little upset, but these users won’t wait nearly as long before they try to join again. And when they do get in, the system will be much more robust and stable, so they’re much more likely to be satisfied. LL would have less signups, but they’d retain more users.

We’d also have another side bonus: less throwaway griefer accounts. The need to pay or get an invitation code to join will deter some of the casual griefers from creating throwaway accounts. Careful alotment of invitation codes will make it hard for griefers to create accounts to “farm” invitations. Throwaway accounts won’t be completely eliminated, but they might well be significantly reduced. Griefing might be reduced as well, since there’s more of a consequence for getting caught.

I hate to use a buzz-word here, but an invitation system would be a “win-win” proposition. LL would buy time to grow their architecture at a reasonable pace, and in the process, they’d get greater stability, higher user retention, and a sense of exclusivity, with even the possibility of reducing griefing. Invitation systems are a well-tested method of controlling growth in order to scale gracefully, and that’s something SL desperately needs.

[I recently suggested these ideas to Torley Linden during an office hour, and Torley seemed interested and was going to forward my suggestions to other Lindens. I posted this here to try to draw more attention from Lindens and Residents.]

There’s now a proof of concept that this vulnerability can be used to take over your SL viewer and make it do whatever an attacker wants, such as sending them your L$.

http://www.securityevaluators.com/sl/

Just to avoid being alarmist:

• There is no evidence that evil people have done this yet.
• You MUST be on land owned or controlled by the attacker for them to get you.
• You can disable quicktime and completely remove the possibility that you’ll be attacked.
• Playing a video on land owned by a friend you trust is not going to leave you vulnerable.

So no running around and screaming. But on the other hand, this is more serious than LL’s blog post makes it seem. This vulnerability CAN let attackers gain complete control over your system, and working exploits for the QuickTime vulnerability itself can be found on the web. LL has said that they’ll be active in investigating any reports of the actual use of this vulnerability in SL, but that might not be enough. What if someone uses their control over your system to “open source” all of your products, distributing them for free?

I’ve sent an email to LL urging that they hit their big quicktime offswitch, despite what I know this would mean for several of the projects I’ve worked on in SL. In the mean time, I urge you to disable quicktime in SL, or at the very least follow these steps to disable RTSP (the vulnerable part of quicktime):

1. Start Quicktime.
2. Edit -> Preferences -> Quicktime Preferences
3. File Types tab
4. Expand “Streaming – Streaming movies”
5. Uncheck “RTSP stream descriptor”.

It’s very likely that this will completely mitigate the vulnerability. However, I’ve seen a littel conflicting evidence on this front, so, since I have so much at risk with my products in SL, I’ve decided to go the paranoid route and only enable quicktime in SL when I completely trust the owner of the parcel I’m on.

Again, I don’t want to incite panic here, but I think knowledge about the possibilities opened up by these kinds of vulnerabilities is critical to making an informed choice.

For those new to the game, JIRA is a product by Atlassian that helps software developers keep track of a monstrously huge pile of bug reports and feature requests. It helps organize issues in relation to each other so that the huge pile of information can be presented in an intelligible manner.

Linden Lab has used JIRA internally for a long time, and this year, with the advent of their open source client, they opened a new instance of JIRA to the SL public, called the “Public JIRA” or “PJIRA”. It’s for us in the community to track issues that affect SL, provide technical information, and help fellow residents by providing more information on the bugs they report. It’s a HUGE step forward in allowing the community to communicate with LL, and I really want to see it succeed. Before this, all we had was the Bug Report black box, and we had no idea if LL had even read what we reported.

Drama Ensues

There are two points to making the JIRA public: to allow communication between LL and residents about bugs to be public, and to allow residents to collaborate on bug reports, thereby enriching them. It’s that latter that causes the most drama.

Here’s what happened:

• Prokofy Neva reported VWR-3071.
• I commented on the report, giving my opinions on the matter.
• Separately from that, I also resolved the issue as per LL’s Issue Posting Guidelines, pointing out that the issue should be reclassified as a feature request.
• Prokofy went nuts because I “unilaterally closed” his issue. He reopened it.
• Prokofy opened MISC-799, a thinly veiled attack on my action in the guise of a request not to allow me or others to ever modify Prokofy’s issues.
• I pointed out the link to VWR-3071, and also moved the issue to its proper classification, WEB-382, since it was an issue about jira.secondlife.com.
• Drama ensued.
• I did my best to provide justification for my actions, and then I ducked out of the thread because I’ve learned in the past that it’s just not possible to out-talk Prokofy.
• The issue was addressed in the 2007/11/19 Bug triage. See transcript, starting around [12:15].
• That leads us up to now: The Lindens have decided to ask Prokofy for examples of abuses in JIRA that have caused problems; read this, this, and this if you’re interested in those examples.

Collaborative Editing and Accountability

My strongest feeling through all of this is frustration with Prokofy’s notion of “unilateral action”. He seems to feel that my “closing” of VWR-3071 constituted a unilateral decision to silence his speech, which it wasn’t. The Issue Posting Guidelines make it pretty clear that “resolving” an issue, especially for resolutions like “Needs More Information” is to be taken as a direct request that the author take more action and then reopen the issue if appropriate. In my comment at the time I resolved VWR-3071, I even gave an example of what Prokofy could do to fix the issue, which is considered good practice.

The thing is, even if I was wrong, the right thing to do would be to reverse my action. Simply reopen the issue and no harm’s done. I’m perfectly willing to hear that I’ve done something wrong, or that the rest of the community doesn’t agree with what I’ve done. If we had to run around getting votes from everyone in the community or approval of the reporter of an issue before the issue could be modified, then we’d never get anything done. On the other hand, if we leave things open, but keep track of everything everyone does, there’s a strong incentive to make sure that you’re NOT acting with impunity, because doing so will only result in your changes being reverted and your reputation suffering.

That’s the key here: this JIRA, like Wikipedia and many other collaborate projects, work on a theory that many people, working loosely and with little organization, can together shape something that’s bigger and better than anyone can do on their own. LL is simply too small a company to individually police the flood of JIRA issues (many of them inappropriate or filed in the wrong place) and shape it into a useful body of information. There’s just too much information for any one person to handle. We could try to elect a “president” of JIRA who we all were happy with and trusted to manage all issues, but the result would be unsatisfying. It’d be impossible to find such a “president” that everyone would be happy with, and even if we did, there’s just WAY too much information for one person to handle. The fact is that one vision can’t succeed.

Democracy can’t, either. We can’t make JIRA democratic, for the reason I stated above: we’d tie our own wrists. There’s just too much to be done, and voting takes too long. Nothing would ever get done. JIRA would topple in a mess of beauracracy.

The solution we’re trying now is collaboration. It’s just like how ants work: scientists are pretty clear on the fact that no one ant has any concept of the structure of the anthill as a whole, not even the queen. Instead, they have basic rules about how they’re supposed to act, and the result of getting a lot of ants together following those rules is that an anthill is created. Scientists would say the anthill “emerges”.

The idea is that we all do a little work here and there, making changes as we see fit, in order to move JIRA as a whole one small increment toward greatness. What about rogue elements? Well, just like in the body, where cancer cells are eliminated on a regular basis, rogue elements in JIRA are quickly subverted by the will of the community as a whole. I could run around closing issues I don’t like, and 20 other JIRA users will run around just behind me, reopening them and building a consensus that I’m being a jerk. Pretty soon I’ll find myself kicked out of the pool. It’s a pretty good system.

The problem is that Prokofy doesn’t agree with the community that runs JIRA, as a whole. He has said over and over that JIRA is frequented by a “cabal” of users that think we speak for the community as a whole, when in fact we’re just speaking for our own bloc. While I feel that JIRA is egalitarian because any SL user can wander over and make changes as they see fit, Prokofy feels that we regular users (“lifers”) occupy a privileged place in the SL community because of the time we devote to JIRA. His feeling is that, by spending hours a day on JIRA, we see our opinions gain an unfair weight because we’re exercising them so often. And he also seems to feel that only a certain kind of person (ie the “techie crowd”) will spend this much time in JIRA, so only a certain kind of opinion will shape JIRA. It’s like a voting bloc. [Note: Prokofy, if I’ve unfairly stated your opinion here, let me know.]

It’s a fair criticism, and I admit that it’s a possibility in a system like this. However, I don’t think it applies in this case. Generally, I try to act in as unbiased a manner as possible, and give reasons and suggested actions when I change or resolve an issue. When I’m not sure I should make a given action, I propose it in a comment rather than doing it immediatley. I haven’t done these things enough in the past, and I’m going to do them more in the future in hopes that I can avoid the kind of drama we’re seeing now. I also don’t think the users of JIRA are exercising any kind of groupthink. There are widely disparate elements that are frequently seen in JIRA, and these people regularly face me head-on and disagree with me. I appreciate it. It helps me do a better job in the future. Thanks, Mercia McMahon!

While I agree that Prokofy’s theory is a possibility, I don’t think that merely stating the fact makes it true. It’s fairly clear to me that Prokofy likes to build up theories of secret cabals of people that are out to influence Second Life to their own selfish ends while ignoring the good of the community as a whole. I don’t think such cabals really exist; rather, Prokofy has a hard time understanding that what is obviously correct to him may not be how everyone else feels. He builds theories of secret cabals to explain why people act the way they do, rather than understand that maybe what he takes to be a fact is just his opinion.

There’s just one way that the JIRA system does filter who uses it, and that’s the interface. This is a tough problem. The fact is that there are many issue trackers out there, and that the vast majority of them just aren’t up to the task of organizing such a vast body of knowledge as that seen in LL’s PJIRA. The JIRA tool helps us perform critically important tasks such as linking issues together as related or as duplicate issues, searching for and categorizing issues based on myriad criteria, and facilitating voting and discussion. I’ve used a lot of issue trackers in the past, and JIRA is hands down the best tool for the job. Without it, we’d spend way more time trying to organize information, and way less time actually doing useful work on concrete issues. In short, without JIRA, we’d waste a ton of time.

On the other hand, JIRA is, by its nature, geared toward technical users. It works GREAT for us. It’s designed by technical people, for technical people. It does exactly what we want in a way that makes sense to us. The problem is that this runs straight up into the first principle of User Interface design that I learned in college: “You are not normal”. In short, when designing a user interface, what the programmer likes is very likely not to make a bit of sense for non-programmers. This explains why a vast majority of computer interfaces are still horrible for most users, and why computers are hard to use for many people.

So the problem is that the JIRA interface itself acts as a filter on who can use it. This sucks, because it’s such a useful tool otherwise. Where Prokofy and I disagree is in what should be done about this. He thinks that everyone should be limited from using PJIRA so that the playing field is levelled. I think that LL should do a ton more work to simplify the interface presented to PJIRA users so that they are better able to participate. Prokofy’s method means that we lose all of the progress we’ve gained so far. Mine means that we keep all of our current progress and gain much more from all of the new users with different backgrounds.

Until then, it’s up to us who easily understand JIRA to reach out to those in the community. Provide links to important issues in forums outside of JIRA. Explain to people that logging in and voting is important, and commenting is useful as well. INCLUDE people. Remember that you are not normal.

That said, I hope that the rest of the community realizes that I’m not some kind of tech-minded automaton. I’m highly technical, but I’m also very concerned about social and economic issues in SL. I make my entire living in SL. It’s in my interests not to bury economic issues in JIRA. And I don’t spend my life in JIRA. I spend about 20-40 minutes on average per day, and I do it because I like to keep track of new issues in JIRA that might affect my business and my job. I clean things up while I’m there because it’s a little bit that I can do to help out. I definitely don’t have hours a day to spend on this stuff.

Open Letter

Well, I just said way more than I thought I was going to say. The problem with Prokofy and me is that we both have very forceful personalities, and we both type a heck of a lot. I’m the kind of person that wants to call people on their bullshit, and won’t back down just because someone else says really hard that they’re right. Going head to head would be a scary thing, because Prokofy and I would probably never stop talking. We both care a heck of a lot about SL. I’m doing my best to avoid getting in an outright flamewar with him, because I know no one will win. I feel a deep need to counter and address many of the thing he’s said, so I’m using my blog as an outlet.

I also wrote to Rob Lanphier (head of open source stuff at LL and, I believe, a fairly major authority on PJIRA) in response to the discussion during the bug triage. I ended up saying a lot of things that were on my mind, and I think this stuff might be interesting to the rest of the community outside of LL, so in parting, I’ll leave you with what I wrote:

Rob,

I just had a chance to check the transcript of the latest bug triage for the discussion about WEB-382 (Prokofy’s crusade). I can’t help but feel a little responsible for Prokofy’s tirade because it was my action in VWR-3071 that set him off, but I suppose it would have happened eventually the moment anyone touched one of his issues.

I’m sorry that I wasn’t able to make it to that triage, and that I generally am not able to devote the time to triages and email lists. I spend 20-40 minutes a day checking JIRA, just to keep up on the latest bugs affecting the grid, and I clean up while I’m at it. I think that even that contribution is pretty helpful, because between us “JIRA cleaners”, we sweep out a lot of cruft. BUT, if I’m doing anything wrong, making any unilateral actions I shouldn’t, I want to know, and I’ll be glad to change or stop what I’m doing. I’m just trying to contribute to making JIRA actually useful.

In regards to the triage, one of the suggestions was to limit closing/resolving issues to people deputized by LL (probably “good-citizens”). It looks like this proposal was tabled, but just in case, I want to put in my two cents. I really don’t think you should do that. As someone pointed out, ANYONE deputized by LL will not satisfy Prokofy, and he will see it as a list of people to villify and as evidence of his “secret cabal” of people ruining SL. It won’t help at all.

As to the actual issue at hand (whether open issue modification rights cause abuse), I haven’t seen any abuse or improper actions in JIRA that were not quickly reversed. Sometimes an action is reversed by the original reporter, but often enough someone else in the community does it. Actual abuses that need to be reverted are very rare, and I’ve NEVER seen an unchecked “revert war” where two people argued by repeatedly undoing and redoing each other’s actions. It just hasn’t happened.

Prokofy seems not to understand what JIRA is for. I see it as a tool to help the community speak with a voice that’s actually useful to LL with regard to what bugs exist in the world. There’re so many that it’s just not as obvious as someone like Prokofy thinks it is to list them all, much less fix them all.

Prokofy seems to want to use JIRA as a weapon to force LL to change to suit his whims, or at least to use as ammunition in his never-ending battle against LL. He seems to want to be able to report an issue and keep it open even if LL doesn’t agree with it, so that he can say “Look, the Lindens aren’t listening to Us!” This is not to say that I think LL always listens perfectly to what the community says, or that I’m an unswaying “LL fangirl”; I’m just of the opinion that JIRA is not a good forum for this kind of thing. It’s not a soap-box. It’s not a wall outside at LL HQ where we can paste our grievances so that the world can see how horrible LL is. It’s for providing LL useful information, not for ranting.

The Triage decision was to ask Prokofy to provide examples of issues in which “unilateral” action caused damage. My action in VWR-3071, of course, is one of those examples, and while I think what I did was defensible, I’m certainly willing to listen to the fact that I may have acted incorrectly.

However, most of Prokofy’s other current examples were either resolved by a Linden or by the issue reporter. It seems that he doesn’t want to allow even Lindens to close issues. He doesn’t trust any Lindens at all. With that in mind, I don’t think JIRA’s going to be particularly useful to him at all.

With all of this said, I think there’s one useful change that should come out of this. It should be made much more clear what LL’s policy on JIRA is. I’ve had plenty of situations where I acted according to the JIRA usage guidelines and people were upset because “some random person not approved by Linden Lab is changing my issue”. I think it needs to be made much more clear what LL wants people to do, what their recourse should be when they feel someone acted inappropriately on JIRA (and reverting the change doesn’t settle the conflict).

More specific to VWR-3071, I think there should be a much more clear definition of whether an issue should be a bug report or a feature request. My feeling is that the definition should be something like, “a bug is when the system does not function as designed”, whereas “a feature request is when the system works as designed, but you want the design changed”. Also, it should be made clear where policy change requests go, if they belong in JIRA at all. Furthermore, Prokofy’s main problem with my action was that I “closed” his issue and am therefore an tyrant. The JIRA policy guidelines already say that a resolution is NOT the same as closing an issue, but this needs to be made much more clear.

Finally, I think the priorities should be more clearly spelled out, with distinct examples of types of issues that belong in each category, and perhaps with concrete examples of properly-prioritized issues. That, or we should completely do away with the priority system. So many people become personally upset when their issue, which drastically impacts their ability to play SL (but no one else’s) is reduced from “Showstopper” to “Normal”. If I’m the one that makes that change, they feel like I’m telling them their issue isn’t important. I’d love it if I could direct them to a more comprehensive explanation of issue priorities than already exists. And while I’m on the subject, I think that the explanation of priorities needs to also include descriptions of priorities for Feature Request proposals, because the current priority descriptions don’t apply very well to feature requests.

Talarus Luan wrote:

A lot of times, verbal abuse comes as a result of lack of communication. I’ve seen it before; lived it, even.

Basically, as a customer, when you ask nicely 100 times and get ignored, then switch tactics on the 101st time, and things start happening, you tend to stick with what works. As such, it is as much the Lindens’ fault as anyone’s for not having effective and consistent communication channels set up with the customer base. It is true with every other business in the world; why do game development (and, more generally, software development) companies think they can get away with it?

They need someone to communicate, and not just delegate communication to the lunchroom announcement board. Communication is a two-way street. They need to listen and respond to what they are hearing, directly. I would estimate that a large percentage of churn is a direct result of the lackadaisical communications policy that they have fully embraced in the last year.

I don’t think you can entirely pin this on the Lindens’ difficulties with communication. For one thing, you have to remember just how many residents there are, and how few lindens there are. If they really spent the time to read and acknowledge the huge body of text that’s directed their way in the forums, the blog, and on various blogs throughout the web, they wouldn’t have time to actually implement anything. Don’t get me wrong, I think maybe they could be doing a little better than they are now, but I’m realistic and know that they can’t have perfect one-on-one communication with everyone.

I think that a lot of the time, customers have unrealistic expectations about communication with a company, and customers of LL are no exception. Especially in my country (the US), it seems like people who are buying a service or product automatically feel like the company is evil and they have to fight tooth and nail to get heard. People seem to feel the need to go in swinging to get any kind of attention. Ask any customer service representative and you’ll know that no matter how reasonable you are, customers will always come in and be incredibly rude, when soft, persistent tones would be just as effective if not more.

We see that in these forums every single day. Customers come in here and scream their heads off, berating LL and telling them how horrible their service is (and yet, more often than not, not choosing to end their business relationship with LL). There seems to be a feeling that LL is completely ignoring us, which is not true. There’s an unrealistic expectation that every single thing we say or suggest, constructive or not, must be read and responded to by LL, no matter which dark corner of the forums we speak it in, and no matter how unclear and unconstructive our comments are.

It’s not constructive or efficient for LL to personally address everything we say about/toward them. It’s not even possible: for every single suggestion made, at least one other person will be vehemently opposed. For every feature that LL implements that a large part of the community celebrates as having been a long time coming, at least a handful of people will come out rabidly against it. It happens every single time. If LL listened to everyone’s feelings all of the time, they would be frozen in indecision and unable to take any action whatsoever.

Simply put, I’m saying that it’s never okay to be belligerent, rude, obnoxious, loud, and personally abusive in the course of business. We must never forget that we’re dealing with real, normal, everyday people when we do that. Most of the time, when a customer is belligerent, they’re being rude to someone who wasn’t really responsible for the decision that made them mad, and maybe can’t do much about it. Shouting at someone just makes them feel horrible inside, and hardens them against customers, which is exactly what we don’t want to have happen. If you wouldn’t treat your neighbor that way, you shouldn’t treat an employee of a company you’re doing business that way.

And if that means that you can’t manage to get your way, even with as much persistence, patience, and compassion for the people you speak to as you can bear, then it’s time to reconsider what you’re doing. It’s not worth making someone go home and feel horrible for the rest of the day just so that you can get your way. If the company is truly so horrible that you feel you need to scream at them to get what you want, then it’s not worth doing business with them. If it still is worth it to you to continue doing business with them, then you need to be calm and reasonable. In the case of LL, maybe it’s time to email Philip Linden. I’ve done it, and I even got a personal response.

This just underlines the need for a trust metric in Second Life. If someone decides to release a client, I need to know that I can trust them. How do I know their client won’t steal my password and tell it to them so that they can run in and wipe my account of Lindens? How do I know their code won’t make a mess out of my computer? How do I know their code won’t inadvertently make me do something that LL’s servers consider griefing? What if their code stole all of my content and sent a copy to them?

Of course, any client that’s developed and released by a third party, due to LL’s licensing, must be open-sourced itself. However, that’s not necessarily enough to make it Safe. That code would still need to be vetted by the community to ensure that there aren’t any hidden trojans that do nasty things when you run the client. I don’t know about you, but I don’t have either the time or the energy to vette a third-party SL client’s code before I run it. I know other people are like me in that respect, and that means that a malicious programmer could release a trojan SL client and do some damage before the community caught on.

So, for now I won’t be running any client that’s not released by Linden Lab, because I have no way of knowing if I can trust the person releasing it. If we had a system like the Reputation System I proposed previously, then it would be much easier for me to make a quick and yet confident decision about whether to trust a client written by a third party. I simply need to check their Reputation Score, and think about how badly they would be affected if their reputation were tarnished. In the case of a big name in SL, someone who’s been around in the community for a long time, it’s pretty likely that they wouldn’t risk ruining their reputation by releasing malicious code in the form of a trojan SL client, because they would, essentially, lose the use of their entire SL identity in the process.

It’s worth reading, though. If I’m right, you can use this article as a blueprint to design and build a Reputation system that could make SL a much better place to live. It might even make you rich. All I want to do is get this idea out of my head and into yours, so that I can have the benefit of its ultimate implementation (or find out why it’s doomed to failure). So sit back, grab a beverage, and dig in.

The Problem

Virtual worlds, especially Second Life, have a fundamental problem: people can be jerks. People can do a surprising amount of things to cause problems, and while technical solutions exist to solve these problems (such as banning), there’s usually a fairly trivial way to get around them and cause more trouble, if one is sufficiently motivated. The real problem is anonymity: the Internet lends you a fair amount of anonymity, so you have less stake in your identity, which means that there are far less reasons to be a good person.

There are plenty of technical solutions to the problem of jerks (aka griefers) in SL. Some of them are fairly effective against certain kinds of grief, and some are spectacularly ineffective and just make your tormentors laugh. Some nasty things people can do have no technical solution, such as using CopyBot-like tools to circumvent your IP rights. Some people are angry enough to continue to find ways around the technical solutions in order to do things like bomb the grid with grey goo.

Other, more subtle problems arise when we start talking about the Big Thing techies are touting in SL: Open Sourcing the platform. There are several meanings for “Open Source SL”, but the one I’m most interested in right now is the feature lots of people are clamoring for: user-run Simulators. In short, people are getting fed up with LL’s servers, and they want to run their simulator on their own computer hardware so that they’re in charge.

The problem with this is less in terms of how technically feasible it is, and more in terms of what to do about the intellectual property that makes the SL world what it is. Simply put, if you bring your content to a simulator run on my server, I can copy anything you’re wearing and anything you’re rezzing, scripts included. This is much more severe than the kind of copying that is currently possible with CopyBot. As long as all servers remain in LL’s control, they’re the ones that control the data flow, and therefor they can enforce some degree of IP rights, in the form of the permissions system. Allowing me to run my own server is tantamount to tossing the permissions system out the window — and, in theory, no amount of encryption can possibly remedy this.

Ultimately, the problem is about consequences. The Internet allows us an unprecedented amount of freedom to do whatever we want, and the aforementioned anonymity makes it very difficult for others to enforce any kind of rules. In Second Life, we have the Abuse Report function, which everyone knows is currently almost completely non-operational (including Linden Lab themselves). We can ban people, but, with free accounts provided to anyone with no real-world information required, there’s nothing to stop a jerk from grabbing another account and hopping around your ban within 5 minutes. They can also, with a little work, get around being completely banished from the game by LL… and LL is hard pressed to fight this.

Many argue that the solution is simply to reinstate the credit card requirement, but remember: the advent of free registration has opened the doors of SL to many awesome people in countries outside of the US that simply couldn’t get in before. These Residents have already made huge contributions to the overall good of the SL community, but they do so quietly, while the tiny percentage of jerks cause their problems loudly. Close the doors, and you throw out the baby with the bathwater, and worse yet, I would argue that you won’t actually make any efffective progress in solving griefing at all.

In the wake of the CopyBot miniscandal (which was what got me thinking about this), people started to realize that there really wasn’t much they could do to enforce even real-world laws in Second Life. Abuse reporting is horrendously slow. You can file a DMCA request, but you have to prove ownership of your intellectual property, and you have to provide your real-world identity. The problem is that laws governing cybercrimes are largely untested, and the Internet moves incredibly quickly. Before you can say “preliminary injunction”, your prize product is in the hands of every dork on the grid at a rate of a $1L apiece. Suing takes a lot of time and resources, and there’s very little guarantee that you’ll actually get any benefit from it, assuming you can even find the real name of the person who’s violating your IP rights. In most cases, there’s not a damn thing you can do, and therefore there are no real consequences for bad behavior.

What I propose is a system that provides consequences. We need a system that can react swiftly and sufficiently to injustice, because the existing options available to the griefed are woefully inadequate in both areas. The system must be accurate, flexible, and widely used. In my opinion, it should be resident-run: LL is too busy trying to keep their grid running to deal with all of the jerks running around in it. Plus, there might even be a possibility for profit.
So, without further introduction, here it is: my proposal for a resident-run Reputation system to help combat grief in SL. I’ll start off describing it in the easiest way possible, with a series of examples of interaction with the system.

Case Study 1: Let Me In Your Club

I want to go to a Prestigious Club, but when I get to the door, I find out that they’re using Reputation Service™. They won’t let me in since I’m not registered, and therefore I have no reputation. I sign up, and I discover that half of my friends are already in the Reputation system, so I ask them to give me some positive votes, upping my trust score. It’s a little boost, but it’s not enough to get into the Club yet.

So I go about my business, being a fine, upstanding member of the community. I open source a useful script tool, or release freebie, and my users provide positive feedback. I behave well on people’s land. My popularity grows. Soon, I can get into the Prestigious Club. And you know I probably won’t act like a twit like I’m there; I’ve spent awhile earning this trust.

Case Study 2: Bad Neighbor

I go back home and find that someone moved into the plot next door. They saw my nice, home-made textures on my buildings, and they helped themselves with GLIntercept.

I’m angry, so I go and post a negative review on their Reputation page. I’m fairly trusted at this point, so my opinion is taken seriously, but how do we know that I’m not slandering someone? Well, the feedback goes on their profile for all to see, with my name attached to my comment. By itself, my one comment won’t make a big difference in my neighbor’s Reputation Score, but others can vote on what I’ve said. Some voters will have high trust values, and some low, and their opinions will be factored accordingly. The more my peers agree with me, the more we’ll impact my neighbor’s Reputation score: safety in numbers.

Case Study 3: Slander

Here’s where it gets interesting. say, for the sake of argument, that my neighbor is falsely accused. Seeing my negative feedback, she talks to her friends, posts on her blog, and explains what happens to convince people of her side of the story. They come vote on my feedback, indicating a lack of confidence in what I’ve said about my neighbor. Soon, the dissenting votes outweigh the assents, possibly to a huge degree if this becomes a big issue in the community. My neighbor’s trust is no longer affected by my feedback. Not only that, but now I find myself on the wrong side of a big crowd of people. My reputation score falls.

Conversely, if they did agree with me, my trust would increase. I heldd an opinion that many otehrs agreed with: my neighbor is scum. My neighbor’s trust decreases, and mine increases, because I brought the issue to others’ attention, and a large group of people agreed with me. I get a boost corresponding to the trust levels of the people who agreed with me.

Case 4: Safety in Numbers

Following this out, each of the “yes” voters gets a boost from being in a group that shares their opinion. If you vote to agree with me that my neighbor is scum, and 100 people also vote to agree with me, then clearly you and they share something in common. You share an opinion, and therefore you trust each other in some way. There is an incentive to come weigh in on an issue and there may be those who are willing to stake their immense reputations on the issues most important to the community. A trust market forms.

On the other hand, if you vote “no”, and there are a large number of people who voted “yes” and only a small group that voted “no” with you, your Reputation decreases. The community as a whole doesn’t share your opinion, and so, on this issue, they trust you less. This means that there are both positive and negative potential consequences to your votes. When you weigh in on an issue, you’re staking your reputation on what you say.

People can always post an explanation of any vote they make. Maybe I disagree with the reasons you voted a particular way on an issue. Say you see a landslide decision on a popular issue that’s topping the Reputation Charts, and so you vote with the crowd just to sponge off their trust and ride the wave. Largely diluted votes like this should be worth less, and especially so if you don’t bother to provide an explanation for your vote. If you can’t make it clear that you’re not just there to sponge off other people’s trust, I can make a negative vote about your vote. Suddenly, your vote and my criticism of it hits your Reputation Profile, and the whole process starts anew, and now you’re the one facing the court of public opinions.

What your reputation does

So how do we use this? For a fee, I can subscribe to the Reputation Service. I get a scritped device that managages my land ban list for me. When new people arrive, it checks their Reputation Score against a limit I’ve set. If a guest doesn’t meet my minimum cutoff, they are gently shown the door, and told to come back when their Reputation Score increases.

In short, I’m paying for the service of finding out who’s good and who’s bad. The Reputation Service’s own reputation depends on the accuracy of their judgements and the quality of advice they give.

Say the Service lets a griefer in. I’m angry, so I tell it that it let a griefer in and I’m not happy. Maybe it rasies my minimum Reputation Score threshold on my land. I also lodge a negative vote on the griefer’s reputation, or vote on one if someone else has beaten me to it. Additionally, the reputation of the Service as a whole can go down… especially if I go tell Reputation Service B that Reputation Service A keeps letting a ton of griefers into my land. Competition forms.

Case 5: Privately Run Simulators

Reputation screening goes the other way, too. Let’s go back to the case of opening the Second Life Grid to allow any person to run a sim on their own server. If Fred’s running his own Simulator, he needs to uphold his reputation, or no one will visit. If he’s evil, he may get a chance to steal 3 people’s things, but very soon, the community will catch on, rumors will spread, and in the blink of an eye, Fred’s trust level will plummet. Suddenly, no one will visit his Simulator. Worse yet, he’ll find that there’s nothing he can really do with the small amount of content he’s managed to steal. People will think twice before buying from someone that nobody trusts.

I value my avatar, so I’ll install the Reputation plugin in my SL client (here’s where we might need LL’s help). Beofre I connect to a Simulator run by a third party, my client will stop and check the Reputation Service to find out the score of the person running the Simulator. If the owner’s Reputatoin Score is too low, I’ll strip down and wear a default “Ruth” avatar before entering… if I enter at all. I’m going to get rid of all my nifty content, and only bring in content that I don’t care about, because, for all I know, anything I bring in might be stolen. The same goes for Clubs and other areas of the Second Life Grid: I’m not going somewhere if the owner has a poor reputation due to failing to keep out griefers.

Pretty soon, the Reputation “Market” becomes important. Everyone watches Reputation Scores, and if you don’t, your reputation may suffer, and you’ll find you can’t really do anything in SL.

What About Newbies?

Then again, what about new people? We want people to be able to join the community and participate, but we also need to deal with the problem of Unverified Alt Accounts, that is, throw-away accounts created for the purpose of acquiring a “clean slate”. New people should be given a relatively low Reputation Score, although perhaps not rock-bottom. We can give them a little bit of rope here… after all, if they’re bad, their reputation score will very quickly plummet to reflect that.

It should be possible to jump-start your reputation, so that the barriers to entering the community are not to arduous. Currently in Second Life, one rudimentary way of increating your reputation as a new player is to provide LL with some real-world billing information. You could, instead, provide some information to the Reputation Service. You can trust them with your info — after all, their entire business is trust. If confidence in the Reputation Service falters, then everyone will jump ship, and their business will fail.

Providing real-world information gives a baseline assurance that you won’t do anything grossly illegal. If you do, your information can be subpoenaed from the Reputation Service by a real-world court. So, you convince the Reputation Service that your information is legit, through whatever means they deem necessary, and they agree to say you did so, giving your reputation score a boost. The Reputation Service is making a statement about you, and so is staking its reputation on you, and therefore you’re borrowing from the Service’s reputation. It wouldn’t be unreasonable for the Service to charge a small fee for this service.

You can also ask people for sponsorship. If your friend is already in the system, they can give you a positive review to get you started, and gush about what a great friend you are, and how they’ve known you in RL since childhood. IF you go bad, however, they will find themselves in the unfortunate position of having endorsed a jerk, which negatively affects their Reputation — so they will have incentive to think twice before endorsing you. On the other hand, if you become the next Torley, a widely-lauded cultural icon, then your friend’s Reputation goes up, because they said you were cool before your Reputation Score had increased so much. You get dividends on your investment.

Maybe you don’t have friends. That’s okay, there will always be places you can go to get started. You can build your reputation organically, through good behavior, or you can seek a few endorsements from a Professional.

A Professional Endorser speculates in reputations. For a commission, they will stake their carefully-earned reputation on judging your character. You pay them, and they spend time with you and get to know you. If they like you, they leave positive feedback. If they don’t, they leave negative feedback. The more you pay them, the stronger an opinion, positive or negative, they will be willing to stand by, which means more work for them in reaching that opinion. Remember, they’re putting their reputation on the line too. If a Professional endorses the next grid-bomber alt, people will see this and the their Reputation may take a nosedive.

Case 6: Saying You’re Sorry

What if you make mistakes, but you want to do better? Maybe you can salvage your reputation by balancing out your negative feedback with positive feedback earned with good behavior, but maybe your reputation has tanked too low to save. This is reminiscent of a case I deal with a lot as an admin of a private island, in which someone feels that my decision to ban them wasn’t fair.

The solution is simple and fair: get an alt. Behave yourself. If you do, no one has to know that you were the last grid-bomber. So long as you behave yourself, everyone wins! You get to go where you want to and visit all the hot Prestigious Clubs, and the community gets the benefit of your good behavior. And if you don’t behave yourself in your new account? Well, pretty soon your shiny new clean slate will be marred by negative feedback, and your Reputation Score will drop accordingly.

Case 7: Age Verification

This system is all about making statements that are backed by your Reputation. Aside from your behavior, one thing people seem to really want to know about you in Second Life is your age. On the one hand, I personally believe that there’s less of a direct correspondence between age and behavior than most people do. There may be some amount of correlation, but correlation does not always imply causation. If your reputation’s high, and everyone loves you, who cares if you’re 12? This Reputation System makes it easy for age to matter a whole lot less, since it’s no longer necessary to rely on it as a coarse-grain filter for behavior.

On the other hand, it’s still often very important to know someone’s age, or more specifically, whether they’re over the Age of Majority. The law makes it necessary to ensure that a sexual partner is above the Age of Majority before engaging in certain acts with them. For companies in the Adult Industry, it’s critically important to know wether someone is 18 or over. While LL’s official policy creates a separate grid for teenagers and bans them from the Main Grid, their policy and ToS states directly that they cannot provide 100% assurance of their members’ ages. Even requiring a credit card is not enough; I had a MasterCard number attached to my checking account when I was 16.

The Reputation Service allows for several different ways that Age Verification could be implemented. The first would be through an Age Verification Service. These services already exist, and their purpose is two-fold: first, they allow Clients to register and provide certain age-identifying personal information to them, and second, they use this information to make assurances to their Customers that a Client, interested in doing business with the Customer, is over a certain age. One or both parties may be charged.

In the Reputation System, the Age Verification Service is staking their Reputation on the statements they make. Their Reputation Score directly affects whether or not Customers and Clients will use their service, so they have an incentive to provide correct information. They make whatever requirements they feel are necessary of a Client to convince themselves of the Client’s age, and they may provide different avenues of meeting their requirements. Perhaps the most trusted Age Verification Service would only accept Clients that were willing to make an in-person appearance or subject themselves to an extensive background check.

Another possibility doesn’t involve a separate service. A person would simply make a statement of their reputation in a public place, perhaps even on their Profile in the Reputation Service. Anyone can say they’re any age at all, of course, but remember, everything you say in the Reputation Service is backed by your own reputation. Perhaps you could give a trusted few friends enough personal information that they feel they can back your statement of age with their own reputations. If someone discovers you’re lying, you’ll find that your reputation tanks, and no one believes that you’re actually 25.

Potential Problems

So why will this work? Why don’t I think it will fail? Why not some other solution? Most griefing solutions I’ve seen proposed, especially in reaction to the CopyBot issue, are technical solutions. The problem with technical solutions is that we’re dealing with a human problem. It’s very difficult to construct a technical solution that is simultaneously specific enough to deal with the problem, and not easy for a jerk to circumvent. The problem is that this is a “people” problem, and people are very creative when it comes to finding ways around computer-based rules.

The Reputation System, on the other hand, is a people-based solution. The reason it can be so flexible and resistant to being circumvented or gamed is that the underlying activity that makes it all work comes from humans. In a technical solution, someone can come up with a creative way of using the system that wasn’t considered by its designers, and thereby subvert the system to their own ends. In a people-based system, so long as the system itself is simple enough, people can catch on to what you’re doing and call you out on it.

Do you remember the old ratings system in Second Life? I started in the Fall of 2004, and the old ratings system was still in existence. You could rate anyone positively or negatively in up to three categories: Appearance, Behavior, or Building. You could choose to attach a note to your rating if you wanted, but only the recipient would see it. Each rating cost $1L. Every week, the people who had collected the most ratings got a big share of a “Stipend Bonus” pool added onto their Stipend. This could be in the range of several hundred Lindens, and often even dwarfed a person’s stipend itself.

Spending about five minutes in-world as a newbie made it clear how this system was gamed. Everywhere you went, people would pass ratings out like candy. “Good job, way to stand there and say nothing, here’s a positive rating,” they seemed to say. Many profiles would have tidbits like “will rateback!!!1″, and their total received ratings were in the thousands. It was a win-win game: rate someone, they rate you back, you both get a higher stipend. Ratings had absolutely nothing to do with whether or not you liked a person’s behavior. Worse yet, negative ratings were largely washed out in the flood of positive ratings you’d get just for walking down the street, and if you felt the need to negatively rate someone for actual bad behavior, they’d negatively rate you back in retaliation. Your profile would reflect the negative rating forever.

Eventually, LL raised the rating price to $25L per rating. Shortly after the price increase, they also abolished the ratings-based Stipend Bonus and removed the ability to rate negatively. Now ratings are given much more rarely, if at all, and they don’t mean much due to the lack of negative ratings. At the time, LL made some brief mention of a “more robust feedback system”. This article is an example of one.

In the Reputation System, there will definitely be incentive to constantly pat each other on the back. But remember, everything you do in the system is a statement that you’re backing with your own reputation. If you run around giving people ratings that are obviously frivolous, someone like me might see fit to point out that you’re not using the system as intended, in the form of negative feedback on your Reputation Profile. If I get enough people to agree with me, my reputation increases. The system is self-policing.

What about other ways of gaming the system? There are rumors around that there are certain blocs of griefers who band together in order to act like jerks with impunity. If you cross one of them, they might make a concerted effort to trash your Reputation Score. Remember, one feedback acting alone won’t have much of an impact on your score, but opinions gathered in force have a much greater effect, especially if those opinions are held by people with good Reputations.

So theoretically, if a griefer bloc wants to trash someone’s reputation, their first step will be to gather a fairly large group of people who have high Reputations. They’ll have to earn those Reputations… possibly by doing the technical equivalent of patting themselves on the back by giving each other constant good feedback, but there’s at least some room for presumption that they’re going to have to be on their best behavior for awhile. This is not insignificant, because it means the community gets the benefit of their good behavior right off the bat.

Then, at some signal, they would launch a feedback campaign against their target. One might lodge negative feedback, and the rest would vote on it. Several feedbacks later, the target’s reputation is trashed. This sucks.

Fortunately, people can catch on to this kind of thing. Obviously, the target’s going to wake up the next day and realize that their Reputation is tanking, possibly the next time they try to go somewhere in SL, or, if they’re obsessive like me, when they grab their morning tea and hop over to their Reputation Profile right after checking their email. Either way, they’ll see what’s happened, and pretty soon they’ll be able to figure out that they’ve been Reputation-Griefed.

Their reaction is to tell all of their friends, post on their blog, and make a big loud stink so the community knows what’s going on. The community frowns on gaming the system to falsely ruin a reputation, and they’ll vote a lack of confidence on all of the victim’s negative feedback, quickly rescuing their reputation and dimishing the reputation of the griefer bloc in the process. They’ll also lodge negative feedback on the bloc, and since the public as a whole is a lot bigger than the bloc, there’s not much the bloc can do to save their reputations.

In short, this starts to sound a lot more like a “roll with the punches” defense than a “put up a really thick, rigid wall” defense. My feeling is that the former is the only kind of system that can work in this case. You can make a wall as thick as you want, but sooner or later someone’s going to find a way to crack it, and then it’s useless. A flexible wall, on the other hand, rolls with the attack, and then rebounds against the attacker with more force than they applied. You might get away with poor behavior for a little while, but pretty soon, you’ll find it blowing up in your face.

Even still, I know there would be complaints of the form, “___ said something really nasty about my mother on my Profile, and I demand that you take it down!” The answer to this is simple: nothing will ever be taken down from the reputation system. It’s necessary for there to be no intervention of this sort in order to maintain trust in the system. Your one and only recompense will be to lodge a complaint against the person in question, and attempt to sway the community to your side. For that and other reasons, I think that providing feedback about a person should be completely free of charge… but I’ll get into that in a minute.

One more thing: adoption. That’s the Achilles’ Heel of this system. It’s not going to work until it hits a certain critical mass of participation, and of course it’s not going to work if no one picks this up and implements it. As to the former, my hope is that, as the system is adopted, pretty soon you’ll find that you can’t help but be part of the system. For one thing, people can lodge feedback on you all you want, whether or not you have actually “Registered”. If people begin to slander you, or you feel you’re getting treated unfairly, your sole recourse will be to register (for free!) and start to counter the negative feedback. Furthermore, my hope is that people will begin to find that they can’t go anywhere or do anything without someone checking their Reputation Score. Fail to pay attention and participate in the system, and you’ll find you’re able to do less and less in Second Life.

Along with the question of adoption is the problem of complexity. If the system is too complex for SL Residents to understand, then they’re not going to use it. Plus, their first interaction with the system might be when they discover that someone’s said something bad about them, so they’ll already be in an anxious mindset. Simplicity is key. It’s critically important that someone can understand the basics of how they interact with the system within a very short amount of time. Fortunately, I think this can be achieved.

The system seems like it might be complex, and from a mathematical, implementation viewpoint (which I’ll discussed later), it’s non-trivial. However, the basic concepts that the user must understand are relatively few and simple:

• you can leave feedback about anyone, affecting their reputation
• if people vote to agree with your feedback
• it counts for a whole lot more, and
• your reputation increases
• if people vote to disagree with your feedback,
• it counts for a whole lot less, and
• your reputation suffers
• every feedback and vote you make is a statement backed by your own Reputation

It’s a little tricky, but the basic rules are simple enough, and the last can probably be removed. More importantly, it’s easy to explain these rules in several different ways. One way might be by example: illustrate a scenario involving feedback and positive and negative votes, and how they affect the reputation of the parties involved. Tips can also be provided as you use the system, such as a tidbit reminding you that the feedback you’re leaving will be a whole lot more effective if you get your friends to come vote on it for you. The underlying key is simplicity, because if it’s not simple, people won’t understand it and won’t use it, and without people using it, the Reputation System crumbles.

Implementation

Who should create this system? Why? What’s in it for them? My proposal sounds like a good idea (I hope), and I’m pretty sure that most people would participate in it if it existed. People love to be able to bitch about someone who offends them in a public forum. We love the idea of real consequences for someone who’s maligned us.

Unfortunately, just because this is a good idea doesn’t mean it’ll get adopted or implemented. For things to get done in this world, sometimes it takes an incentive other than moral goodness. Fortunately, economics comes to the rescue: I think that someone with a good business sense could easily make this system turn a profit. In fact, I think there’s enough of a market that two or three or maybe more such systems could compete with each other.

My proposal for a business model (note, I don’t have much business sense) is simple: accept feedback for free, but charge to view a Reputation Score, and possibly to view existing issues on someone’s Reputation Profile. Simply charge me every time I want to view someone’s Reputation Profile on the website. Charge me once each time my land-based reputation manager looks up someone’s Reputation Score in order to decide whether they get into my land. Make it relatively cheap, and I promise that I’ll be constantly checking then profiles of those around me. In fact, give me a HUD, and I’ll click a button every time I meet someone to check up on their Reputation Score, which will help me decide whether I want to bother to continue to interact with them. If we can convince LL, give me a hook in the Buy and Pay windows that lets me check a vendor’s reputation before I do business with them. Heck, let me put a script in my vendors that decides whether or not to sell a product to someone based on their reputation. I don’t want to do business with a jerk, because they might try to steal my product, and they might harass me constantly for technical support when they should just read the manual.

The System should accept feedback for free, though. This is important for several reasons. First, people are providing the system information, and it’s collecting it into a huge database, mining it, and determining Trust and Reputation based on that information. That’s where the Service comes in. In fact, it might even make sound business sense to PAY for feedback, but this is probably unnecessary, because people love to gossip about other people. Another reason that keeping feedback free is important is that people need to be able to counteract false feedback. I should be able to be completely broke, and yet still have my voice heard when I’m falsely accused.

The real key to the system is the algorithms used to turn that gigantic stream of feedback into Reputation Scores that can provide useful information. I can take a few guesses at what form these calculations might take, but I think that they need to be considered very carefully in order to produce an effective system. In fact, this is where companies can innovate and competitors can gain an advantage on each other. It’s important to make it clear what kinds of computations are made, so that people know how to use the system. For example, it needs to be clear to me that if I vote “no” on something that the entire community has said “yes” on, then my reputation score will decrease. But how much will it decrease? How will the decrease be computed? That can remain behind the scenes.

One potential solution would be to actually produce a Reputation Economy. This has been proposed in several books such as Charles Stross’ Accelerando (read it free here!). When you “stake your reputation” on a certain statement that you make about someone, make that an actual Investment of some portion of your Reputation Currency. If it turns out that the community agrees with you, you gain Dividends on your investment and your score goes up. Those who disagree find their investments losing value. Potentially, this could result in a fixed circulation of Reputation Currency in the system. This solves one hidden problem in what I’ve described above: inflation. If everyone behaves well, and reputation scores continue to go up, pretty soon everyone will have a high score, and the system could become diluted. An Economy-based model could counteract that. However, it’s complicated, and we’d need a full-fledged professional economist to design the system. (Hint hint.)

If you like what you’ve seen so far and have a mind for comptuer algorithms, I’d love to hear what you think about how we could make this system work. As I said, I’ve got a few good ideas, and I might post more on this later, depending on the reaction I get.

Take this idea

So here it is. I hope that I’ve provided a mature, solid idea that can be implemented to produce a system that could make a serious step toward combating the griefing problem. I’d love to hear your feedback, so comment here and trackback from your own blog. If this won’t work, let me know why. Maybe we can come up with a solution together. If it will work, tell all of your friends and spread the word.

Better yet, take this idea and implement it. I would like nothing better than to see a system like this in action, and to have the benefit of its judgements on my own land so that I can stop having to put up with griefers. I would love to implement this myself, but I’m only one person, and I’ve got some pretty serious RL-based barriers to taking on a project as big as this. Plus, I’ve got no business sense, and I really don’t want to run a business. I just want to tinker, design algorithms, come up with creative solutions to problems, and, if you’d have me, maybe even help you write some of the code. I hate web programming, though.

So, I present this idea to the Community. You can take it, follow what I’ve said here, and quite possibly turn it into a moneymaker and become everyone’s hero. I gain in that I get to use such a system, and I’m pretty sure that I’d get a big boost in my reputation for being the mother of such a vital tool, assuming it works ;) I’m unable to make this happen on my own right now, and I feel that the need for a system like this is so great that the community just can’t wait until I’m able to implement it. Instead, I present it to the world, wide-open, so that the basic idea cannot be patented (just the specifics of your calculation algorithms, if you see fit). If you make this work and get rich, it might be nice if you made a donation to the Let Lex Eat fund, and maybe mentioned me in the credits… but let’s just see how this goes, shall we?

Lex Neva has been a resident of Second Life for over two years. She is a hacker, a tinkerer, and a brainstormer, and she loves nothing more than to spend hours trying to make LSL do things no one knew it could do before. Her accomplishments include the scripting in The Settlers of Second Life (a system so complex that it made Philip Linden say, “I think she might be insane…”), PipeMaker, Rez-Faux, and tons of other freebies, scripting techniques, and ideas. She lives in Suffugium, a cyberpunk sim created and owned by her and the rest of the Squidsoft Collective. Drop by, and you’ll see her brain-children flitting about all around you.

I started this blog for one reason: to write up a fairly long essay I’ve been tossing around in my brain and in my paper journal. It’s going to deal with the huge problems Second Life (and by analogy all internet gathering places) is dealing with regarding jerks: people who just don’t know how to get along with others, or who actively try to piss everyone off.

I’m going to present a pretty good solution to the problem of griefers in Second Life. A lot of people have presented a lot of solutions, and most of them are unworkable for various reasons. Mine’s different: it actually stands a good chance of working, and it clearly and neatly answers every objection I can think of that normally kills ideas of this sort in their infancy.

So stay tuned. I’ll be posting soon, once I get the whole thing composed in a clear, concise manner that presents the idea well. It may take me awhile, because my wrists ache if I type too much.