UX for "threads"

[martinetd]

The "new" "reply in thread" feature shows messages as if they were normal messages, so it's easy to reply in the main chat to a message that was in a subthread, leading split discussion (and hard to follow for others)

So we need two things:

• when a reply was in thread, markup the message to irc so that it's at the very least easy to differentiate it was a threaded reply and not blindly reply in the open
• allow a way to reply in such thread

Looking at the raw debug events, threaded messages have this relates_to prop:

relates_to:
Some(Thread(
  Thread {
    event_id: "xxxx",
    in_reply_to: Some(InReplyTo { event_id: "yyyyy" }),
    is_falling_back: true
  }
)) 

The first event_id points to whatever message was the start of the thread (any normal message seems to be a valid target)
The in_reply_to event_id seems to point to the last message in that thread? I'd guess we can try leaving it None...?
also need to check what is_falling_back is about in whatever MSC defines threads...

Proposed UX:

• if someone replies in a thread, allocate a shorter id in memory and display message with a [T<id>] prefix
• allow replying with \T<id> in which case we look for id and reply there

Drawbacks:

• this cannot create a new thread; I'm fine with this for now. Could try to add other \commands to make new thread if this works out but this is inherently racy if we try to refer to e.g. "previous message" and another message just comes in..
• this cannot work if server restarts, I believe threads a short-lived enough that this is fine. This could be addressed by previous point if we want to implement that... Alternatively maybe I'll get encrypted sqlite working at some point and we could persist these :|
• probably want to clear old ids after a while..

I'm not sure about the implementation for replying, but marking threaded replies shouldn't be hard so I'll start with that next time I get bitten by this...