HonorBox

Introduction

The HonorBox "platform" gives publishers of content three powerful capabilities:

1. To create a "donation address" specific to each piece of content, such that donations or "honor system" payments can be made by end-consumers regardless of distribution.
2. To embed in each publication to verifiable claims about its authenticity and the royalty commitments its publisher assumes, including for direct donations.
3. To embed a QR code from #1 into #2, thus guaranteeing that royalty statements can be automatically and programmatically enforced by decentralized direct payments.

A demo of the backend can be found here

Technological/Stack choices

"Donation addresses" are encoded, in this prototype, as Solana programs (smart contract), or technically as two Solana addresses, one for control and the other to hold balances for each withdrawer of funds authorized by the initial royalty contract. This contract, along with authorship/rights claims, are encoded at time of publication using a back-end explained below. One by-product of this encoding is a QR code (generated using the npm package node-qrCode) which can be displayed on a donation/authenticity/royalties page. This optional page is appended to the PDF using PDF-LIB, which is also used to deterministically generate the "tamperproofing" hash contained in the authenticity statement.

Both sets of verifiable claims about a publication are encoded as Verifiable Credentials, a W3C standard (CR stage) that wraps a set of claims about a subject (expressable in, for example, a JSON object) in a signed JSON-LD envelope, which allows for data portability by anchoring to one or more Linked-Data Ontologies. We use the open-source DIDKit libraries from Spruce Systems to handle signing mechanics and to convert royalty statements, authenticity statements, and blockchain address/accounts into Verifiable Credentials. These VCs are then embedded into PDFs using PDF-LIB.

All of this is handled in a custom back-end, which we are making available as open-source (linked below). It is built by extending [Strapi] (https://strapi.io/). The front-end was developed using Next.JS and Tailwind CSS (https://tailwindcss.com/). One noteworthy feature is that rather than simply using Strapi's built-in username/password user account system, we bound Strapi accounts to an "SSI" wallet, which not only allows for user-friend KMS and blockchain interoperability, but also allows a copy of the VCs generated to be stored by the user for more secure record-keeping and privacy-preserving auditing. As the Spruce team finishes packaging the next version of Credible, we plan to migrate from the mobile-based to the browser-based version of Credible, although we might keep both options once a replication system is introduced. Strictly speaking, there is nothing specific to Credible that makes it impossible to replace it with any other standards-conformant SSI wallet.

PDF-Lib can also be used, in combination with DIDKit, to verify a tamperproof authenticity statement against the content. Such verification is out of scope for this prototype, but we have already prototyped such verification as part of another project.

Architecture and Dependencies

This new SourceCheck prototype builds on an earlier project made with support from a small Mozilla prototyping grant (see codebase here and live demo here). This earlier project stitched together open-source components (Next.JS, Strapi, Spruce Systems' DIDKit and Credible) to create a backend for publishers to embed authenticity provenance, tamper-proofing, and royalty-obligation transparency commitments into PDFs in the form of W3C Verifiable Credentials (another draft standard a little further along in W3C). These PDFs could then be view in a WMS-enabled server-side renderer extracting and verifying.

To understand how this functionality is composed of various open-source components, extensions, and modifications, see our architecture document. Also see our authentication and signing flows document and our changelog for the project to round out the documentation.

The components, organized as separate repositories for maximum reusability and forking, are:

• Revenue-Sharing Solana Program: Code snippets for establishing simple revenue-sharing smart contracts according to arbitrary user input (as seen in the backend component)
• HonorBox Publisher dApp: A site where publishers can upload content in the form of a PDF, define verifiable royalty commitments, encode these as smart contracts on the Solana blockchain, and wrap all of this into a new PDF for "honor system" distribution.
• HonorBox Back-End API: Customized Strapi API to handle provenance, VC, and re-wrapping of tamper-proofed and signed PDFs.
• HonorBox Back-End dB: MySQL and Redis dockerized to support Strapi & customizations.
• Credible Wallet: Used for authentication and signing. Custom builds can be made from the github repo, and standard/demonstrator builds will soon be available in both major app stores (being listed at time of press).

Updates

Sign up for updates on our website, SourceCheck.org.