Set the limit on the returned events in the timeline in the get and sync
operations. The default value is -1, means no upper limit.
For example, using `filter_timeline_limit: 5000`:
POST /_matrix/client/r0/user/user:id/filter
{
room: {
timeline: {
limit: 1000000000000000000
}
}
}
GET /_matrix/client/r0/user/user:id/filter/filter:id
{
room: {
timeline: {
limit: 5000
}
}
}
The server cuts down the room.timeline.limit.
This tracks data about the entity which made the request. This is
instead of passing around a tuple, which requires call-site
modifications every time a new piece of optional context is passed
around.
I tried to introduce a User object. I gave up.
This follows the same flows-based flow as regular registration, but as
the only implemented flow has no requirements, it auto-succeeds. In the
future, other flows (e.g. captcha) may be required, so clients should
treat this like the regular registration flow choices.
Removes device_id and ClientInfo
device_id is never actually written, and the matrix.org DB has no
non-null entries for it. Right now, it's just cluttering up code.
This doesn't remove the columns from the database, because that's
fiddly.
