Support m.in_reply_to

[KitsuneRal]

It should be as easy as passing an optional eventid to Room::post* methods; adding necessary parts to the message text should probably be left up to clients.

[KitsuneRal]

Turned out that the spec defines (with MUST) exactly how replies should be constructed and parsed. Full implementation of that is not easy so moves to ~~0.6~~0.7. Clients still can use postJson() and (as of 2213080a13a4eb472c8ac2267efcebc6f0936eb1) postMessage() to attach non-compliant (=without fallbacks) m.relates_to blocks.

[opk12]

(Thread awareness) Sorry if this is the wrong place to report. The reply implementation could be compatible with threads from the start. When a client implements replies, but not MSC3440 threads, compatibility with clients that support threads is obtained by adding the fields that are documented in MSC3440's Sending m.thread before fully implementing threads.

[KitsuneRal]

That's the right place :) yes, that's pretty much the intention.