| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Parse the top level of m.room.encrypted messages.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
|
|
| |
Route the count of remaining one time keys out of the sync result.
We need the newer (v2?) API for this.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
|
|
|
|
| |
Parse the device-2-device messages in a sync.
We have to get the order right since we need the rooms created before
parsing the d2d messages, but we may need to have processed the d2d
messages to decrypt events in the room.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
|
| |
|
|
|
| |
* Comment about using state table for ephermal events
* Move JSON handling into matrix-api
|
| |
|
|
| |
using the "Group Typing Notifications" plugin
|
| |
|
|
|
| |
https://github.com/matrix-org/matrix-doc/pull/165 changes the format of the
/sync response. Update our code to accept it.
|
| |
|
|
| |
Post-SPEC-254, we now need to handle state events which arrive in the timeline.
|
| |
|
|
|
|
|
|
|
|
| |
We needed better tracking of what we had told purple was each member's
displayname. It was terribly confusing having matrix-roommembers try to track
it implicitly, which was causing bugs where we were getting out of sync.
Instead, let matrix-roommembers hold opaque data for each member, which
matrix-room then uses to keep track of the purple displayname. Then move a
bunch of the member-update-handling stuff back into matrix-room.
|
| |
|
|
|
| |
Propagate received invites to the UI, and correctly handle accepting/refusing
them.
|
| |
|
|
|
|
|
| |
If the connection dropped in the middle of us receiving a sync response, we
tried to set the next_batch setting on the account to an invalid string
(because we failed to initialise the pointer). Fix the segfault that caused,
and clean up some of the other error handling in the area at the same time.
|
| |
|
|
|
|
|
|
|
| |
Trying to keep the size of matrix-room.c under control, move the membertable
management bits out to a separate file.
Also do away with the special handling for the first /sync of a room, and
instead *always* group together member arrivals/departures until after we've
finished handling the state table.
|
| |
|
|
| |
The 'persistent' behaviour matches the matrix model much better.
|
| |
|
|
|
|
|
|
| |
An initial implementation for displaying the people in a room. This isn't very
nice, and the code is somewhat thrown together as a prototype/proof-of-concept
for now. We probably want to refactor matrix-room.c, which is now altogether
too unwieldy. It probably also makes sense to try to do some of this stuff on
the server.
|
| |
|
|
| |
Give rooms a name according to who's in it, if there is no proper name.
|
| |
|
|
|
|
|
| |
Move all matrix-login and bits of matrix-sync into matrix-connection, where
it seems to make more sense.
Also move MatrixConnectionData into matrix-connection.h
|
| |
|
|
|
| |
This structure comes and goes with each connection, so rename it to better
reflect its lifecycle.
|
| |
|
|
|
| |
Persist the next_batch, so that we don't get old scrollback each time we open
the application.
|
| | |
|
| |
|
|
| |
Do local echo of sent messages, and ignore the remote echo.
|
| |
|
|
| |
Use an external http parser, instead of inventing that wheel ourselves.
|
| |
|
|
|
| |
Factor out the handling of errors from API calls, to make it easier to add new
ones.
|
|
|
Move things around quite a lot, to make it a bit saner
|
