- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Mon, 26 Sep 2016 15:09:45 +0200
- To: Timothy Holborn <timothy.holborn@gmail.com>
- Cc: Manu Sporny <msporny@digitalbazaar.com>, Web Payments <public-webpayments@w3.org>
- Message-ID: <CAKaEYh+zKOoi10e-hL6LkHv9RQaOAfubgxBxN=rKZDJ4S21DFg@mail.gmail.com>
On 26 September 2016 at 15:06, Timothy Holborn <timothy.holborn@gmail.com> wrote: > A left field Example; If tooling for burning unique ids into products, > perhaps using open badge based solutions were made available to MFG's, > alternatives to traditional currency may end-up being a result. A bit like > barter... > > A lot of MFG is based in parts of the world where access to VISA (as an > example) alongside Internet and electricity is relatively low. > > So, therein is an opportunity where business models of today still fail to > support basic humanitarian advancement. > > This in-turn looks a little more like the credentials methods than the > bitmark related methods, mind, I see a blend of great ideas being the most > useful for vulnerable people... > > Finding one person who can supply attribution is likely easier than > putting a card in the hands of every person on the planet. Already buskers > are struggling in a cash-less society, so it's not like the service density > is improving with tech. Advancement at present, IMHO. I find the humanitarian use case a very compelling example of where the web can potentially add value in new ways. > > > On Mon, 26 Sep 2016 at 10:56 PM, Melvin Carvalho <melvincarvalho@gmail.com> > wrote: > >> On 5 April 2016 at 23:05, Manu Sporny <msporny@digitalbazaar.com> wrote: >> >>> On 04/04/2016 06:49 AM, Melvin Carvalho wrote: >>> > Lastly, please please please, dont abandon the CG specifications. >>> > They are some of the best work anywhere. In a sense the CG is in >>> > some ways ahead of the WG at this point. >>> >>> We have no intention of abandoning the concepts in the CG >>> specifications. We will fight for the consensus positions of this group >>> - level playing field, financial inclusion, innovative ecosystem, etc. >>> >>> The recent scuffle in the Web Payments Working Group is not the end. A >>> decision was made to use the Microsoft/Google specification as the base >>> specification for the Web Payments Browser API. We have the ability to >>> change those specifications. One approach is by submitting >>> counter-specifications like this: >>> >>> https://github.com/w3c/webpayments/pull/115 >>> >>> Another approach is for people from this community to pick an issue to >>> fight for/against and move that particular item forward: >>> >>> https://github.com/w3c/browser-payment-api/issues >> >> >> Great! >> >> The way I see it there are three webs, and three payments webs: >> >> Roughly speaking: >> >> The Web 1.0 era (c. 1990-2000) is about web sites. A typical payments >> solution would be a banking site or paypal. This is a model that's works >> well on the web and can be standardized in a fairly predictable way by >> identifying common pain points, use case and creating uniform APIs. >> Definitely a pls. >> >> The Web 2.0 era (c. 2000-2010) is more about web pages. Typically this >> allows a page to be a first class citizen of the web and dynamically access >> the network and update itself. This has lead to patterns (primarily AJAX) >> that allow remote interaction. Payments now can be done in the browser >> sandbox within a page, but in a very similar fashion to web 1.0, however >> without page reloads. Similarly it makes sense for the WG to standardize >> this work and create APIs. >> >> The web 3.0 era (c. 2010-2020+) is about data. Data, and particularly >> linked data, on the web becomes a first class citizen. This is a >> fundamentally different model, but also one that very few people have yet >> to understand. It is in a sense a more distributed and decentralized model >> of the web in line with the original vision. Payments in this paradigm >> new, exciting, and very powerful, and can solve use cases existing and not >> yet imagined to date. It can also handle all existing use cases via >> bootstrapping. In this sense it's very similar to technologies like >> bitcoin. It also covers a lot of the work done with JSON LD which deals >> with first class data primitives on the web. >> >> While it's valuable to try and modernize the work going on in the WG >> which is really revolved around web 1.0/2.0 technologies imho, it seems >> there is a political will do dumb things down to much that independent web >> developers are struggling to have their use cases addressed. >> >> It's common at the IETF to view a specification and have in your mind >> what future versions of that spec will look like. >> >> So Id like to work on essentially W3C Web Payments NEXT, without waiting >> for the modernization of the vendor payments system, shopping cart >> experience, choosing a credit card, and other nice things the WG is doing, >> but have relatively little relevance to the exciting modern internet >> payments phenomena. I think the WG has dropped the ball, for various >> reasons on this one, but will possibly still have useful deliverables. >> Let's anticipate that, make it the best it can be, and perhaps look toward >> the next version of payments which can bootstrap the old and create a whole >> new era of use cases on the web ... >> >> I've spent a lot of time doing infrastructure and plumbing work for >> this. Im now ready to actually code stuff on top, and integrate it into >> real world payments workflows and live crypto currencies. >> >> I'd really like to take the recommendations here, and in the block chain >> community group to make very exciting payments workflows, in live systems, >> and incorporate existing useful workflows. >> >>> >>> >>> >>> > I think there is a compelling case to be made though interoperable >>> > implementations. Im hoping to spend the next 3 quarters of this >>> > year working on some. This can often be a better way of convincing >>> > people than simply a specification ... >>> >>> Agreed. Implementations matter. Digital Bazaar will be doing an >>> implementation of the Web Payments HTTP API and the hope is that >>> provides a counter-weight to some of the Browser API design decisions. >>> >>> -- manu >>> >>> -- >>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) >>> Founder/CEO - Digital Bazaar, Inc. >>> blog: The Web Browser API Incubation Anti-Pattern >>> http://manu.sporny.org/2016/browser-api-incubation-antipattern/ >>> >>>
Received on Monday, 26 September 2016 13:10:17 UTC