ruma / ruma Goto Github PK
View Code? Open in Web Editor NEWA set of Rust crates for interacting with the Matrix chat network.
Home Page: https://ruma.dev
License: MIT License
A set of Rust crates for interacting with the Matrix chat network.
Home Page: https://ruma.dev
License: MIT License
ruma::api::client::r0::push::get_pushrule::Response takes a ruma::api::client::r0::push::PushRule, which is not compatible with any of the pushrule types defined in ruma::events::push_rules. IMO there should be an enum over all pushrule types and get_pushrule::Response returns that enum.
This is not properly documented in the spec, but you can see /kick referring to a reason field here:
https://matrix.org/docs/spec/client_server/unstable#post-matrix-client-r0-rooms-roomid-kick
maybe we should ask in #matrix-spec first if this is correct
ruma_client_api::r0::membership::kick_user
ruma_events::room::member::MemberEventContent
The reason the user has been kicked. This will be supplied as the reason on the target's updated m.room.member event.
In ruma/ruma-api#34, I once again discovered that the macro code could use some refactoring. I will try to work on this soon-ish, although if somebody else wants to look into this, I'd happily mentor that person as well.
Moved over from https://github.com/ruma/ruma-api-macros/issues/5.
There are several places in the expanded code where unwrap/expect are used. These should be converted to normal Result-based error handling.
In 0.21, we had custom events for all of our "collection" enums. In the api22 branch, we don't currently have them. This should be fixed before releasing 0.22, but doesn't block merging api22 into master.
… one for the sending side, one for the receiving side.
This may help reduce the amount of copying around of bounds that people have to do when the Outgoing
trait is reintroduced (which it is almost certainly going to be to allow usage of borrowed identifiers).
https://github.com/ruma/ruma/blob/master/ruma-client-api/src/r0/sync/sync_events.rs#L260
Feel free to assign me to these I could just as easily open a PR but I want to make sure this is correct.
Key verification events as per matrix-org/matrix-spec-proposals#2241 will be sent out as normal room messages. This means they will contain a sender
, event_id
, origin_server_ts
etc.
Key verification events need to be updated to include those attributes.
The affected event types are:
Since one can initialize a tuple struct with TupleStruct { 0: expr, 1: expr }
, it should be possible to merge the initialization code of newtype body fields and regular body fields as well as query map fields and regular query fields. There may places other than initialization too where things can be simplified by operating over both named and unnamed fields.
Based on the changelog on matrix-doc
/rooms/{roomId}/aliases
for retrieving local aliases for a room. (#2562).m.rule.contains_user_name
default push rule to set the highlight tweak. (#2519)event_id
is returned when sending events. (#2525)/createRoom
. (#2571)My idea from ruma/ruma-events#82 for this:
enum RedactionEvent {
// assuming redaction events are valid in v1 rooms
V1(RedactionV1Event),
// assuming room version 7 includes the format change
V7(RedactionV7Event),
V1V7Compat(RedactionV1V7CompatEvent),
}
struct RedactionV1Event {
// message event fields
redacts: EventId,
content: RedactionV1,
}
type RedactionV7Event = MessageEvent<RedactionV7>;
struct RedactionV1 { ... }
struct RedactionV7 { ... }
Specifically for when we build a dummy http type to then change it later on.
Every room event might have been an encrypted event, e.g. a client will turn a m.room.encrypted
event into a m.room.message event
.
Clients need to present some info about this to users. For example an event wasn't encrypted but is posted in an encrypted room, clients might want to decorate such an event with a warning.
Clients will want to show:
I suggest we add an optional EncryptionInfo attribute to the events containing something like:
struct EncryptionInfo {
verified: bool,
sender_key: String,
device_id: String,
session_id: String
}
Most of those attributes will come from the encrypted version of the event, the m.room.encrypted
event. The lack of the EncryptionInfo
would indicate that the event was unencrypted.
Long-term, we need to make basically all structs #[non_exhaustive]
so we can extend them without breaking changes. We still need to have ways for users to create them though, apart from using Deserialize
. My current feeling on this is that we should have manual constructors that have parameters for the required fields, with the rest being set either using mutation or (preferably) using struct update syntax:
// Already possible today because we introduced this constructor at some point. We
// should probably rename that constructor to just `new`, and add similar ones to all
// structs that are made non-exhaustive.
let text_message = MessageEventContent::Text(TextMessageEventContent {
relates_to: Some(RelatesTo {
in_reply_to: InReplyTo { event_id: my_event_id }
},
..TextMessageEventContent::new_plain("this is the message body")
});
// For cases where some fields are mandatory and a constructor without named arguments
// would be unclear, add an exhaustive `Init` variant of the same struct with a
// `From<ThingInit> for Thing` implementation (if this comes up often enough, we can
// generate both of these things).
let third_party_protocol_instance = ProtocolInstance {
icon: Some("mxc://path/to/icon.png".into()),
..ProtocolInstance::from(ProtocolInstanceInit {
desc: "Freenode IRC network".into(),
fields: BTreeMap::new(),
network_id: "freenode".into(),
})
};
See 13.13.1.5.2 Predefined Rules in the spec. These should probably be exposed as const
ants from push_rules
.
I'm thinking we should have colons after each of the keywords, to make the content look a bit more ordinary, and to make error: ErrorType
look less out of place.
With this + ruma/ruma-identifiers#24 we'll also be able to update the server_name
variants to return references to this new type. There is probably no point in releasing the new type under a non-breaking version 0.16.1 because it will be a breaking change for the higher-level crates to switch to this new type anyway.
Matrix doesn't use floats anywhere, and removing support will let us get rid of the dtoa
dependency.
Currently ring
s Ed25519 doesn't work for the WebAssembly target (briansmith/ring#918), hence ruma-signature doesn't work on WASM either.
Currently it is just a string, but it is defined very clearly what it should look like
/// A decimal integer optionally prefixed by one of `==`, `<`, `>`, `>=` or `<=`.
///
/// A prefix of `<` matches rooms where the member count is strictly less than the given
/// number and so forth. If no prefix is present, this parameter defaults to `==`.
is: String,
We could represent this instead as a struct or enum and even easily provide a helper method for checking whether this condition applies to a given count of room members.
Sometimes it's useful being able to serialize things, e.g. to cache into persistent storage in a certain format like JSON, so it'd be helpful to have a feature that automatically derives API responses.
This needs an adjustment in the API macro around here and should be behind a feature flag:
It would be nice to have individual issues for new contributors to jump in on, as well as to keep track of what's left to do.
https://github.com/ruma/ruma/blob/master/ruma-client-api/src/r0/message.rs
Is this just from getting everything to work with the new ruma-events?
Currently, most endpoints in ruma-client-api share the same error type. Since every endpoint has a documented set of errors it can return, we could capture this information by generating an appropriate enum.
I think there's no big reason not to, but I'm not sure.
… and fix the existing message logging example.
My gut tells me that serde_json::Value
in #52 is going to be a performance bottleneck, in particular for large event payloads. I have an idea for a way to speed this up, but would like to measure how useful it actually is. @DevinR528 are you interested in adding a few deserialization benchmarks with differently-sized events and differently-ordered fields for that (in the same or a subsequent PR)?
Deserialization benchmarks for other parts of ruma would also be appreciated (enums with #[serde(flatten)]
and lots of variants or lots of data contained in one or more variants would probably benefit from some optimization in particular).
Since it is not really tied to events in any way.
Not sure if this is out of scope, but the UIAA login fallback endpoint and the generic login fallback endpoint are missing. These both return HTML pages that the user can use to complete login.
This is the motivation for https://github.com/ruma/ruma-events/issues/47 and blocked on that. It's labeled as hard, but once the ruma-events issue is resolved, it will be very easy. The concrete endpoints to update are:
send_message_event
send_state_event_for_key
send_state_event_for_empty_key
send_event_to_device
Especially in ruma_events::{collections::{all, only}, stripped}
, we are missing any tests at all. We only know from real-world usage that our code seems to do roughly the right thing. Deserialization of custom types as part of the collection types is a bit more complex than deserialization of known event types, so it's one of the more important test cases to add.
In addition, deserializing a known event type as Custom(Room|State)Event
might be something that we want to disallow (I'm not sure whether we currently allow it) and test.
It seems as though (basing this on the encryption stuff in matrix-rust-sdk) m.room.encrypted
should be part of AnyStateEventContent
?
Of course without allocating when going from owned to borrowed, and without additional checks no matter the conversion direction.
This will require custom parsing, because the event type isn't changed when an event is redacted. Redacted events can be detected by checking for a redacted_because
field.
… and possibly replace them with Box<serde_json::value::RawValue>
.
serde_json::Value
has mostly been replaced by Box<serde_json::value::RawValue>
, but it doesn't seem to be working in BTreeMap<String, Value>
. Needs further investigation.
It would be really useful to be able to compile ruma-client to WASM and run it inside a browser. I guess that would require feature'izing hyper and adding a fetch/xhr feature, maybe using reqwest.
Deserialization(RequestDeserializationError { inner: Json(Error("EOF while parsing a value", line: 1, column: 0)), http_request: Request { method: GET, uri: /_matrix/client/r0/rooms/!RhCpxacCaP5pvSQhwo%3Amatrixtesting.koesters.xyz/members?not_membership=leave&at=103
body: []
There are signatures that take UserId and DeviceKeyId and some that take ServerName and ServerKeyId Maybe we need to make the Signatures struct in ruma-signatures (forgot that existed) generic and provide Signatures<UserId, DeviceKeyId> and Signatures<ServerName, ServerKeyId>.
We should also update all the fields that hold signatures to use this type rather than a BTreeMap.
Dependent on matrix-org/matrix-spec-proposals#27.
Opening this issue so I don't forget about doing this.
… which should be optional. I'm not sure whether we support optional header parameters right now.
The search is performed case-insensitively on user IDs and display names preferably using a collation determined based upon the
Accept-Language
header provided in the request, if present.
https://matrix.org/docs/spec/client_server/r0.6.0#post-matrix-client-r0-user-directory-search
EDIT: This is no longer possible with the Ref
types no longer existing in ruma-identifiers. The below might become possible again with custom DST based identifiers, but those are far away. See the comment below for why this issue is still useful. The idea in the description might still be implemented, but as _ref
macros that would mostly be useful for tests (though is it worth it to write the extra code for that?).
It's already possible to obtain SomeIdRef<&'static str>
s from string literals. However, that involves verifying the string literal at runtime. If we can create const fn
constructors for the ID types (which I think should not be an issue, we just have to move the logic into a dedicated, non-type-generic method rather than a TryFrom
impl), we can create macros that do the construction of SomeIdRef<&'static str>
at compile time, something along the lines of:
macro_rules! user_id {
($s:literal) => {
{
const RES: $crate::UserIdRef<'static> = $crate::UserIdRef::from_str($s).unwrap();
RES
}
}
}
although for the unwrap()
to work, some additional compiler work is yet to be done, plus these macros would have to be Nightly-only for some time.
There's now a crate intended to share a "body" type between HTTP client implementations, which we can use to prevent ruma-api from being bound to Hyper. I didn't check if Hyper actually supports it yet, but if/when it does, we should switch over.
Here's the crate: https://crates.io/crates/http_service
And here's more background on why we wanted this: rustasync/team#84
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.