flowdock/oulu

Flowdock IRC Gateway

Oulu: The Flowdock IRC Gateway

This component acts as an IRC server, and bridges the messages between clients and Flowdock.

If you're looking to simply use this IRC gateway, check out the help page.

Prerequisites

Oulu uses bundler, so simply run bundle install before running tests. No database is needed.

Running tests

Use: bundle exec rspec

Running acceptance tests

Use: TEST_USER="[email protected]" TEST_PASSWORD="..." TEST_FLOW="mytest/main" bundle exec rspec spec/acceptance_tests.rb

Running the server

Use: foreman start

Possible environment configuration:

• FLOWDOCK_DOMAIN - where's your Flowdock at? (optional, default value: flowdock.com)
• FLOWDOCK_UNSECURE_HTTP - use http instead of https. This makes testing on your local machine much nicer.

There is a sample.env file which should suffice for local testing so you can just

ln -s sample.env .env

Define port using command line parameter --port (optional, defaults to foreman's default port)

Deploying to Flowdock's server environments

There's a separate repository with deployment scripts and instructions.

oulu's Issues

possible to use this gateway with freenode in some way?

Wondering if its possible to use this -- or another flowdock gateway -- with freenode?

Really like flowdock, just we need to keep our main channel on freenode.

My 1-1 message edits are sent back to me (and incorrectly)

When I edit one of my messages in a 1-1 with someone, the edit is sent back to me in IRC, apparently from my own nick.

For example, if I'm chatting to someone in the Web interface, and write "test", and then change it to "test2", then at that point I immediately receive a privmsg in my IRC session, apparently from "Kev" (my own nick), with the text of "test2*".

My guess is that this is because lib/events/message_edit_event.rb lacks the check from lib/events/message_event.rb:6 (or similar).

Configurable option to show Team Inbox as a separate channel

In Flowdock, having lots of Team Inbox messages doesn't ruin the chatting experience, but with Oulu it's a bit more difficult.

All flow members are shown in IRC rooms, even if they are offline

For example, a flow that has 10 members, only 3 of which are currently online will show all 10 members in the IRC user list. However, in the web UI, only the 3 online members are shown unless you click the arrow.

This means that it's impossible to know who's actually online or not using IRC, and you have to keep checking the web UI for user status.

Or am I missing something?

Order is not preserved for messages sent from the client

Pasting a code block in the IRC client will generate multiple REST API calls, and their order is not guaranteed.

We should probably buffer the messages, and for one user we should wait for the confirmation before sending another message. In this particular case, it would be even better to delay the submission a bit, and construct only one Flowdock message.

Struggling to authenticate

Hello, friends.
Is this IRC gateway still working?

Using both Colloquy and irssi, I was unable to authenticate using TLS /w irc.flowdock.com on port 6697.

I made sure to remove whitespace and strange chars from my password.

I tried setting the server_password to [email protected] pa$$w0rd.
Messaging NickServ with and without quotations surrounding the args didn't seem to work in both clients.
I also tried substituting my personal API token for my password using both methods, but that didn't seem to work either. (https://flowdock.com/account/tokens)

I'd appreciate any pointers on this one -- cheers. 👍

Show chat history

Some options, or a combination of them:

• Show messages mentioning my name automatically when connecting
• Implement a /history #channel command. It would essentially break the IRC spec, but I guess most clients relay unknown commands directly to the server.
• Catch a chat message like !history, and instead of relaying it to other users, fetch the history.
• Simply offer a link to the web UI when joining a channel.
• Check out how ZNC does this.

Server password support

It should be possible to bypass the NickServ authentication by sending an optional server password. This would make reconnecting a lot easier.

IRC bridge stops receiving messages

Every week or two, typically overnight, users connected to the IRC bridge stop receiving messages. There is no indication from the server that anything is wrong, and reconnecting typically immediately fixes the problem. It happens to all connected users simultaneously. Messages sent from the IRC bridge show up in Flowdock fine, the issue is just with receiving messages. Let me know if there's anything else I can do to help track down the problem, because it is a bit irritating.

The 2015-02-22 update broke something

Hi,
when connecting this morning (talking about team wywy on flowdock.com) everything looked ok, until...

[10:16:46] <Florian> o_O
[10:16:47] <Florian> o_O
[10:16:54] <Florian> I see evry line twice. doh
[10:16:54] <Florian> I see evry line twice. doh

Reconnecting does not fix it. This happens

a) when I write on irc
b) when I write on flowdock.com

While my setup is a bit convoluted (quasselclient connects to remote quasselcore, quasselcore connects to local znc, znc connects to flowdock) it has worked until this morning on irc and flowdock.

No indication returned to user when message was not posted

When oulu is unable to successfully post a message to the Flowdock API, it records the error in its logs. However, it does not inform the user that the message was not delivered. This means that when the API is having trouble receiving messages (like last Friday), IRC users have no way of knowing which (if any) of their messages have actually been sent.

This very severely impacts the usability of the IRC gateway, since there is no way to trust that it has actually delivered any messages - and no way to check, apart from using the web interface or a native client (and avoiding these is usually the point of using the IRC gateway in the first place).

The problem is on line 290 and line 297 of irc_connection.rb. This is where $logger.error is called, but what is almost certainly needed is something like

send_reply(render_unavailable_resource)

or

send_reply(render_cannot_send_to_channel)

Use realname for email and server password for FD password

Server password in the format of "email password" is too confusing. Splitting them to separate fields would make this more understandable.

Configurable option for NOT sending emojis

Weechat on Linux can't show emojis (it's kinda Linux issue) but I can see other scenarios where sending :raw_emoji_string: instead would be beneficial.

Edits older than 60s are not delivered

If someone edits a message that was originally sent more than 60 seconds ago, the notification of this event is not delivered to IRC users. However, web users will see the edited message. IRC users may justifiably also be interested in the revised content, even though it's over a minute old.

What's the rationale behind this arbitrary limitation?

It would be useful if it could be customised somehow.

A workaround is to edit lib/event/message_edit_event.rb and make MESSAGE_EDIT_THRESHOLD_IN_SECONDS be very large, and then run a local oulu.

Edited 1-1 messages are not delivered

When I'm in a 1-1 with someone, if they edit a message (within 60 seconds), the edited message is not delivered to me in IRC. By contrast, edits in flows are delivered fine (with "*" appended), as expected.

Spaces in shared URLS/uploaded files not converted to %20

When files are uploaded to a flow, the URL sent via IRC isn't properly URL-encoded. Specifically, spaces aren't converted to %20. This gives things like this:

<RandomPerson> https://www.flowdock.com/rest/files/81438/n3ISn0DBwkVhTkTYGm_nQQ/Screenshot 2015-01-15 13.26.33.png

which are unclickable in most IRC clients. It should instead be

<RandomPerson> https://www.flowdock.com/rest/files/81438/n3ISn0DBwkVhTkTYGm_nQQ/Screenshot%202015-01-15%2013.26.33.png

Support PART and LIST

We should use flow's "open" attribute to define which flows are interesting. It should be possible to JOIN flows with "open: false", and it should be possible to PART from flows with "open: true".

LIST should give a list of all other flows, including flows you've never attended.

Threads can be seen but not replied to

Threads can be seen in the chat denoted by [thread_name]

there is no way currently to reply to a thread in a channel

Omit subdomain prefix in channel names when possible

If the user only has access to one company, there's no need to prefix channel names with the company subdomain. "#example/main" could be just "#main".

Authentication fails when user has 0 flows open

Previous implementation of IrcConnection#authenticate assumed, that it's not possible to JOIN channels afterwards. Now that it's possible, we shouldn't block the connection entirely, but instead tell the user to use LIST.

Show Trello updates

Our organization is using a mix of Trello and Flowdock. There is commenting on both sides, as appropriate. Web users see all of the Trello updates, whereas IRC users only see replies to them from the Flowdock web interface.

To say the least, this is a bit confusing.

When file is uploaded to flowdock there is no message sent via IRC gateway

Is this just an unsupported event type (like trello for example?)

JOIN should return error before authentication

Currently reconnected clients join channels automatically, and JOIN doesn't return anything. It should return an error message so that it would be more obvious to the user, that you're not actually on the channel.

IRC cannot be used for replying

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.