Text archives Help


Re: [projectvrm] [personal-clouds] How Web 2.0 killed the Internet


Chronological Thread 
  • From: Phil Windley < >
  • To: Joe Trippi < >
  • Cc: Doc Searls < >, Tom Crowl < >, David Brin < >, ProjectVRM list < >, " List" < >, Nick Katsivelos < >, Aral Balkan < >, Drummond Reed < >, Craig Burton < >, John Battelle < >, Andy Oram < >
  • Subject: Re: [projectvrm] [personal-clouds] How Web 2.0 killed the Internet
  • Date: Thu, 5 Jun 2014 11:42:02 -0700

Yes, I think it does. I think each entity (regardless of whether it’s a person, place, things, organization, concept, or sub division of such) should be representable online. 


On Jun 5, 2014, at 10:29 AM, Joe Trippi < "> > wrote:

But doesn't this speak to device identity (the car in your example) being just as important (if not more so) than personal identity?


Sent via the Samsung Galaxy Mega™, an AT&T 4G LTE smartphone


-------- Original message --------
From: Phil Windley < >
Date:06/05/2014 1:14 PM (GMT-05:00)
To: Doc Searls < >
Cc: Tom Crowl < >,David Brin < >,ProjectVRM list < >," "> List" < >,Nick Katsivelos < >,Aral Balkan < >,Drummond Reed < >,Craig Burton < >,John Battelle < >,Joe Trippi < >,Andy Oram < >
Subject: Re: [projectvrm] [personal-clouds] How Web 2.0 killed the Internet

I don’t know if I’m one of the people Doc was trying to draw out…

I think most of the interesting transaction are happening in places where there’s not necessarily a human in the loop to press the button and so the permissioning, if it happens will happen before or be out of band from the transaction in some other way. 

Imagine an online representation your car. Let’s call it a pico. You’ve given the car a budget and charged its stored value card (since those exist right now) with money. Now, your car, via the stored value in the pico, can pay it’s own way, buying gas, paying for maintenance, registering itself with the DMV, etc. You might pre authorize certain types of transactions so that you never see a button to press. The transaction fades into the background. When you do see a button, it’s probably on your watch or phone, not in a browser. 

We’re already there with tolls. Whether it’s by license plate readers or RFID, most toll roads are moving away from toll booths and toward the car paying it’s own way. This reduces the friction of driving on toll roads substantially, so watch for toll roads to become much more popular in the future, especially as more and more vehicles become electric and paying for roads from fuel taxes becomes harder. 


On Jun 5, 2014, at 6:30 AM, Doc Searls < "> > wrote:



Consider this possibility:

All these models for a micropayment depend on that 'button' being able to identify the user clicking it.

There are a number of models that require no button at all. Nor a browser. Maybe not even a device. I'm not just trying to be mysterious here, but to draw some people out. :-)

Now being signed-in to the browser is one way... BUT what if this system provides a user identifier (temporary or permanent) ? Hence the browser (or whatever vehicle the button is applied to)... and payee have assurance of its validity.... and the browser at least has the basic stat (of a click) but w/o all the individual's particulars if the user didn't want to provide them (or they weren't required)... but  the user has control over his/her data.

And that identifier... which can be optional... can be used for purposes other than the monied like button.

(Just as my x-box I.D. allows me to do other things besides buy avatar outfits for 25 cents)...

But here we've taken it out of the private silo... and yes... put it in another sort of silo. But of a very different sort.

I also suggest that this 'button' is inevitable... and ignoring this is virtually guaranteeing that it will end up in a privately held silo... just like all the other natural concentrations which have taken place on this new landscape.

I'm trying to head 'em off at the pass.

Have you thought about private personal silos? Or about silos that are shared between individuals?

So far we're a very small posse.

Also very small circles of awareness, obsession and the rest of it. But the old systems are cracking and many new approaches and technologies are coming on. 

Doc








On Wed, Jun 4, 2014 at 12:36 PM, Tom Crowl < " target="_blank"> > wrote:
Your method looks good David... I just think there's a way to take the enterprise one step up from the browser/email provider... and then have THAT entity serve multiple providers... however the transaction is conducted or monetized.

And I think that should be done.

And you're right its not like all the payment providers are going to jump on board... nor for that matter will the browser providers want to abandon the additional hook that this capability would provide them to further entrench their positions... (which while I wish them well I want to avoid).

And then there's the fact that the capability completely alters the role of money in politics (I believe leading to rapid reform and better politics but not to a complete ban on advocacy which in my opinion is a idiocy and would entrench professional opinion management by the monied)

SO... my hope is that the whole subject can stir up one heck of a debate. This capability is way to important to be delayed any longer.





On Wed, Jun 4, 2014 at 12:19 PM, Tom Crowl < " target="_blank"> > wrote:
I agree proper place may be through browser... (and email providers who are largely the same guys)...

 but the browser must not control this silo... or its data and users... since not only must the function be available to mulitiple browsers (Not separate one for each browser provider... which would only further entrench the silo'd monopolies)

... but must keep separate from the browser provider the data such a capability might provide... the disposition of which should be left to the discretion of the user...

which the browser provider should certainly have the right to pursue through agreement with the individual concerned... and in many cases the user may find advantage in sharing... but not always.

The reason these large corporate silos are forming is not the nature of the code (in my opinion) ... but the nature of the capabilities they perform.

And this creates problems.

Once the landscape was enabled (the Internet)... certain functions are naturally going to concentrate.

I believe the micropayment (monied like button) is one of that very small group... and in fact COULD be run profitably. I just believe that for a variety of reasons it should take a somewhat different route... and especially should not be narrowly controlled, owned or governed.

This has nothing to do with an opposition to enterprise... but rather a conviction that we're now dealing with a very unique landscape which may need some new organizational forms... which are technologies after all.



On Wed, Jun 4, 2014 at 9:29 AM, David Brin < " target="_blank"> > wrote:
Tom Said: "I also believe that for at least some aspects of its utility some unification is necessary... and have long seen that unification as a potential for creating a counter-balancing force with a fundamentally different design than the existing 'silos'...  Sooner-or-later people are going to realize that maybe there are other things to be done with 25 cents than buy an avatar outfit on their X-box. And they won't want to be limited to their x-box to make that transaction."

DB replies: "This is why I think the proper locus of activity is the browser.  Chrome, Safari etc provide the nickel buttons for Cps (content Providers) to install on their pages.  

When a nickel button is clicked by a user, the message goes to the user's Financial Intermediary (FI) who MIGHT at first be a credit card company... (though convincing one of them to come aboard will take persuading that this is the wave of the future. Small margins on small transactions. Over time, other FIs will come in.)

The FI (1) unlocks the content for the user, (2) adds a nickel to the CP's pile to be sent over at the end of the month, and (3) adds a nickel to the tally that will be billed to the user at the end of the month (or chosen delay period.)   

(4) Some transactions the user disavows (either at time-of-us or at billing). These are removed from both lists, before reconciled totals are sent to the CP. However disavowals are added to a pile of transactions that a separate unit investigates for fraud or freeloading or reputation management.  (5) User pays the FI the monthly charge and the FI pays CP.

The narrowest intrinsic bottleneck here is the browser.  Not a "silo" but a definite narrow point in the chain.

DB







> > > > > > > > > > > > >




Archive powered by MHonArc 2.6.19.