Commit ae3f201b authored by Lysander Trischler's avatar Lysander Trischler
Browse files

Add a few basic requirements

parent 4d69400d
......@@ -23,6 +23,109 @@ Requirements and Specification
Functional Requirements
* Data privacy and protection
* No data must be publicly available. Exercises might be used to extract
health data, so insurance companies and other questionable people might be
interested in getting something to earn more money and milk their
customers. Only authenticated users can see any exercises, GPX files or
users, etc.
* All local users of a Kraftwerk instance can see anything. It's expected
that a peer group runs and operates a Kraftwerk server. In order to become
motivated to exercise, it's key to also see what others are up to.
* Maybe in the future: Define groups who are explicitly granted access to see
ones exercises. Possibly even only a subset of exercises. But that all
defeats the goal of mates having fun together.
* No connection between different Kraftwerk servers.
* Minimal user information must be stored:
* Username
* Hashed and salted password
* Optional display name
* User settings
* Timezone
* Language (German and English will be supported in the beginning)
* User login
* For the start: local Kraftwerk-own user database
* Maybe long-term: OAuth/etc. But that goes against the rule of simplicity and
puts a big hole in the privacy part.
* Maybe mid-term: provide a bridge to authenticate users with other systems.
* User registration
* Password must be repeated once to catch typos.
* Open registration for anybody must be deactivatable in the configuration.
* An administrator (do we really need this role?) should be able to approve or
reject a registration request. This should also be optional via the
* Exercises
* Start and end timestamp
* Are associated with one user
* Different types
* Situps
* Pushups
* Hikes
* Bicycle tours
* etc.
* GPX files should be optionally attachable.
* Web UI
Technical Requirements
* Written in Go
* Minimal dependencies
* Must work without JavaScript (maybe except for map)
* HTML5 and CSS
Open Questions for Discussion
* Which database?
* MySQL/MariaDB: The only relational DB Lyse has worked with successfully in
private projects. So some basic knowledge is there.
* PostgreSQL: Would be cool to try, but last time Lyse checked, it was quite
a pain to set it up, so in the end this was scrapped in the process.
* SQLite: Lyse has used that one before, too. But won't scale for large
systems. Haha, as if there were more than two people running Kraftwerk on
their servers.
* Key value stores? Would this really make sense here in this project? Lyse
kind of doubts that.
* Any other cool shit?
* Probably best to have an interface to then provide several different
storage implementations.
* Difficult data model
* Exercises are of very different kind of nature:
* Pushups and situps only require a simple counter, the number of
individual exercises that have been made.
* Hiking and bicycle tours can have GPX files attached (and the extracted
information out of it, distance, speed, altitude, etc.), a counter does
not make much sense, it will always be 1.
* What other exercises do people want?
* Any cool localization support in Go?
* The thing yarnd uses seems a bit odd to Lyse.
* Is there a good gettext implementation for Go? GNU gettext has the advantage
that it is an open format, that exists for quite a long time. So people are
already familiar with it and has good tooling support (PO editors etc.).
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment