Life & Research Notes

For my Hacking Second Life project I was interested in the trails of data each Second Life resident inadvertently generates without any awareness or control of its usage. While content creators in Second Life have some control over the licensing of their work, how do we navigate and manage the digital content created simply as a result of ‘living’ in a purely digital world in which our speech, gestures and actions are made of the same stuff as our code, clothes and cars? How do we decide whether others use this content? Can we set up personal license policies for our personal data?

To begin thinking about these issues, I wrote a small script that may be attached to any object, and that sends all locally overheard chat to a “Permanent Record” web application via an HTTP post. On the web, visitors may then view a list of the names and unique keys of all people recorded and all listening devices, and can view a live updating audit of all chat.

The site acts as a real time observation post of all conversations taking place within range of any of the listeners, revealing speaker identity, content, location and time. Check out the screenshot and screencast (24MB) of the permanent record and recorder in action.

I plan to put up a more permanent version of the site as soon as possible, and I’ll install a few listeners around some MIT or Media Lab sanctioned land. I’ve been tempted to attach the script to a variety of different types of objects, especially projectiles so I could launch them towards interesting things happening. It would be interesting to have these things distributed all over the place, though at some point I’d probably be violating the Linden Lab ToS.

Luis and I tested out the recorder a little…

Unfortunately he felt compelled to sit on it.

Check out the LSL source code. If nothing else, it at least has some generalized little functions for sending RESTful HTTP posts. Since Second Life only allows 20 HTTP requests per 100 seconds, my code queues up overheard statements and sends them in batches.

I just now added a quick and mellow search API for Tiny. The url looks like this:

http://tiny.media.mit.edu/search/<term>.<format>

Formats can include html, xml, or js, with html as the default. Try out some samples:

sign (xml) (json)

coffee (xml) (json)

face (xml) (json)

world (xml) (json)

Update: Check out the Tiny Search API documentation. I also added support for an optional callback parameter for the json format. Explanation and examples are on the search page. Should be ripe for mashups now.

Luis has released the OS X dashboard widget for Tiny. It’s true to the web version in its interaction, yet as a widget provides a more accessible, always-available interface. Check out related posts by Luis and John, and be sure to download the widget from Apple.