|
|
TODO: include a simple overview of the service here
|
|
|
|
|
|
[[_TOC_]]
|
|
|
|
|
|
# Tutorial
|
|
|
|
|
|
<!-- simple, brainless step-by-step instructions requiring little or -->
|
|
|
<!-- no technical background -->
|
|
|
|
|
|
TODO: think of a few basic use cases
|
|
|
|
|
|
# How-to
|
|
|
|
|
|
<!-- more in-depth procedure that may require interpretation -->
|
|
|
|
|
|
TODO: restart? upgrades?
|
|
|
|
|
|
## Pager playbook
|
|
|
|
|
|
<!-- information about common errors from the monitoring system and -->
|
|
|
<!-- how to deal with them. this should be easy to follow: think of -->
|
|
|
<!-- your future self, in a stressful situation, tired and hungry. -->
|
|
|
|
|
|
TODO: pager playbook.
|
|
|
|
|
|
## Disaster recovery
|
|
|
|
|
|
<!-- what to do if all goes to hell. e.g. restore from backups? -->
|
|
|
<!-- rebuild from scratch? not necessarily those procedures (e.g. see -->
|
|
|
<!-- "Installation" below but some pointers. -->
|
|
|
|
|
|
TODO: restore / rebuild procedures
|
|
|
|
|
|
# Reference
|
|
|
|
|
|
## Installation
|
|
|
|
|
|
The machine is temporarily hosted at Lunanode while a decision is made
|
|
|
about where to host it.
|
|
|
|
... | ... | @@ -16,9 +53,165 @@ Lunanode was chosen as a cheap and easy temporarily solution. Some |
|
|
doubts remain regarding how to make sure the machine and service are
|
|
|
updated on a timely manner.
|
|
|
|
|
|
TODO: expand the install procedure and how to hook it up
|
|
|
|
|
|
TODO: https://docs.btcpayserver.org/ConnectWallet/
|
|
|
|
|
|
## SLA
|
|
|
|
|
|
TODO <!-- this describes an acceptable level of service for this service -->
|
|
|
|
|
|
## Design
|
|
|
|
|
|
<!-- how this is built -->
|
|
|
<!-- should reuse and expand on the "proposed solution", it's a -->
|
|
|
<!-- "as-built" documented, whereas the "Proposed solution" is an -->
|
|
|
<!-- "architectural" document, which the final result might differ -->
|
|
|
<!-- from, sometimes significantly -->
|
|
|
|
|
|
<!-- a good guide to "audit" an existing project's design: -->
|
|
|
<!-- https://bluesock.org/~willkg/blog/dev/auditing_projects.html -->
|
|
|
|
|
|
<!-- things to evaluate here:
|
|
|
|
|
|
* services
|
|
|
* storage (databases? plain text files? cloud/S3 storage?)
|
|
|
* queues (e.g. email queues, job queues, schedulers)
|
|
|
* interfaces (e.g. webserver, commandline)
|
|
|
* authentication (e.g. SSH, LDAP?)
|
|
|
* programming languages, frameworks, versions
|
|
|
* dependent services (e.g. authenticates against LDAP, or requires
|
|
|
git pushes)
|
|
|
* deployments: how is code for this deployed (see also Installation)
|
|
|
|
|
|
how is this thing built, basically? -->
|
|
|
|
|
|
TODO: design audit
|
|
|
|
|
|
TODO: document how this is hooked into https://donate.torproject.org/cryptocurrency/
|
|
|
|
|
|
## Issues
|
|
|
|
|
|
<!-- such projects are never over. add a pointer to well-known issues -->
|
|
|
<!-- and show how to report problems. usually a link to the bugtracker -->
|
|
|
|
|
|
There is no issue tracker specifically for this project, [File][] or
|
|
|
[search][] for issues in the [team issue tracker][search].
|
|
|
|
|
|
[File]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/new
|
|
|
[search]: https://gitlab.torproject.org/tpo/tpa/team/-/issues
|
|
|
|
|
|
In the long term, given the sensitive matter of hosting a payment
|
|
|
service, we should have this in our tpa managed infrastructure, see
|
|
|
[issue tpo/tpa/team#33750](https://gitlab.torproject.org/tpo/tpa/team/-/issues/33750) for details.
|
|
|
|
|
|
TODO: integrate the service template here, and make proper docs,
|
|
|
especially about upgrade/backup/restore procedures. |
|
|
## Maintainer, users, and upstream
|
|
|
|
|
|
<!-- document who deployed and operates this service, who the users -->
|
|
|
<!-- are, who the upstreams are, if they are still active, -->
|
|
|
<!-- collaborative, how do we keep up to date, -->
|
|
|
|
|
|
hiro did the first deployment of this service at lunanode, anarcat is
|
|
|
working on the second deployment, which should be managed by TPA.
|
|
|
|
|
|
The finance team is fundamentally the people responsible or at least
|
|
|
dependent on this service, alongside anyone who needs to donate
|
|
|
cryptocurrency to the Tor project.
|
|
|
|
|
|
Upstream is the [BTCpayserver project](https://btcpayserver.org/) itself ([GitHub org](https://github.com/btcpayserver/)) and
|
|
|
are fairly active.
|
|
|
|
|
|
## Monitoring and testing
|
|
|
|
|
|
<!-- describe how this service is monitored and how it can be tested -->
|
|
|
<!-- after major changes like IP address changes or upgrades. describe -->
|
|
|
<!-- CI, test suites, linting, how security issues and upgrades are -->
|
|
|
<!-- tracked -->
|
|
|
|
|
|
TODO: how do we monitor payments work?
|
|
|
|
|
|
TODO: how do we test BTC payments works?
|
|
|
|
|
|
## Logs and metrics
|
|
|
|
|
|
<!-- where are the logs? how long are they kept? any PII? -->
|
|
|
<!-- what about performance metrics? same questions -->
|
|
|
|
|
|
TODO: logs and metrics
|
|
|
|
|
|
## Backups
|
|
|
|
|
|
<!-- does this service need anything special in terms of backups? -->
|
|
|
<!-- e.g. locking a database? special recovery procedures? -->
|
|
|
|
|
|
Upstream has a [backup procedure](https://docs.btcpayserver.org/Docker/#how-can-i-back-up-my-btcpay-server).
|
|
|
|
|
|
TODO: how do we actually restore? does it matter? apparently we can
|
|
|
just reset an instance from our wallet, how does that work?
|
|
|
|
|
|
## Other documentation
|
|
|
|
|
|
<!-- references to upstream documentation, if relevant -->
|
|
|
|
|
|
TODO: link to upstream manual
|
|
|
|
|
|
# Discussion
|
|
|
|
|
|
TODO: document why this project exists
|
|
|
|
|
|
## Overview
|
|
|
|
|
|
TODO: more in-depth audit
|
|
|
|
|
|
<!-- describe the overall project. should include a link to a ticket -->
|
|
|
<!-- that has a launch checklist -->
|
|
|
|
|
|
<!-- if this is an old project being documented, summarize the known -->
|
|
|
<!-- issues with the project. to quote the "audit procedure":
|
|
|
|
|
|
5. When was the last security review done on the project? What was
|
|
|
the outcome? Are there any security issues currently? Should it
|
|
|
have another security review?
|
|
|
|
|
|
6. When was the last risk assessment done? Something that would cover
|
|
|
risks from the data stored, the access required, etc.
|
|
|
|
|
|
7. Are there any in-progress projects? Technical debt cleanup?
|
|
|
Migrations? What state are they in? What's the urgency? What's the
|
|
|
next steps?
|
|
|
|
|
|
8. What urgent things need to be done on this project?
|
|
|
|
|
|
-->
|
|
|
|
|
|
## Goals
|
|
|
|
|
|
<!-- include bugs to be fixed -->
|
|
|
|
|
|
TODO: Go over the essentials of the [launch ticket](https://gitlab.torproject.org/tpo/tpa/team/-/issues/33750) and describe
|
|
|
what is the requirements for this project
|
|
|
|
|
|
### Must have
|
|
|
|
|
|
### Nice to have
|
|
|
|
|
|
### Non-Goals
|
|
|
|
|
|
## Approvals required
|
|
|
|
|
|
accounting, finance, TPA, hiro.
|
|
|
|
|
|
## Proposed Solution
|
|
|
|
|
|
TODO: summarize the strategy we have taken to maintain this thing
|
|
|
|
|
|
## Cost
|
|
|
|
|
|
TODO: cost
|
|
|
|
|
|
## Alternatives considered
|
|
|
|
|
|
<!-- include benchmarks and procedure if relevant -->
|
|
|
TODO: briefly cover alternative systems (e.g. "generate a bunch of
|
|
|
bitcoin addresses periodically and have a button to show one at a
|
|
|
time") |