At ProjectVRM we call EmanciPay “a relationship management and voluntary payment framework in which buyers and sellers can present to each other the requirements and options by which they are willing to engage, or are already engaging”. These include preferences, policies and choices about what to pay and how. (Actual payment would be carried out by PayPal, Google Checkout or some other system built for the purpose.)
All of this is new stuff for buyers, and we’re not building it all out at once. In fact, we’re starting with a small piece of code for the seller’s side, so they can signal willingness to engage with buyers in the free and open marketplace, rather than only in the sellers’ own silos. If they want to signal that willingness (which we might call “VRM-friendliness”), they’ll include a bit of RDFa code in their Web pages. If that code is present, the seller’s r-button goes from a default gray to red. If the user already has a relationship (or has had some other interaction) with the seller, the buyer’s side r-button also turns red. So, in this mocked-up example —
— I can see that KQED is VRM-friendly, and that I already have had some kind of dealings with the station.
Right now the code for both sides is in the works, and is also a Google Summer of Code (GSoC) project. It builds to a large extent on Tipsy, described as a “a framework for voluntary donations to bloggers, musicians, and other content creators on the web”. Tipsy is the creation of Oshani Seneviratne and Adam Marcus, both grad students at the MIT Computer Science and Artificial Intelligence Laboratory (CSAIL), whom I got to know through David Karger, a professor at CSAIL, whom I got to know through Keith Hopper, who fathered ListenLog. Our GSoC programmer is Ahmad Bakhiet, a student at Kings College London.
When we’re through with the current stage, we’ll be ready to test out the seller’s side code with stations (or with anybody), which will include means for deciding what happens when the user clicks on the right-side r-button. What matters most at the first stage is the signal of VRM-friendliness, which is a huge state-change form the old silo’d business-as-usual. What it says is “I’m open to what you bring to the market space between us, and to a potential relationship.”
We have this in the real brick-and-mortar commercial world, but not in the e-commerce world, for the simple reason that we have lacked mechanisms for creating the open market spaces between buyers and sellers — the space in the middle here:
1995: Invention of the cookie.
Cookies are bits of code that sites put in your browser to help them remember stuff about you. These are handy in many ways, but they also put all responsibility in the hands of those sites — of the sellers.
And if you want to do serious shopping, you can’t just put down cash or a credit card, do your business and walk away. No, you have to register. And to do that you need to accept terms of service that are known in the legal trade as contracts of adhesion. These are usually not read by users for several reasons, the most important of which is that they are not negotiable. Whether or not they are unconscionable, or enforceable, is beside the point. If you want to do business, you have to agree.
Where contracts of adhesion apply, markets are not conversations.
Needing to accept these contracts is a big source of friction in the online marketplace. It’s one of those areas where things are slower online than off. It is also therefore one of those areas where the better model is the familiar offline brick-and-mortar one. (In fact, one could argue that loyalty cards bring to the brick-and-mortar world one of the more annoying inventions of online retailing.)
So that’s a big part of EmanciPay’s challenge, and something we’ve been working on at ProjectVRM. What we’re working to create is a two-sided approach to eliminating the need for users to accept one-sided contracts. We’re creating code with easily-understood wording and symbols, which can be read by lawyers, ordinary users, and machines (ideals first articulated by Creative Commons.) This code can be used for expressing preferences, policies and bases on which each side can trust the other. There’s much more that can go on both sides, but those are a start.
When you click on the seller’s r-button in EmanciPay, you might see a pop-down menu that looks like this:
The new item there is the symbol I’ve labeled “terms”. It’s one half of the iconic “scales of justice.” A similar one might be on the buyer’s drop-down menu as well. Also there might be preferences, standing requests for products or services, links to personal data stores, or whatever we feel like putting in there.
We see the r-buttons and their affordances as places where both the buyer and the seller (or the individual and any organization — this needn’t be limited to commercial settings) can offer, selectively, means of engagement and the data required.
But one of the first jobs here is to get the paranoid lawyers out of the room and the engagement-oriented ones in the room, to help describe new terms of engagement that yield little or nothing in real protection, while offering means for engagement that reduce or eliminate the frictions to which we have become too accustomed over the last fifteen years.
While we’re still baking EmanciPay, I want to visit some questions about what my actual or potential interactions with KQED, WBUR, WWOZ and other stations on my ListenLog might be. There are many possibilities here. One might be to take a budget that I pay down proportionately through time. Another might be to just throw some money now and then at sources of programs that I’ve found especially good — or that I like right now, for that matter. We can be real-time about this. Another might be to pledge money to stations where which I spend more than X amount of time. The list can go on.
I can also, at my discretion, also share some or all of my data with stations and other parties (such as program hosts or producers).
And I can also open myself to programmatic approaches, created by other parties, that work inside the EmanciPay framework. The possibilities are endless here, and suggestions are welcome.
At this stage we plan to test out and play with EmanciPay at first by using Tipsy‘s lottery model. In this one, listeners pay one source, on (say) a monthly basis, with the source being chosen as the winner of a lottery. In other words, if you look at the list of stations on my ListenLog, I would budget $X per month to pay out to some lucky public radio station. Code on the station’s side (the same code that lights up the seller’s r-button) would make them eligible for winning my monthly lottery. At the end of the month, the lucky station gets paid. Get enough listeners and stations involved, and we can have some fun with it.
But that’s just a small first step. The ones that follow will shake down richer and more symmetrical, involved and cross-informative relationships between stations and listeners — and then expand out into other territory, I hope starting with the music industry. From there we can move on to other content industries, and then to the broader marketplace in general.
If all goes according to plan, r-buttons will be commonly used and well-understood symbols. Of course, plans can change. Alternative ideas are sure to emerge, along with many improvements to this one, which is among many others in the VRM movement. It just happens to be the one I’ve been working on most.
Meanwhile, big thanks to to Vince Stehle (who has moved on from Surdna, but made the grant happen when we needed it most), to Keith Hopper and NPR, to Jake Shapiro and the crew at PRX, to many other friends in public radio (and to ones in free commercial radio as well, such as Bill Goldsmith of Radio Paradise), to Daniel Choi, Oshani Seneviratne, Adam Marcus, Ahmad Bakhiet and other helpful programmers, to the VRM community, and to the Berkman Center, which has kept faith with me and with ProjectVRM through the years required to get things off the ground.
We’re still getting started here. But we’ve come a long way too.
Comments are now closed.
@wendycockcroft No, a kind of code. Stay tuned. :-)