A clean library for the Matrix open standard. Sending and receiving messages seems to work, and basically the entirety of the /sync event is handled, but everything else is uimplemented.
#[tokio::main]
async fn main() -> Result<()> {
let mut client = morpheus::Client::new("your_token");
client.on_message(|msg| async move Box::pin({
if msg.content == "I love facebook" {
msg.reply("Begone, Thot").await;
}
}));
client.run().await
}- Flexible way to handle parameters (or absense thereof) in rest client
- Clean way of handling all endpoints without repetition (macros?)
staticlifetime of tokens and other goods for easier thread management- Add caching of rooms and members to client
- Fix
displaynamevsdisplay_name - Make most booleans required (
falseis usually correct when field is absent) - Make more things required (servers will commonly serve empty things as
[]/{}anyway). Another example,m.typing::user_idssets the array to required, even if there may be no elements, but this is not done most of the time. - Make
room_versionrequired - Question: why is the
state_keyone level back in room events? - From
jointojoin== changing display name? Is there a more understanble way to present an event that changes someone's display name without some join-but-not-really-a-join solution. - Is
urlinm.image/m.filereally required? Some image events from matrix.org don't have that field. - Use
height/widthrather thanh/w - Encryption could encrypt more metadata?
- Consolidate all thumbnail info into seperate
Thumbnailtype, instead of repeating thethumbnail_prefix for several fields. - Consistently either "redefine" or "don't redefine". The
ThumbnailInfois defined in many different message types, butEncryptedFileisn't. - Normal names (rather than super short 2-3 character params) for EncryptedFile/JWK
- Some time fields have
_mssuffix likerotation_period_ms, but most don't. Inconsistent. - Are two different encryption algorithms needed? Complicates encrypted messages
- Differentiate between signed/unsigned and 32/64 bits for integers
- Explicitly mark
m.room.message.feedbackas deprecated - Specify all the enum variants for
RoomVersionsCapability::available - Why
m.room_key_requestinstead ofm.room.key_request? inconsistent with most events - Type names should either be PascalCase or have spaces between each word, not a mix of both
- Make all type names 100% unambiguous: There is Event, EventContent (which isn't actually the content of the previous Event), unnamed-event-content (this time for the actual Event type), State, StateEvent (which IS the event for the State), RoomEvent, RoomEventContent, ToDevice, Event (for ToDevice only), etc. These names are inconsistent. Some of them have a
Contentsuffix, others do not. - Redaction shouldn't be determined based off the absense/presence of a field, there should just be a boolean called
redacted, or maybe some enum of the state of a given message. Determing state based off absense of JSON fields makes client implementations really clunky. - The specification shouldn't mark things as
Requiredwhen they are supposedly optional. If they are required ONLY for sending, then it should be specified as such. - Question: the
ToDeviceevent will specify thetype, but unlike most other events, theEventContentdoesn't depend on any type. Does ToDevice need to specify the type? Or should the content be in a different format that varies based off the type? - Specification of the fields on
m.directis incomplete/absent - Undocumented
m.push_rules::device? - Why two possible types per field?
PushRule::actionsis weird to implement and seems to be lacking in documentation. - Inconsistent specification of
m.receipt. Normally, any maps of ids to objects are specified as{string: object}, but form.receipt, we oddly specify the name of the key as the type of key (which is not the name). Unclear and inconsistent with all other map fields. m.receiptoverall has a very strange and non-obvious layout, and all the fields are optional for no apparent reason.- Inconsistent naming:
tsvstimestamp m.room.avatarevent but alsoavatar_url? why not just one of the twom.room.third_party_invite::PublicKeysshould be renamed toPublicKey. It only has one key.- Deprecate
m.room.third_party_invite::public_key. Also, why Required. if it only exists for backwards compat? - Question: why is so much metadata preserved after redaction? Why isn't it just marked as some generic "redacted" event?
- The
UnsignedDatainsideState Eventcan contain theprev_contentfield. However, it is not documented as such. Only the/_matrix/client/r0/pushers/setendpoint documentsUnsignedDatato contain aprev_contentfield. EventContenthas anunsignedfield, andUnsignedDatahas aprev_contentfield. These two types are infinitely recursive. Difficult to implement in a strongly typed language.- The spec states that
Timelinehas an array ofRoomEvent's, however, many of these events contain thestate_keyfield, which are only present inState Event's. Either the spec is wrong or synapse. m.reactionis a room event but doesn't have them.roomsuffix?- Many undocumented
m.reserved fields
Morpheus is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License, version 3, as published by the Free Software Foundation.
Network use is distribution. If you use this code in an application which runs on a network, you must release the source code of said application under the same license.