You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
architecture/docs/goals.md

45 lines
1.7 KiB

---
gitea: none
include_toc: true
---
# Usage scenarios
## Basic scenario
A person X and person Y know each other online.
Person X feels something towards person Y, but doesn't know if their feelings are returned.
They don't want to risk misreading the situation and embarassing or pressuring Y or to be perceived as creepy, so they cannot approach Y directly.
What they can do is to visit the proposed website, log their sympathy towards Y and get notified if Y will do the same for them,
or receive an immediate response if Y already did the same for them.
## Metamour scenario
Additionally, when logging their sympathy towards Y, X should be able to choose if they want to learn about the shared connections.
If X's feelings towards Y are returned,
_and_ there is an user Z such that their feelings towards both Y and Z are returned,
_and_ both Y and Z also choose that they want to learn about the shared connections,
_then_ X should receive an immediate response about that, and both Y and Z should be notified.
# UI requirements
## Mutual sympathies
For every match (for all scenarios), all users involved should receive notifications, if they opted in to receiving these.
Additionally, for every request that ended up creating a match, an user that initiated this request should receive an immediate response about the match.
Additionally, an user should be able to see a list of all the successful matches they're part of.
# Linking social media identities to the sympathies system
TODO: to be written...
# Security, trust
All the features described above should require as little (ideally, no) trust in the admin / maintainer.
For more details, refer to [Threat models](threat-models.md)