OpenSource note-taking & archiving
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.
The very first version of Paperwork was started in July 2014 as a pet-project by this guy, mainly out of frustration about the existing services (Evernote & others), fear ignited by the Snowden revelations and curiosity about whether the effort would lead to something people would be interested in. And apparently it did. :) Soon, more great people joined the project and contributed.
However, originally the tech that was used to build the very first version on top (mainly PHP 5, MySQL, Laravel 4, Angular & Bootstrap) was chosen to keep things simple and allow iterating quickly. The primary goal for the project was the actual result, rather than any sort of technological finesse.
Over the time, two observations concerning the chosen technology were made:
- Most of the time, the biggest pain-points during the implementation of new features were not within the front-end but rather on the back-end side
With us basically struggling to implement heavily requested features, not solely but also due to technical debt that was caused by poor technical decisions in first place, the project slowly became dormant.
So, what now?
This branch contains a very first suggestion, of how the second iteration of Paperwork could look like. As you might notice, one major change is the clear separation of components, making this branch (and hopefully soon the whole repository) only one piece of the puzzle. Currently, it only contains of the back-end component — or better, one of them — and does not include front-end components whatsoever. The idea is to build the second iteration in a more modular and diversified manner, picking the right tool for the task rather than building a monolith that is harder to maintain the bigger it grows.
Okay, cool. But what took you so long to get to this point?
Funding. Basically this point was planned and headed towards sometime in mid 2016. Since then, different attempts were made to get funding for this project, through individuals but also programs like Prototypefund. The general idea was to accelerate development by paying you, the contributors, using a bounty-source-like approach. Unfortunately none of the attempts led to an actual funding or investment whatsoever. At this point putting the effort into the actual development, instead of pursuing further discussions and applications for such programs seems to make more sense.
I would love to help!
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 project board to see what needs to be done or suggest what and how should be done.
This repository is structuring and unifying all required components for Paperwork.
$ git clone firstname.lastname@example.org:paperwork/paperwork.git
The setup is split into separate compose files that can be run individually of each other. In order for the
service compose-files to work, the
infrastructure compose-file needs to be running, though.
The compose-setup depends on an encrypted overlay network to be created. For that, your docker environment needs to have swarm activated. You can do so by running:
$ docker swarm init
There is no need to join any more members to it. Only with swarm enabled the
infrastructure can be launched:
$ docker-compose up --build
infrastructure is up and running all the services can be started individually.
In order to start the users service (
service-users), run the following command:
npm run dev
infrastructure) reach out to the local development instance of
service-users. In to do that the
devproxy is being required.
devproxy automatically runs inside the
infrastructure, exposes port
2222 on the host and provides a way to forward local development ports into the docker environment. In order to forward the local
service-users port into the docker environment, an SSH port forward is required:
$ ssh -o "UserKnownHostsFile /dev/null" -o "StrictHostKeyChecking=no" -p 2222 -R 3000:127.0.0.1:3000 email@example.com
The root password is
root. This forwards the local port
3000 into the
devproxy, so that
service-kong could reach
In order to do so, the locally running
service-users needs to have the
SERVICE_USERS_URL environment variable set to
http://devproxy:3000, as it uses this variable to set up the kong upstream for
Developing / contributing
Please refer to the components' repositories in order to get more information on how to contribute.