I just installed the latest v1.0.179 update on both my Windows and Linux machine,
I see in the update notes that the following is listed:
new, more secure encryption methods, so that they can be switched to at a later time is listed.
But if I go to my encryption settings I don't see an option to switch anything, does this mean this was just a backend feature that allows support for new encryption methods, but none have actually been implemented?
Thanks,
It looks like it's just a backend feature that hasn't been fully implemented and integrated yet. I don't think they're talking about having a user switch but instead referring to switching to a better, more secure encryption method in a future release to solve some issues some of the more tech savvy people here have brought up.
Honestly, I love the changelog Joplin is using, but for the sake of sanity and whatnot, it might be a great idea to separate User related changes from Backend changes. That way users don't get confused about what is what as much. 
Not sure how clearer someone can state that the switching is not yet implemented. Also, the switch might be internal and not touch the user at all.
User/Backend changes are usually always listed at the same time. Check any other changelog...
The problem was clarity to if it’s up to the user on which protocol they wanted to use VS it being chosen by someone the developer community. I assumed that meant it was up to the user to switch protocols when they so choose to, when in reality we were talking about it being a more “Under the Hood” thing that doesn’t affect the average user yet.
Ah, I see. As to what happens in the future I cannot say. @laurent can answer if the encryption method will be a user option. Either way, currently it’s just a backend change that will be used in the future.
Yes it's more a commit message and maybe shouldn't be in the changelog. The encryption methods have been added to all clients, and they'll be switched to default at a later time (in a few months), once most clients out there would have been updated.
I checked the existing encryption and it says AES. While AES is not the most secure method, it is at this time unbreakable and still used by the US Federal Government. Another advantage of AES is that most current processors have a routine built in that speeds the process considerably. The downside to AES is Russia and China have their best and brightest working round the clock to break it. They have discovered several weaknesses in the encryption, but none have lead to failure. If/when quantum computing comes to fruition, all encryption will be rendered useless.
I think it's great to have that in the changelog since it's valuable for those that are either looking to help implement it or looking to fix bugs caused because of the changes made in the future. A little bit more transparency about what it means for the common user like @Gamegenorator is all I'm really asking. It seems quite a few users here are more casual techies than people like @IrwinElectronics (which I love your posts so far, by the way; definitely my kind of nerdy tech talk).
@bedwardly-down Aww, thank you! What can I say, I’m a techie, blogger, technical writer, and an engineer. I’ve been working on computers since the '80s. I studied electrical engineering at RETS on the weekends when I was still in High School. When I worked at American Express, they paid for my training and certifications for A+, Novell CNA, MCSE, and Computer Forensics Specialist CFS. I also obtained an NTCIP cert. Most of these are meaningless today, but hey, I earned them.
Thanks for looking into it @IrwinElectronics. As I understand, the issue is that we're using OCB2, which apparently has a flaw (although it seems it can't be easily exploited), so I'm preparing the groundwork to migrate to CCM, which doesn't have any security flaw.
Hey, all encryption methods are not 100% fool proof and will always have at least 1 security flaw. 
It's just a matter of which ones are the ones that aren't worth it to crackers for what they would gain from breaking them.
I would’t describe myself as a casual user, just not a custom to the field of encryption, Electron, React, and backend syncing to a server.
I do though, think it is worth the idea of having ether, 2 changelogs, one being for more detailed information about what has been changed, and similar version that focuses on what will directly impact the user as of that update. Or at least attempting to make clearer in the current changelog what will directly impact the user and what won’t yet.
When I release an update to my own software, I put in the changes that directly impact the user into the release notes, but at the bottom I have a link to the “full” changelog that gives detailed information about every tiny bug fixed, every groundwork feature, and anything that doesn’t directly impact the user immediately.
Does this seem like a reasonable idea?
No offense meant. I wasn't referring to you specifically as a casual user; i was saying most common users could have the same issue you did and a large amount of users for note taking apps are very casual software users that may just use Joplin for notes without even messing with its more advanced features.
I honestly don't know a massive amount about encryption either other than basic security related parts of it.
This is very much what I'm getting at. It is very reasonable.
Alright, @laurent What are your thoughts on the matter? Does having two changelogs seem ok?
I certainly wouldn’t waste my time writing 2 changelogs. Also, they are auto-generated from commit messages. I seriously doubt that Laurent wants to manually create 2 changelogs.
If that ends up being the case, @Gamegenorator wanna collab on posting a user friendly format for people that don’t know what these fixes mean to help with confusion?
If their auto generated he'd only have to write 1, the other is just making remembering to add the prefix to the commit.
I wouldn’t mind the idea, finding time to go through each commit would be the biggest issue for me.
Because the changelogs are auto generated from commits, that should theoretically make it so much easier to find them. On github, there’s a way to view all commits. Then it’s a simple ctrl f on the browser.
gh also has an api. Check in the Tools directory the script git-changelog.js.