Doc,I very much appreciate your ideas and suggestions. And I also understand the rationale regarding patents and intellectual property rights. But I would hope there would be consideration that at least occasionally 'the exception makes the rule"Here's Why:The capability I've described (a one-click payment capability across multiple identification systems) MUST at some point... funnel into that final signaling stage (i.e. a button, swipe, whatever).And for the very small transaction at least... it moreover must be connected to a payment source that addresses the fixed transaction charges that are attached to individual payments by the wide variety of payment sources used... and that make the micropayment impracticable.Moreover, when one begins to consider the potentials of even very small payments at scale... one must begin to consider issues related to curation and potentials for misuse.That, to me at least suggests that the curation, TOS, etc. around that function are of considerable importance... ( shall we let a "Help send a kid to Syria" donation button show up in a browser ad?)... and that there is a very significant public interest in its operation and boundaries around it usage.I'm not trying to be "the king of the button"... what I am suggesting is that at least one significant Internet capability should be under some other form of governance than via a private corporate... or banking interest.This is a design consideration particularly applicable for the volume micropayment... and I believe is of importance for the future of the web... and the individual's relationship to it... in ways that extend beyond the micropayment itself.W/o any intellectual property protection this almost certainly will become dominated by the banking giants and/or the Internet giants... as an additional source of revenue and control. I'm suggesting that this is not the right way to go and will do what I can to prevent it.This is not because I'm opposed to profit or the Internet giants... which are natural concentrations. As for the banks that's a different story.(I'm going to take some time in a separate email to address why they should be separated from this functionality... at least for the volume micropayment and for an Internet wallet)As for my own interest... I don't apologize for it.... and am happy to find a way to accommodate this being done via some public (e.g. non-profit, co-op foundation, etc.) But they damn well better hire me as a long term consultant... I should be dead within 15 or 20 years so its not really such a long term commitment.Kevin... my question is this... Are Australian banks inter-operating in order to accomplish the volume micropayment? What are they doing about the fixed transaction charges making it impracticable?Finally, I'm going to give a bit of personal history in a separate email which may provide some understanding for my view on this. Which has both personal and public roots. Again its not about being Left or Right... nor is it about opposing private businesses or even banks... but its about good design for a developing landscape.Is it possible that by ensuring that a volume micropayment vehicle is NOT dominated by banks or private corporations that there would be MORE opportunity for various open source, publicly oriented development to be done?This is a time of very important evolution in the Internet landscape... and just letting it develop haphazardly is not a good idea. We are creating structures which very well may last for millennia. And mistakes will have very significant consequences.Tom CrowlOn Tue, Aug 18, 2015 at 2:43 PM, Doc Searls < " target="_blank"> > wrote:I’ll second everything Andy says. More inline below...On Aug 18, 2015, at 2:05 PM, Tom Crowl < " target="_blank"> > wrote:Thanks Andy.... and Yes... I very much understand that in moving from suggesting a framework (sort of a battleplan)... to implementation (the first shot).... things may not go as expected.... and so I don't mean to suggest exactly how it should be done in every detail... but it may be the root to begin an evolution. What's important is to have some idea of where you're going (just as in the evolution of hypertext).So I have a couple of ideas too.One is that free customers are more valuable (to themselves and to the marketplace) than captive ones. (Kinda for the same reason that we are worth more in freedom than in slavery, or in lesser forms of captivity.)Another is that lots of market problems are best worked out from the customers’ side — by equipping customers with tools for both independence and engagement.For both those reasons I started ProjectVRM. I knew, mostly by covering free software, open source and Linux as a journalist, that the best chance of seeing either of those ideas prove out was having lots of developers working on lots of different projects, some of which might have a chance of succeeding — and none of which would be exactly what I would develop if, for example, I pursued proof with my own start-up. (Though I’ve often been tempted.)I have had (or co-had) a number of ideas for products, services, UI elements and code bases. Examples are the r-button, Intentcasting and EmanciPay. I’ve also believed that the chances any of them would have of succeeding would be maximized if I did not assert any kind of intellectual property rights over them, or try to extract income from them. I looked instead for what JP Rangaswami and I years ago began to call “because effects.” You make money because of the ideas, rather than with them.The jury is still out on VRM. But the jury is growing, and the number and variety of developers working on making individuals free, independent and better able to engage is also growing. Eventually one or more projects will succeed or my founding ideas will prove false. I doubt the latter will happen, but I also have to assume that it’s possible. Theories require that.I bring all this up because it’s kind of a corollary to the old saying (on which there are many variants), “There’s no telling to how much success you can have if you don’t insist on the credit.” Which brings me to this:But in my small way... I want to be at the party... and deserve a seat. All I started with is an idea that very small payments would be useful in a few areas especially.... and then started looking at its needs and implications. My patent is an early iteration of an idea... but contains a core element re account design.... and I can't afford any more patents.I agree that you deserve a seat at the party. I also agree with Andy and others here that the party is not likely to be exactly what you would have designed. And that there may be many parties.And, much as I deeply respect the work and money you have put into your patents, I know that the existence of those patents is a turn-off for at least some of the developers it would be good for you and your ideas to have on your side. Patents are like that. They cut a number of ways, and not always in the hands of the patent holder.All that said, I am glad you keep pushing. Your work and your ideas are important, and I for one value your seat at the VRM table, and your contributions here.DocTom Crowl
On Tue, Aug 18, 2015 at 10:54 AM, Andy Oram < " target="_blank"> > wrote:I'll make a high-level comment. What I see of radical proposals for new systems is that they need to play a balancing game. The idea you present is interesting and should live on, but you can't predict exactly how it will be done. Look at Ted Nelson and hypertext--it all came to pass, but not the way he expected. (Actually, Tom, you're filling in some of the infrastructure that Nelson wanted and never got.)It's nice to see that certain aspects of an implementation (such as the browsers you brought in) will work in theory, but I would avoid trying to get a whole implementation worked out from soup to nuts. It probably won't happen the way you think it will. The core idea is the thing to hit on over and over.Andy--On Tue, Aug 18, 2015 at 1:41 PM, Tom Crowl < " target="_blank"> > wrote:Andy... et al,Let me know if this adds clarity to what I'm talking about...Let's assume:
- A broadly available micropayment would be useful for various purposes across the web (advocacy, charity, journalism, etc.)
- A one-click capability is necessary for micropayment viability (as size of payment decreases... ease of execution must increase)
- Hence secure user identification is important for making that payment viable
- The pooled-user-determined account design is a useful "wallet" design for addressing the fixed transaction charges attached to the large variety of various payment sources used for deposit into that wallet
- Broad availability requires an ability to operate across multiple browsers and Internet-based identification sources
Hence: Just as Microsoft browser can interact with google gmail... and various other identity sources interact... SO must a wallet necessary for this type of payment.Moreover while such a system could be formed by agreement via the various "identification sources"... the "wallet" itself should be its own separate entity... and I strongly feel (not for technical but for socio/political reasons) that it should not be formed as a part of any bank or even the banking system itself... but separate from it... though obviously it would receive deposits via them.... just as payment would go out via various browsers and/or identification systems.That's what I'm talking about... not a stand-alone website or wallet. I've long felt... and it hasn't changed... that the micropayment is the key to a very important Internet institution.I'm not a programmer... I'm not a businessman... I'm a hodad (an old term for someone trying to pretend they're a surfer but are faking it all the way). I just think I'm a hodad who's on to something important. Its not only about the Future of Work, gov 2.0.. or anything else... its about the design of the net... and its future.P.S. As a hodad... I'm naturally interested in where my fraud is inadequate so that I might improve the illusion. SO... if anyone wants to let me know what I'm missing... I'm listening.Tom CrowlAndy OramEditor, O'Reilly MediaBoston, MA, USA 617-499-7479
Archive powered by MHonArc 2.6.19.