Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: DMing users across platform #191

Open
NikkyAI opened this issue Jun 7, 2017 · 24 comments
Open

Feature Request: DMing users across platform #191

NikkyAI opened this issue Jun 7, 2017 · 24 comments
Labels
Milestone

Comments

@NikkyAI
Copy link
Contributor

NikkyAI commented Jun 7, 2017

Trying to write a bot using the api i came across the limitations of "just" sending messages to the gateways, so a way to reply to users available to users and bots would be very useful

I am not enterily sure how to adress a specific user and a specific platform using eg. irc or slack in a intuitive way..
but sending a DM to the bridge bot starting with {username}@{account} would provide enough information to search for eg. [email protected]
each platform would search for nicknames before username and optionally insert the string needed to reply eg: [email protected] as nick/user name

usig this system a bot can send respond to any user on any (DM-capable) platform, i hope

PS: actually just having the bots part implemented would be plenty features for me at the moment

@david-drinn
Copy link

david-drinn commented May 21, 2019

Sorry, I'm a newb to your project, @42wim but it's pretty promising for my use case and so I had to reach out. I got it up and running between XMPP and Rocket.Chat in a jiff. But it only seems to work between channels, and doesn't support direct messages.

However, I take it from this FR and that it closes several other trackers, that direct message bridging is now supported... is that so? If so, I don't see how to enable that. Is there a special gateway channel format to use?

@NikkyAI
Copy link
Contributor Author

NikkyAI commented May 21, 2019

no, this FR is still open, other requests are just closed to avoid duplication

@ramack
Copy link

ramack commented Oct 13, 2019

is there any plan to add support for direct messages? Actually I am planning to use matterbridge with my personal account credentials, as I do not have access to server settings, so I'd like to have also direct messages in my XMPP-world.

@42wim
Copy link
Owner

42wim commented Jan 11, 2020

I've been thinking about how to support this, but I don't really see an option to have this directly in matterbridge, it's too cumbersome to chat between users as shown in a possible example here:

As in the example of @NikkyAI e.g. matterbridge is in slack as a bot called matterslack and also is running in irc server as matterbot.

So if you want to DM from yourself (user1 on irc) to user2 on slack.

  • User1 will need to send a msg to matterbot "user2@slack: hi".
  • User2 will receive a DM from matterslack with "user1@irc: hi".
  • User2 can then respond with a DM to matterslack: "user1@irc: hi back"
  • User1 will see receive a DM from matterbot with "user2@slack: hi back"

This isn't very user-friendly and will be very confusing when DM multiple people.
Also the private messages can be intercepted by the person running matterbridge.

So maybe a solution for this is setting up an out-of-band chat (preferably P2P and E2EE), so the example will be:

So if you want to DM from yourself (user1 on irc) to user2 on slack:

  • User1 will need to send a msg to matterbot "chat user2@slack".
  • matterbot responds: "you can chat with user2@slack on this URL"
  • User2 will receive a DM from matterslack with "user1@irc wants to chat with you use this URL".

User1/User2 chat with each other on the specific URL.

Other ideas/remarks/suggestions on how you would see DM's between two users are welcome.

@qaisjp
Copy link
Collaborator

qaisjp commented Jan 11, 2020

For the out of band chat we could piggyback off public IRC servers? We could let users select their "provider" of choice. The ToS of freenode / rizon etc would need to be checked. GitHub Pages can of course be used for any website hosting — a fork of kiwiirc with changes specific to matterbridge.

I've always considered the following quote to be a necessary caveat for this feature:

Also the private messages can be intercepted by the person running matterbridge.

With that in mind, the idea I've had in the past is to do something like:

  • User1 sends a msg to matterbot !mbchat user2@slack and the PM session just PMs that user until further commands are sent.

Alternatively:

  • the user can set aliases for users on accounts (!mbchat user2@slack u2) and then future messages can be preceded with u2 Hello, world to send the message Hello, world to user2@slack

Fwiw my IRC bridge has PM support and it's really bad! I'll edit this later with info about that if I find anything useful to share.

@NikkyAI
Copy link
Contributor Author

NikkyAI commented Jan 12, 2020

with any kind of state like setting a target user one has to keep in mind that this has to easily work across matterbridge restarts, having to add complexion by parsing user settings at startup from some file or sqlite database would suck and potentially add more ways to crash on config change

i like the idea of using something like a fork of kiwiirc to act as webinterface for matterbridge.. as a fallback for platforms where implementing PM delivery or interaction is too annoying
i guess mtterbridge would generate tokens for each user, so one can keep track of who opened the website an is chatting.. (sounds like having to deal with state again.. and js on top of that)

@hmrhkr
Copy link
Contributor

hmrhkr commented Jan 12, 2020

Some protocols support some kind of virtual direct messaging (on xmpp this system is called transports) i believe other protocols have similar features. For the start we could just develope a a way to send dms via those systems which schould be relatively easy and possibly later think of a way to connect the other protocols.

@qaisjp
Copy link
Collaborator

qaisjp commented Jan 12, 2020

Do we have a list of platforms that do support PM bridging? Is it just XMPP?

@Humorhenker, for XMPP, I've found this info:

Do you have any other useful links? The wiki page suggests that you need to transfer credentials, which may be undesirable

@patcon
Copy link
Contributor

patcon commented Jan 14, 2020

Oooooo i like that kiwiirc tactic, but maybe it could be even simpler -- just drop patcon@slack and anon2@irc into urls like this:
https://kiwiirc.com/nextclient/#irc://chat.freenode.net/##matterbridge-anon2-patcon-xxxxxxxxx?nick=patcon--slack--xxxxxxxxx
https://kiwiirc.com/nextclient/#irc://chat.freenode.net/##matterbridge-anon2-patcon-xxxxxxxxx?nick=anon2--irc--xxxxxxxxx

So someone messages a matterbot with dm anon2@irc or some signal, and matterbridge sends a similar connection link to each, with a portion of room name (xxxxxxxx part) being unique to the communicating pair of users. It could be determinstically generated from some internal app state that is consistent between restarts. I would imagine there might be a salt, but this is really just to prevent harrassment. If someone goes to the trouble to reverse the salt, then the people will still see someone entering the IRC room with the two of them, and it will be obvious.

(##channels on IRC are for more ephemeral rooms, if I recall correctly.)

@qaisjp
Copy link
Collaborator

qaisjp commented Jan 14, 2020

I've just realised that if we went the way of IRC, we don't even need to use irc channels (e.g. @patcon's ##matterbridge-anon2-patcon-xxxxxxxxx) — you can just do it using IRC private messaging.

IRC channels can still be used for group PMs.

@patcon
Copy link
Contributor

patcon commented Jan 14, 2020

Good point! A room still feels most straightforward imho, as we don't need to tell people to type some techno-genius-looking command in order to start. (kiwiIRC can't auto-run an arbitrary command on join, like desktop clients can, so can't auto-init the DM session)

But maybe I'm suffering from a failure of imagination :) What would you imagine the best-case interaction for IRC private message to be @qaisjp?

I'm thinking the best we could do is, if message from patcon@slack to anon2@irc:

  1. patcon send a DM to bot to initiate cross-bridge private message, e.g., /dm @matterbot anon2@irc
  2. matterbridge sends DM to patcon@slack and anon2@irc, posting a link to join freenode via kiwiIRC link, autofilling a nick like patcon--slack--xxxxxxx
  • this message also tells the user to: (1) type /msg anon2--irc-xxxxxxx hi! i just joined this chat

So just one more step from the room way, but also chance of confusion if someone doesn't realize that the other person won't see the messages they type before arrival. Of course, the same issue exists in the ##room tactic, but at least in there, matterbridge could theoretically drop a message to explain.

@hmrhkr
Copy link
Contributor

hmrhkr commented Jan 14, 2020

Hm, i dont want to be the one pessimistic here. But that still would be a pretty userunfriendly way afterall. Especially the fact that there will be no offline messages with that method and this whole process of initialization would turn off many users in my opinion.
Another option would be some kind of internal DMsystem where the users have to use commands with the bot to write messages like:

  1. /msg [email protected] Hello whats up?
  2. /r Doing fine

and the other user would recieve them directly from the bot with a note of the sender.
Would probably not be easier to implement but way more userfriendly if you ask me.

@qaisjp
Copy link
Collaborator

qaisjp commented Jan 14, 2020

What would you imagine the best-case interaction for IRC private message to be @qaisjp?

We would fork KiwiIRC so our client automatically sets up a direct message channel.

Ideally we'd completely hide the fact that IRC is being used — lock it down a little.

@patcon
Copy link
Contributor

patcon commented Jan 16, 2020

still would be a pretty userunfriendly way

@Humorhenker agreed, unfortunately

Another option would be some kind of internal DMsystem where the users have to use commands with the bot to write messages like:

Originally liked this approach too. The catch of that is that being in more than one conversation is quite confusing to user. All messages would come in as DM's from matterbridge-bot and be intermixed, right? (Or am I misunderstanding?) Technically doable though.

We would fork KiwiIRC so our client automatically sets up a direct message channel.

@qaisjp Ah, ok, wasn't expecting that scope. I guess I'm lacking a sense of what scope there's willingness to accomodate (e.g. setting up a mandatory supporting platform)

re: IRC private message approach. seems quite onerous, especially since it doesn't seem to offer a significantly better experience than simply using an obfuscated public channel. IRC PM's seeming require either (1) build/host a custom kiwiIRC client, or (2) expect user to run some IRC commands on join.

@NikkyAI
Copy link
Contributor Author

NikkyAI commented Jan 16, 2020

i kind of do not get.. if we plan between using a existing irc backend.. and hosting one.. why not implement the message routing between clients on the already running program? (matterbridge)

@qaisjp
Copy link
Collaborator

qaisjp commented Jan 16, 2020

if we plan between using a existing irc backend.. and hosting one.

Nothing would be hosted. Existing services would be piggybacked, so it's privacy preserving (the bridge doesn't see PMs).

why not implement the message routing between clients on the already running program? (matterbridge)

Do you mean the first example here #191 (comment) and here #191 (comment)?

  1. privacy (bridge owner can see PMs)
  2. can't do this because the bridge appears as a user. the bridge can't sent messages as other people.
  3. if the bridge appears as a user, people's messages are all mixed in one feed

@hmrhkr
Copy link
Contributor

hmrhkr commented Jan 17, 2020

privacy preserving (the bridge doesn't see PMs).

I dont get how that would offer more privacy. The bridge hoster sees every message with bridged channels nevertheless. You will need to trust the bridge hoster.
Why should we outsource the trust to some irc operators then? Because now the users would have to trust the irc operators for DMs while the whole process is rather transparent so they might not even know that.

@42wim
Copy link
Owner

42wim commented Jan 18, 2020

Thanks for the useful feedback!

I like the idea of using kiwiirc instead of developing something from scratch ;-)

@Humorhenker wrt to privacy, matterbridge now only does "public/group" channels, as in data meant to be at lease some what public. Private/direct messages are something else.
Of course when using irc we would just move the problem, that's why I proposed P2P with E2EE.

But that's probably too ambitious, so maybe we can start with the low-hanging fruit for now.

Grouping the suggestions together we end up with something like this:

  • users who want to initiate a private chat send a DM to matterbot to initiate conversation with a specific user.
  • matterbridge will return a link to a website (hosted remote or on matterbridge self)
  • this link will start kiwiirc to an irc server* which will be used for the private messages.

Wrt to that irc server: using a public irc-server probably opens up the "private" messages to more people then just the matterbridge owner (as @Humorhenker correctly notices).

So maybe we can add a built-in irc server to matterbridge so users can choose to use a public/private or built-in irc server.

@hmrhkr
Copy link
Contributor

hmrhkr commented Jan 20, 2020

built-in irc server

after doing a quick search https://github.com/fimad/ggircd/ seems to be a good fit. Small and easy to implement.

Afterall there will be the problem of no offline messages when we deside to use irc. That is a huge downpoint for me.

@qaisjp
Copy link
Collaborator

qaisjp commented Jan 20, 2020

TBH if I wanted to PM someone on another platform, I'd just switch platform.

If we forked kiwiirc (instead of just using it) we could make it so that messages are saved in localStorage? Not great cross-platform but it's better than nothing?

@minecraftchest1
Copy link
Contributor

An idea I have is to add a command that when sent in a DM to the bot, would create a private channel/room for the DM.

@gardar
Copy link

gardar commented Mar 4, 2021

Perhaps it would be possible to take a similar approach to the one that Mio does (m.io)?

Their approach seems to be to create a new "app" for every direct message, their video gives a good explanation on the subject: https://www.youtube.com/watch?v=nNxF_svA59Y
That approach might not work for all the bridges, but should at least work with microsoft teams / webex teams / slack.

@harryfei
Copy link

harryfei commented Apr 6, 2021

https://github.com/ehForwarderBot/ehForwarderBot

Maybe we can learn from thid project

@nycki93
Copy link

nycki93 commented Dec 8, 2023

I don't think there's any "seamless" way to do this, not as long as you have one chat (you + the bot account) acting as a proxy for many chats (you + your friends). There's basically three solutions to this: fake accounts on demand, mode switching, or addressing every message.

fake accounts on demand

the bridge creates fake accounts for every user, and you just message the appropriate "puppet" to DM that user.

<alice> hello!
<bridge-bob> howdy alice!
  • pro: looks the most like "real" DMs
  • con: probably violates discord TOS
    • workaround: make a dedicated DMs guild and create a private channel for every conversation
  • con: probably the hardest to implement

mode switching

you have one bot DM, and you issue a command to switch who you're DM-ing, like this:

<alice> !dm bob
<bridge> now talking to bob.
<alice> hello!
<bridge> (bob) howdy alice!
  • pro: allows for natural conversation flow
  • con: easy to accidentally dm the wrong person if you forget to switch

address every message

you have one bot DM, and you prefix every message with the user you're talking to, like this:

<alice> bob hello!
<bridge> (bob) howdy alice!
  • pro: hard to accidentally dm the wrong person
  • pro: mimics the way we already talk when getting someone's attention in a group chat
  • con: verbose

personally I think addressing every message is the way to go. maybe you could even give short nicknames to the people you dm the most often, like

<alice> !alias bob b
<bridge> chats for 'b' will be sent to bob.
<alice> b hello!
<bridge> (bob) howdy alice!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests