mirror of
https://github.com/vrtmrz/obsidian-livesync.git
synced 2025-12-13 17:55:56 +00:00
bump
This commit is contained in:
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"id": "obsidian-livesync",
|
||||
"name": "Self-hosted LiveSync",
|
||||
"version": "0.25.8",
|
||||
"version": "0.25.9",
|
||||
"minAppVersion": "0.9.12",
|
||||
"description": "Community implementation of self-hosted livesync. Reflect your vault changes to some other devices immediately. Please make sure to disable other synchronize solutions to avoid content corruption or duplication.",
|
||||
"author": "vorotamoroz",
|
||||
|
||||
4
package-lock.json
generated
4
package-lock.json
generated
@@ -1,12 +1,12 @@
|
||||
{
|
||||
"name": "obsidian-livesync",
|
||||
"version": "0.25.8",
|
||||
"version": "0.25.9",
|
||||
"lockfileVersion": 2,
|
||||
"requires": true,
|
||||
"packages": {
|
||||
"": {
|
||||
"name": "obsidian-livesync",
|
||||
"version": "0.25.8",
|
||||
"version": "0.25.9",
|
||||
"license": "MIT",
|
||||
"dependencies": {
|
||||
"@aws-sdk/client-s3": "^3.808.0",
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "obsidian-livesync",
|
||||
"version": "0.25.8",
|
||||
"version": "0.25.9",
|
||||
"description": "Reflect your vault changes to some other devices immediately. Please make sure to disable other synchronize solutions to avoid content corruption or duplication.",
|
||||
"main": "main.js",
|
||||
"type": "module",
|
||||
|
||||
32
updates.md
32
updates.md
@@ -1,3 +1,14 @@
|
||||
## 0.25.9
|
||||
|
||||
20th August, 2025
|
||||
|
||||
### Fixed
|
||||
|
||||
- CORS Checking messages now use replacements.
|
||||
- Configuring CORS setting via the UI now respects the existing rules.
|
||||
- Now startup-checking works correctly again, performs migration check serially and then it will also fix starting LiveSync or start-up sync. (#696)
|
||||
- Statusline in editor now supported 'Bases'.
|
||||
|
||||
## 0.25.8
|
||||
|
||||
18th August, 2025
|
||||
@@ -5,7 +16,7 @@
|
||||
### New feature
|
||||
|
||||
- Insecure chunk detection has been implemented.
|
||||
- A notification dialogue will be shown if any insecure chunks are detected; these may have been created by v0.25.6 due to its issue. If this dialogue appears, please ensure you rebuild the database after backing it up.
|
||||
- A notification dialogue will be shown if any insecure chunks are detected; these may have been created by v0.25.6 due to its issue. If this dialogue appears, please ensure you rebuild the database after backing it up.
|
||||
|
||||
### Fixed
|
||||
|
||||
@@ -107,25 +118,6 @@ In next version, insecure chunk detection will be implemented.
|
||||
|
||||
Side note: Although class-oriented programming is sometimes considered an outdated style, However, I have come to re-evaluate it as valuable from the perspectives of maintainability and readability.
|
||||
|
||||
## 0.25.4
|
||||
|
||||
29th July, 2025
|
||||
|
||||
### Fixed
|
||||
|
||||
- The PBKDF2Salt is no longer corrupted when attempting replication while the device is offline. (#686)
|
||||
- If this issue has already occurred, please use `Maintenance` -> `Rebuilding Operations (Remote Only)` -> `Overwrite Remote` and `Send` to resolve it.
|
||||
- Please perform this operation on the device that is most reliable.
|
||||
- I am so sorry for the inconvenience; there are no patching workarounds. The rebuilding operation is the only solution.
|
||||
- This issue only affects the encryption of the remote database and does not impact the local databases on any devices.
|
||||
- (Preventing synchronisation is by design and expected behaviour, even if it is sometimes inconvenient. This is also why we should avoid using workarounds; it is, admittedly, an excuse).
|
||||
- In any case, we can unlock the remote from the warning dialogue on receiving devices. We are performing replication, instead of simple synchronisation at the expense of a little complexity (I would love to express thank you again for your every effort to manage and maintain the settings! Your all understanding saves our notes).
|
||||
- This process may require considerable time and bandwidth (as usual), so please wait patiently and ensure a stable network connection.
|
||||
|
||||
### Side note
|
||||
|
||||
The PBKDF2Salt will be referred to as the `Security Seed`, and it is used to derive the encryption key for replication. Therefore, it should be stored on the server prior to synchronisation. We apologise for the lack of explanation in previous updates!
|
||||
|
||||
## 0.25.0
|
||||
|
||||
19th July, 2025 (beta1 in 0.25.0-beta1, 13th July, 2025)
|
||||
|
||||
@@ -11,6 +11,25 @@ As a result, this is the first time in a while that forward compatibility has be
|
||||
|
||||
---
|
||||
|
||||
## 0.25.4
|
||||
|
||||
29th July, 2025
|
||||
|
||||
### Fixed
|
||||
|
||||
- The PBKDF2Salt is no longer corrupted when attempting replication while the device is offline. (#686)
|
||||
- If this issue has already occurred, please use `Maintenance` -> `Rebuilding Operations (Remote Only)` -> `Overwrite Remote` and `Send` to resolve it.
|
||||
- Please perform this operation on the device that is most reliable.
|
||||
- I am so sorry for the inconvenience; there are no patching workarounds. The rebuilding operation is the only solution.
|
||||
- This issue only affects the encryption of the remote database and does not impact the local databases on any devices.
|
||||
- (Preventing synchronisation is by design and expected behaviour, even if it is sometimes inconvenient. This is also why we should avoid using workarounds; it is, admittedly, an excuse).
|
||||
- In any case, we can unlock the remote from the warning dialogue on receiving devices. We are performing replication, instead of simple synchronisation at the expense of a little complexity (I would love to express thank you again for your every effort to manage and maintain the settings! Your all understanding saves our notes).
|
||||
- This process may require considerable time and bandwidth (as usual), so please wait patiently and ensure a stable network connection.
|
||||
|
||||
### Side note
|
||||
|
||||
The PBKDF2Salt will be referred to as the `Security Seed`, and it is used to derive the encryption key for replication. Therefore, it should be stored on the server prior to synchronisation. We apologise for the lack of explanation in previous updates!
|
||||
|
||||
## 0.25.3
|
||||
|
||||
22nd July, 2025
|
||||
|
||||
Reference in New Issue
Block a user