In preparation for threads we have realised that the `reactions`,
`thread_root` and `in_reply_to` were only available on `Message` types,
which doesn't play well with Stickers and Polls.
This PR introduces a new `Aggregated` `TimelineItemContent` variant
which holds the message `kind` (Message, Sticker, Poll) as well as well
as any related aggregated data. it will help treat them all in a similar
fashion as well as account for future changes.
There are no functional changes, it's mostly about moving code around
and the FFI interfaces haven't changed.
Part of #4833.
It allows to reuse the URL for different actions more easily than having
to call `OAuth::account_management_url` every time for a different
action.
It also adds a method with fallback if we want to ignore action
serialization errors, to always present a URL.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
`send_reply` is geared towards clients that don't render threads themselves. It sends a reply and optionally forwards it onto any existing thread.
This PR adds `send_thread_reply` for clients that do render threads themselves. This sends a message onto a thread, regardless of whether a thread existed before, and includes the fallback for non-threaded clients only if the message is not itself a reply on the thread.
Signed-off-by: Johannes Marbach <n0-0ne+github@mailbox.org>
Accept a URL or a query string for simplicity.
That way we don't need to expose AuthorizationResponse.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
Since they perform blocking I/O we probably don't want to block a thread on that.
We use spawn_blocking, the alternative would be to use tokio::fs functions, which do the same thing and would require to load the whole file content in memory before (de)serialization.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
Use the same prefix as the other types in the OAuth 2.0 API, and use the
same suffix as other data-persisting APIs for consistency.
It also avoids to have two modules with very similar names, the only
difference being a trailing `s`.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
That way users only need to call finish_login, since there is no other
reason to call finish_authorization currently.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
Fixes: #4793
There was a previous PR https://github.com/matrix-org/matrix-rust-sdk/pull/4802 which attempted to implement this, but missed some backwards compatibility needs.
This updated PR has the original commit and then additional commits to add the compatibility (along with tests for the new intent param generally).
These prompts were used in the Element X app, probably in some other clients too.
Since Ruma removed these cases, we're just passing them as `_Custom(value)` ones, which do work.
And make it take a boolean indicating whether we want to set up a
lightweight tokio runtime or not, instead of having
`setup_lightweight_tokio_runtime` as a public function + another
function, both of which would have to be called anyways.
cc @stefanceriu @jmartinesp
