The API here might have changed? It seems this call was going just fine
until it wasn't. It was returning an empty string. Adding `local=False`
seems to force it to fetch the info remotely and return a proper Iq.
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
And the docstring now reflects the reality again!
We're parsing the Encrypted dict again, when we just did it in
decrypt_message above, but this function is also part of the API and
doing that for them is the least we can do.
Maybe there should be an internal function that we can call from
decrypt_message, that also gets called by should_heartbeat.
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
It appears a receiving chain length set to None just means we haven't
received any message for this session yet. It doesn't make sense to spam
heartbeats at this stage
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
receiving_chain_length would sometimes be None (thanks python strict
typing) causing the thing to fail.
When this is the case, I assume this means the session hasn't been
confirmed from our side yet and it would be good to ACK it. (To be
confirmed with people who know, in progress).
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
The condition wasn't necessary in session_start for PEP nodes not to be
published multiple times.
This also fixes the fact that we weren't publishing on reconnect.
And also fixes one indentation level too many in the _initial_publish
method.
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
This would likely do that we had a fixed set of prekeys because we
wouldn't republish after one was used.
This shouldn't have any security implications. Just so that we wouldn't
have been able to initiate new sessions after all published prekeys were
used up, as we don't have the private keys anymore. They are deleted
when used (as should be) by the backend OMEMO library.
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
With this commit, slixmpp-omemo now reads the ratchet chain length,
(both receiving and sending), that we should track to know when to send
a heartbeat message.
This allows us to signal other devices that we are still active and
listening. Some clients will stop encrypting to us if we haven't replied
for a certain number of messages.
The current 0384 spec (0.7) says we should send a heartbeat message at
least once this number goes over 53 (fair dice roll). It doesn't say
when a client may/should stop encrypting to us, or what it should do at
all once we go over 53.
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
This allows the user to be able to do what they want with the string.
They can then insert colons, or split up in groups of chars or..
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
