Sameh Abouelsaad 9dce815daa feat: Add basic project structure and initial crates

- Added basic project structure with workspace and crates:
  `kvstore`, `vault`, `evm_client`, `cli_app`, `web_app`.
- Created initial `Cargo.toml` files for each crate.
- Added placeholder implementations for key components.
- Included initial documentation files (`README.md`, architecture
  docs, repo structure).
- Included initial implementaion for kvstore crate(async API, backend abstraction, separation of concerns, WASM/native support, testability)
- Included native and browser tests for the kvstore crate

2025-05-13 20:24:29 +03:00

2.9 KiB

Raw Blame History

What’s Improved in the New Implementation

and why Encryption and Password Protection should be implemented in the Vault crate

1. Introduction

This document compares the old and new designs of the key-value store (kvstore) module, highlights improvements in the new implementation, and explains the architectural decision to move encryption and password protection to the vault crate.

2. Improvements in the New Implementation

a. Async/Await API

All operations are asynchronous, enabling non-blocking I/O.
Essential for WASM/browser and scalable server environments.

b. Backend Abstraction

The KVStore trait abstracts over multiple storage backends (native and WASM).
Enables cross-platform support and easier testing.

c. Separation of Concerns

The storage layer (kvstore) is now focused solely on key-value persistence.
No longer mixes storage with cryptography or user authentication.

d. WASM and Native Support

Out-of-the-box support for both browser (IndexedDB) and native (sled) environments.
Easy to extend with new backends in the future.

e. Cleaner, More Testable Design

Each layer is independently testable and mockable.
Simpler to reason about and maintain.

3. Why Encryption and Password Protection Belong in the Vault Crate

a. Single Responsibility Principle

kvstore should only handle storage, not cryptographic operations or user authentication.
vault is responsible for security: encryption, decryption, password management.

b. Flexibility and Extensibility

Different applications may require different encryption schemes or policies.
By implementing encryption in vault, you can easily swap algorithms, add multi-user support, or support new crypto features without touching the storage backend.

c. Security Best Practices

Keeping cryptography separate from storage reduces the attack surface and risk of subtle bugs.
All key material and secrets are encrypted before being handed to the storage layer.

d. Cross-Platform Consistency

The same vault logic can be used regardless of storage backend (sled, IndexedDB, etc).
Ensures consistent encryption and password handling on all platforms.

e. Easier Upgrades and Auditing

Security code is isolated in one place (vault), making it easier to audit and upgrade.

4. Summary Table

Layer	Responsibility	Encryption	Passwords	Storage Backend
kvstore	Persistence/Storage	❌	❌	sled, IndexedDB
vault	Security, Key Mgmt	✅	✅	Uses kvstore

5. Conclusion

The new design is more modular, secure, and maintainable.
Encryption and password logic in vault enables strong, flexible security while keeping storage simple and robust.

2.9 KiB Raw Blame History Unescape Escape