A modern, decentralized re-imagining of the Unix plan file. Running at https://dotplan.online.
This repository has been archived on 2022-07-19. You can view files and clone it, but cannot push or open issues or pull requests.
Go to file
Rudis Muiznieks 16cd4d52c5
only caching GET requests for static files
closes #1
2022-07-19 09:55:43 -05:00
data added docker-compose and quick run details 2022-07-19 07:53:14 -05:00
static updated old github links to new location 2022-02-22 07:22:28 -06:00
test added test 2021-06-21 20:17:19 -05:00
.gitignore more files added to .gitignore 2022-07-19 07:56:08 -05:00
Dockerfile installing math::pari via apk to avoid ftp timeouts 2022-07-19 08:31:22 -05:00
LICENSE updated temp static site and added license 2020-07-23 19:17:14 -05:00
README.md added docker-compose and quick run details 2022-07-19 07:53:14 -05:00
docker-compose.yaml added docker-compose and quick run details 2022-07-19 07:53:14 -05:00
schema.sql verified check fix 2021-06-21 19:44:14 -05:00
server.pl only caching GET requests for static files 2022-07-19 09:55:43 -05:00



A modern, decentralized re-imagining of the Unix plan file.

  • User-provided content tied to an email address.
  • Text only.
  • No re-tweets, shares, @s, likes, or boosting of any kind.
  • Authenticity optionally verified by clients using minisign.
  • Accessed via public APIs.
  • Open source.
  • Self-hostable, discovery via domain SRV records.

Client Implementations and Tools

  • dotplan-cli is a script for interacting with dotplan providers from the linux shell


Any Dotplan implementation should expose at least the following endpoint and behavior:

  • GET /plan/{email} - retrieve a plan
    • Accept: text/plain request header - return raw plan content
    • Accept: application/json request header - return json plan details:
      • plan - raw plan content
      • timestamp - when this plan was created
      • signature - optional signature if this plan was signed
    • Last-Modified response header should indicate when the plan was created
    • X-Dotplan-Pubkey: {base64 signify pubkey} request header - perform signature verification
      • append X-Dotplan-Verified: true response header if verification succeeded
      • 403 if verification failed or is not supported by the server
      • client-side signature verification using the json response should be favored since the server may not be trusted
    • 404 if no plan found
    • 301 redirect if domain SRV record indicates plan is on a different dotplan provider
      • this is optional for servers to act as relays, client-side SRV lookups should be favored since the server may not be trusted


The reference dotplan implementation also exposes these endpoints for account management and authentication. Other implementations may differ and offer other authentication mechanisms (OAuth2 for example, or supporting the creation and invalidation of multiple authentication tokens).

  • POST /users/{email} - request new account
    • request json data:
      • password - the password for the new account
    • an email with a validation link will be sent
  • PUT /users/{email} - validate new account
    • request json data:
      • token - the validation token from the email
  • GET /token - retrieve auth token
    • http basic auth
    • ?expires={minutes} sets an explicit expiration, default is 5 minutes from creation
    • response json data:
      • token - the authentication token
  • DELETE /token - invalidate current auth token
    • http basic auth
  • GET /users/{email}/pwchange - get password change token
    • an email with a password change token will be sent
    • token expires 600 seconds from creation
  • PUT /users/{email}/pwchange - update password
    • request json data:
      • password - the new password
      • token - the password change token from the email

Updating a Plan

The reference dotplan implementation exposes this endpoint to update a plan using a given authentication token. Other implementations may differ and offer other mechanisms to update a plan (by email or text message for example, or integration with other services).

  • PUT /plan/{email} - update a plan
    • request json data:
      • plan - optional new plan content
      • signature - optional ascii encoded PGP signature
      • auth - the authentication token
    • omitting plan from the payload will delete the existing plan


If experimental features are enabled in this reference implementation, GET /js/{email} with an optional callback parameter will return a JSONP script that calls your function (handle_dotplan by default), passing the plan in json format. You can also optionally specify a pubkey parameter (if verification fails it will return an {"error":"..."} object).

Discovery via Domain SRV

To facilitate service discovery by Dotplan clients and relays, add a SRV record to your email domain with the name _dotplan._tcp. For example, to use dotplan.online as the service provider for email addresses at example.com, the record would look like this:

_dotplan._tcp.example.com. 86400 IN SRV 0 1 443 dotplan.online.

Docker Quick Run

git clone https://code.sitosis.com/rudism/dotplan-online.git
cd dotplan-online
cp data/msmtprc.example data/msmtprc

Edit the Dockerfile if you want to run as a user other than PID 1000, edit the ENVIRONMENT section of the docker-compose.yaml and make any other customizations for your setup, and edit the example provided data/msmtprc with your real SMTP server details (only used to send email verifications for new signups and password reset links).

cat schema.sql | sqlite3 data/users.db
docker-compose build
docker-compose up -d

You should now be able to make requests at http://localhost:4227, which is where you should point your reverse proxy for SSL configuration, etc.