Paperwork is an open-source, self-hosted alternative to services like Evernote ®, Microsoft OneNote ® or Google Keep ®

This branch contains the second iteration of Paperwork, which is a complete rewrite. Not only is it based on another framework - it is based on a completely different technology stack. It is in its very early development phase and not yet usable.

If you were looking for the Laravel-based version 1 of Paperwork, please check out this branch. Version 1 is not in active development anymore!

Feel free to check out this branch and get involved with what's there already to get an idea of where Paperwork is heading. Also check out the current issues to see what needs to be done or suggest what could be done in future iterations.

Also, you can join the official chatroom and participate there.

Info: 99% of the action happens inside the other repositories! This repository only contains of the one-click-deployment of Paperwork!

In order to get Paperwork in its current state (under development) running, you have to have an understanding for how Docker and DNS works and know the basic concepts of HTTP proxying. Also, experience with Traefik and Minio might come in handy.

If you don't have that, then the current state of Paperwork probably isn't for you in first place. To make it clear: This software is not usable at this moment. It's being worked on to be made usable in the near future. In its current state, Paperwork v2 is targeted to developers that would like to get their hands dirty and contribute to the project.

This repository is structuring and unifying all required components for Paperwork. It its purpose is to provide an example of how you could host Paperwork yourself. However, please keep in mind that the stack file used in this repostiory should not be used for real-world, internet-facing deployments, as it lacks the ability to manage credentials between services in a secure manner.

$ git clone [email protected]:paperwork/paperwork.git

In order to easily get Paperwork running as a Docker stack, utilizing whichever orchestrator you'd like, this repository comes with a handy Makefile. Let's have a look at it:

$ make help

Launching the Paperwork can be done by make-ing the deploy` target:

$ make deploy

The Makefile then takes care of initializing Swarm, in case you haven't done that already, creating the encrypted network (papernet) and deploying the Paperwork stack on top of it.

Note: This Docker stack is configured to use www.paperwork.local (for the web UI) and api.paperwork.local (for the API services). Hence you will need to add these to the 127.0.0.1 entry in your /etc/hosts file:

127.0.0.1   localhost paperwork.local api.paperwork.local www.paperwork.local

In order to stop/remove the whole stack, simply use the undeploy target:

$ make undeploy

Note: This won't make your Docker host leave Swarm again, in case it wasn't running in Swarm mode before deploying! If you'd like to turn off Swarm, you have to manually do so.

If you'd like to use a different orchestrator for stack deployment, you can do so by setting the ORCHESTRATOR variable on deploy:

$ make deploy ORCHESTRATOR=kubernetes

For more info, check the official Docker documentation for Mac and Windows.

As soon as you've finished the setup, you should be able to access your Paperwork deployment through this URL and you should be greeted with the login/registration:

In order to use Paperwork, you will need to register a new account.

Please refer to the individual services' repositories in order to get more information on how to contribute.

Here are the main repositories of Paperwork v2:

• paperwork: This repository, containing the one-click-deployment and overall documentation
• paperwork.ex: Elixir SDK for building Paperwork services
• service-configs: Configurations service built in Elixir, that stores instance configs and provides them through an internal endpoint to other services
• service-users: Users service built in Elixir, that stores user information and provides endpoints for users to register, login and update their information
• service-notes: Notes service built in Elixir, that stores all user's notes
• service-storages: Storages service built in Elixir, that stores all user's attachments
• web: Angular 7-based web front-end for Paperwork

The Paperwork project consists of a handful of custom-built API services, which take care of everything related to their specific domain: Configurations, users, notes & attachments. Underneath those, there are various infrastructure services which are either implemented by the Paperwork project (service-gatekeeper) or simply awesome third-party open-source projects that's being made use of (e.g. Minio and Traefik).

The API services provide the core logic that processes domain specific data and persists it on the service's own database. Each API service has its own database that no other services accesses directly. Instead, services communicate with each other through internal HTTP endpoints. The gatekeeper service abstracts the authroization layer from each individual service by checking and decoding the JWT bearer, so that every service that runs behind service-gatekeeper can be sure that access was validated and session information is forwarded and accessible via HTTP headers. JWT crafting is currently done in service-users. Hence, service-gatekeeper and service-users need to share the same JWT secret. Implementation in this area is kept simple for now but will change with the introduction of OAuth2.

While the API services are not exchangeble, infrastructure services usually are. For example Traefik could be replaced with NGINX, Minio with a real Amazon S3 storage and even gatekeeper could more or less easily be replaced with Kong or a similar API gateway in future. API services on the other hand are tighly integrated with the business logic and their own databases. Also, because they exchange information with each other through internal endpoints, they depend on each other and (partially) on their peer's data structures. For example the notes service performs an internal request towards the users service when a note is being requested, in order to include user information (first name, last name, etc) for every access definition within that note. This aggregation of data is not neccesary form a back-end point of view and is only done in order to make things more comfortable for the UI layer. While, from a separation-of-concerns-perspective this might not be an ideal setup, it reducdes complexity for now and allows the project to iterate quite quickly.

On top of the infrastructure and API services there is the UI layer that was just mentioned, which currently consists of the Paperwork Web UI. The web UI is a PWA built on Angular 7 that talks to the API services through the gatekeeper service. It's aimed to provide 100% offline use capabilities, so that it can be worked with in scenarios in which there's no connectivity to the API.

As for now, all tasks/issues are being collected inside this repository, just to keep it simple. On a long term, tasks/issues will be transferred into the related service's repository, in order to be able to reference them through git commits.

The best way to help this project is by contributing to the code. However, if that should not be possible to you, but you'd still like to help, the Paperwork project gladly accepts donations in form of Bitcoins and Ether. Please use the following addresses to direct your donations:

CAUTION: Do not send any donations to anywhere else but those addresses. Unfortunately we had situations in which random people (that were not affiliated with this project in any kind) posted PayPal addresses inside GitHub issues in order to scam money.

• Browse
• Chat
• Tweet
• Mail