Democratic Parties: An Interview With UCLA Computer Scientist Kevin Eustice

from the the-lowest-common-denominator-dj dept

This was all part of an NSF-funded project that's intended to develop secure infrastructure for ubiquitous computing (a term coined in the 90s by Mark Weiser). We're interested in smart spaces and social software, and providing secure support for this type of infrastructure. We conceived our version of Smart Party more than two years ago, and built the first implementation of it in the summer of 2006. It was our idea that we would run an application that would get the developers who were building it—certainly myself and some of the other students in my lab—excited about it, because obviously we were going to be working on it for a while. We were really excited about the idea of social music, and managing that in a location constrained manner. We were developing an infrastructure that supported management of location context, device configuration, secure session establishment, et-cetera.

And this "infrastructure" is called Panoply, right?

Panoply is a middleware for developers to easily build ubiquitous computing applications; it looks at the device as the representative of the user in the digital world—your avatar, in the sense that it represents the user. We look at the requirements for this sort of device device as kind of a stack. At the lowest level, you have communication, just being able to automatically configure itself to an environment. Above that you have security. Above that, we have issues of social context and location context, and beyond that we want the device to be able to make the user's will count, to make it act as the user's representative in the social and location context it has acquired. So we have this hierarchy of device requirements, and when the device goes into a new area, it goes from the bottom up trying to establish secure connections, acquiring whatever context it needs to localize itself or identify social peers in the environment. Once that's done, the device can actually start to do something useful. In the case of Smart Party, that's voting on behalf of the user, participating in music interest groups in order to get certain artists played at the Smart Party.

What other functions do you envision for this?

A year before we built the Smart Party, we did another application, a locative media application, and used the same infrastructure to write a group-based interactive narrative. We defined a description language for writing interactive media that's tied to locations and has a social element—in other words, characters. We supported arbitrary social groups, but then we had Student from the English department at UCLA who developed the narrative for us using the facilities we created. So they wrote a science fiction story set on the UCLA campus in which a team solve a mystery on the campus. It was heavily inspired by live action role playing, alternate reality games, things like that

A pretty straightforward application we've considered is extending this to support context-aware museum experiences.You can provide media content directly to a device; you can customize it to social groups; you can customize based on the age or language of a person visiting the exhibit. It's really intended to be a general framework for manage location and social context. So anyplace you can imagine that would be useful to have, we can come up with applications that would support that. One of the applications I would love is: You're walking down the street and you want to know where your social network thinks is a good place to eat in the nearby area. We're starting to see the ability to take existing services and create something like this: If you take something like Facebook and merge it with Google Maps, you might be able to do something like this right now using Web 2.0. But we're looking at building general tools as opposed to specific services that people may or may not make open.

What about the privacy concerns raised by this sort of routinized information sharing, especially when it's designed to be keyed to someone's physical location and movements?

In general terms, I can't touch that. Ubiquitous computing has potential to do great good, but obviously when you're talking about sharing immense amounts of personal data there's also potential for great harm. In the Smart Party specifically, we have thought it through: We've considered privacy to the extent that we don't want to just publish your entire set of musical preferences to the environment when you enter someone's home. That's why we're looking at things like voting protocols, where individuals may not suggest certain songs. That way you're not publishing your full set of preferences, but a very limited set that may even be location dependent. Musical preferences may not be the most sensitive data, but you can extend the metaphor.

Is Digital Rights Management technology an obstacle to something like Smart Party? Or, for that matter, public performance licensing fees?

There are a couple ways to deal with DRM. One is the iTunes approach, where you license another machine to play your content. If we can do that in a dynamic manner, an automated manner, you could license the local room or Smart Party infrastructure to play back a single song, maybe a one-time-only license. But recently we've seen studios releasing DRM-free music, and if that trend continues, that would be perfect for this type of application.

Alternatively, we can bypass that altogether and really only exchange preferences. Then the music is drawn from a pool that's already there in the environment, and DRM is a non-issue.

Most of the scenarios we've envisioned aren't really what I think would be considered a "public performance." If you're talking about actually using this at a real club, you'd have a whole set of other issues we haven't really considered—thinking about how to make this a real product hasn't been our focus.

What's the next step?

Well, I'm working on my dissertation, so what's next for me is graduating. But we've got some other students who are extending the Smart Party, looking at more coordination algorithms, better voting algorithms. Some of the comments in the blogosphere have pointed out that if you're only replaying the same old songs, that's not a very interesting algorithm. So one of the things we've been looking at is incorporating the notion of surprise, finding songs we can predict people would like based on their other preferences and drawing those out—the long tail, if you will, of the preference set. We're also running a lot of simulations. I've probably simulated several million parties in the last year looking at how different voting algorithms affect the satisfaction of the party goers. That means looking at overall satisfaction, but also the distribution of the satisfaction, how fairly satisfaction is distributed.

We're looking now at issues of multiple rooms in a party environment. If you have a certain number of rooms and a certain population of people, how can you change the overall song dynamic to increase satisfaction? Can the infrastructure figure out that there are population groups that aren't being satisfied but could be satisfied by looking at the voting trends and maneuvering people by playing certain music in certain rooms to draw them out.

Though Arrow's Theorem tells us that every possible voting system breaks down somewhere.

Well, we've been looking at different types of voting schemes as part of this work. Our current scheme is a modified Borda count, where we use a point allocation system that allows us to evoke secondary preferences. You'd often have hidden preferences in a preference vector if you've got a bunch of songs you rank one through five. If you're just voting for those songs, there may be songs that would be just as good, from the perspective of what you'd like to hear, and you end up enforcing a false ordering.

I do think it's fascinating that what seems to have caught people's attention is the whole idea of voting for music in an environment. In a way, that wasn't really the point of the project. The point of the project was that someone could go to an environment they've never been to before with a device that's transparently configured to be part of that environment, and receive information that lets them figure out where they are in that environment. We want our wireless devices to be behaving, from a usability perspective, more like our cellphones: You expect that you go someplace new, and it just works. And that's not just that you get "on the network," but that you get on the right network for the application for the application you want to be using. So going in with whatever credentials or authorization we need, we can get all the context we need for localization and discovering other people at that party with no user intervention, or anyway minimal intervention. That's what really excited us, and the application was a way of finding something to do with it—but it's really cool that people have shown so much interest in it.

Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.

Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.

While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.

–The Techdirt Team

Filed Under: democracy, dj, music, parties, shared, ubiquitous computing