I read through your updated proposal and have some more comments:
on subsequent saves of already-locked notes: no revision history deletion needed (body is already empty, revisions see nothing new)
For this point, can you make it clear that an actual code change is needed here to suppress creation of revisions for locally encrypted notes?
skip populating beforeChangeItemJson (set to null) when is_locally_encrypted is true, so plaintext doesn't leak through item_changes.before_change_item (Note.ts, L821-831)
Regarding item changes, I initially thought it was necessary to explicitly suppress the beforeChangeItemJson being set within Note.save, but actually I realise it is not necessary to do so, because the inner Note.load call to set the oldNote value would not use the option gate, so therefore it would always match old body to new body which will both be an empty string, providing that the body is tranferred to the local_cipher_text field first. However it is important that the added logic (including transferring the local_cipher_text value) when useLocalEncryption = true, is added before the changedFields array is set, otherwise the save model will not detect any change on the local_cipher_change field and wont save it in the db
if
is_locally_encryptedfield is present, use it directly
Note that it still needs to strip the prefix in this case
revision leak: mrjo118 identified that the plugin's approach triggers the revision system with plaintext. even using Laurent's suggested
joplin.views.editorsAPI to bypass revisions during editing, the initial encryption still creates a revision, anditem_changes.before_change_itemis completely outside plugin reach.
I think you can remove this ’revision leak’ point, as it is a adressable when we have a Joplin 3.6 stable release. Instead, replace it with a ‘no revision control’ point. While existing unencrypted revisions can be deleted upon encryption of a note, when using a plugin, it wont be possible to opt out of the revision service. In particular, changes to encrypted notes could create large diffs as revisions, due to the contents being a cipher instead of plain text.
Additionally a significant point you could add is ‘no sync control. Probably the biggest disadvantage of the plugin approach is being unable to bypass the sync when decrypting the contents for editing, unless you make your own editor plugin for this purpose. But if you write your own editor plugin, it is going to offer a significantly cut down experience, as you would need to replicate the markdown and or rich text editor to provide a full editing experience.
Also, please change the timeline to a 350 hour project, as 175 hours is just too short. The project plan is still for 12 weeks though.