crushdb/specification.txt

SPECIFICATION (German)

Project role
- This is an online contact directory / personal archive, not a transaction
  ledger. Its main job is to store and share structured information about
  people and their related items under controlled access.

Core concepts
- Account (Login identity)
  * One account is permanently tied to exactly one email address.
  * Each email address has its own password.
  * Different accounts can have different rights.
  * An account is the login boundary, not the data owner in every case.

- Person
  * A person is the central real-world entity.
  * One person can be linked to multiple email addresses / accounts but every account /e-mail can only be linke to oner person.
  * A person is not owned by any single account.

- Article
  * Every person has articles.
  * Articles exist in different article types.
  * Article visibility is not global.
  * Articles are only visible to people who hold the required rights and/or
    belong to the required group(s).

- Article types
  * Examples of article types:
    - Contact details
    - Notes
    - Profile text
    - Documents
    - Links
    - Phone numbers
    - Addresses
    - Social profiles
  * The set of article types is fixed for the implementation, but the system
    treats them as distinct, named categories.

- Groups
  * Groups are person-dependent.
  * Groups are NOT email-dependent.
  * A group describes a set of persons.
  * Group membership follows the person, regardless of which account or email
    is used to access the system.

- Rights
  * Rights are fixed, named capabilities.
  * Rights control what can be seen, created, edited, or removed.
  * Rights are used together with group membership to decide access.

Relationships
- Account <-> email
  * One account, one email address, fixed binding.
- Email <-> password
  * Each email has its own password.
- Person <-> accounts / emails
  * One person may relate to several emails/accounts.
- Person <-> groups
  * Groups are built around persons.
- Person <-> articles
  * A person owns articles of various types.
- Articles <-> readers
  * Reading and other actions depend on rights.
  * Reading can also depend on group membership.
- Groups <-> persons
  * Membership is defined by persons, not by accounts.

Access model
- Visibility rule
  * An article is shown only if the requesting party has the required right
    AND is allowed by the relevant group constraints.
  * If either condition is not met, the article is not visible.
- Purpose of the rule
  * Some articles are private.
  * Some articles are shared only with selected persons or groups.
  * Group-based visibility is independent from email/account identity.

Account scope
- Login
  * Accounts are used to authenticate a user.
  * Authentication is tied to an email address and password.
- Rights assignment
  * Different accounts can be granted different rights.
  * Rights are assigned at account level or in relation to persons/groups,
    depending on the access rule for the article.

Person scope
- Data ownership
  * A person is the owner of their own articles.
  * A person can have multiple linked accounts/emails.
- Shared context
  * Other parties may access articles only through the rights/group model.

Groups and persons
- Membership
  * Groups contain persons.
  * Group membership does not depend on the email used for login.
- Example interpretation
  * If a person belongs to a group, then that group relation follows the
    person, not a specific email account.

Article model
- Each article has:
  * An article type
  * Content belonging to that type
  * An owner person context
  * Access rules based on rights and group membership
- Article types are distinct categories, not free text, so that access can be
  handled per type in a structured way.

Security and privacy goals
- Private by default where appropriate
  * Not everything is publicly visible.
- Controlled sharing
  * Sharing happens via rights and groups, not via open access.
- Person-centric sharing
  * Visibility follows persons and groups, not only the account that logs in.
- Separation of concerns
  * Login (account/email/password) is separate from data ownership (person).
  * This allows one person to be reachable through several emails without
    merging all content into one account identity.

Functional expectations
- Account management
  * Create account for an email address with a password.
  * The email address is fixed for that account.
- Person management
  * Represent persons independently of a single account.
  * Link multiple emails/accounts to one person where needed.
- Article management
  * Create, view, edit, and remove articles for a person.
  * Store articles by type.
  * Enforce visibility by rights and group membership.
- Group management
  * Groups are defined around persons.
  * Membership is used for visibility/access decisions.
- Rights handling
  * Rights decide what is allowed for an account/requesting party.
  * Rights work together with group-based visibility rules.

Non-goals for this version
- This is not a payment system.
- This is not a transaction ledger.
- This is not primarily an account-consumption platform; accounts exist for
  login and rights, but persons and their articles are the main content.

Level of detail required from the specification
- Account model
  * Fixed email per account.
  * Password per email.
  * Different rights per account.
- Person model
  * Persons as first-class entities.
  * Support for multiple emails per person.
- Article model
  * Article types.
  * Ownership context.
  * Rights/group-based visibility.
- Group model
  * Person-dependent groups.
  * No email-dependent groups.
- Access behavior
  * Explicit visibility rules.
  * No open global visibility for restricted articles.

This specification intentionally describes what the system is and what rules
it follows, so that later implementation matches the intended model exactly.