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.

      * 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?

    * 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.

    * Use the BIP-70 Bitcoin Payment Protocol to create payment requests.
    * Record requested payments

    * 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.

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
---------------