feat: ✨ add ability to reply with text messages

[HarHarLinks]

I did refactor send_markdown_message along the way because it is almost identical to send_text_message and code reply and other would be doubled up otherwise. This should improve maintainability while staying compatible with earlier versions.

Sending replies isn't so bad, but receiving and reading replies correctly is a harder problem. I think it is reasonable to just not go there and wait for MSC2781 matrix-org/matrix-spec-proposals#2781 to arrive at which point the issue would be resolved.

I also revised the manual to reflect the changes.

Demo:

[HarHarLinks]

I think calling the received event "message" might be confusing here, since the parameter is also called message and the text is example_message. Perhaps rename it to event?

[ghost]

Renaming it to either event_content or message_content would probably be better. I think that event would be confusing.

[HarHarLinks]

it's not content though, it's the actual nio.events.room_events.RoomMessage object, isn't it?

[ghost]

You are right. What about content_body?

[cutec-chris]

is there an chance that this could be merged ?

[ghost]

We are waiting on MSC2781 matrix-org/matrix-spec-proposals#2781

[HarHarLinks]

We are waiting on MSC2781 matrix-org/matrix-spec-proposals#2781

@imbev: MSC3676 which starts fading out reply fallbacks has been merged and element has partially start dropping them as well (e.g. you can now reply with files etc. and you can send anything you want inside of threads).

[imbev]

Relevant part of the spec - https://spec.matrix.org/v1.3/client-server-api/#forming-relationships-between-events

[imbev]

The implementation in this branch does not match the current spec.

Current branch:

content["m.relates.to"] = {"m.in_reply_to": {"event_id": reply_to.event_id}}

Spec

{
  "m.relates_to": {
    "event_id": "$an_event",
    "rel_type": "org.example.relationship"
  }
}