Initial support for Voice Rooms

[Half-Shot]

To begin with this would be really barebones stuff like just making sure the room is created and nobody can speak in it. I'd also like a state event to track who is currently in the call on the Discord side and what their status is (deaf/undeafened).

Oh, and there are a lot of cases where I have hardcoded us to only work with text rooms so we need to unfuck those.

[MayhemBill]

Expanding upon this a bit, would you be going through Jitsi, or some other method for voice? It would possibly be a bit more resource efficient to go through Jitsi, and just have the bot auto join (or remain joined indefinitely) when people joined into the Discord Voice.

Unless you're looking to have it so each user joined individually and each person has their audio directed to different accounts, which I'm not sure it's that's possible from Discords side. if it is, it would be very difficult to achieve.

[MyriaCore]

Old post, but something I'd definitely be interested in. going through jitsi would make sense, although im not sure if bridges can do that

[kfatehi]

Forgive me if i sound very ignorant below of how this bridge works, because I am, I've never run it, but I've been thinking about voice bridging and want to add my response to this thread:

Using matrix bridge as platform to bridge discord user transmissions with status and identities into Jitsi sounds brilliant.

I have been toying around a little bit inside a discord music bot and find the voice client to look pretty sensible.

Voice bridging might not be as hard as we seem to think, but of course the design we are talking here regarding Jitsi's involvement (because I was at first only interested in discord<->discord, but this is a matrix bridge, so this makes sense) makes the stack more complex (I am currently of the mind that it's worth it because in discord it will be hard/impossible-->[because no puppets allowed in discord, surely] to show identities of the speaker visually but the voice client emitting transmissions originating from within discord knows who is who and thus relays those to the jitsi component which can vivify "ghost users" in an active call or room and that could be okay if the security model here is similar to the puppet-series of bridges where the homeserver is isolated and really is just a launchpad for these things rather than for inviting other people who might also use bridging features as that just confuses the hell out of me).

Assuming nobody has started this by then, I may look into it after redeploying all the components again as it's been a couple years for me since I've operated synapse. It probably makes sense to hack out a minimalist proof of concept of what I'm describing above and then show it to Half-Shot rather than to try to mix the feature in. Yes, I now see why Half-Shot has it labelled as hard; the PoC itself isn't hard but making things consistently making sense and secure from each platform certainly is.

[HammyHavoc]

Forgive me if i sound very ignorant below of how this bridge works, because I am, I've never run it, but I've been thinking about voice bridging and want to add my response to this thread:

Using matrix bridge as platform to bridge discord user transmissions with status and identities into Jitsi sounds brilliant.

I have been toying around a little bit inside a discord music bot and find the voice client to look pretty sensible.

Voice bridging might not be as hard as we seem to think, but of course the design we are talking here regarding Jitsi's involvement (because I was at first only interested in discord<->discord, but this is a matrix bridge, so this makes sense) makes the stack more complex (I am currently of the mind that it's worth it because in discord it will be hard/impossible-->[because no puppets allowed in discord, surely] to show identities of the speaker visually but the voice client emitting transmissions originating from within discord knows who is who and thus relays those to the jitsi component which can vivify "ghost users" in an active call or room and that could be okay if the security model here is similar to the puppet-series of bridges where the homeserver is isolated and really is just a launchpad for these things rather than for inviting other people who might also use bridging features as that just confuses the hell out of me).

Assuming nobody has started this by then, I may look into it after redeploying all the components again as it's been a couple years for me since I've operated synapse. It probably makes sense to hack out a minimalist proof of concept of what I'm describing above and then show it to Half-Shot rather than to try to mix the feature in. Yes, I now see why Half-Shot has it labelled as hard; the PoC itself isn't hard but making things consistently making sense and secure from each platform certainly is.

Did you have any joy with it in the end?

[kfatehi]

No, unfortunately I haven’t been developing much in the matrix scene lately.

On Tue, Oct 31, 2023 at 11:41 AM Hammy Havoc @.***> wrote:

Forgive me if i sound very ignorant below of how this bridge works, because I am, I've never run it, but I've been thinking about voice bridging and want to add my response to this thread:

Using matrix bridge as platform to bridge discord user transmissions with status and identities into Jitsi sounds brilliant.

I have been toying around a little bit inside a discord music bot https://github.com/Just-Some-Bots/MusicBot and find the voice client https://github.com/Just-Some-Bots/MusicBot/blob/master/musicbot/bot.py#L384 to look pretty sensible.

Voice bridging might not be as hard as we seem to think, but of course the design we are talking here regarding Jitsi's involvement (because I was at first only interested in discord<->discord, but this is a matrix bridge, so this makes sense) makes the stack more complex (I am currently of the mind that it's worth it because in discord it will be hard/impossible-->[because no puppets allowed in discord, surely] to show identities of the speaker visually but the voice client emitting transmissions originating from within discord knows who is who and thus relays those to the jitsi component which can vivify "ghost users" in an active call or room and that could be okay if the security model here is similar to the puppet-series of bridges where the homeserver is isolated and really is just a launchpad for these things rather than for inviting other people who might also use bridging features as that just confuses the hell out of me).

Assuming nobody has started this by then, I may look into it after redeploying all the components again as it's been a couple years for me since I've operated synapse. It probably makes sense to hack out a minimalist proof of concept of what I'm describing above and then show it to Half-Shot rather than to try to mix the feature in. Yes, I now see why Half-Shot has it labelled as hard; the PoC itself isn't hard but making things consistently making sense and secure from each platform certainly is.

Did you have any joy with it in the end?

— Reply to this email directly, view it on GitHub https://github.com/matrix-org/matrix-appservice-discord/issues/149#issuecomment-1787789464, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABKZSOR7GALQNIWKOS6K4DYCFA65AVCNFSM4FC2GKR2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZYG43TQOJUGY2A . You are receiving this because you commented.Message ID: @.***>

[HammyHavoc]

• [ ]

No, unfortunately I haven’t been developing much in the matrix scene lately. … On Tue, Oct 31, 2023 at 11:41 AM Hammy Havoc @.> wrote: Forgive me if i sound very ignorant below of how this bridge works, because I am, I've never run it, but I've been thinking about voice bridging and want to add my response to this thread: Using matrix bridge as platform to bridge discord user transmissions with status and identities into Jitsi sounds brilliant. I have been toying around a little bit inside a discord music bot https://github.com/Just-Some-Bots/MusicBot and find the voice client https://github.com/Just-Some-Bots/MusicBot/blob/master/musicbot/bot.py#L384 to look pretty sensible. Voice bridging might not be as hard as we seem to think, but of course the design we are talking here regarding Jitsi's involvement (because I was at first only interested in discord<->discord, but this is a matrix bridge, so this makes sense) makes the stack more complex (I am currently of the mind that it's worth it because in discord it will be hard/impossible-->[because no puppets allowed in discord, surely] to show identities of the speaker visually but the voice client emitting transmissions originating from within discord knows who is who and thus relays those to the jitsi component which can vivify "ghost users" in an active call or room and that could be okay if the security model here is similar to the puppet-series of bridges where the homeserver is isolated and really is just a launchpad for these things rather than for inviting other people who might also use bridging features as that just confuses the hell out of me). Assuming nobody has started this by then, I may look into it after redeploying all the components again as it's been a couple years for me since I've operated synapse. It probably makes sense to hack out a minimalist proof of concept of what I'm describing above and then show it to Half-Shot rather than to try to mix the feature in. Yes, I now see why Half-Shot has it labelled as hard; the PoC itself isn't hard but making things consistently making sense and secure from each platform certainly is. Did you have any joy with it in the end? — Reply to this email directly, view it on GitHub <#149 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABKZSOR7GALQNIWKOS6K4DYCFA65AVCNFSM4FC2GKR2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZYG43TQOJUGY2A . You are receiving this because you commented.Message ID: @.>

No problem!

Just having a look at this at the moment. There are open source bridges for Discord to get it running in TeamSpeak and Mumble, so it obviously must be viable, just a case of figuring out doing it for Matrix.