Kill zFire RedZone with fire!

I'm going to repeat my usual disclaimer here, just to pre-empt the whining and screaming that would otherwise follow. This post is purely my own opinions and thoughts. It is not a statement of The Phoenix Viewer Project, Inc., and does not necessarily represent the views of any other member of the Phoenix team. If you want to know what some other Phoenix developer thinks about this, ask them.

The subject of zFire Xue's RedZone system has ben a hot topic around SL for the past couple of weeks. RedZone is marketed as a tool against griefers and copybotters. It works by matching the avatar's name with its IP address by feeding the viewer a URL with the information encoded it it for that purpose and having it play it as media (a movie). The information thus collected is then used to link other avatars with the same IP address to that one, as an alt of that user.

This has many problems:

• It's inaccurate. IP addresses are not normally fixed to a specific user. Even RedZone's own data server is on a dynamically-allocated IP address. Someone else who comes along behind a user on an IP address they've inherited will be listed as an alt of that user. People who use public access IP facilities, such as hotel wireless connections, will all be listed as alts of each other.
• It violates the laws of several European countries which prohibit logging of IP addresses and associating them with any personally identifiable information.
• It violates sections 8.2 and 8.3 of the Second Life Terms of Service, by transmitting content that violates users' privacy and is illegal.
• It's nobody's $DEITY->damned business who my alts are.

The last is what makes this personal for me. Yes, I have alts. If I think you need to know about them, I will tell you. If not, I will not, and you have no right to know. That is my decision and mine alone. I have what I believe are more than good and sufficient reasons for keeping it that way. Don't like it? Too damned bad.

I'm far from alone in this belief. However, I am in a position to help users do something about it and keep their privacy.

First, I am working to make Sione Lomu's media whitelist/blacklist patch available in the mainline Phoenix and Firestorm viewers. The main code is present already in Phoenix. There are some refinements that need to be made; I'm working on them as quickly as I can. When it's ready, I will push as hard as I can to get a full Phoenix release out with that protection in place.

Next, I will, purely for myself and not as a part of the Phoenix project in any way, post instructions specifically on how to block RedZone with that facility. I will also do my best to make sure that they are widely spread around SL.

Finally, I will continue to work with others to help spread the word about RedZone and see that it is removed from places that people frequent. Put simply: Anyone who uses RZ is declaring war on their users' privacy, and they should be shunned.

I really wish it hadn't come to this. But since there's a war on, I intend to help the right side win it.

Now, anyone know of a good replacement for zFire Prim Animator? It may be the best thing out there to do that job (far better than Prim Puppeteer), but it has to go. I refuse to support its maker as long as he conducts a war on privacy.

Where I've been hiding

I was moved to post the last post by annoyance about FUD from a Viewer 2 partisan, trying to convince version 1-based users to switch so they wouldn't ruin others' SL experience. It took something liek that to get me motivated to write here again.

Where have I been hiding?

Mainly, I've been heads down working on Firestorm. By now, the initial preview release of Firestorm is out and available for folks to try. It's only a preview, and those who try it should keep firmly in mind there's a long way to go yet. Many of the most popular features from Phoenix, like the radar and AO, simply aren't there yet.

Nevertheless, if you want to see where we're going, check it out. To find out more, join the Phoenix-Firestorm Preview Group inworld. That's where you'll find support for it, and the notice with the notecard that has the download links and a link to Jessica Lyon's video explanation of what's in it. Please be sure to watch the video first.

Now, back to beating on the code...

Answering anti-v1 FUD

Ash Qin has been passing around the following notecard full of FUD, arguing that people shouldn't use version 1-based viewers:

Users of 1.x viewers might not be aware...

As it stands, the 1.x viewer branch currently creates more lag and issues for other Second life residents as they are more harmful to simulator resources. In the 2.x branch of Second life, textures, assets, inventory and even various detailed information are downloaded from dedicated servers for these resources.

Many 1.x viewers don’t even support these options and those that do are using outdated methods or buggy implementations that automatically fall back onto older methods. These older methods do not request the data from the dedicated servers, but instead hammer the region with requests which degrades performance of the region for everyone. The difference measured in a region between ten users using a 1.x viewer and ten using a 2.x viewer on a region can be enormous resource wise.

Additionally, a few popular 3rd party 1.x viewers use various non-standard methods where standards have been established. One example is the use of secondary attachment points, when Second life supports attaching attachments to any point multiple times without needing to readjust attachments in the 2.x branch of viewers. The non-standard attachment points are incompatible with all the different viewers out there, while we have already a proper standard for them, this stifles the Second life user experience as 1.x viewer developers are not conforming to standards.

To summarize, the 1.x viewers are introducing more lag and creating incompatibility which reduces the user experience exponentially. 

I ask that you be more considerate and not ruin other people’s Second life experience - please don't use a 1.x viewer.

Thank you for taking the time to read this,

Ash

Quite simply, Ash, you're full of prunes.

What he's referring to in the paragraphs talking about lag is HTTP GET for textures. (No code, not even Linden Lab's Viewer 2 production releases, uses HTTP fetching for inventory. Remember the inventory problems last December or so? Those were caused when LL tried turning HTTP inventory fetch on. They had to turn it back off, and viewers will need code changes to use it now. Those changes are not in 2.4 or earlier viewers.)

All currently running Phoenix releases can and will use HTTP GET for textures, just as Viewer 2 will. The ability was turned on by default in release 1.5.1.373; users still on 1.5.1.225 can set it with a menu selection. (I recommend everyone upgrade to 818 anyway, for this and many other reasons.)

The argument against secondary attachment points is an old one, dating from the time Emerald introduced it - many months before LL introduced their own system. There were a few folks complaining about others using secondary attachment points because it made things look wrong to those not using advanced viewers. As it happens, Phoenix 818 (and 725, for that matter) support multi-attach, while still viewing things on the secondary points correctly. This is the best of both worlds. People who switch from 373 or earlier to 725 or later will automatically have their attachments on secondary points converted to the new system.

Ash has a comment in his profile that's telling here:

If you can't see some attachments (ie: parts of me are missing), it's because your viewer doesn't support Linden lab's standard multi attachment support.

This is just the same complaint people raised against Emerald's secondary attachments, but in reverse. The difference is that, until the release of Phoenix 725, more people could see and use secondary attachment points than multi-attach. Even now, significantly more people use Phoenix than Viewer 2 - in any incarnation.

Who sets the standard? LL tries, but the users vote with their feet. Less than a third of users currently use Viewer 2. The percentage on Phoenix is higher than that.

I firmly believe in the idea that one should not ascribe to malice that which can adequately be explained by stupidity. However, I do note that Ash is associated with INSILICO and has posted some blog entries and comments defending the CDS package, claimed to be a copybot defense system. Both are projects of Skills Hak, one of the three folks LL insisted leave the Emerald team - though Skills, at least, agreed to go to keep Emerald alive.

Even so, I can't help but suspect his motives in slamming V1 viewers - and especially Phoenix, the most popular viewer on the grid - are somewhat less than pure. His arguments are either simply wrong or amount to equine sadonecrobestiality.

If you're running Phoenix 818, you're not hurting the grid in any way. The choice of what viewer to use is yours and yours alone. Don't let FUD from anyone tell you any differently.

It's easy to design a mall, right?

Well, maybe. It's certainly easy to design one poorly, but not so easy to do well.

One place I have a store is redoing their mall. The new one is where the sim landing point will be set, and the users will, hopefully, shop a bit before heading into the sim; the sim owner is also hoping this will reduce lag in the main sim. Okkay, fine. I can deal with that.

Unfortunately, I was asleep for the opening land rush (which happened overnight US time), and wound up with a less desirable location than the one I currently occupy, right where the teleporter drops a new arrival into the current mall. This wouldn't be quite so bad except that the design of the new mall makes only a few spaces desirable, and leaves the rest with significant handicaps.

When I open up a store, I look for one where my products can easily be seen from where a new arrival comes in. The idea is to grab their attention right off the bat. There are usually several places in a mall that qualify, and I try hard to grab one. This particular mall seemed designed to minimize those spaces, however. Here's the basic design unit of the mall:

That's me standing on the landing point, using the standard camera view from behind. It's an island pod in four quadrants, with spaces around the outside wall. Four of these units are arranged in a square. Because of the layout, though, only the one island space is clearly visible, and all of the outside spaces are at least partially obscured. There are four spaces visible straight down the lanes between the islands. One of those, however, is where the wall will be removed when the mall is expanded at some point in the future, leaving only three, plus the four inward-facing island spaces, as desirable locations. Those were, of course, all gone by the time I got there.

From this picture, it looks like there's not as much of a problem for folks not in the 7 prime locations. That's because I derendered all of the vendors visible in this picture. The reality is much worse, because no limits were initially imposed on the folks inhabiting the islands. This one isn't too bad:

(All I did was move the camera around; I didn't move myself at all.) That vendor, at least, showed some restraint. (So to speak.) The real horror is this one:

That vendor essentially blocked out one entire corner of the mall, and management let them. When I complained, the manager told me she'd impose a 5-meter height limit on shops in the islands, and a 15-meter height limit on the ones along the wall. This misses the point, to me, though. Even that kind of height limit doesn't preserve the sight lines from a user just popping in to the shops behind the islands.

I wound up here, to the left of Chorazin Creations:

The two vendors in the island in front of my shop had kept to the low height of the walls, and my sign, at least, was visible over them. I'm not entirely happy with this location, but I don't think I'm going to be able to do better. I'm stuck in that mall for a while longer, since I'd (rather stupidly, it appears) prepaid my rent at the old mall for quite a while in advance.

I'm not a designer. I leave that to my good RL and SL friend Axi Kurmin (of, among other businesses, Urban Forge Virtuatecture). But if I can see problems with this design, I'm sure she can outline many more.

Final releases usually aren't

Sigh. By now, if you've been following the saga of Phoenix, you know that 725 was less than a total success. We put a lot of work and fixes into it, and pushed even harder to release 818 by Christmas.

It's better, but it's still got bugs. (Film at 11.)

The only program that's bug-free is one that's never used. Just as with any other human endeavor, no program is perfect. There are bugs left in Phoenix that need fixing, mostly in the areas of RLV, texture video memory management, and the new inventory system LL keeps trying to push out, AIS.

At this point, however, Phoenix is feature-frozen. It will get bug fixes, but no new features, at least officially. (I can't speak for Jess, but I expect that new features that can be dropped in without significant effort will be added - as long as they're added to Firestorm first.) All new feature development will happen in Firestorm, and only get backported to Phoenix on a time-available basis.

The difference between now and a couple of months ago, when I first said that we weren't feature-freezing Phoenix yet, is that the developers believe that the major features that can be added to Phoenix have been. In particular, display names and multi-attach are in and working about as well as they can be. We're also tired of chasing some persistent bugs that simply don't exist in the V2 codebase.

Even so, as we fix things, there will be more releases of Phoenix. We hate having a viewer out there with problems as much as the users hate having to deal with problems. This is a final release only in that new versions likely won't have significant feature additions. There will be bug fixes, at least until Firestorm reaches production release status. Once that happens, though, expect Phoenix to be finalized.

Release early, release often

One of open-source guru Eric Raymond's favorite sayings is "Release early, release often". This appeared originally in his seminal work The Cathedral and the Bazaar, which should be required reading for anyone doing open source development.

This has relevance to the current state of the Phoenix Viewer project. The release of 1.5.2.725 - what we're calling a release candidate, mainly in self-defense - was delayed by quite a bit of time relative to our previous schedule of releases. We kept adding features and fixing bugs and introducing more bugs and adding features and introducing more bugs and fixing bugs. Part of the reason there is that the release was delayed for a while, waiting first on my fix of a nasty texture upload issue, and then the completion of the parcel Windlight settings feature.

Regardless of the reason, the end result was the same: we wound up having to do a lot of debugging, and releasing with bugs we'd rather have fixed.

The answer is in Eric's dictum. Releasing early and often both tends to compartmentalize the addition of features and the corresponding bugs, and also tends to make bug resolution easier and closer to the introduction of whatever caused the bug. On top of that, it also reduces the pressure to just push something out before it's really ready, by keeping users happy that features are being introduced and bugs fixed on an ongoing basis.

A case in point here is the support for Display Names. The original feature was added by a developer scratching his own itch. As I've said before, that's the norm in open source development. The feature was originally added to just show the display name int he user's tag and profile, and tested that way. One user submitted a patch, after that version went out in beta test, to extend the reach into local chat windows - but we couldn't add it, at that point, because we were trying to lock it down tighter for the formal release of what became 725.

Then we had a couple of showstopper bug reports - including one that was submitted to us that we agreed to fix before the release, but that apparently didn't satisfy the user, who submitted an abuse report with Linden Lab over it! (I really, really hope I don't find out who that idiot is. He caused a lot of needless pain and agony.) Those delayed the release even further, and got in the way of proper beta testing as we quickly approached the deadline we'd publicly set. The result was a release candidate that isn't bad, but has a few noticeable bugs that really should have been caught before release.

The answer is to release much more often. No, I'm not advocating public betas. What I am advocating is that we release whenever a major bug is fixed or a significant new feature is added and tested. This shouldn't necessarily happen on any fixed schedule, but rather as we get the work actually done. Releasing to a fixed schedule leads to putting things out before they're ready, and rushing to do so - with less-than-optimal results.

What of Firestorm? We're faced here with two conflicting demands: a group of users who want it, and a group of users who will only use it if it's been sufficiently de-sucked. The fear is that waiting long enough to satisfy the latter will cause the former to go off to something else, while satisfying the former runs the risk of the latter trying it, saying "This is just like Viewer 2! This sucks!" and never trying again.

I would argue that we should err, once again, on the side of releasing early and often. We should also make it plain to the latter camp that Firestorm is very much a work in progress, and that nothing is nailed down until the users are happy - so, like the weather in Houston, if you don't like it, just wait 10 minutes and it'll change. That has two benefits: it gets us people actually finding bugs, which is the true power of doing open source development, and it shows the user base in a concrete manner that we are indeed listening to their concerns and working to fix them.

Will we irritate people? Yeah. I think we're going to do that any way we cut it, and that this approach will cause the least total irritation in the user community of anything we might do.

De-sucking Viewer 2

With the impending release of the next version of Phoenix, the team is beginning to turn its attention to Firestorm, our version of Viewer 2. We're just beginning the process, and there's a lot of work to do. Even so, there's already been significant de-sucking done, as this screenshot will show.

The biggest overall complaint is that Viewer 2 wastes immense amounts of screen space, between the sidebar and the separate IM and local chat floaters and the UI design that puts huge borders everywhere for no apparent or good reason. As that screenshot shows, we've already gotten local chat docked into the IM window, with vertical tabs, as in Phoenix, and a separate inventory floater like the one in version 1. That screenshot is already very reminiscent of the way I lay out Phoenix's user window.

This is very preliminary. We haven't really devoted much thought or design effort to Firestorm, as yet, and so any or all of that can change. We also have a lengthy list of features to examine, adapt, and port to the new codebase. The whole developer community uses Phoenix's feature set above and beyond that of the base viewer. To be sure, we all use different parts of it, but if there's a feature in Phoenix, there's a member of the team that uses and knows it.

We're not going to put out a viewer we won't use ourselves.

In addition, the members of the development team have a wide range of experience within SL, and the folks we know have an even wider range. For example, I personally know one of the biggest vendors of clothing in SL. As far as I'm concerned, Firestorm isn't ready for prime time unless he can get his job done as easily as he does today, with the minimum of learning curve to surmount. (He doesn't have time to spend learning another way of working. He's too busy creating.) The same goes for folks in many other realms of SL.

No, Firestorm isn't going to happen overnight. There's too much to de-suck, for too many people. I don't expect even an alpha version to be available to the testers for quite some time. I can promise this, though: When it does come out, it'll be worth the wait.