# SourceCheck User Stories v0.2
v0.2 moved to hackmd: https://hackmd.io/dlecbXABSSWyIJNEq-ZcZQ
v0.1
1. "Enrolment": Publisher Creates SC account, associates WMS acct to SSI account
1. Publisher goes to SC website and clicks on "Register" button
1. App shows registration instructions:
1. Install Credible wallet
2. Install WMS account
2. App shows QR code and a message saying something like, "come back after you've got these two things to continue"
2. Publisher gets WMS wallet (Uphold) from Coil
3. Publisher downloads Credible and creates ID
4. Publisher logs into SC website with Credible wallet
5. Publisher opens WMS page on SC backend - enters recipient-wallet info
6. Publisher scans QR code asking SSI wallet to authenticate
1. Once authenticated, publisher is redirect to "Finish registration" page
1. Provide default WMS address
2. Confirm / customize default royalties structure (100% of royalties goes to publisher)
1. [in future, allow multiple publishers and multiple WMS addresses]
- Jefferson: we need to dig into the mechanics of WMS enrollment— can publisher get a credible ID and a WMS account in any order? any way to bind the two?
2. (A)Publisher Creates Book
- Step 0A.) Publisher already has a manually-generated fancy PDF that they were thinking of selling on Amazon (40% cut). Assume fancy PDF uses dynamic table of contents and internal links.
1. Publisher clicks on "Publish book" ( "Publish SourceCheck Edition"? we need to convey that it's not a book— it's a SC book :D )
2. "Publish Book" dashboard is shown, with the following fields:
1. PDF File (click upload)
2. [Choose watermark/downgrade option - default is none]
3. Select Royalties structure from list of defaults or manually create
1. Optional field: BTC or Ethereum address for "manual voluntary payments"
2. [For later: deterministic default royalty structures based on ToC]
4. Back-end Processing Steps
1. WMS embedded in the PDF
2. Royalties structure is appended to PDF
5. Click on "Sign and Publish"
6. App shows QR code asking to sign the file / royalties structure
7. Publisher signs the PDF with the SSI wallet
8. (Backend:) SSI signatures embedded in the PDF
9. [Redirect to second signing page for watermarked/downgraded preview]
10. [(Backend:) Apply watermark/downgrading effect]
11. (Backend:) Redirect to next step
3. App shows a page confirming publication
1. Link to SourceCheck book preview
2. Link to downloadable signed PDF file
3. [(aka [2](//2)B) User "re-orders" chunks (i.e. orders chapters) and enters title info. This automatically creates a Title Page, legal page, table of contents. ]
- Step 0B.) Publisher can create structured content directly in "SC backend" (strapi)
1. Optional: They are taken to "edit pages" for auto-generated title page and table of contents. Most users will not modify auto-generated content here.
2. Optional step: Publisher inputs royalty info for "honor system" royalty scheme. Leaving all fields blank will great a generic "publisher keeps all royalties" page.
3. Publisher signs book with SSI wallet
1. WMS added automatically if "enrolment" user story above has already associated with signing identity
2. Otherwise, popup will direct to [possibly slightly diff] enrolment process
4. Publisher gets back permanent link directly to WMS-activated preview of book (i.e. [preview.sourcecheck.org/org/book.pdf](http://preview.sourcecheck.org/org/book.pdf) )
5. Publisher can link to "preview" anywhere the book is sold
6. Publisher downloads PDF, which opens normally in a PDF reader
7. Publisher can use downloaded PDF to confirms/test the preview (without having to pay themself)
4. [(aka 2C) Ghost-based book generation]
- Step 0C.) Publisher already has a paid Ghost acct (can be self-hosted or hosted) full of chunks of content. Logs into Ghost, selects the chunks, and exports to SC backend via a Ghost plugin that we write, which does only that.
5. [(aka 2D) REST-based book generation in other CMSs, including DRUPAL]
- Step 0D.) Publisher can pull content from other places through REST APIs / OAuth (to be researched- out of scope for now)
- Note: Drupal already has "book formatting" options and a book [object class](https://www.drupal.org/docs/8/core/modules/book/overview)
6. Publisher, with downloaded book from Story 2, can sell PDF on [leanpub.com](http://leanpub.com) or other marketplaces [ideally directly from leanpub]
1. ***Research action item: investigate leanpub options***
7. Reader discovers book <somewhere>
1. Reader follows link to preview.sourcecheck.org/org/book.pdf
2. views PDFs, paying with WMS
1. If no WMS (Coil) extension the content will not be available; error messages should say "go get WMS and return with it installed.
2. Error handling: can our rendered page detect if WMS isn't paying? What error messages or error pages should we have for problem cases?
3. [Feature to disable screengrabs in-browser?]
3. [some day— gets refund/discount on preview?]
1. [no way to do this in today's coil wallet, but keep in mind when discussing alternate WMS wallet requirements]
8. [Reader buys PDF, views without paying]
1. [Rebate for WMS credit? not sure current WMS spec allows any kind of self-tracking or opt-in for credit. For further research]
9. Publisher Dashboard - What info do they have about their published books?
1. Conventional metrics (pageviews per page, at least from our renderer)
2. [WMS metrics per book? (***Action item: figure out what Coil's WMS protocol currently supports/allows***)]
3. Unpublish /deactivate book
10. Education use case #1: who is googling "how to publish books in WMS"? Think through publisher onramps and corresponding steps of education for Publisher (payments, identity, PDF security, server-side PDF versus download)
11. Education use case #2: who is googling "how to preview books with WMS"? Think through user onramps and corresponding steps of education for Publisher (crypto, browser extension)
Sign in with Wallet
Connect another wallet