Add screenshots and information about what the bridge can and can't do to the README

[ShalokShalom]

Hi there :)

I am from the fsharp community and I hope that this solution can connect our Slack instance to the new Matrix instance I just found.

In order to achieve this, is a RFC issue important and I appreciate every form of help, like a little screenshot, which shows how a puppet looks like in Slack.

🙂

Another open question is, what you mean by 'your homeserver' and 'a specific user'?

I hope, that its possible to bridge a whole community at once?

[thomas-profitt]

Before thinking about where and how to present this information in a nice permanent way, I'll respond here.

---

This bridge just allows an existing Slack user with a their own Matrix homeserver (a homeserver they can run bridges on and trust their Slack API keys and Slack activity to) to use their Matrix homeserver, their Matrix user and a Matrix client as a Slack client.

You can use this bridge as a Slack client without your Slack team's permission, and even without them knowing (as long as you can create a Slack API token).

This bridge acts as your Slack user and turns Slack channels your user is in into Matrix "ghost" rooms your Matrix user is in, and Slack users who post messages are turned into "ghost" Matrix users sending the same messages in Matrix. Messages your Matrix user sends in those rooms are turned into Slack messages sent by your Slack user, for the people using Slack to see.

The result is that you can use Matrix, not Slack, and see all the Slack rooms, users and messages converted into Matrix rooms, users and messages, and the Slack users see your Matrix messages in your Matrix rooms as Slack messages (from your existing Slack user) as Slack messages in their Slack channels.

This bridge works for all channels your Slack user is in, including direct messages.

---

If you want to let Matrix users (without Slack accounts) communicate back-and-forth with Slack users (without Matrix accounts), look at matrix-appservice-slack instead.

That bridge works as a Slack channel integration, to bridge a single Matrix room with a single Slack channel. It uses a single Slack bot to convey messages from Matrix users in the Matrix room to Slack users in the Slack channel, and creates ghost Matrix users to represent individual Slack users in the Matrix room.

That bridge only works on a per-channel basis, and does not work for direct messages (a Slack and Matrix user cannot DM eachother through it).

It does not require you to run your own Matrix homeserver (but be sure you trust the homeservers of the Matrix users in the room with any messages that might come through Slack!), but it does require setting up a Slack integration in the Slack channel.

[ShalokShalom]

Ok, fine. This is how I imagined it. You can put that text on the README, its very informative. :)

[ShalokShalom]

Why does this depend on an own Matrix homeserver?

I am fine with the extra bridge per user, while it would be far more convenient to host it on a casual device, so every user can setup one for its own. :)

[kfatehi]

Interesting -- I am having trouble fully understanding/imagining how that would work. Do you have a design in mind?

[ShalokShalom]

A bundle/installer for a homeserver and the bridge together, so its easy and simple to setup. :)

Then everyone can connect to one room?

[thomas-profitt]

I agree that it would be nice to have a super-easy way to set up a personal homeserver with bridges, but there are still requirements that make that just a tiny bit tricky (a homeserver must be reachable via a DNS name, and must have port 8448 exposed if it's federating).

It'd be great, but let's put it aside because it's an entirely separate project (already addressed to some extent by avhost/docker-matrix)

---

matrix-puppet-slack requires a Matrix homeserver you control (you have to be able to configure the homeserver to run this bridge) and trust (you have to trust the bridge with your private Slack API token), and if you run multiple matrix-puppet-slack bridges on a homeserver, you'd have to have each bridge reserve a separate ghost user name prefix (see #34 ).

It would be a little silly to do that, though, because then you'd just have a bunch of people using Slack with Matrix homeservers, Slack bridges, and Matrix clients as their Slack clients. It wouldn't ease your transition into Matrix the way matrix-appservice-slack would.

I think you'll get a good feel for this if you try both bridges and get a feel for how this can work.

[ShalokShalom]

This is the issue:

The current community is partly skeptical and it seems difficult to get matrix-appservice-slack confirmed

Which is why I see the other approach more suitable :)

[thomas-profitt]

You and any of your Slack team's members can connect to Slack via this bridge and Matrix if they want, but they'll still just be using Slack. No one will actually be using Matrix. Everyone will still have to have a Slack account, and all your communication will still take place in Slack.

You could start using this bridge as your Slack client, then encourage others to use it as their Slack client, and maybe your users will start to want to use Matrix because of that, but you won't actually be bridging your Slack team with Matrix.

I'll follow up with you in the Matrix Bridging room; it's an appropriate place to talk about your overall problem and there are a lot more people involved to help.

[ShalokShalom]

I never wrote that we attempt to completely switch?

ruma/ruma#192

[thomas-profitt]

If that's the case, this bridge will serve that purpose; you and other members of your team can use Matrix as a Slack client without the involvement of anyone else. That's what I'm using it for.

[ShalokShalom]

Yeah, it just requires a full setup of synapse and the bridge. That is something most people will not do. Unless its so easy as the installation of any other tool.

[thomas-profitt]

Yes, and they also have to run the bridge server and homeserver, it's not just installation.

[ShalokShalom]

What I mean. When you combine all this in one package, is it much easier.

[thomas-profitt]

Again, that'd be great, but it's not relevant to this project or this issue.

I'm going to close this issue. The conversation can continue in the Matrix Bridging room.