Should we try to bridge chat services?

I am a total noob when it comes to messaging services and setting up bridges between them,
also people might have various reasons for not wanting bridges between services.
(Bridged messages are often of lesser quality compared to normal messages)

Personally I have only very limited experience (one discord channel bridging to an irc channel) with chat services where bridges where used, however I found that experience positive, because of it I communicated (a little bit and mostly read their interesting messages) with irc people I wouldn't have communicated with otherwise.

I only did a very very short search (so maybe there are other better tools) and found this:

From a rough look it seems to support a lot and is actively developed.

Personally I think it would be cool if every service (discord, slack, maybe matrix) had one chat room dedicated to bridge "general" talk, so the end result would be discord, slack, (matrix), irc bridged together.
An important question is also what the irc users think, would they be welcoming of a bridge bot posting messages in their channel? (I am assuming that is how it works for irc)

Are there people who are interested in trying something like this out?
Are there reasons not to use bridging at all? (apart from the work to set it up and get it working)

2 Likes

I agree! It would be awesome to have a separate channel like #general-bridged that is connected to all services we currently have (discord, slack, irc). I would hope we can setup that integration without adding yet another service though (mattermost) :upside_down_face:

1 Like

I think matterbridge can be used completely independently from mattermost, the way I understand it mattermost is just another protocol that you can choose to bridge to and we have no reason to do so.

Its about states:

bridge between mattermost, IRC, gitter, xmpp, slack, discord, telegram, rocketchat, twitch, ssh-chat, zulip, whatsapp, keybase, matrix, microsoft teams, nextcloud, mumble, vk and more with REST API (mattermost not required!)

@spdegabrielle Maybe you can move the messages starting from my message into a separate topic "Should we try to bridge chat services? (discord, slack, irc)" so that this topic isn't hijacked?
It can also stay here if you have nothing against it, whatever you prefer.

1 Like

Done

@b625e17 @simonls A slack/discord bridge written in :racket:Racket would make a great experience report for RacketCon...

2 Likes

I think that we should bridge the chat services. I've seen it at work in the Nim community and liked it. That said, I only used IRC, so I don't know how the messages from IRC looked on the Discourse or Gitter sides.

I also think that we should use software for this that has already been used by several projects and most likely has had subtle bugs fixed. I think the time and effort that would go into developing a new tool only for the sake of having it written in Racket should rather go into other parts of the language or ecosystem where this effort is needed more.

Also keep in mind that software has to be maintained, and if the people that would write the bridge service would turn to other things, that could be a problem. I already found it sad how long the "empty page bug" in the package server existed. Don't get me wrong, I find it totally legitimate to change personal priorities and stop maintaining some open source code you've written. But for the users of the software that can of course be a problem.

4 Likes

I think a best choice is a racket content searching engine, which include things from different sources if they want to be included. This can avoid splinter and also encourage diversity!

1 Like

I'd distinguish between (relatively short-lived) chat content and more persistent web content (say, Racket website, blog, Discourse, individual blogs, etc.). I think only the second category would benefit from such a search engine. On the other hand, the chat services would benefit from a bridge service connecting the chats.

I'd rather say, maybe control splinter to some extent, but not avoid it.

Generally, I think it's better to reduce complexity instead of adding more complexity to control the initial complexity. Then again, if the complexity can't be reduced otherwise, having a specialized search engine may be useful, i.e. better than not having it.

1 Like

I agree, regarding the second category, I am not sure whether we need a search engine, certainly doesn't seem like it would be easy to build one...
But I think there is already something that does a good job with helping with that category: https://racket-stories.com/

About
Welcome to Racket Stories.
Racket Stories is a place where you can find and share links to anything Racket related: blog posts, tutorials, new packages, papers etc.

4 Likes

What everyone else said, but even more so. Trying to keep up with the flavor of the week community communication service is nauseating.

2 Likes