🏕 Darim

• Darim: Diary Improved
• Darim is a personal diary service that supports encryption, calendar view, and markdown syntax.
• You can keep your diary a secret even from the developer through client-side encryption.

Architecture

• Darim is following the layered architecture.
• Each layer cannot be cross-referenced. All references between layers can flow in a higher direction. In other words, only the upper layer can invoke the lower layer members.

Client

• index.html - An entry point of the application. It is built by parcel.
• Pages - Pages represented by URL. Each page can use general components, API fetchers, and models.
• Components - Reusable components used on multiple pages.

API Gateway & Server

• main.rs - An entry point of the application. It runs a http server.
• Routes - A presentation layer that makes API public and passes request/response data to other layers.
• Services - A business layer that processes the transaction.
• Models - A data layer that can access the database and define data structures.

Client-side Encryption

Darim supports client-side encryption to protect the user's secrect from others including server.

Key generation

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
    Note over client: generates<br>secret and public
    Note over client: encrypts secret<br>using public
    client ->> local storage: set(encrypted_secret)
    client ->> server: POST /public_key { public }
    server ->> rdb: INSERT public
    rdb -->> server: [OK 200]
    server -->> client: [OK 200]

1. When a user finishes the sign-up process, a secret key and public key are generated on the client-side.
2. The client encrypts the secret key using the public key and saves the encrypted secret key to local storage.
3. The public key is sent to the server, and the server stores it.

Read & Write

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
    Note over client: creates a new post
    client ->> local storage: get(encrypted_secret)
    local storage -->> client: encrypted_secret
    client ->> server: GET /public_key
    server ->> rdb: SELECT public
    rdb -->> server: [OK 200] { public }
    server -->> client: [OK 200] { public }
    Note over client: decrypts<br>encrypted_secret<br>using public
    Note over client: encrypts the post<br>using secret
    client ->> server: POST /post { encrypted_post }
    server ->> rdb: INSERT encrypted_post
    rdb -->> server: [OK 200]
    server -->> client: [OK 200]

1. After a user creates a new plaintext post, the client requests the public key to the server.
2. The client decrypts the encrypted secret key in the local storage using the public key from the server.
3. The plaintext post is encrypted by the secret key decrypted by the public key.
4. The encrypted post is sent to the server, and the server stores it.

• At this point, the server can only know encrypted post.
• If the client reads a post, the flow is the same until the client requests to create a post to the server.

License

This project is distributed under the AGPL-3.0 License - see the LICENSE file for details.