Monday, January 3, 2011

predictions for 2011 : second life, virtual worlds and farmville

offering predictions is en vogue for tech bloggers these days; who am i to buck a trend? my area of interest is the technology and business of virtual worlds in general and second life in particular. so here's what i see when i peer into the crystal ball. let's come back in a year and judge the quality of my predictive powers.

i'm going to start with a few easy predictions. these are not so much predictions as observations of existing trends. in other words, here are some trends that will continue.

drama will continue amongst second life residents. it may sound like i'm saying our resident community as being overly sensitive or dramatic. well, yes, i am. but i don't mean it in a bad way. second life attracts drama for the simple reason that people attract drama. saying that there's drama in virtual worlds is to say that there's a critical mass of people who treat the virtual world as an extension (or alternative) to the "real" world. you don't get a high level of emotional involvement with hotmail or google docs. live journal, twitter and facebook get a little more emotional immersion, but it's nowhere near what you get with virtual worlds.

when done right, virtual worlds saturate the senses and engage the "whole person." where you find people, you find drama. and that's a good thing.

InWorlds, ReactionGrid, SpotOn and OSGrid will continue to lure the "old guard" away. let's face it, linden has ticked off several people in the content creation community. the "old guard" lindens are now mostly all swept away; along with them was lost the engagement with the community and the sense we're all pulling in the same direction. despite his faults, philip rosedale was great at communicating second life's vision and making it's residents feel the love.

later in philip's reign and throughout mark kingdon's tenure, the lab found it difficult to communicate effectively to SL residents. after the lab's "adult supervision" left the building, linden management seemed "spooked" by resident's passion. rod humble, the lab's new leader, has a good pedigree, but it'll take months (if not years) for the lab to rebuild credibility with the resident's they've alienated.

there's still plenty of "old folks" left in second life, but the OpenSim based grids can offer features and pricing you won't find in second life. but... while OpenSim based economies will grow, they will still be dwarfed by second life's "linden ecomony."

now let's talk a little about second life and linden lab. the last year's been pretty chaotic for linden what with lay-offs, project cancellations, direction changes and executive shuffles. my prediction for the lab in 2011 is you won't see as much "weirdness" in the lab as you did in 2010. it'll take a few months (at least) for mr. humble to really start to make changes at the lab. towards the end of the summer of 2011, i predict there'll be a few small hornets' nests kicked over, but nothing like the bizarre events of 2010.

i also predict that mark kingdon's focus on facebook or facebook-style games like farmville will get mild lip-service, but eventually fade away. why? farmville, mafia wars and other "casual games" are the polar opposites of second life. people poke at farmville a couple times a day and get on with their lives. second life users log in and stay for a while. and i think rod humble's background allows him to fully understand this concept.

this is not to say the various social media initiatives the lab has will be completely abandoned, but the AU purchase and subsequent shuttering must have really stung, so if the lab releases something socialesque, i think they'll release something small, well thought out, and supported unanimously by executive management. due to the lab's internal processes, i predict it will be a small project implemented by one engineer and two project / product managers within a 6 month period.

talking about technology, we shouldn't forget the web-based initiatives we saw beta tested this last year. i have a bold prediction: we won't see anything like this (web based viewer) from the lab this year. why? the whole "leveraging external technology" sounds like something that would come out of joe miller's technology integration group. four of the five members of this group left the lab in the last year.

plus, the technology is still a little rough. WebGL is out there slowly chugging along, and at the end of the year, we may see a lot of people with web browsers that can effectively communicate with GPUs. google's chrome viewer with it's v8 javascript engine may be able to keep up with the kind of data throughput numbers you'll need to support, but i still think it'll be a couple years before the browser makers create something that can handle the amount of data a typical second life session throws at a client.

so these are my main predictions. 2011 will be an especially boring year compared to 2010 for second life and linden lab. OpenSim based worlds will continue to gain in popularity and second life will not get turned into farmville.

Wednesday, November 17, 2010

Boycott KLIF's Advertisers?

So i just got finished listening to some of Chris Krok's broadcasts for KLIF radio in North Texas:
After a bit of outcry, he later issued an "apology" in which he defended his right to have an opinion on what is said in Ft. Worth Council meetings. His apology did not extend to incendiary remarks he made about LGBT persons and his antagonistic attitude towards the LGBT community. (And personally, I think his comments were pretty disrespectful of Mr. Burns, his district and of Ft. Worth.)

It's pretty clear he's using queer-baiting as a professional ploy. He moved from Chicago to Madison to Minneapolis (the latter two being relatively liberal) to Atlanta to D/FW in search of a market where he could sell his agenda of discord. The guy is clearly pandering to angry right-wing listeners, trying to boost his ratings by being "shocking." His tired schtick is grating and relatively unpleasant, but I'm comforted to know his audience only supports a part-time AM radio listenership. Seriously, there are probably internet podcasts with larger audiences.

Still, his whole queer-baiting act is unworthy of KLIF radio, and the guy will get dropped once the old guard that still go for that kind of vitriol die off. LGBT folk come from all walks of life and have significant economic clout. Sure, maybe we have more organized political muscle in San Francisco and New York than we do in Dallas, but the bottom line is this joker is making coin by disrespecting me, my family and my friends. LGBT individuals have made significant gains in mainstream acceptance in the last couple of decades, but let's not kid ourselves about this, there are still people who have nothing better to do than get worked up over who's sleeping together.

I think this kind of message is on the way out; but we can accelerate its departure by contacting KLIF's advertisers and letting them know we do not appreciate their support of programming that is demeaning of us personally or advocates a political agenda that disenfranchises us. So... anyone who wants to start taking shifts listening to KLIF and noting the names of their advertisers is welcome to join me.

If you happen to find yourself listening to KLIF, tweet the name of the advertisers with the hashtag #klifads. Include contact info for the advertiser if you have it. Every couple of days come back to twitter, search for the hash tag and call the advertiser to remind them they do not want their product associated with Mr. Krok's message.

Also, you may want to contact Mr. Krok's supervisor at KLIF directly and let him know how disappointed you are with Mr. Krok's comments on-air. His name is Jeff Catin. He can be reached at +1 214 526 2400 and his email address is jeff.catlin@cumulus.com. Please remember to be respectful of Mr. Krok and Mr. Catlin. They may have opinions we disagree with, and they may be making money peddling a message of hate, but we have the moral high ground here. We'll lose if they can drag us down to their level.

On The Dangers of Depending on a Single Provider

Yesterday I encountered a bit of a shock when I attempted to log into Second Life. Rather than seeing the familiar setting of my in-world beach house, I was greeted with a rude error message. "Login Failed. Second Life cannot be accessed by this computer. Contact support@secondlife.com."

"Ugh," I thought, "another error in an error-filled day." I had recently modified my settings.xml file to accomodate the weird screen size of my laptop and was convinced I had somehow managed to hork my settings to the point the viewer couldn't figure out which way was up. But after issuing the command `rm -rf ~/.secondlife` to perform a second life settings labotomy failed to clear up the problem, I started to get worried. Thinking my client install had somehow gotten horked, I re-downloaded and re-installed the linux client. Still no love.

At this point I sort of paniced and thought I had been permabanned. Fortunately friends were around to remind me to try to login from other machines. Fortunately, I could log in from the ancient iBook G4 I still have laying around the office running an old copy of viewer 1. After downloading viewer 1 to my main machine and trying to log in, still no love.

For whatever reason, my ID0 or MAC had been banned.

Something was seriously horked here, so I did what you're supposed to do in situations like this: I emailed support@secondlife.com like it says to do in the error dialog. In a few moments I got a response back saying that even though the client told me to send them an email, I'm really supposed to use a web form to file a ticket. After filing a ticket and getting confirmation from Linden's automated support tracking system, all I could do was wait.

While waiting, I found some Second Life Forum discussions about exactly the same problem. Apparently back in the old days this would happen from time to time and after about four hours after filing the ticket, someone would get to it and unban them. So I waited.

I'm a bit lucky in that I have a few support resources that most Second Life residents do not. As a former Linden, I have several personal friends who still work at the lab who were able to confirm that there's nothing on my account "rap sheet" that would indicate my account had been banned (we knew this already). The weird bit is there was no record of my IP address or my MAC addresses being banned either.

Yay! Random weirdness.

So I wait and wait and wait. This morning it's still not resolved so I send an email to a friend at the lab jokingly suggesting this is Linden's way to prevent me from attending virtual world standardization meetings in-world. Let me just stop here and say that while it's fun to let paranoia sweep you away and imagine a consipiracy to prevent you from doing your work in world, it's probably not accurate. Remeber the saying.. "do not attribute to malice what could easily be attributed to incompetence."

Rather than there being a conspiracy to keep me from logging in, here's what probably happened... When you log in to Second Life, your client sends a couple of numbers that uniquely identify your PC: the MAC address and the ID0. These values are used to identify the PCs of griefers, scammers and generally bad people. This is one of the reasons I was surprised to get the ban hammer. What the heck had I done to warrant banning?

MAC addresses and ID0's can easily be spoofed; "bad guys" do it all the time. And probably what happened is somewhere out there a random griefer picked a random ID0 and got caught. The random ID0 they picked happened to match mine and when they were "banned," Linden added the spoofed ID0 to the black-list. Once the "bad guy" in this story couldn't log in with my ID0, they probably picked a new one at random and went back to griefing. I, on the other hand, was left unable to get in-world because it's a violation of Linden's acceptable use policy to spoof these values. You're supposed to resolve the issue through the support center.

So you see what's going on here, right? Linden is using a technical mechanism to enforce a decent policy. But the only people punishes by its enforcement are legitimate users who don't spoof the second life servers.

After working my personal connections inside the lab, I was able to get this issue resolved. But I can't help but wonder what people who are NOT former lindens do.

So let me try to wrap this up with this thought: doing business in Second Life is unnecessarily risky. While it's a wonderful platform for people to express themselves and it's a great, social immersive experience, the policies that govern this virtual world are a bit wonky. And they're likely to stay wonky for the near term.

As messed up as Second Life is, it still has some great things going for it: lots of participants and lots of bling you can buy to name a few. But at the end of the day, if you run a business in Second Life, you are dependent on an external for-profit organzation for your bread and butter. In the 2D-web world, services are neatly interchangable. If you don't like Google's privacy policy, you could get an account at Yahoo! or Hotmail. Or at your local ISP. Or if you knew what you were doing, you could build your own email server. Ditto for other basic web services,

But you simply can't do this with Second Life because Linden owns the service definition. Not to mention, they've got a great head-start against potential competitors like InWorldz and ReactionGrid. Both are great services offering experiences that are more or less the same as Second Life, though with a significantly reduced community. Owners of virtual businesses stick with Second Life in spite of it's seemingly random behavior because "that's where the money is."

When we chartered VWRAP, our objective was to create a truely open virtual world ecosystem. The protocols we worked on were intended to be implemented by a wide array of participants allowing Second Life to grow beyond it's "walled garden" beginnings. By opening the virtual world up to potential competitors, Linden risked short-term reduction in revenues from land sales, but could have participated in a "3d web" that was more attractive to businesses (and educators and ...)

VWRAP is now effectively dead. The HyperGrid lobby may try to recharter VWRAP to focus on HyperGrid, but it's an implementation rather than a protocol. The IETF is sort of allergic to these types of efforts; taking a protocol implemented by a single product and "blessing" it as "the" standard. And with due deference to the activities of ReactionGrid and InWorldz, the larger business community is probably not interested in risking an investment in a protocol with a single implementation. (Thankfully, there are enough bleeding edge users out there that RG and IW can probably survive.

But at the end of the day, when you depend on someone else for technology, you depend on their business remaining stable enough to support your business until you've recovered your investment. This is why Linden makes a lot of people nervous. Sure, they have to adapt to changing business realities, but it's irritating when they behave seemingly randomly. It's even more irritating when you realize that it's their economy you're playing in.

And this is why dealing with OpenSim grids is irritating. You wonder if they're going to be around long enough for you to recover your investment in their economy.

Clearly it's not so irritating that I don't involve myself in their use and development. But I think I'm likely to be cranky and irritable 'til... well... until Second Life and Reaction Grid are dim memories (like AOL and Compuserv) and their creators move on to more profitable open virtual ventures.

[author's note: Kyle, Robin and Chris, who are employees of Reaction Grid have protested in the comments below. I think there's some validity to their comments. I was unclear in that last paragraph about what I wish goes away. For the record, I TOTALLY love what Kyle &co are doing at Reaction Grid (the company). I have nothing but best wishes for Reaction Grid (the company). What I wish goes away is the concept that you can only make money in virtual worlds if you're a "grid operator." That is, I hope we land in a future where "the grid" as a concept goes away and is replaced by a cluster of services that implement a virtual world. I hope Reaction Grid (the company) or Reaction Grid (the community) or Reaction Grid (the collection of virtual locations) all have a prosperous future. I do, however, hope that Reaction Grid (the artificially walled garden of content and identity) evaporates in the future. Given Reaction Grid's (the company's) support of HyperGrid and OpenSim, I believe they share that goal. This meaning was pretty obvious in my head when I wrote that last paragraph, but clearly it was unclear. I apologize to Kyle, Chris and Robin for the confusion.]

Monday, November 1, 2010

fun with sl8.us

so i've been playing with the sl8.us URL shortener-redirector for a bit and have figured out a few fun applications. (for peeps that don't know about it, the sl8.us redirector shortens second life URIs like secondlife://Meyers/171/13/48 and converts them into http URLs like http://sl8.us/mHcs48A9P, that redirect you into Second Life.)

sl8.us was originally intended to shorten SL URIs so they could be easily included in tweets. so the first obvious application is to tweet your location. i've been using it to tweet about interesting in-world locations. you can search for shortened URLs on twitter by searching for "sl8.us" to see locations other people find interesting.

you can shorten a URI by visiting the social avatar site or by using the in-world HUD that shortens (and optionally tweets) your location. (you can get info on it's installation and use at the HUD intro page at sl8.us.)

the in-world HUD lets you "mark" a location for url shortening or look to see who else has been making marks in your current location.

but something more convenient i've found is the ability to bookmark in-world locations in my web browser and online tools. some social bookmarking sites barf on secondlife:/// URIs, so having a http:/// URL that does the same thing is rather convenient. i've added a list of locations i visit frequently in-world to my browser bookmark bar. it's nothing major, but it makes SL a little more "fast." i'm kind of surprised linden hasn't tried to roll out something like this.

Friday, September 10, 2010

announcing project brookdale

this is a quick post to announce "project brookdale," an open source implementation of the Virtual World Region Agent Protocol (VWRAP) suite. VWRAP is a collection of specifications produced by the IETF's VWRAP Working Group. these specifications define interoperability for a "second life-like" virtual world. you can find more information about VWRAP on my VWRAP Page or the blog post "what's the virtual world region agent protocol?"

project brookdale will produce PHP, JavaScript and C/C++ middleware that manages protocol interactions. it is not, in and of itself, a complete virtual world implementation. it is instead designed to be used to simplify the development of VWRAP compatible tools and services. this division is not completely unlike the division between libomv and OpenSim.

here's a quick list of things you'll find in brookdale:

Dynamic Structured Data (DSD) and HTTP Transport Bindings

"DSD" is an evolution of the previous LLSD and LLIDL abstract type system and interface description language. the main difference between DSD and LLSD are minor changes in the XML serialization and a "layered" approach making it easier to use VWRAP messages with non-HTTP transports. more information about the motivations behind DSD can be found in a "abstract resource definitions vs. LLIDL". the internet draft draft-hamrick-vwrap-data-00 describes DSD in more detail.

one feature desired by implementers of previous OGP and early VWRAP work was clear guidance or agreement for how to handle content negotiation and caching of VWRAP messages carried over HTTP(S). draft-hamrick-vwrap-foundation-00 builds on the previous work and describes the use and interpretation of HTTP headers and status codes for content negotiation and caching.

project brookdale provides PHP and JavaScript classes and C functions implementing the interface semantics of DSD. it allows web and application developers to easily manipulate VWRAP requests, responses and events.

a capability management facility and capability broker

web capabilities are an integral part of VWRAP. they allow distributed, trusted systems to grant fine grained access to sensitive resources without a global identity management system. an informal introduction to capabilities in VWRAP can be found in the earlier blog post, "VWRAP essentials : capabilities".

capabilities serve as aliases for RESTful VWRAP resources. composed of a cryptographically unguessable URL, they combine authorization to access a resource with that resource's address. the "capability broker" is the system component that maps a URL managed by a system to the object or database row it represents.

a simple VWRAP event queue over long poll

the VWRAP event queue is a simple abstraction for unsolicited server to client communication. VWRAP currently reifies the event queue as a "long poll" over HTTP. it is hoped that future work will specify the use of WebSockets as a carrier for VWRAP events.

simple connection manager with trust model support

trust between components in a VWRAP system is established by asserting identity using an X.509 client certificate. the VWRAP specifications do not require systems to trust any particular entity or certification authority, but they do require entities accept connections that use client side certs. in other words, a VWRAP system is free to ignore X.509 credentials from a client, but it must not disallow clients from sending them.

one ramification of the VWRAP trust model is it requires a "trusted" service to potentially present a destination-dependent certificate to a remote peer. an authentication service, for instance, may identify itself to an asset service by presenting it with a certificate issued by the asset service (or a trusted third party certification authority.) the brookdale connection manager maintains a mapping between destination URLs, client certificates and their related private keys.

VWRAP Authentication (including OAuth support)

VWRAP defines several "native" authentication technqiues as well as the use of OAuth in protocol transactions. the brookdale authentication components manage the process of user authentication and the seed capability lifecycle.

Client Application Launch Message processing

the VWRAP client application launch message (CALM) is an optional message sent to a web browser with specific details of which servers a client application (like the second life™ viewer) should contact to complete the login and rez process. intended to be used in conjunction with web authentication and authorization schemes like OpenID or OAuth, brookdale contains PHP, JavaScript and C functions to generate and process calm messages.

we're starting by publishing a few PHP and JavaScript files at the project brookdale page. these files are much more "middleware-ish" than they are "application-ish," but more will be coming in the next week.
the release of the code corresponds with the latest VWRAP abstract type system proposal. more code will be released at the brookdale site as the newer VWRAP drafts are published this month.

Thursday, August 26, 2010

net video startups, you don't get me

one of the great things about being me is i have a bunch of friends who work for startups in sili valley and i sometimes get invites to beta their wares. i work as a software developer instead of a marketing guru, so peeps frequently invite me to look at things late in the development process, usually to show off their technical mastery.

and i have to admit, i'm usually impressed. there's a lot of cool tech going on in the valley at the moment (even though we're in the middle of a double dip economic downturn.)

but i'm now a single co-parent. my extra time and cash goes into my family life and a college fund for the offspring. so if you want me to subscribe to your service (or buy your latest tablet) you have to show me some pretty clear value.

i had a netflix subscription until i realized i could easily replace my netflix use with hulu and redbox. and my hulu use is pretty minimal. i tried to watch lost and heros, but just couldn't get into them. i LOVE eureka and my son loves the clone wars. between my son and i, we consume about 2.5 hours of traditional televison content per week. the rest of our packaged video entertainment time is maybe 3 hours of movies per week. and when i remember to do it, i watch john stewart's daily show.

the rest of our inside entertainment time is spent playing video games (maybe an hour per day in the summer, but about two hours per week during the school year if all our homework gets done on time.) i spent a couple hours per week in second life or one of the independent OpenSimulator virtual worlds.

and i watch a metric boatload of youtube videos. i can't get enough dancing cats. i consume my media on my computer; but i would LOVE to watch videos on my TV. right now the only thing i use it for is to play DVDs and vintage nintendo games.

from talking with my peers, it seems like the main difference between me and other people is that the ratio of TV programs to youtube videos is a little bit skewed.

so i'm always surprised when companies like apple, sezmi, boxee and hulu try to shove "premium content" down my throat. i would rather wedge sporks in my eyeballs than watch most sitcoms. i won't pay to watch friends reruns or current episodes of two and a half men.

i would actually pay to watch google tech talks and nova on my TV (instead of my computer.) but i don't think i would pay much.

on thing that fascinates me though; watching movies online with friends. i used to work for the people that made second life, so it shouldn't be a surprise i have some social contacts "in world." one thing i really enjoy doing is getting a group of people together and watching a movie inside the virtual world. sadly, there's little content legally available.

the other evening 200 of my closest friends and i watched a broadcast from within second life on treet.tv. the program was obviously supported by advertisements, and i hope the treet.tv folks were able to charge enough in advertising to cover their streaming costs. the particular show, which dealt with weirdness in the emerald viewer community, had a very focused audience. if i were running ad sales at treet.tv, i would have charged a premium for the ads during that hour (due to the larger than average market,) and tried to find ads targeted towards content developers, super-users and open source developers.

i guess what i'm thinking here is there may be a "long tail" play here in internet video. youtube has part of this niche, but what i would LOVE to see is a ROKU or Nintendo video channel for "interesting science and technology programs." i have a nice television set i would like to use. but i don't want the hassle of a complete windows media center PC. i sure as heck don't want to browse the web on my TV. and i'm totally down with the idea of configuring my device on a web page i access via a desktop or laptop computer.

but the main thing i'm interested in is "watching TV with my online social network." i would love to have a "geek tv channel" that i program, that i invite my friends to view with me. i would populate the channel with live video broadcasts from the web: treet.tv, kink on tap, google tech talk reruns. i want to watch the video on my TV, but have a group text or voice chat session on my laptop.

i'm not so conceited as to think this is "the future of television," but i have to think it's closer than someone trying to sell me friends reruns for $20 per month.

Wednesday, August 25, 2010

VWRAP essentials : the event queue

this week on VWRAP essentials, i wanted to talk about the "VWRAP event queue." in the world of second life(tm) viewer development, the term "event queue" has a very specific meaning. it is a set of data structures, functions and UDP message types that communicate events from servers to clients. that's not what we're talking about here.

VWRAP is intended to be an application layer protocol that can be carried over multiple transports. implementers MUST support transporting VWRAP messages over HTTP(S), but there's been a lot of interest in optionally moving some traffic over XMPP and RTP. so defining anything in terms of HTTP is sort of a problem for VWRAP.

instead, we define an abstraction and then define a bunch of ways the abstraction can be reified by network protocols of real software. the VWRAP event queue is an application layer abstraction for a facility that delivers arbitrary, unsolicited messages to a network peer. in other words, the event queue delivers messages from servers to clients without a specific request from the client.

this is a general problem with interactive web applications as well, and a couple solutions have surfaced in the web community. embedding flash or java content in an HTML page is one solution. plugins for these technologies are readily available for popular web browsers. but VWRAP doesn't use HTML, and it certainly doesn't use a web browser.

another popular technique is "the long poll." interactive web apps implement the long poll by using the JavaScript XMLHttpRequest object to query a specific URL on the server. if the server has nothing to say to the client (i.e. - there are no unsolicited server to client messages) the server just waits, leaving the connection open. as soon as it has something to say, it delivers the message to the client. the client processes the event and queries the poll URL again, waiting for the next message. this technique is simple, but can be wasteful of resources in some programming languages.

more importantly, it's a hack. in a RESTful world, where accessing resources of HTTP is supposed to be idempotent, the idea getting something different each time you access a resource seems somehow unclean.

but there's an emerging standard for how servers should push streams of unsolicited data down an HTTP connection. it's called WebSockets. it's not without warts, and will require a little retooling of some of the web's infrastructure. it didn't include every feature that everyone wanted, but there's general agreement that it's "good enough" and is much better than using the long poll.

VWRAP could have defined the event queue in terms of WebSockets, but at the time it wasn't clear WebSockets would become "the" standard. it may also require some amount of tinkering with the infrastructure to implement, so it's not entirely clear WebSockets will work everywhere all at once. it's also possible that some organizations may be behind aggressive firewalls that will block WebSockets,

for all of these reasons, the VWRAP designers decided to create an "abstract" event queue that could be reified by sending messages over long poll or WebSockets.

the current foundations draft only defines the event queue over a HTTP long poll. future versions will describe it's use over WebSockets.