search

ekmartin / slack-irc

Connects Slack and IRC channels by sending messages back and forth.
MIT License
588 stars 157 forks source link

Feature request: Buffering messages directed at IRC users who are not present #80

Closed makoConstruct closed 8 years ago

makoConstruct commented 8 years ago

It seems there's a fairly serious UX issue here, users in slack arn't given join/part messages(and for good reason, they can be extremely noisy), so if they reply to an older message from the other side of the bridge, they often wont be sure that the recipient is still listening, they don't know whether it'll get through. For some public channels where people come and go, it could rarely seem worth it to reply to messages that're more than 10 minutes old.

Suggested solution: buffer messages that contain a single @name, when is not present in either side of the bridge, then relay them to when they rejoin.

ekmartin commented 8 years ago

Hi! You can show join/part messages by enabling it in the config, see the bottom of the example here for more information: https://github.com/ekmartin/slack-irc#example-configuration

Not sure if I understand the buffer solution you're suggesting. Are you thinking of sending messages to users when they reconnect if they were highlighted previously? So if I send a message with your name highlighted when you're disconnected, it would be posted again when you reconnect? If I'm not misunderstanding this sounds quite confusing.

makoConstruct commented 8 years ago

Ah, I see my comment was mangled a bit when github removed an occurrence of "name" that had angle brackets around it. Thanks github, glad you're stripping anything that looks like html from peoples' comments, I feel protected. But you seem to have understood. I'm not sure why it would be confusing. Maybe if the messages were kept from going through to IRC until the user rejoins, but it just occurred to me that wouldn't be necessary. What we could do is send the message through to IRC right away even if seems to be addressed to a user who isn't present, then relay it again to that user in private when they rejoin. Now I think about it, this is a feature that would make sense in a lot of IRC channels for a lot of IRC bots, even when slack isn't involved.

ekmartin commented 8 years ago

What you're describing is almost like an IRC bouncer, which allows the user to read previous a backlog of messages/queries when they reconnect.

I don't think the extra complexity this would require would be worth it for slack-irc though, but thank you for the suggestion nonetheless.

makoConstruct commented 8 years ago

Well, you should probably know that I'd fork it over this issue.

From the perspective of a consummate slack user the bridge really doesn't seem useful without this. Seems that either people will miss messages, you'll have to pollute the slack channel with join/part messages, pollute its culture with the transience of a public IRC channel, or impose an expectation that everyone on the IRC use a bouncer, which is a large part of the reason people tend to leave IRC for slack in the first place.