change titles for minimal intrusive design

README.md

@@ -33,7 +33,7 @@ As of Jan 2022, the plugin is considered in BETA stage. **DO NOT USE IT for any
 
 ## Limitations
 
-- **"deletion" operation can only be triggered from local device.** It's because of the "[minimal intrusive design](./docs/minimal_intrusive_design.md)". May be changed in the future.
+- **To support deltions sync, extra metadata will also be uploaded.** See [Minimal Intrusive](./docs/minimal_intrusive_design.md).
 - **No Conflict resolution. No content-diff-and-patch algorithm.** All files and folders are compared using their local and remote "last modified time" and those with later "last modified time" wins.
 - **Cloud services cost you money.** Always be aware of the costs and pricing.
 - **All files or folder starting with `.` (dot) or `_` (underscore) are treated as hidden files, and would NOT be synced.** It's useful if you have some files just staying locally. But this strategy also means that themes / other plugins / settings of this plugin would neither be synced.

docs/minimal_intrusive_design.md

@@ -1,36 +1,21 @@
 # Minimal Intrusive Design
 
-The plugin tries to avoid saving additional meta data remotely.
+Before version 0.3.0, the plugin did not upload additional meta data to the remote.
+
+From and after version 0.3.0, the plugin just upload minimal extra necessary meta data to the remote.
 
 ## Benefits
 
-Then the plugin doesn't make any assumptions about information on the remote endpoint.
+Then the plugin doesn't make more-than-necessary assumptions about information on the remote endpoint.
 
 For example, it's possbile for a uses to manually upload a file to s3, and next time the plugin can download that file to the local device.
 
 And it's also possible to combine another "sync-to-s3" solution (like, another software) on desktops, and this plugin on mobile devices, together.
 
-## Flaws
+## Necessarity Of Uploading Extra Metadata
 
 The main issue comes from deletions (and renamings which is actually interpreted as "deletion-then-creation").
 
-Consider this:
+If we don't upload any extra info to the remote, there's usually no way for the second device to know what files / folders have been deleted on the first device.
 
-1. The user create and sync a file to the cloud on the 1st device.
-2. Then download this file to the 2nd device.
-3. And then delete this file on the 1st device.
-4. And sync on the 1st device. The file on the cloud is also deleted.
-5. And sync on the 2nd device. **The 2nd device would upload the file again to the cloud.**
-
-In step 4, the file is marked "deleted" on the 1st device, and the 1st device send the command "delete this file on the cloud" to the cloud sevice (e.g. s3). Then the file on the cloud is also deleted. So far so good.
-
-But, in step 5, because no meta data are saved on the cloud, the 2nd device doesn't know that the file are deleted. Instead, it thinks "the file was not synced to the cloud last time, so it's uploaded this time". So an unintentional upload occurs.
-
-Currently no way to fix this if no meta data are saved remotely. The only workarounds are:
-
-1. Delete the file on the 1st device, **before** syncing it to the cloud. Then the file never show up on the cloud or on the 2nd device.
-2. Or, manually delete the file on 2nd device **before** step 5 in above situation.
-
-## Future
-
-This design may be changed in the feature, considering the flaws described above.
+To overcome this issue, from and after version 0.3.0, the plugin uploads extra metadata files `_remotely-save-metadata-on-remote.{json,bin}` to users' configured cloud services. Those files contain some info about what has been deleted on the first device, so that the second device can read the list to apply the deletions to itself. Some other necessary meta info would also be written into the extra files.