Qwyre.com — Converting a digital work into a monetized stream [Grant Report #1]

Projects are like London buses. You wait for hours, standing alone in the pouring rain at midnight freezing your important bits and wondering if you'll ever be warm again, when two come along together.

And so I found myself, six months ago, navigating two wonderful projects while hoping that I'd pull it off.

Gentle reader. Working 14-hour days, seven days a week, for six months, is not a healthy pursuit. Hence the break in these monthly reports. My apologies. But the last month has been well spent with an interim release for you to play with.

One of the most gratifying new features (for me, as a lazy person) is that you can paste a link to an epub and simply import direct into the app. And here a shout-out to Standard eBooks which are a wonderful community project reformatting public domain books into standards-compliant epubs.

If you're a self-published author and want to link to the app direct and don't want your readers to have to faff about, generate a link yourself:

Converting digital objects into digital streams

Web Monetization is a per-second payment stream and it requires a per-second product. Some things are naturals for this, and they're usually live or where the digital service is tightly linked to a platform. Text isn't normally streamed, but music and movies can easily be downloaded as well.

Streaming means deliberately breaking data into chunks and streaming those in a format that permits live, iterative, building of the digital object from these chunks while also serving the content in that dynamic object.

For text, that means a stream of words. Except they also have to carry markup so they're formatted properly on arrival. Then the page needs to be updated without offending the reader. It's not trivial.

For anyone else stuck with this, here is an exceptional Stackoverflow answer that details not just the high-level strategy, but also provides a great foundation in code.

Progress on objectives

The status as of the previous updates (1, 2, 3):

• Convert docx into epub using Chapisha,
• Read epub using Futurepress,
• Monetize using Coil (and please do read my lengthy write-up on how to do this).

For this report, these additional features are complete:

• Importing an *epub" for publication,
• Agreeing, and signing, a contract with an editor,
• Converting a work to a stream source,
• Streaming the work in response to web monetization.

Preparation of a work for publication

There are plenty of ways independent authors can self-publish. That lack of any friction between the author and the reader is one reason so much is produced, and with such low quality. Commercially-published work benefits from the simple barrier of being edited. Just that surfaces poor prose and obscure, or irrational, storytelling.

Qwyre is about collaborative publication, so here's the workflow:

1. Start at your new creator's workshop

Here you'll find links to the docx convertor, as well as panels to review your works in progress, and offers for editors.

2. Import your epub, either during the docx conversion process or, if you've produced your epub in some other way, direct into the platform:

This is intended to be as easy as possible. If you've got an external link or a local file, either can be imported.

3. Review the work and check that metadata, the contents and sample text are presented as expected:

The metadata and text are derived entirely from the epub you uploaded. If anything is incorrect it may be because of non-conformance to the epub standard, or because the text is wrong in the source. Correct that, upload a new epub, and ensure you're happy.

4. Prepare a contract with your revenue share between yourself and prospective editors. This is what will be shared between the author and editor during monetization.

Here's another reason to only permit publication after review by an editor. Here I'm attempting to claim authorship of 'The Magician' by W. Somerset Maugham. No, that should never be accepted. Any editor should catch that right away and refuse even to accept an offer to collaborate on the work in the first place.

5. Offline collaboration for publication is an important part of the creative process.

The review and collaboration process is initiated via email. Sharing the editor's email address with the author only when offered, and then getting out of their way once they finalise their contract. Qwyre is not going to own the editorial process and the parties to the creative work should edit and review as they prefer.

Only once both parties have agreed the contract, and agreed the work is ready for publication, can the creator release the work onto the platform.

6. Readers can search for published works and start streaming

There is as little friction between reader and reading as possible. You don't need to login to start reading a work. You don't even need to pay for the initial pages. The app works for free, giving a reader the opportunity to anonymously try out the app, and the creative work.

7. Seamless call to monetization, and a judgement call ...

The sign-up process involves two steps:

• Creating a Qwyre.com account
• Creating a Coil.com subscription and linking that to Qwyre.com

One reason was to physically seperate Qwyre.com from monetization. The app itself stores nothing about monetization out of the browser. There's no account to delete or concern about data probity. Sure, not forcing the user to create an account would simplify sign-up. That way we only have to worry about the reader signing up with Coil.

However ... I need some way to keep track of where the reader has gotten to in streaming any work so that they are not double-charged for the same thing across multiple devices. That requires a login.

Once the reader has authenticated everything, they are still in complete control of the monetization process.

Development and monetization receipts ...

This is harder than it needs to be. There are no development APIs, so you're working with live Coil accounts, and the largest challenge is proving that you are getting paid.

Webmonetization offers a receipt verifier service. This is yet another third-party layer between your app and payment. Instead of embedding wallet pointers into your code, you now interpose a verifier endpoint: $receipt-verifier.example/%24wallet.example%2Falice

It's a complex requirement and immediately runs into CORS issues, meaning you'll need to implement this all yourself creating additional opportunities for broken/dangerous code.

Some recommendations I'd like to see:

• We need some developer endpoints. I want to test out what happens when payments fail in various scenarios. This is hard to do with a live account.
• The Web Monetization scripts returns a series of events. It would be tremendous if this included a receipt by default. If I want to implement my own receipts verifier, fine, but not having it here creates sequencing issues. Receipts need to be verified continuously for continuous payments. The more endpoints to pole, the more chance for glitches and delays.

What's next?

The last outstanding feature is the search engine. Once that is done, I'll release the final version. I also intend to run a demo with the African Speculative Fiction Society members and get some feedback on the work to date. The 2021 Nommo Awards were just announced so go find some African scifi to read.

What community support would benefit your project?

I'd appreciate thoughts and feedback on the publication workflow, as well as on the interim release at Qwyre.com.