Democratic Parties: An Interview With UCLA Computer Scientist Kevin Eustice
from the the-lowest-common-denominator-dj dept
If the ecstatic attention techblogs showered on the nascent Smart Party system last week is any indication, there are thousands of geeks out there who, like me, got their first peek at an iPhone and immediately began fantasizing about a spontaneous, democratic, distributed jukebox that would emerge anywhere friends with shiny gadgets gathered. Smart Party polls all WiFi-enabled music players in the vicinity to figure out what’s on user playlists, and then plays music off a central system (even pulling tunes directly from each user’s device) tailored to the taste of the group. It’s like a DJ who automatically knows what will most please the crowd. But as far as UCLA computer science grad student and Smart Party co-creator Kevin Eustice is concerned, plebiscitary soundtrack software is just a tiny part of a broader project, aimed at crafting an open architecture that will enable a whole range of mobile, location-sensitive social networking applications. Below the fold, my interview with Eustice on music, math, and the future of ubiquitous computing. If you’re reading via RSS or from the front page, click on “Read More” to get the full interview.How did Smart Party come about?
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.
Filed Under: democracy, dj, music, parties, shared, ubiquitous computing
Comments on “Democratic Parties: An Interview With UCLA Computer Scientist Kevin Eustice”
Very interesting. Stuff like this makes some of my favorite Sci-Fi technobits seem plausible. I can almost see a day where everyone has a microcomputer in their pocket. A kind of Universal Electronic Gadget that does everything from Net browsing and e-mail, to telephone (even group telephone) calls, to live GPS navigation. Heck, it could even pick up digital TV signals or let you read e-books.
Only downside is even if something as cool as that comes out, it’ll be destroyed by corporate greed. All the features would be hamstringed, and you’d have to pay extra to use each feature on a monthly basis so they could just milk you.
I would much rather they just charge for updates. Would be nice for those who are knowledgeable enough to be able to make their OWN fixes to any bugs, and their own custom software.
But its one of those idealistic things that would be absolutely wonderful if it became true, and thanks to a greedy few probably wont in the foreseeable future.
Oh and before angry dude makes any comment on this article, he’s an idiot and just ignore him. Be a nice Mozilla plugin idea to have a feature much like the ad blocker that blocks user comments on websites by their user name. Then I wouldn’t have to see the idiocy and bigotry that is angry dude. Was bad enough when it was just Dorpus . . .
how long before the RIAA and the likes cracks down on this for unlicensed public performance?
Mobile devices transparently configured
to be a part of the environment. I loved that phrase. There are so many awesome ideas here, and I tend to have an optimistic outlook that all the creative business people and web wonder-workers out there are going to find ways to help the new models become functional and thriving. It’s ok if it isn’t easy. It’s certainly worthwhile.
Thanks Kevin and Julian for a great post.
Context is king...
It seems to me ranking a song one to five isn’t quite granular enough for this application. I may have classical pieces or other more studious works hanging out on my playlist — and depending on the partygoers, many of them may have the very same, but that certainly doesn’t imply I’d want them to play in that *context*. Of course, ranking songs on an additional, contextual dimension seems like more trouble than it’s worth. Perhaps in the same way they’re drawing psychoacoustic data to “long tail” the resultset, they could use some of that to make sure duds don’t slip through.
Re: Context is king...
You’re absolutely right. Which is why we need to incorporate more information about genre, BPM, mood, age appropriateness, etc. from the metadata (or from datamining), and enforce certain rules about appropriate types of music transitions. We don’t want to switch from dance music to Bach to Barney…