Text archives Help


Re: [projectvrm] One-click micro payments, membership monopoly, monied "like" button


Chronological Thread 
  • From: Peter Cranstone < >
  • To: Kevin Cox < >
  • Cc: Tom Crowl < >, John S James < >, William Dyson < >, Doc Searls < >, ProjectVRM list < >, David Brin < >, "Grant, Frank (Perkins Coie)" < >, Michel Bauwens < >, Kendria Pearson < >, "Andy Oram" < >
  • Subject: Re: [projectvrm] One-click micro payments, membership monopoly, monied "like" button
  • Date: Sat, 21 Dec 2013 19:15:38 +0000
  • Accept-language: en-US
I’d hedge your bet. Bitcoin is here to stay - is it unstable - Yes, but it’s a payment solution that has tailwinds. Invent your own but support the current winner. 





Peter
_________________________
Peter J. Cranstone
C: 303.809.7342



  

On Dec 21, 2013, at 11:28 AM, Kevin Cox < "> > wrote:

Tom,

Here is how I understand John James' ideas.  John can correct me if I am wrong.

John is creating electronic cash.  He is giving an electronic form of taking cash from an ATM machine and spending the amount we take out in small lots.  He does this by giving us an electronic way to create smaller amounts of money from a larger amount and a way to spend it.

In principle it is a good idea.  For it to work, and not be gamed, the money tokens should be like cash and be interest free.  Also the value of the tokens should not erode with inflation.  I like you, believe that we have to work with regular money but it needs to be divorced from the financial sector where cash earns interest and where all currencies suffer from inflation. 

Kevin

PS. This is the promise of bitcoins but bitcoins are computationally expensive and their value is unstable; hence they are unsuitable as electronic cash.




On Sun, Dec 22, 2013 at 1:43 AM, Tom Crowl < " target="_blank"> > wrote:
Good to see this active discussion going on! And John James' ideas seem like an interesting approach offering a lot of flexibility. And I take his word that its software would be easy to write.

But I'm not a programmer and so its seems awfully complicated to me. 

John, would a system like yours be better able to arise within or accompanying the entity I envision? Could its existence make it easier to see your vision  come to be?

I've been fairly convinced that to ever get adoption of much of anything in this area... or advance the use of currency alternatives... it must at least begin with traditional currencies... and be independent of the financial services sector.


On Fri, Dec 20, 2013 at 5:33 PM, Kevin Cox < " target="_blank"> > wrote:
John this is most interesting.  The credits we are creating could be used with your system.  Money tokens are a promise to pay and provided the supplier of the tokens can be trusted to honour the request to redeem the tokens then they can be used for any purpose.  The important issues are that the tokens must never have a value simply because they are tokens.  That is, there is never any time value of money.  The value of the tokens must be agreed and be related to some agreed product or service.

Once you have tokens with these properties then the tokens can be used in systems that you propose.  That is, you could build your system using credits from individual systems that you can trust.

The problem with using regular money is that the money can earn interest while "at rest" and hence there is an incentive for the money to be stored and not circulate.  This means we get far too many tokens created.  The second problem with regular money is that it does not hold its value.  All countries in the world seem to have accepted the desirability of inflation.  That means money tokens change their value over time.  The third problem is that the value of regular money changes arbitrarily because of currency exchange fluctuations.  Because of variability in value it becomes possible for people to game the system, gamble on changing values, and accumulate interest bearing tokens.  This undermines systems such as replicounts.

We could fix the existing system if we stopped creating money tokens through issuing debt - but that is not going to happen.  

An alternative is to create stable money tokens ourselves and not wait for others. Individuals, Companies, Government instrumentalities and Not for Profit organisations, can create their own individual money tokens by tying them to a measurable product or service that they produce.  Those entities that prove they can be trusted to honour their tokens can then feed them into systems such as yours.

Kevin


On Sat, Dec 21, 2013 at 5:51 AM, John S James < " target="_blank"> > wrote:
I've been working almost as long developing a software idea for more easily implementing all kinds of financial systems -- whatever you want to put into them. But it's been so hard to get people to understand what this concept is and why it's important, that I've basically given up on that, and will be working on specific applications instead. But for this group, here's the main idea.

If you allow online financial accounts to replicate (reproduce), then the "children" accounts can of course inherit money from the parent. But far more importantly, they can also inherit any number of options and settings that customize and control the account, and can control all sort of applications that can be embedded within the accounts themselves (where the friction from the financial transaction process itself will be near zero). These accounts can inherit hundreds of such settings instantly, at "birth." They can handle many languages and payment methods for each, make many of their own decisions, consult with their owner only when necessary, and even self-destruct in case in inactivity, returning any money and information value as directed, in case account access is lost. We think that many users will often go through several accounts per day, creating and destroying that many in one day's business; meanwhile the same user can have other replicating accounts that are used occasionally for years.

One of the most important changes from prevailing procedure will be far greater options for owners to set the tradeoff between convenience and security. For example, a 5 cent or 50 cent anti-spam micropayment (to let a stranger's email bypass filters and reach the recipients personal attention) could travel with the email in the clear. Not only is the amount hardly worth stealing, but the code transmitted could pay only the specific recipient, and be useless to anyone who didn't have occasion to pay that party. Also -- with multiple accounts, the best security is not to have serious money in accounts created for convenience over security.

And such accounts will evolve through many generations with different human and/or corporate owners, as they are selected for usefulness and user-friendliness.

The most important application will be what I've called mass sponsorship. This is a way for independent digital artists, musicians, videographers, reporters, and other "knowledge workers" to get paid online -- but NOT by micropayment from everyone. Instead, anyone with money to spend can be an instant sponsor -- buying handfuls, hundreds, or thousands of prepaid free accesses at bulk prices and distributing them publicly or privately through networks as they wish -- with their own optional message (which can be an advertisement) attached if they want. This ad or other message can then reach specialized audiences based on content interest plus network status, audiences not otherwise targetable. There are all sorts of additive or synergistic motivations for participating. And for whomever provides the service, monitization is automatic -- just charge an agreed percentage of all money coming in, probably well under 1%.

For several reasons replicating accounts should make this software considerably easier to write and debug than would otherwise be the case.

For more information a starting point is www.replicounts.org. I've written a lot over the last six years -- pardon that it's not all cleaned up and reachable from the home page at this time. I'll fix it up when and if there's any interest in this idea besides my own.

John S. James


On Fri, Dec 20, 2013 at 9:24 AM, Tom Crowl < " target="_blank"> > wrote:
Believe me I know how hard it is to get heard... I began with this back in early 2007 with an obsession about the potential for the micropayment in overcoming the power of 'big' money in politics... and that the micropayment would paradoxically actually lead to campaign finance reform, transparency and limits... and moreover is a fundamental of speech.

This arose out of a conviction that something I call the "Altruism Dilemma" is a real, biologically based conundrum that makes scaling human groups problematic.

It soon became clear that for a 'political' micropayment to work... every other kind would need to as well... and everyone had to be at the party.

And THAT lead to a conviction that the "party" created was also a very important piece for creating a more equitable landscape for us humans.

There's an interesting book out recently that offers some documentation on how this dilemma plays out in real life:

White-Collar Government: The Hidden Role of Class in Economic Policy Making (Chicago Studies in American Politics)

I don't believe the micropayment and its needed network solves all the problems... (and will create a few of its own)... but I'm convinced it can form the root of an institution which may... on multiple level... become a needed feedback mechanism. 


On Thu, Dec 19, 2013 at 11:28 AM, William Dyson < " target="_blank"> > wrote:
This is part of what we are working on…...


Yes, through the browser is good... but what is needed is a sort of 'inter-provider' agreement between the large players (similar to some interbank systems like ClearXChange)...

Which would create this core clearing house... so that the soliciting interest because of the agreements with those providers could offer its button through all browsers simultaneously.

I also believe that such an agreement would place tremendous pressure on the various payment vehicles to join this network... rather than trying to do micropayments by themselves. (similarly with email providers)



On Wed, Dec 18, 2013 at 4:59 PM, William Dyson < " target="_blank"> > wrote:
Very Interesting.
I have been Developing  intentions services and Micropayment system for than ten years.
We are currently developing technology that integrates Micropayment's into a Browser as well as a platform 
Interesting points/ideas concerning the corporate structure of this kind of project….We are also investigating this area


William 

All Power to All the People 






(Changing the subject to the subject.)

On Dec 18, 2013, at 8:45 AM, Tom Crowl < " target="_blank"> > wrote:

Doc Searls et al,

I'm not qualified to address the ins and outs of VRM.

Everybody is. VRM is still zero-based. All of us make the ins and outs (and choose your prepositions) here.

However I am convinced that the requirements for making a micropayment possible lead to a natural monopoly for its core. And that core may easily be just as important as the micropayment itself.

One would think. I'm not thinky enough to challenge that, though. Perhaps others here can weigh in.

And were this core to be constructed as a for profit enterprise... owned by its members...(one human, one share, non-transferable and expires with death)...

Interesting idea. A co-op of everybody. May I volunteer Customer Commons? <http://customercommons.org> While not quite zero-based, it's not far past the starting line.

It seems to me this gives that inevitably ubiquitous user base tremendous power regarding the use of its data... as well as a means to acquire compensation from those who wish to use it... whether the user ever makes a micropayment or not.

Getting more ideas here. Need to hold back until I bake (or burn) them a bit.

While the system for the micropayment itself is very straightforward and not a 'programming issue... I'm not a programmer and can't say I can fully see how the VRM aspect might operate... it seems to me there's something to be thought about there.

Agreed. I'm not a programmer either. But that doesn't stop me from seeing, if not fully. 

If not... so be it. I wanted to throw it out. David Brin and I are putting together an article on the general capability... and I was curious to see if there might be something to be added from this end.

Characteristics of the Monied "Like" Button

One-Click Micropayment Capability for Volume Solicitations and Multiple Providers

P.S. The "for profit, one user,one share...etc." idea for ownership is my own and separate from the basic mechanisms themselves... and I can't say whether Dr. Brin necessarily agrees or not... so if its terminally stupid... put it on my head.

P.P.S. And if this has no relationship with your ideas I understand and won't push it. But I think its worth a moment or two for consideration.

Much more than a moment. Thanks for vetting it with us. Much to talk about here.
Tom Crowl

Lots of other good stuff in Tom's blog, all very VRooMy. I invite others here to peruse it.

Doc













Archive powered by MHonArc 2.6.19.