Add MAYBE.md, update task list.

Dependencies

• [2] AVDFWICB More musings for the TASKS file.
• [3] MGOF7IUF Update TASKS list to reflect completed projects.
• [4] EZQG2APB Update task list.
• [5] A6HKMINB Attempting to improve JSON handling.
• [6] MB5SHULB Add route for accepting an invitation with an existing account
• [*] AXKKXBWN Initial attempt at writing down my ideas for a company based on trust.

Change contents

• file addition: MAYBE.md (----------)
  [8.2]
  + Maybe!

  + ======

  +

  + This is a place to document crazy ideas of things that we could

  + implement. It is intended to serve as a source of inspiration

  + to people joining the fixpoint aftok.

  +

  + Big Ideas

  + ---------

  +

  + ### Plan for merges as well as forks.

  +

  + It's fully to be expected that some aftoks will splinter. But it's

  + equally possible that separate aftoks might want to join forces!

  + The payout algorithm could take into account independent project

  + histories in a way that allows payments to be allocated fairly

  + irrespective of how projects of split and recombined.

  +

  + ### Build an integrated hosting platform.

  +

  + The idea here is to build something like Heroku, or a Docker hosting

  + service, with additional support for users to make things like

  + subscription-based services trivial to build. Hosted, secured account

  + management seems like something really useful for people building

  + new applications.

  +

  + Smaller Ideas

  + -------------

  +

  + ### Library Features

  +

  + * Timeline

  + * Secure the event log via inclusion of periodic hashes of the log

  + into a public blockchain?

  + * User

  + * Add public keys that can be used to sign requests. How does this interact

  + with certificate-based auth from browsers? Require openpgpjs?

  +

  + ### Webapp / API Features

  +

  + * Login

  + * Evaluate OpenID and jwt.io

  + * User Creation

  + * Require user to provide the PGP public key that will be used to authenticate requests

  + * Authentication

  + * Require bodies of all requests to be PGP-signed; this would take the place of

  + other authentication.
• edit in TASKS.md at line 33
  [4.2005]

  [4.2054]
  + * Come up with a user-friendly and reliable way to ensure that users

  + don't make errors in their BTC addresses. Maybe use very small

  + confirmation transactions, as is done when establishing ACH access

  + to checking accounts?
• replacement in TASKS.md at line 57
  [2.350]→[2.350:945](∅→∅)
  − * Previously, I had thought it would be easiest for payments to be made directly to

  − a per-aftok BTC address, and a subsequent transaction used to then distribute

  − that transaction to the participants. However, I now think it makes more sense to

  − present the payer with a transaction to complete and sign that sends funds directly

  − from their wallet to the participants, as a multiparty txn requiring signatures

  − of both the aftok server (which would sign in advance) and the payer. This avoids

  − the central server even momentarily having control of any funds.
  [2.350]

  [4.2757]
  + * Use the BIP-70 Bitcoin Payment Protocol to create payment requests.

  + * Record requested payments
• edit in TASKS.md at line 66
  [4.3015]

  [4.3015]
  + * Read history of payments and provide reconciliation and recordkeeping

  + functionality.

  + * Record BTC/USD (and other currencies) exchange rate at time of transaction

  + to aid in recordkeeping requirements of U.S. tax law. Since BTC is treated

  + as property rather than currency, one must track the basis price in order

  + to correctly report capital gains, in much the same fasion as is done for

  + stock.
• edit in TASKS.md at line 81
  [4.3394]→[4.283:326](∅→∅),[4.339]→[4.326:339](∅→∅),[4.326]→[4.326:339](∅→∅),[4.339]→[3.1:72](∅→∅),[3.72]→[4.483:767](∅→∅),[4.483]→[4.483:767](∅→∅),[4.767]→[3.73:124](∅→∅),[3.124]→[4.820:931](∅→∅),[4.820]→[4.820:931](∅→∅),[4.931]→[3.125:209](∅→∅),[3.209]→[4.1014:1075](∅→∅),[4.1014]→[4.1014:1075](∅→∅)
  −

  − Future Work

  − ===========

  −

  − Library

  − -------

  −

  − * Timeline

  − * Secure the event log via inclusion of periodic hashes of the log

  − into the public blockchain?

  − * User

  − * Add public keys that can be used to sign requests. How does this interact

  − with certificate-based auth from browsers? Require openpgpjs?

  − * Payouts

  − * History of payouts (read from blockchain?)

  −

  − Webserver

  − ---------

  −

  − * Login

  − * Evaluate OpenID and jwt.io

  − * User Creation

  − * Require user to provide the PGP public key that will be used to authenticate requests

  − * Authentication

  − * Require bodies of all requests to be PGP-signed; this would take the place of

  − other authentication.

  −

  − Payouts Service

  − ---------------