Things blocking or slowing progress of Ruma

[jimmycuadra]

I'm creating this issue as a place to keep track of the things in the Rust and Matrix ecosystems that are completely blocking or slowing the progress of Ruma (the homeserver as well as supporting libraries.) We can use it to track the status of these blockers and as a place to link people wondering about the status of the project.

Rust (blocking implementation)

• Release of http: blocks the use of these shared HTTP types being used in ruma-api, the integration of these types in hyper, and the integration of these types in downstream web frameworks we'd consider using, such as Gotham, Rocket, a renewed version of Iron, or something we build ourselves on Hyper
• Adoption of the http crate in hyper (tracking issue): blocks adoption of an http-crate-based hyper in web frameworks we might want to use
• Adoption of the http crate in an async web framework: blocks our ability to use an http-crate-based ruma-api with said web framework
• Stabilization of async/await (RFC 2033, tracking issue): blocks ergonomic use of async code
• Choosing a web framework once they all support async/await

Rust (blocking stabilization/release)

• Stablization of impl Trait (RFC 1522, RFC 1951, and RFC 2071, tracking issue): blocks ergonomic, performant use of async code. Note: Part of impl Trait has been stabilized, but it's not yet usable in traits.
• Stabilization of the TryFrom and TryInto traits (RFC 1542, tracking issue): blocking stable use of fallible type conversions; used in several places in Ruma
• Stabilization of procedural macros (RFC 1566,
  tracking issue): blocking stabilization of ruma-api-macros, and in turn ruma-client-api, plus planned ruma-api crates like ruma-federation-api

Matrix (blocking implementation)

• Client-server API specification r0.3.0 (or whatever the release after r0.2.0 ends up being): blocks some aspects of progress on the client-server API, notably end-to-end encryption support
• A stable release of the server-server API specification: blocks ruma-federation-server
• A stable release of the application service API specification: blocks future application services in Rust using Ruma libraries
• A stable release of the identity service API specification: blocks a future identity service in Rust using Ruma libraries
• A stable release of the push gateway API specification: blocks a future push gateway in Rust using Ruma libraries

Matrix (blocking stabilization/release)

This is just a list of issues we've opened against the Matrix spec in the process of building Ruma. It includes places where things are wrong/misleading/undocumented. At least some of these are likely to be resolved in new versions of the specs listed above.

• the GET form of /login has gone missing from swagger and spec
• /search spec says the only possible JSON body parameter is search_categories, but the example also has order_by and groupings
• Document all event keys shown in examples
• Spec is unclear about what is stored in the content repository
• Spec does not explain the values of string keys in the /search's response
• Handling the reason field in kick and ban endpoints
• Explain the bind_email parameter to the registration endpoint better
• Enumerate all events created when a room is created
• Document event size errors
• Provide a full reference of all the different error codes
• Grammar for completely opaque APIs
• Grammar for room IDs and event IDs
• Document grammar for device IDs
• Document semantics/guarantees around transaction IDs
• Explain the rationale for /account/password authentication
• search API lies and claims that it takes a v2 filter
• Specify format of origin_server_ts Superceded by: Timestamp time zone?
• Presence list API response does not match m.presence schema
• StrippedState schema is inconsistent

[farodin91]

This month, i have some task to do for the current term. Next i will try to implement, something like the dendrite room server style.

[vbrandl]

I'm not sure if you are still actively working on ruma, but some of your issues seem to be resolved by now:

• impl Trait has been stabelized in Rust 1.26.0
• there is an async web framework, that uses the http crate: https://github.com/actix/actix-web
  I haven't used it myself but it looks promising

[lnicola]

There's also https://gotham.rs/, based on hyper. And hyper 0.12 will come out in a couple of days with full support for the http types.

[jimmycuadra]

Yes, the project is still active and we're still following developments of the things in the issue description. We're not likely to change the HTTP framework we use for a while longer, but keeping an eye on what's out there.

[lnicola]

I'm not sure about the future of iron, though.

[Serkan-devel]

Why not rocket.rs?

[jimmycuadra]

We may end up switching to any of the existing frameworks, or perhaps one that doesn't even exist yet. Things are still moving fast and it's too soon to tell.

[bachp]

I think actix-web makes use of the http crate. It is also working on stable rust.

[Half-Shot]

@jimmycuadra Are some of the matrix issues resolved with release of the S2S spec?

[jimmycuadra]

Yes, I have updated the description at the top! Thanks.

[lnicola]

Adoption of the http crate in an async web framework: blocks our ability to use an http-crate-based ruma-api with said web framework

hyper, tower-web, gotham, tide and actix-web all use http, IIUC.

[jimmycuadra]

That is true, but the spirit of that line was more about deciding which framework to choose, which I think hinges more on async/await than use of the http crate at this point. I'll update the items to better reflect that.

[lnicola]

Stabilization of the TryFrom and TryInto traits

You can tick that off :-).

[Half-Shot]

• Handling the reason field in kick and ban endpoints matrix-org/matrix-spec-proposals#798
• search API lies and claims that it takes a v2 filter (SPEC-301) matrix-org/matrix-spec-proposals#598

have both been closed :)

[cdata]

Looks like matrix-org/matrix-spec-proposals#772 and matrix-org/matrix-spec-proposals#1468 were just closed today.

[jimmycuadra]

I crossed off 1468 but 772 still might need another tweak. I left a comment there and am leaving it in our list for the moment.

[runiq]

Triage: All of the impl Trait issues linked are resolved in some way or other, so they ought to be crossed out. However, there's a new tracking issue with some additional stuff in it (like impl Trait in type aliases, in traits, and in let/const).

The async/await MVP is stabilized in 1.39.0, but a host of other issues still remain to be resolved.

Edit: The Hyper framework has initial support for async/await in 0.13alpha.

[grinapo]

• async/await reached stable
• impl Trait tracking issue is closed

and I expect web frameworks quickly livitate onto async/await now. Sounds exciting!

[teburd]

It seems like the blocking list is close to being done, I'd love to help make a better matrix server. Just today the matrix.org synapse based homeservers are slooooow

[jplatte]

@BFrog The easiest way to contribute to the project right now is to contribute to ruma-client-api, which contains the Rust API definitions for the client-server protocol. Currently these are only used in ruma-client, our client library, but when homeserver development picks up again they will be used there too.

See the issues section for a list of things that have to be done; also come join #ruma:matrix.org, where I and other people can help you get started.

[felix91gr]

From the blocking list, the issue titled:

Spec is unclear about what is stored in the content repository

Seems to have been closed :3

[jimmycuadra]

@felix91gr See ruma/ruma#189 (comment) above.

[felix91gr]

@jimmycuadra ohh, indeed. My bad! :)