I'll be hanging from the hope that I'll never see that recipe again

Finally, after enough involvement over enough time to become "that guy" to more than a few people, I've stopped using, reading, and caring about Second Life. It's not a very forward looking system, its being locked up by a single vendor preventing the development that could make it great.

Starting from the basic fact that they're both San Francisco startups, I've always seen parallels between Linden Lab and Six Apart. That makes it hard to actually argue what I just wrote without slipping into or having to defend its business model: selling an internet service on which it has a natural monopoly through source code control. I could argue that my employer's business model is not something I can control, but thinking of it more locally, my "business model" rests solely on the company's. At least, that's so if we were speaking morally instead of economically—and if economy is the science of scarcity, doesn't it have great moral implications?

Instead, I would argue actual differences. We aren't the only vendor of blogs; in fact, we're in a pretty competitive space, competing not only with other blog services but other supplementary products (photo hosting, social networks, etc).

Really, though, Second Life is not a community to which I belong. I might find it useful to start doing my own thing, cultivating my own little basement metaverse—it's an unfilled facet of my life as of a few months ago—but at this point it's hard for me to want to replace Second Life, too. I thought I had some good ideas about building a new internet community (in a larger context than, say, the social MUD theses I wrote a while ago, I mean). I started writing this post probably a month and a half ago, with a very different focus. I had a plan, a rudimentary program design. I even imagined a brand identity, and bought the domain name.

This is the crest of a wave, though. Had I acted when I was first developing the idea, I could have helped lead a movement toward a more open system. Garages are starting to hum with the activity of cloning and refining the formula Linden Lab is selling so hard. The basement pirates are already building (not to genericize [info]jarodrussell's term of art too much). At this point even the bloggers are realizing a closed metaverse does not sustain (despite my best efforts I lost the link I was going to cite—I hope I didn't imagine it).

However I like to think duplication is not my cup of tea. Plus things are going better at work, so the fantasies about my own startup are firmly back in the realm of fantasy. (Good thing too, because going into business up against so established a player as Linden Lab in a space about to be so crowded is surely crazy talk.) Plus I spend barely any free time alone at home, so I don't have any time I could build such a thing, anyway.

I guess I should talk about the program plan I was developing. The idea was guided by three precepts:

  • Distribution. Linden Lab has shown that you can get amazing horizontal scale by sharding geographically, connecting servers at the physical edges. However, that doesn't let you scale where you'd most like to: inside one place. To step that up, you'd have to model the world in a differently (you might say "more") distributed architecture. You need to solve the problem of how to increase computational density of a space, and scale inward, not outward.
  • No invention. There's a bevy of free infrastructure parts for delivering data and user experience. It happens to currently all be optimized for experiences shaped like web sites. Use them. (I think this is what drove me from MUDs: you can't reuse components when your system is some ancient C monolith, instead of a pluggable n-tiered service. Hell, split the difference and be a gooey UNIX pipeball, just give me options.)
  • Modest goals. Even using commodity parts, Linden Lab has a big head start (in marketing, if nothing else). Unless you have some field-changing advantage, you can't compete in their niche--mdash;but then, you shouldn't, anyway. Imvu is in a good place here by being differently good.

Based on these axioms, there were three possible products. The first was I (one), and it was the latest evolution of the MUD I always wanted to build. So you have a universe of objects; make each object its own service on the internet, exposing an API by which they can communicate with each other. "Hi, Room, I'm a Thing. May I move myself into you?" "Hello, Thing. (I see you're operated by Player, who is trusted by my operator with that permission.) Sure! Here are my description, exits, and the URIs to the other objects I contain..." Make a gateway service that's a telnet server, which presents itself to the world as an object you inspire, and converts your commands into messages to other objects and messages from other objects into text output for you to read. Very distributed, and so modest I doubt I would bother making it for its own sake.

But from that idea, it's a small leap to the product I called 3D: render the world not in text but as a 3D scene. It's the exact same thing. You can pull textures and rich content over HTTP to leverage web infrastructure parts. (The main reason I started considering seriously the entire possibility of competing services to Second Life is because I found with a little research that the core renderer for Disney's Toontown kids' MMORPG is open source, co-maintained by Carnegie Mellon for use in computer/media coursework.)

In the middle of the two is the path I considered most seriously, and which I was calling 2.0. This is something like the same thing, but instead of using a that speaks MUD, or a 3D program, the interface is a dynamic web site.

The truth is—and I realized this most only just now when I wrote these here descriptions of I, 2.0, and 3D—you could make one contiguous metaverse that supports all three interfaces. It would lay the burden of making three interfaces for every object on content creators, which you wouldn't want to do, but it would be possible at least.

Ultimately, without the work, these ideas are worthless. The ideas of anyone who produces running code are greatly more valuable. As I learn I don't have to do everything (because, as you might expect, I can't do everything), I feel more like it's fine if I don't participate in this movement. On the other hand, if this new energy truly is a rising tide, and if I aspired to compete, then the name I picked would be eerily prescient: I chose Waveshark.

Previous EntryAdd to MemoriesTell a FriendNext Entry

Comments

untitled

This is such great clarity of thought -- I'm glad we're doing right (enough) by you that you're more comfortable with your role. I still have to process a lot of this, but my immediate thought is that I want to plug that rendering engine in on top of Vox. If you arbitrarily map content/presentation decisions in HTML to ones in 3D space (using "stella dog" theme == "live in a castle") it could be pretty interesting. :)

untitled

I'm sure having Vox around has influenced these ideas some! Even as it is, it hits some of the same recurring themes.

untitled

Have you seen http://libsecondlife.org/ ?

Seems to have very similar ideas and goals. An open client that interacts with things on a more meta level? I've just learned about it today, so.

Anyway, I've always wanted to get into this space. I think CCP is a great forward step in my goals towards that, especially with some of the things we've got cooking up internally. All game related, but you never know where the technology will go in a dozen years.

untitled

Yeah, the dam broke for all the “let's replace SL” projects after the libsl people released Copybot (which also exploded the project from inside out last I heard).

I don't think it'll help though (I can't make myself care about libsl any more than I do about SL itself, at least). They're voluntarily lifting all the legacy problems of SL on their shoulders. All the interesting experiments are taking lessons from SL and starting over from first principles otherwise.

untitled

Bingo. LibSL is a dead end, ultimately, since its pretty much tied to SL's misguided legacy. That's even after attempting to ignore the drama from some of their members and the fact they've essentially just shuffled each other around on paper and nothing more. For one, they're pretty much verboten from attempting to emulate the server software right there in the TOS, even ignoring the fact that a physics engine just isn't going to fall from the sky and bless them, anyway.

I know you and I have discussed these subjects a fair bit. I dunno, I've been a broken record about LL as a startup, the conflicting statements and lack of direction, how SL itself is not a sustainable business for either LL or the people operating within SL itself, etc. I'm sure this was really annoying to hear from me two years ago, but meh.

Ultimately, I'm not very optimistic on the idea that the next big thing is really going to relate or even learn from SL, per se. I don't place much stock in many of the hobbyist developers attempting to 'do it like X, but better' as it stands. We'll see. I'll speak to you on AIM or something about it.

untitled

This is going to sound insane, but MMOG's need a Dave Winer. Instead of focusing on building all the software-solutions, someone needs to sit down and lay out a protocol/schema for communicating. (Which you said in the second-to-last paragraph, mostly I wanted to nail down that XML seemed the best way to design this protocol.)

The "scaling inward" problem gets solved if you treat worlds and objects as syndication feeds, because then all the "host" has to deal with is bandwidth -- something that Amazon's S3 and similar services would make cheaper and feasible.

Also, genericze away. ;)

untitled

There are already the protocols we need for the basis of stuff:

HTTP (transport)
RDF (syndication and descriptive stuff and so on)
XMPP (realtime messaging)
VRML (object descriptions)

I believe VRML also has stuff for animation, though I don't know how verbose it is for things like skeletal deformation or what have you.

Still, I can totally see a completely distributed virtual community based on those four technologies (well, three, with HTTP as the underlying transport for the others).

A room is an XMPP group conference with VRML (or RDF which links to VRML or whatever and links to other rooms and so on). An avatar provides an RDF which links to a profile, VRML + skeletal deformation info + animation info + whatever else to give others an idea of what they look/sound/move like. (Back in grad school I developed a few theories about how to use a simplified linear algebraic transform as a "pump" to allow trainable physically-modeled actions rather than requiring people to actually keyframe animate things or whatever, though these theories are still untested, what with graduating and then real life getting in the way.)

I think the main problem is that people are thinking TOO HARD about the problem and not realizing that all the solutions are already there!

This was the original promise of VRML, and back in its heyday I remember seeing some pretty clever things done with it, such as CGI-based procedural modelers and so on.

untitled

Yes, this is exactly what I meant by zero invention!

I was already thinking XMPP for the object messaging. I guess VRML would work for object descriptions; I don't know anything about VRML. Does it have a method of describing changes in objects by themselves, or would you have to retransmit the entire representation?

There's not really an analogue for a MOO or web chat though, so you'd have to invent that part for those.

untitled

VRML is an XML, and thus can use plain old DOM methods for incremental updates.

untitled

RDF may work best for what the Basement Pirate Markup (or Modeling) Language (BPML) was intended, however I'm not too familiar with RDF. I eschew XML namespaces as much as possible. The only purpose of BPML is to...

1. Define an area (name, width, length, height, ground texture, etc.) of a location.

2. List all the objects within a location, and in doing so list the "asset servers" where they come from.

3. List who's in an area, where their avatar comes from, etc.

I really didn't want BPML to be a 3D modeling language or a chat system; it's strictly a inventory system for laying out the bare minimum of a virtual world. Everything else (objects, chat, etc.) should be as interchangeable as possible, so you can use the latest 3D engine or a basic 2D web browser to generate a world. Chat too, I'd think, would be client specific. Some would use XPMM, other AIM, etc.

If RDF can do that, then it would be much more preferable than re-inventing the wheel.

untitled

Er, how is BPML any better than VRML?

RDF is a generalized syndication/container format (essentially a very loose form of RSS; it's what RSS grew out of). Ostensibly the XMPP environment would somehow link to RDF which would link to VRML documents describing the room and says which objects are present and giving their relationship to the current room (including physics and ownership and so on), and actions on those objects would be sent to the RDF's controller (linked to from the RDF), which could also be queried for, say, changes since a certain timestamp (with the original timestamp stored in the RDF, so no need for NTP sync since it'd all be server-relative).

The great thing about the RDF format is that it'd give you the ability to put in other content descriptors, too; it can also link to, say, an image, or a text blob, or whatever, via LINK tags (or whatever the RDF equivalent is; I'm not too up on its actual format intrinsics).

The XMPP environment would also have, in the information about the individual participants (I'm sure XMPP provides some provision for that!), an RDF link for the individual participants, which would have their appearance (again with multiple content-types, e.g. text, VRML, image, etc.), text formatting styles, carried objects, movement behaviors (as links to a procedural descriptor or various skeletal deformation animations or whatever), and so on. There's no need for an "asset server" because it's implicit to the RDF link. People can host it on their own server or get hosting from somewhere else or even put it on Geocities, and they could do whatever fancy stuff they want with CGI-based RDF generators (look different to everyone in the room! change appearance based on time of day! etc.). As long as there's some XMPP primitive which could be used to tell other participants to update the RDF, there's no problem.

As far as inter-room linking, that'd (again) be on the room's RDF; there'd be something like <link rel="portal" href="XMPP conference identifier" etc> where "etc" is attributes giving its relationship in the world (for example, polygonal extents in the source and destination rooms). It'd be up to clients to decide whether to honor the portal at all or whether to treat it as physical or to let people be in multiple rooms at once or whatever. There's also no reason there couldn't be one-way portals, or references between rooms which don't make physical geometric sense (think Valve's "Portal" game - I've been working on these ideas LONG before the students who started that game even enrolled in DigiPen but it's a useful way of describing it), or whatever.

Obviously there's no good way of protecting content or making it truly "physical" with such a scheme, but that wasn't the case on SL either (and it's not as if libsl copybot surprised anyone who has even a basic understanding of networking or packet sniffing).

Anyway. There's still a bit of other stuff which can happen before this is quite feasible; last I heard, XMPP's conferencing protocol hasn't yet been formalized (and it's a tough problem, since there needs to be some way of enforcing permissions without XMPP having any sort of centralized session or statefulness - two people can easily Jabber away without being on the same server, which is the whole point to it). One-to-one conversation permissions are easy to do, but many-to-many, with the permissions based on the "room?" Kind of difficult.

One temporary way of implementing this would be to have rooms themselves as a special chat participant which just relays stuff to everyone else in the room. An XMPP server which allows users to create these pseudo-users on the fly and get, say, UUID@servername, would work fairly well. That way you could also implicitly put build quotas into the server (and if someone wants unlimited room building they just run their own XMPP server with these capabilities).

untitled

Er, how is BPML any better than VRML?

I'm hesitant to use VRML at all. From what I understand, VRML is a language for describing 3D objects. I dislike the idea of making any one rendering sceme a part of the "protocol" because that seems like it would make handling Poser, Max3D, Blender, Half-Life and other 3D systems harder for the client. My current thinking is that each client should be able to handle any kind of object, and the communication scheme (be it RDF, OPML, BPML or whatever) should only convey inventory and placement informatrion.

But to answer your question, BMPL isn't meant to replace VRML. It's what I was thinking of using to send inventory lists to clients. That said, there may be no need for BPML if RDF can do that. From what you say, it seems like it can.

Combinging OPML list with an RDF feed might be all you'd need. The OPML lists the "world" hierarchy, listing placement locations and item keys. The RDF then could contain all the other information required (file location, size, etc.).

There's no need for an "asset server" because it's implicit to the RDF link.

Right. I tend to call the web servers that hold objects "asset servers," because if you say "web server" to Second Life people they wonder why you're serving HTML files in a 3D world.

An XMPP server which allows users to create these pseudo-users on the fly and get...

Just off the top of my head, would it be better to use FOAF for this? If people already had assigned ID's -- even loose ones -- then no matter where you went, you'd still be the same person.

untitled

XMPP provides identity in a secure, authenticatable way. FOAF is just a way of saying "assuming this person is who they claim they are, here is where you can get metadata about them." What I meant was something like that, though - have the XMPP session link to an external metadata document (an RDF of some sort), rather than having the metadata stored within the XMPP session itself.

IIRC, FOAF uses RDF as its underlying container format, FWIW.

untitled

When I started visiting SL more recently and playing with the games people had implemented inside of SL, the promise of distribution is what most stood out for me. Centralized servers are great for shared content development, communications, property security, and prototyping new concepts. But I'd love to be able to specify, "Everything within this cube can be taken over by a plugin."

That client-side plugin could start as a simple racing game, running peer-to-peer for speed considerations and taking control of little more than positions/orientations of players, perhaps swallowing a few keyboard commands for itself. But by adding more and more hooks, it might become someone else's metaverse entirely, limited only by having to work through SL for money changing, messaging, and permissions on accessing/altering any data persisting outside of the plugin space. A thin API, just enough to implement a simple game, could iteratively develop into a whole distributed system. At each step, it would kick out tons of new games and ideas as people find uses for their newfound control.

They're adding mono (GNU .Net runtime) support to replace the old scripting system, as I understand it. It should be added client-side as well to help kick something like this off.