Re: Markup for payable HTML resources

Thanks Adrian and others for the feedback!

We decided to push this back a bit and will review your suggestions in
detail once we open up our system to external developers. For now we
will use the markup we have already implemented.

As for launch progress, you can now download and use our WordPress
plugin (https://wordpress.org/plugins/satoshipay/) - we will announce
this officially later this month.

Cheers, Meinhard.

On 18.11.2015 18:34, Adrian Hope-Bailie wrote:
> The API proposals are here:
> 
> https://github.com/WICG/paymentrequest/
> https://github.com/WICG/web-payments-browser-api
> 
> There are also these two proposals from the CG
> 
> https://github.com/web-payments/web-payments-messaging
> https://github.com/web-payments/web-payments-http-api
> 
> On 18 November 2015 at 12:32, Adrian Hope-Bailie <adrian@hopebailie.com
> <mailto:adrian@hopebailie.com>> wrote:
> 
>     Hey Meinhard,
> 
>     The topic of a declarative mechanism for doing this did come up in
>     the Web Payments WG discussions in TPAC last month.
> 
>     Currently the WG is scoped to define a standard payment request flow
>     and also the associated message elements for describing the
>     supported payment schemes and payment terms [1].
> 
>     I'd consider SatoshiPay a payment scheme in this sense, although we
>     have started moving away from using the phrase as it has some well
>     defined definitions among various stakeholder groups so I like to
>     just say payment method or way to pay.
> 
>     I don't think it would be a stretch to take the payment request
>     message definition and derive a good way for this to be expressed
>     declaratively (as opposed to a JSON object or similar that is passed
>     to the payments API).
> 
>     The current stage of this work is that we are evaluating two
>     proposals for how this API and messaging could be designed so I'd
>     suggest looking at them and seeing if you have an effective way of
>     putting those messages in a declarative form.
> 
>     An alternative approach may be to use 402 responses when requests
>     are made for specific resources (like images) and use this as a
>     trigger to kick off the payment flow.
> 
>     [1] http://www.w3.org/Payments/WG/charter-201510.html#Web_Payments_Terms
> 
>     On 18 November 2015 at 01:37, Meinhard Benn <meinhard@satoshipay.io
>     <mailto:meinhard@satoshipay.io>> wrote:
> 
>         Hello fellow web payment enthusiasts,
> 
>         I have been reading this list for a while and I'd like to introduce
>         myself and ask for your opinion on an issue I'm currently trying
>         to resolve.
> 
>         I am the founder of SatoshiPay and we are looking at making
>         paying for
>         web content as frictionless as possible for all parties
>         involved. As our
>         payment layer we chose bitcoin payment channels (a simple "smart
>         contract" on the bitcoin blockchain), because of its extremely low
>         transaction fees - think fractions of a cent. Our system works
>         without
>         any download or sign-up for the end user, because we ship a complete
>         bitcoin wallet written in JavaScript with the website the payable
>         content is on and instantly create a private key if the user doesn't
>         have one yet.
> 
>         To make a simple integration for the content publisher or
>         merchant as
>         easy as possible we simply added a few data properties to HTML tags,
>         which will be parsed by our JavaScript widget. In code it currently
>         looks like this:
> 
>         <div class="satoshipay-content-item-text satoshipay-masked"
>         data-content-url="http://will.satoshipay.eu/api/v1/article?id=4ypNl2BMe"
>         data-satoshipay-id=563cc11c8c823d110025e951 data-content-length=1170
>         data-price=4000></div>
>         <script src="https://wallet.satoshipay.io/satoshipay.js"></script>
> 
>         Dump this anywhere on any website and it will just work. Your
>         payments
>         will be donated to our office coffee fund. :)
> 
>         Some documentation for the enriched div tag:
> 
>         <div
>           /* trigger class, plus design */
>             class="satoshipay-content-item-text satoshipay-masked"
>           /* content URL after payment */
>             data-content-url="http://.../article?id=4ypNl2BMe"
>           /* product ID at SatoshiPay */
>             data-satoshipay-id=563cc11c8c823d110025e951
>           /* content length (for text) */
>             data-content-length=1170
>           /* price in satoshis (0.00000001 bitcoin) */
>             data-price=4000
>         >
> 
>         What's happening in the http://will.satoshipay.eu/ example is
>         that after
>         top-up the JS bitcoin wallet connects to the SatoshiPay server via
>         WebSocket, negotiates the smart contract and moves funds to a
>         multi-sig
>         bitcoin address. With each payment the contract gets adjusted and a
>         payment certificate is issued to the client by the SatoshiPay
>         server.
>         This certificate (currently a pre-shared secret) is shown by the
>         client
>         to the content server, which then ships the content. At no point
>         SatoshiPay ever holds control over funds. We are merely the broker.
> 
>         Now, while the payments work fine, there are a few issues with the
>         markup above as it's neither flexible nor consistent. So that's
>         my where
>         my question starts. My current idea is to redesign as follows:
> 
>         <div
>           data-sp-type="text/html"
>           data-sp-url="/paid-content/1?spCert=%s"
>           data-sp-id="563cc11c8c823d110025e951"
>           data-sp-currency="XBT"
>           data-sp-price="0.00004"
>           data-sp-length="1170"
>         >
> 
>         Improvements:
> 
>          - there is a vendor prefix
>          - different text types could be rendered and styled differently
>          - the position of the SatoshiPay payment cert in the content
>         retrieval
>            URL can be controlled by the publisher
>          - different currencies are supported
>          - price denomination meets a standard
> 
>         A payable image could look like this:
> 
>         <img
>           data-sp-type="image/png"
>           data-sp-url="/paid-images/1?spCert=%s"
>           data-sp-id="abcdef"
>           data-sp-currency="XBT"
>           data-sp-price="0.00006"
>           height="600"
>           width="800"
>         >
> 
>         Video/audio tags and download links would follow a similar pattern.
> 
>         So, I was wondering, did you spend some time on thinking about a
>         standard for this already? The only W3C resource I found is a
>         retired
>         draft from 1999: http://www.w3.org/TR/Micropayment-Markup/
> 
>         On https://www.w3.org/community/webpayments/ I see a lot of
>         JSON, but no
>         HTML markup.
> 
>         Other thoughts? Are we thinking the right direction here?
> 
>         Cheers and thanks for listening, Meinhard Benn.
> 
> 
> 
>

Received on Tuesday, 5 January 2016 01:57:33 UTC