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.
46 lines
1.7 KiB
46 lines
1.7 KiB
3 years ago
|
---
|
||
|
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)
|