Gitter: Post notifications to chat, post transcripts to forum

Feature
1

Alternative service to:

and

2 Likes
2

Hi!

I’ve been working on my GSoC proposal for this project and I wanted to share some notes about my progress. I’d really appreciate some feedback.

Post notifications to a room in Gitter

I’ve come to two ways to notify posts and topics creation in a Gitter room:

To the activity feed

This could be considered the “natural” way to do it since it’s here where all the other integrations’ activities are. To accomplish this, it’s necessary to post the data to a webhook URL, which Gitter provides per each integration in a given room (unlike Slack where an only webhook is enough to post to different channels). In this case, the user should enter the webhook URLs of the rooms he wants Discourse to post notifications to in the admin interface.

An advantage of this approach is that the Gitter services library permits the developers to send a pull request to integrate some code to process the incoming data (to give a nicer format or add a custom icon for example) before it’s displayed in the activity feed.

In my opinion, separating messages and external services events is cleaner. Also, as mentioned in the gitterHQ/services room, the integrations events used to go to the messages pane, but given that many users complained claiming that their rooms got too noisy, they changed to the current activity feed.

To the messages pane

For this purpose, as the only webhooks Gitter support allow to post to the activity feed, a bot user would be necessary to send messages to the room. Gitter doesn’t support custom bot users, so the user would have to create a user and provide the API key. In addition, the user would have to set in the admin interface the rooms URIs (i.e. gitterHQ/services) he wants to post to (as long as the user he created has enough permissions to access them).

In both cases, the admin interface will include a filter rules table, similar to the one Discourse Slack plugin currently has. It will allow specifying the category (or all the categories), the type of filter and the rooms to send the notifications. In case the notifications are sent to the activity feed, it will also be necessary to include the webhook URLs. All this data would be stored using the PluginStore.

Post transcripts to forum

Given that Gitter doesn’t support outgoing webhooks yet, a solution would be to build a bot to be continuously listening (on its own thread) to a given room messages, waiting for commands. For this, the streaming API and the [Faye endpoint] (Faye Endpoint | Gitter Developer Program) are available, both of them allow real-time access to room messages (I still need to figure out which one to use).

After the bot receives a command like /topic last:50 category:staff, he will consult the Gitter REST API, get the 50 last messages and then create a new topic in the specified category with those 50 messages as posts. Additionally, I was thinking in merging continuous messages from the same user with a minimum time gap (probably seconds) to create an only post.

Regarding some stretch goals:

  • If the command includes a parameter like from:15:35-16:10, this is a different way to specify which messages to post to the forum, right? Instead of last:50

  • If the command includes a parameter like ‘ignore:bob,sara’, the messages belonging to those users (in Gitter) would be filtered out before creating the posts.

  • “Post as the user who issues the command”. If the user’s username is the same in Discourse and in Gitter, I think it’s a simple task. However, if that’s not the scenario, it would be needed a way to match the two usernames. For now, I’ve come to a workaround that includes a feature I’ve been considering to add: only forum admins are allowed to post transcripts. This is because I think of this feature as a way to make backups of Gitter conversations, and making backups is a task usually performed by admins. In that sense, when the bot receives the command, he would try to find an admin user with the provided username and if he doesn’t get any result, he will look for in a list of “username equivalences” (set in the admin interface).

  • “Open a pre-filled topic in the browser instead of posting directly”. I don’t fully understand this one. I read this post about pre-filled topics and I don’t think there is a way to pre-fill many posts. Please, let me know If I misunderstood this.

I hope I explained myself well enough. Please, let me know what sections I should go in more details, what sections I should be more clear, whether I missed an important aspect, if I misunderstood some spec or key concept or some feedback in general. I’d appreciate it.

Greetings!

1 Like
3

Hey Jafeth,

This looks good! Just a couple of things that need to be cleared up.

This method does sound preferable. I wasn’t aware of this feature though. Could you please share a screenshot of it in action?

I think we’ve had a misunderstanding here. The idea is to post it all as one topic, not as individual posts. The idea is that you’d want to edit the transcript of that conversation into a single cohesive post that sums up the entire conversation.

Yes, they are mutually exclusive. Trying to execute both at the same time should result in an error.

As mentioned above, there would only be one single post made. But yes, those message would be excluded from the transcript that gets exported to Discourse.

That’d be a fair restriction to start out with, sure.

This one should make more sense when you think about it in terms of just a single post :wink:

4

Thanks for the feedback and the clarification :slight_smile: I will make some corresponding changes to my proposal.

Here is a screenshot of a room in Gitter with the activity feed on the right side. There would go the forum’s notifications in markdown and probably some color (depending on the type of event) and the forum logo as icon.

Gitter room.png1365×767 211 KB

1 Like
5

Dedinitely keep a close eye on this development:

Edit: Sounds like they’re planning to keep it running for the foreseeable future. The default chat application for GitLab is Mattermost though, so something’s bound to happen in this space eventually. I’d say that’s probably a year++ off, so this is still worth pursuing.

3 Likes
6

Glad to know this is still worth to pursue. And yes, as also explained in their blog, I see Gitter has several plans for the future.

1 Like
7

In progress:

1 Like