W3C home > Mailing lists > Public > public-webpayments@w3.org > June 2014

P2P Payment technologies & info (WAS Re: Is payment "timeliness" addressed in our work yet?)

From: Tim Holborn <timothy.holborn@gmail.com>
Date: Wed, 4 Jun 2014 13:28:18 +1000
Cc: Joseph Potvin <jpotvin@opman.ca>, Web Payments CG <public-webpayments@w3.org>
Message-Id: <3989B75A-1720-4733-9DEF-476F986697B7@gmail.com>
To: Dave Lampton <dave.lampton@gmail.com>
Hi Dave,

Do you have a Link to the speech you refer to?

 (draft, i still have a great deal more to author, before editing… - but link: http://webarts.mediaprophet.net/?page_id=39 )

Personally; i agree that individuals should have their own domain names; and that whilst this is not and should not be a mandatory requirement for users, the ability to use existing WWW Systems (inc. DNS) with a domain provides enormous benefits.  Perhaps the barrier is the methodologies in which existing CPANEL (or similar) systems work; and within that environment, webized [1] Cloud Storage [2] provides some of the underlying building blocks needed to create cloud-based user-environments, supporting an array of WWW applications…  

deiu wrote a paper [3] relating to his work on RWW.io / data.fm and related Linked Data [4] projects (of which deiu is involved…).  Obviously, members encourage others to develop solutions in an array of ways, from use-case and standards; to working solutions.  I think the main effort surrounds attempting to collaborate around the standards needed to support interoperability, supporting users through web-standards as best as possible. 

In your text, you’ve embedded a few economic models around how you envisage your service to be commercialised.  Classical Web 2 models centralise data to a branded domain where CDN’s and related infrastructure then need to support user-growth.  revenue models in-turn are supported often, by systems such as advertising and data-mining.   Due to the nature of a centralised or funnel styled topology, the bulk of users are then served by a centralised management system that can support sophisticated internal business units, in-turn supporting commercial engagement with vendors supporting functions such as advertising aggregation and monitization. 

In distributed models - users would have their own accounts and their own hosting space.  Perhaps some systems are sold / purchased / leased by the user on the basis of an economic awareness surrounding the use of advertising systems to make the cost to the user, of owning a service - cheaper or free.  Ideally perhaps, these systems can be as cheap as is possible whilst also being highly secure - so that more sensitive data such as commercial objects, personal objects of a sensitive nature (medical records, financial accounts, etc.) are entirely secure save exceptional circumstances where a court-order may require disclosure on a specified account, or similar…  

anything that is 100% secure - actually doesn’t exist, from thereon its’ a slippery slope and i guess the gambit is to get close to that rating, without engaging in a conversation with those who believe they can obtain it. 

Another up-side of distributed applications, is that application developers do not need to fund the traffic requirements for growth. This in-turn democratises the capacity to build applications, and to successfully commercialise them, similar to the old industry of distributing open-source software on floppy disks / early internet systems.   

IMHO, it gets down to a philosophical layer, which i think is best described here [5].  If, as a community, we build standards and basic systems that support the needs of a person (natural legal entity); then the rest benefits, including our ability as persons to develop applications that we believe have a role to play in life, in some practical sense.  It seems sensible to consider that Web2 portals will develop technologies to adapt their service to improve functionality, and support web3 capabilities.  meanwhile new applications will develop using web3 functionality, requiring some form of cloud-storage that may or may not be hosted by a person on their own domain…

I’m not sure how many people in future will store all their digital transaction receipts in Facebook, or on a google, iCloud or similar service - but i’m sure they’d all hope for millions…  Equally, i believe individuals may benefit from the transparency and ease of understanding the data-privacy related risks incumbent upon the alternative of storing all of your personal data, on your own hosting system, connected to your own domain, using your own run-time of software solutions that incorporate a ‘data space’ as something that is owned by you legally, as it is connected to that specified domain of which you are responsible for its operations; or something along those lines…  

underlying that of course; is the need for security with regard to fiduciary responsibilities.  AML, KYC are amongst the terms used in this space.  I would argue that if a user has an institutionally approved Cloud Storage service (as described, in-part, by the references in this doc); then so long as a transaction is between two known entities; facilitated in a manner that maintains integrity between WWW Points of distribution (meaning, from one person to another person, without being intercepted, copied, redirected, etc.) then in-turn institutional systems should be able to honour those ‘IOU’s’. 

Whilst some may argue that users storing their own data is insecure; i’m aware of local police departments in countries other than the USA having difficulty accessing data from portals owned, operated & incorporated in the USA for good purpose. Perhaps two imaginary examples could be 1. like kids, publishing or promoting their suicide intentions, being ‘missing’ from loved ones at the time or 2. person gets into car accident and the emergency department has difficulty obtaining health data / records from the individuals mobile-phone application package provider, who delivers the application freely with advertising...
 
I’ve started putting together documentation for my mid-year update; i know a bunch of typo’s, issues exist - am still working on it..); nonetheless, 

hopefully useful...

What are WebCredits - http://webarts.mediaprophet.net/?page_id=39
GraphDB Technology vs. relational Databases - http://webarts.mediaprophet.net/?page_id=52
Socio-economics and the evolution of relational database technology - http://webarts.mediaprophet.net/?p=63
Don’t be afraid of ‘peer to peer’ - http://webarts.mediaprophet.net/?p=61
(any suggestions on my works, always welcome ;) )

[1] http://www.w3.org/DesignIssues/Webize.html
[2] http://www.w3.org/DesignIssues/CloudStorage.html
[3] http://myprofile-project.org/thesis/manuscript_en.pdf
[4] http://github.com/linkeddata/
[5] http://www.w3.org/2007/09/map/main.jpg
On 4 Jun 2014, at 1:54 am, Dave Lampton <dave.lampton@gmail.com> wrote:

> Not sure exactly what to make of the Lacker speech. He's still talking present day technologies with middle-men and discussing the perceived usefulness of trying to minimize transaction times to reduce float. I'm talking about negating the float altogether by allowing individuals to trade real digital currency, just like we can trade real physical currency without a middle man today.
> 
> My concepts are akin to a peer-to-peer payment system with real-time clearing from the central bank of that currency. Similar to the Web Credits idea, having a "wallet" (or an "account" or a "generic money bag" etc.) at a particular URI is part of my thinking as well, however I have the software endpoints much more concretely defined to a standard. In my imagined system we'd actually be trading REAL dollars (or yen or francs or whatever that central bank issues) and the central bank clears transactions on its own currency in real time. Every digital dollar will always have a single "physical" home (an obfuscated URI) at any one time. Payers initiate transactions. Cost would be on the order of $10 to run a server like this for a whole year. There would be almost no cost to anyone who maintains their own currency server (just electricity and an Internet connection). The cost of maintaining a single server would be comparable to having an email server, to the point that it's likely people would be giving away these accounts as part of a loss-leader to upsell to some other service perhaps.
> 
> Anyway, I know, I'm still just the new guy here... :)
> so I say it all with some humility...
> ...but I feel like I have yet to see a proposed system that does everything mine does. I guess I should try to find time to finish a working demo of it. I'm about a third of the way there already.
> 
> Cheers.
> 
> 
> 
> Dave Lampton
>  @dave_lampton
>  DaveLampton
>  +DaveLampton
> www.linkedin.com/in/davelampton/
> 
> 
> 
> 
> On Tue, Jun 3, 2014 at 8:21 AM, Timothy Holborn <timothy.holborn@gmail.com> wrote:
> Re: dave's post below...
> 
> Webcredits is an alternative that seems to provide a functionally similar capability (although, using rww systems), with an array of other functional capabilities.
> 
> See #webcredits in freenode, or http://www.w3.org/community/webpayments/wiki/Web_Credits
> 
> If you get a rww.io or data.fm account, and put a Testnet address into your foaf document, I think melvster (in #webcredits, per above) has a bot running that can provide some basic demonstrations.
> 
> His also a walking library of knowledge in that area specifically....
> 
> Mind.  Accelerating, and diminishing costs for transfers is one thing.  I figure once a transaction hits a financial bank to be converted into traditional currency, it'll likely have requirements surrounding identifying where the funds are sourced, etc. 
> 
> Much like existing payee relationships, once one payment has been made between two accounts, additional transactions are easier.
> 
> This is perhaps different for digital currencies, or IOU's / accountability capabilities, and other purposes of stuff like block-chains, and things that can be done with that geek...  
> 
> I don't think gold needed an identity, beyond being tested to ensure it was gold.  The ID has always lived with the accounts systems.  Perhaps also ensuring people don't taint the "gold" with a cheaper substitute, or otherwise breach the terms of trade.  More complex examples could be asserting a value for use of an image, beyond the scope of a Creative Commons license, perhaps all embedded in the image...   The semantic clipboard http://dig.csail.mit.edu/2009/Clipboard/ seems to consider the Creative Commons elements quite well...  
> 
> Webcredits is well worth a look IMO...  I'm really impressed with it, understanding of course, it's still early days...
> 
> Timh.
> 
> Sent from my iPad
> 
> On 4 Jun 2014, at 1:00 am, Joseph Potvin <jpotvin@opman.ca> wrote:
> 
>> Dave, 
>> 
>> Take a look at "Immediate Funds Transfer: A Central Bank Perspective" from the Federal Reserve Bank of Richmond
>> http://www.richmondfed.org/press_room/speeches/president_jeff_lacker/2011/lacker_speech_20110907.cfm
>> http://www.chicagofed.org/webpages/publications/economic_perspectives/2011/summers_wells.cfm
>> 
>> -- 
>> Joseph Potvin
>> Operations Manager | Gestionnaire des opérations
>> The Opman Company | La compagnie Opman
>> jpotvin@opman.ca
>> Mobile: 819-593-5983 
>> 
>> 
>> On Tue, Jun 3, 2014 at 10:50 AM, Dave Lampton <dave.lampton@gmail.com> wrote:
>> Since its inception, PayPal has primarily made their money "on the float" meaning that during those few days they have your money, they are able to invest it in short-term money markets, etc. When you're dealing with such a large number of transactions, these investments can be very large and the returns quite handsome.
>> 
>> I'm new to this group, but I have joined because I've been developing my own solutions for "digital money" and wanted to see what else is going on. So far, I am gathering that both the current WebPayments (PaySwarm) platform as well as other proposed alternatives like OpenTransact are still all based on email for the sending/receiving of payments, is that right?
>> 
>> There is STILL no way for me to send $5 directly to my brother, for example. There is still always going to be at least one third party involved, and often more than one, just for me to give my brother five bucks. Or have I missed something?
>> 
>> ...
>> 
>> Has anyone discussed the development of something entirely new like a protocol especially used for nothing but financial transactions? My feeling is that email servers don't know what a payment is and never will be able to do anything with one. End users are still dependent on a third-party to move money to/from their bank accounts.
>> 
>> On the other hand, I have a much more complete system for digital money developed in my mind if anyone is interested. If our money were held by our own digital accounts, we could send money to one another just like we can already hand one another cash without any third-party involvement. (it would even put into question the need for banks!) A super brief overview follows:
>> 
>> First off, this idea would actually require governments/central banks to issue the digital currency that could subsequently only live in my proposed digital accounts. Yes, I realize that's a huge hurdle to expect their involvement at any stage, but frankly, I think it is the only real way to solve the larger problems permanently.
>> 
>> So, what if every financial account in the world were assigned a permanent URL (either a domain or subdomain that is owned by the account holder). Every website already requires a domain, so it's not a big leap to require every digital account to also have a domain or subdomain (and with the advent of IPv6 we'll have so many IP addresses at our disposal, it's absurd). Ownership of digital accounts and the transfer of their ownership would all be handled using the same mechanisms we use today to manage domains using registrars and DNS. In this case, every digital dollar must have a home in a digital account somewhere. Each digital dollar knows its issuing bank, its unique serial number, its current owner (holding account) and 
>> 
>> Essentially, a digital account would be a new type of Internet endpoint, one that is similar to the function of an email server, but only processes financial transactions. It would be addressed in much the same way that email servers have an MX record in DNS, the currency servers might have a CX record. In my mind, the easiest way to implement something like this would be with a Node.js server using secure WebSockets (wss://) and a simple NoSQL document store, most likely a MongoDB instance. The software itself could be so simple as to be mindless, not even needing configuration, knowing only how to either send or receive currency, nothing more.
>> 
>> Lastly, my ideas to keep it all secure turn the traditional cryptographic methods upside-down. Rather than make every financial transaction in the world a big freakin' secret, I would instead make every transaction completely public and recorded by a whole lot of people at once. It would be impossible to fake because only the central banks will transmit transaction confirmations, but everyone will be keeping copies of them as they happen on their network segments, and records can be looked up by anyone at any time. However, to be fair to everyone, money must have no memory, and so only the current owner is known for a given piece of currency, previous owners are purged from the records when a new transaction is confirmed.
>> 
>> There are lots more details to all of this if anyone is interested.
>> 
>> Not sure if perhaps you're all more interested in forwarding the established ideas, but I wanted to throw this out there since I still do not yet see any proposals which would allow me to send that $5 directly to my brother!!  :)
>> 
>> thanks.
>> 
>> 
>> Dave Lampton
>>  @dave_lampton
>>  DaveLampton
>>  +DaveLampton
>> www.linkedin.com/in/davelampton/
>> 
>> 
>> 
>> 
>> On Tue, Jun 3, 2014 at 4:40 AM, Joseph Potvin <jpotvin@opman.ca> wrote:
>> I don't recall seeing anything specific yet about basic timeliness of
>> web payments.
>> 
>> Here's an example. In the course of having some funds reimbursed to me
>> by a business via PayPal, I then transferred the money from my PayPal
>> account to my bank account. Once that transaction was processed via
>> the PayPal site, I recieved the following emaIl message:
>> 
>> ---------- Forwarded message ----------
>> From: service@intl.paypal.com <service@intl.paypal.com>
>> Date: Tue, Jun 3, 2014 at 7:03 AM
>> Subject: We're transferring money to your bank
>> To: Joseph Potvin <jpotvin@opman.ca>
>> 
>> We're transferring money from PayPal to your bank
>> Jun 3, 2014 07:03:36 GMT-04:00
>> Hello Joseph Potvin,
>> You asked us to transfer $XXX.XX CAD from PayPal to your bank account,
>> and we're processing it now. It usually takes 3-5 business days for
>> transfers like this to go through, so you should see the money in your
>> bank account by Jun 10, 2014.
>> -----------------------------------------------
>> 
>> Huh?  3-5 business days?   But the ACH system clears at least every day.
>> 
>> Does anyone here know in which organization's hands the money sits for
>> 3-5 days? And why?
>> 
>> Is this a delay due to some slow anti-launderiing verification
>> processes mandated by government?
>> 
>> Alternatively I can imagine there's a cloth bag tied with sisal
>> containing my $XXX.XX CAD being loaded onto a side-bag of a donkey,
>> getting ready to make the trek in this direction. I'm fine with that.
>> Just need to know though.
>> 
>> --
>> Joseph Potvin
>> Operations Manager | Gestionnaire des opérations
>> The Opman Company | La compagnie Opman
>> jpotvin@opman.ca
>> Mobile: 819-593-5983
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -- 
>> Joseph Potvin
>> Operations Manager | Gestionnaire des opérations
>> The Opman Company | La compagnie Opman
>> jpotvin@opman.ca
>> Mobile: 819-593-5983
> 


Received on Wednesday, 4 June 2014 03:30:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:31 UTC