 | nio | 37 Members |
| The nio matrix python library | Latest release 0.6 https://pypi.org/project/matrix-nio/ | Documentation: https://matrix-nio.readthedocs.io/en/stable/ | 19 Servers |
| nio | 37 Members |
| The nio matrix python library | Latest release 0.6 https://pypi.org/project/matrix-nio/ | Documentation: https://matrix-nio.readthedocs.io/en/stable/ | 19 Servers |
| Timestamp | Message | |
|---|---|---|
| 11 Sep 2019 | ||
| 17:08:35 |  poljar changed the room topic to "The nio matrix python library | Latest release 0.6 https://pypi.org/project/matrix-nio/ | Documentation: https://matrix-nio.readthedocs.io/en/stable/" from "The nio matrix python library | Latest release 0.4 https://pypi.org/project/matrix-nio/ | Documentation: https://matrix-nio.readthedocs.io/en/stable/". | |
| 17:30:28 |  miruka | so, about the new |
| 17:31:18 | miruka | let's say I use the new option and close the client today, then 100 new messages happen before I start it again |
| 17:31:29 | miruka | will the first sync give me these 100 messages? |
| 17:33:10 | poljar | no, it'll give you the most recent 10 one by default, if you set your event limit in a filter to 100 it'll give you the 100 |
| 17:34:58 | miruka | hm... what is the difference between using or not storing the tokens then? |
| 17:35:09 | miruka | storing or not* |
| 17:35:21 | poljar | but either way, more messages than your limit can happen while you are away, and fetching them using the room_messages() is the way to go |
| 17:35:59 | poljar | if no messages happen you won't get any of them, that is it remembers stuff that you already synced nad won't present it to you anymore |
| 17:36:40 | poljar | it's a bit important to not get for example twice the same Olm message, since you won't be able to decrypt it another time since the ratchet moved forward |
| 17:36:51 | poljar | and decryption errors mean that we mark the session as wedged |
| 17:37:33 | poljar | also, it's easier on the server if you remember the token |
| 17:37:36 | miruka | but the client has to store events/states by itself for that to be useful right? |
| 17:38:32 | poljar | well not necessarily, you can tell the server to give you the full state and you can fetch past N messages using room_messages if some rooms for example don't have any messages |
| 17:39:25 | poljar | but yeah, riot does store the room state and some amount of messages on disk to load it the next time you run |
| 17:40:15 | miruka | if you pass |
| 17:40:44 | poljar | yeah, one thing it wont give you that was surprising to me is the room summary |
| 17:40:52 | poljar | that's probably a bug |
| 17:42:01 | poljar | so if you're doing lazy loading for users, you'll need to make sure to fetch the members fully before sending messages in encrypted rooms |
| 17:42:40 | poljar | using the joined_members method |
| 17:42:58 | poljar | if nio gets a room summary, it's smart enough to do that on it's own, at least in the async client |
| 17:48:33 | miruka | something else that's been giving me troubles |
| 17:49:56 | miruka | so I usually have two instances of my client running, the normal one that always stays on so I can chat and the dev one that 's always restarted while I program |
| 17:51:11 | miruka | and frequently, the messages in an E2E room will become undecryptable in one of the client but not the other |
| 17:51:28 | miruka | (restarting the client fixes it) |
| 17:53:19 | poljar | i think that's the case where you get the decryption key after the message |
| 17:53:24 | poljar | this can happen |
| 17:55:19 | poljar | you'll have to listen for a RoomKeyEvent that has the same session id as the MegolmEvent |
| 17:55:47 | poljar | after you receive such a RoomKeyEvent you'll be able to decrypt the message using the decrypt_event() method |
| 12 Sep 2019 | ||
| 00:44:34 |  James Hogan left the room. | |