Alternative service to:
and
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 oflast: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
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 
Thanks for the feedback and the clarification 
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.
1 Like
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
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
In progress:
1 Like