Reword parts about omemo lib/MIT, and device keys
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
This commit is contained in:
parent
8d75a9962e
commit
7b333d7df5
1 changed files with 5 additions and 7 deletions
|
@ -50,18 +50,16 @@ The [python-omemo] library that is used -- developed by Syndace -- is a complete
|
|||
reimplementation of the Signal Protocol unlike [python-axolotl], which is a
|
||||
port of the original library implemented in Signal.
|
||||
|
||||
The only bits that prevent him for releasing his library under MIT is the
|
||||
wireformat, that has to be the same as the original implementation as
|
||||
specified in [XEP-0384][OMEMO]. Providing that we define another wireformat
|
||||
for all OMEMO implementations to use, this restriction will go away (still
|
||||
easier said than done.)
|
||||
There are bits that prevent him from releasing his library under MIT at the
|
||||
moment, I am not entirely sure to grasp all the details but this is being
|
||||
worked on.
|
||||
|
||||
[python-axolotl]: https://pypi.org/project/python-axolotl/
|
||||
|
||||
|
||||
## Why OMEMO?
|
||||
|
||||
There is still lots of things to be improved in the OMEMO specification.
|
||||
There are still lots of things to be improved in the OMEMO specification.
|
||||
|
||||
I would personally like to see what is usually called _Full Stanza Encryption_
|
||||
added to the spec. Today, an OMEMO implementation will only encrypt the
|
||||
|
@ -71,7 +69,7 @@ disable them, for privacy-conscious implementations.
|
|||
|
||||
I would also like to drop _Forward Secrecy_, in the context of Instant
|
||||
Messaging. And I would like to have a better way to manage all these device
|
||||
keys, and I know there are people working on this already.
|
||||
keys, fortunately there are people working on this already.
|
||||
|
||||
Not having all these options (or having them, in the case of _Forward
|
||||
Secrecy_) heavily degrades user experience in my opinion, and that is my main
|
||||
|
|
Loading…
Reference in a new issue