IRC cannot be used for replying

[jaranta]

Replying to specific discussions is a useful feature of Flowdock, but there seems to be no way of doing it through IRC. An easy way of answering to specific messages would make following discussions easier for the people using the web interface. Following specific discussions through IRC would be even better.

[mutru]

@gitkrax Unfortunately the IRC protocol doesn't support threads, so we would need to do something that's based on plain text.

It could be something like pointing your messages to a message's numerical ID "123456: This is a comment", but that doesn't seem very usable either. We're open for ideas (and pull requests).

[jaranta]

IRC seems to show threads, so I was guessing there was some way to
implement it.

My best solution would've been some kind of text recognition and matching
that to the message'a ID. But I guess numerical ID's would also work. You
could make it usable by also publishing a perl-plugin that would give
autocomplete to the ID's.

Any kind of solution would be good at this point.

[lewellyn]

I'm curious which IRC client you're using which apparently supports threaded conversations. A long-time complaint (one which I had 20 years ago myself, but have long since learned to accept the limitation) is that if there are multiple conversation threads going on simultaneously in a channel, it can quickly become unclear which is being responded to by a particular user. It's much like a cocktail party where everyone is facing each other in a big circle instead of mingling in small groups, really.

In normal IRC scenarios, this isn't a big deal as people start to intuit the conversation flows. With Flowdock, proper threading is a bit more required if the use case is a very mixed web/IRC case. So this is indeed a valid feature request, but one which could be tricky to implement.

I have a suggestion, though untested/unimplemented yet:

13:48 <Matt> [DOWN alert: www.example.net is DOWN] <7221> << Network maintenance. Out of our control. <7298>

The timestamp and nick are obvious (and are part of the IRC client's formatting, nothing to do with Flowdock directly). The part in brackets ([]) is the message being replied to in the thread (already implemented). The part after the double angle brackets (<<) is the reply to the message thread, from the web interface.

The new part here is the number in the angle bracket group (<####>). This is the message's numeric id, as mentioned by @mutru. Note that I chose a reply done via the web to demonstrate how one can see both the original message and the reply by ID, so that either can be easily responded to.

I envision being able to include the message ID in the same format in replies (at either the beginning or end, and with an optional delimiting space, depending on user preference and what people might find more scriptable in their client). For example:

ETA for being back online is 25 minutes. <7221>

or:

<7298>Is it time for us to be finding a new datacenter?

Feedback is welcome on this idea. It's simply what came to mind as a reasonable compromise between the two paradigms and which allows IRC users to be first-class Flowdock citizens. :)

[lewellyn]

In my local tree, I've started work on implementing the suggestion I made. However, I'm running into difficulty with referencing the parent in a reply. I've tried adding :message => parent to post_chat_message in lib/irc_connection.rb where parent is the ID of the message being responded to (or an empty string if it is unavailable; it appears this is valid). My debugging output indicates that the parent is being found and is sending the expected JSON to the correct URL.

From https://www.flowdock.com/api/messages it appears my approach is correct. However, it is not being associated properly as a reply. Am I missing something? I also tried to use the comment endpoint, but then I get a 404 with content of {"message":"Resource not found"}. I find that error surprising, however I don't believe comment is correct anyhow.

Additionally, it appears that the parent's parent ID is not provided. So, I've had to leave that out of my current implementation, though I would love to be able to include that as well. IRC should be a first-class citizen, even in 2014. 😺

In any case, I'm starting to think that message IDs should be a umode for people to be able to opt in. This would allow them to respond if they somehow knew the ID, but would relegate it to a "power user" feature which wouldn't detract from the "chat" interface. Considering that it is a reasonable expectation that anyone who would be willing to manually associate their IRC replies for proper threading could be considered a "power user", this is probably a good trade-off.

In fact, if +w or +s was used, it would be somewhat semantically correct (well, as correct as can be expected, considering the fact that there is no 1:1 mapping for "wallops" or "server notices" anyhow). It might even be worthwhile send a server message to the user when they set the mode, to let them know what the number means and how to use it.

But that's later work, for after replies actually start associating properly. 😆

[spil-fransjan]

What's the current status of this? Anyone at Flowdock that still has this on the radar?

[milanaleksic]

I made a simple Docker container to make your PR work until this is merged @charliewolf https://github.com/milanaleksic/docker-oulu-threading/
Thanks a lot for this work, I don't need to mix irssi with flowdock-in-browser any more!