also:
Dear @tessus, I did read the template, and went to check out the discourse, which yielded nothing related to this. Since I intended to contribute, if none could help out, (by reading the code) and planned to create a PR for this issue to improve the documentation, I thought it was wise to use the GitHub Issue system as intended: to discuss issues. Unclear documentation is an Issue in my book but I do come from a security background.
Is a feature enhancement request a support question in your book?
Or should I have reported it as a bug instead?
Or should I have contacted support to report it as a security issue?
I sense a bit of build-up annoyance around all this. Maybe because people are used to using the issue system as intended. Old habits die hard and imho a feature enhancement request is not an urgent support question to be asked on discourse.
As @laurent22 said:
Doc is important and we're keen to improve it, however I'd argue that what you're asking is not as straightforward. We shouldn't list SQL queries in the doc - once it's in the doc we have to support it properly. That means for example we can't change the database structure without breaking people's scripts. So certain things, like this, are undocumented for a good reason.
Is that subject to a lot of (planned) change then, where/how the masterkey is stored?
I'm just advocating for a clear spec, that way security researchers can more easily verify the security properties. 'Gutting" Joplin to it's bare but compatible minimum would also be easier which could be desired (although by a small amount of people). Same thing for joplin compatible forks.
Furthermore, documenting this kind of information increases the trust. Being open-source is awesome, being open source with very good docs is utterly brilliant. The time constraints you mentioned in the GitHub issue are just as valid for most other people inspecting/thinkering with Joplin. Good docs also reduce the amount of stuff to explain to junior devs. Consider me a candidate to help improve these.
The thing is with E2EE enables every other thing you want to do with your files hinges on that master-key: backups, scripting, ... So imho it's a prime candidate for a stable API and corresponding docs. But I'd love to hear your opinion.
Anyway keep up the good work and happy Hacktober! 
There’s a spec for E2EE at https://joplinapp.org/spec The keys themselves are stored in the database in the master_keys table.
Yup, I’ve seen the spec.
Well, and the keys are also stored together with the encrypted files right?
I’m reworking the Master Key section of the spec.md file on my fork (but can’t post the link here), if you agree with a PR I’ll surely make one. Feedback welcome ofcourse.
Yes they are also with the synced files. Sure, if you could create a PR for it that would be great.