|
1 | 1 | # @evolu/common |
2 | 2 |
|
| 3 | +## 6.0.1-preview.16 |
| 4 | + |
| 5 | +### Patch Changes |
| 6 | + |
| 7 | +- af1e668: # Owners refactor and external AppOwner support |
| 8 | + |
| 9 | + ## 🚀 Features |
| 10 | + - **External AppOwner Support**: `AppOwner` can now be created from external keys without sharing the mnemonic with the Evolu app. The `mnemonic` property is now optional, allowing for better security when integrating with external authentication systems. |
| 11 | + - **New Config Option**: Added `initialAppOwner` configuration option to specify a pre-existing AppOwner when creating an Evolu instance, replacing the previous `mnemonic` option for better encapsulation. |
| 12 | + |
| 13 | + ## 🔄 Breaking Changes |
| 14 | + - **Owner API Redesign**: Complete refactor of the Owner system with cleaner, more focused interfaces: |
| 15 | + - Simplified `Owner` interface with only essential properties (`id`, `encryptionKey`, `writeKey`) |
| 16 | + - Removed temporal properties (`createdAt`, `timestamp`) from core Owner interface |
| 17 | + - Eliminated complex `OwnerRow` and `OwnerWithWriteAccess` types |
| 18 | + - **Database Schema Changes**: |
| 19 | + - Replaced `evolu_owner` table with streamlined `evolu_config` table |
| 20 | + - New `evolu_version` table for protocol versioning |
| 21 | + - Simplified storage of AppOwner data in single config row |
| 22 | + - **Configuration Changes**: |
| 23 | + - `Config.mnemonic` replaced with `Config.initialAppOwner` |
| 24 | + - More explicit control over owner initialization |
| 25 | + |
| 26 | + ## ✨ Improvements |
| 27 | + - **Enhanced Documentation**: Comprehensive JSDoc with clear explanations of owner types, use cases, and examples |
| 28 | + - **Clock Management**: New internal clock system for better timestamp handling |
| 29 | + - **Test Coverage**: Extensive test suite covering all owner types and edge cases |
| 30 | + |
| 31 | + ## 🔧 Internal Changes |
| 32 | + - **Database Initialization**: Refactored database setup to use new schema with better separation of concerns |
| 33 | + - **Protocol Updates**: Updated to protocol version 0 with new storage format |
| 34 | + |
3 | 35 | ## 6.0.1-preview.15 |
4 | 36 |
|
5 | 37 | ### Patch Changes |
|
13 | 45 | ### Patch Changes |
14 | 46 |
|
15 | 47 | - 0911302: Enhance message integrity by embedding timestamps in encrypted data |
16 | | - |
17 | 48 | - Add timestamp tamper-proofing to encrypted CRDT messages by embedding the timestamp within the encrypted payload |
18 | 49 | - Update `encodeAndEncryptDbChange` to accept `CrdtMessage` instead of `DbChange` and include timestamp in encrypted data |
19 | 50 | - Update `decryptAndDecodeDbChange` to verify embedded timestamp matches expected timestamp |
|
41 | 72 | ### Changes |
42 | 73 |
|
43 | 74 | **createdAt Behavior:** |
44 | | - |
45 | 75 | - `insert`: Always sets `createdAt` to current timestamp |
46 | 76 | - `upsert`: Sets `createdAt` to current timestamp if not provided, or uses custom value if specified |
47 | 77 | - `update`: Never sets `createdAt` (unchanged behavior) |
48 | 78 |
|
49 | 79 | **Documentation Improvements:** |
50 | | - |
51 | 80 | - Updated JSDoc for `DefaultColumns` with clear explanations of each column's behavior |
52 | 81 | - Clarified that `updatedAt` is always set by Evolu and derived from CrdtMessage timestamp |
53 | 82 | - Added guidance for using custom timestamp columns when deferring sync for privacy |
|
74 | 103 | ### Patch Changes |
75 | 104 |
|
76 | 105 | - 6279aea: Add external ID support with `createIdFromString` function |
77 | | - |
78 | 106 | - Add `createIdFromString` function that converts external string identifiers to valid Evolu IDs using SHA-256 |
79 | 107 | - Add optional branding support to both `createId` and `createIdFromString` functions |
80 | 108 | - Update FAQ documentation with external ID integration examples |
|
89 | 117 | - 45c8ca9: Add in-memory database support for testing and temporary data |
90 | 118 |
|
91 | 119 | This change introduces a new `inMemory` configuration option that allows creating SQLite databases in memory instead of persistent storage. In-memory databases exist only in RAM and are completely destroyed when the process ends, making them ideal for: |
92 | | - |
93 | 120 | - Testing scenarios where data persistence isn't needed |
94 | 121 | - Temporary data processing |
95 | 122 | - Forensically safe handling of sensitive data |
|
137 | 164 | - c86cb14: Add timing-safe comparison for WriteKey validation |
138 | 165 |
|
139 | 166 | ### Security Improvements |
140 | | - |
141 | 167 | - Add `TimingSafeEqual` type and `TimingSafeEqualDep` interface for platform-independent timing-safe comparison |
142 | 168 | - Implement Node.js timing-safe comparison using `crypto.timingSafeEqual()` |
143 | 169 | - Replace vulnerable `eqArrayNumber` WriteKey comparison with constant-time algorithm to prevent timing attacks |
|
329 | 355 | The great news is that Effect is stable now, so there will be no more releases with deps updates. Let's dance 🪩 |
330 | 356 |
|
331 | 357 | New features: |
332 | | - |
333 | 358 | - Multitenancy (we can run more Evolu instances side by side) |
334 | 359 | - Initial data (to define fixtures) |
335 | 360 | - Logging (you can see what's happening inside Evolu step by step) |
|
0 commit comments