Let's Reverse Engineer Discord • Hacker News Board

Re: Let's Reverse Engineer Discord

#101

Post by dyeje » Mon, Jan 13, 2020, 5:53 PM UTC

krige wrote: post #37

dyeje wrote: post #22

Earlier quoted context omitted.

Discord trying to take on Epic and Steam to create a marketplace was perhaps the worst move I've seen in the past few years. Steam is entrenched and Epic is printing money. Discord needs to capitalize on its greatest asset: a massive community. To me, the obvious path forward is doing Patreon like features for servers and perhaps trying to break into the streaming market.

When Discord was making that move, Epic store did not exist, the period when both stores existed was rather short and unevnentful, discord's being on clear decline, epic's not even bare bones and tossing money on any and all early access games in sight.

They were announced within months of each other [1][2]. That means both companies were planning their stores at the same time. I find it hard to believe Discord did not have any idea about Epic's store, considering they were simultaneously raising a funding round and talking to VCs about their plans (who you would think would be aware of Epic's move). I suppose it's possible Epic played their cards close to the chest though.

[1] Discord Announcement https://blog.discordapp.com/the-discord-store-beta-9a35596fd...

[2] Epic Announcement https://www.unrealengine.com/en-US/blog/announcing-the-epic-...

Re: Let's Reverse Engineer Discord

#102

Post by jagger27 » Mon, Jan 13, 2020, 5:54 PM UTC

franga2000 wrote: post #21

coenhyde wrote: post #14

I don't think Discord makes any claims that the audio is P2P encrypted. There are legitimate reasons why Discord might be dropping malformed packets, apart from an indication that they are spying on you (they may be doing that too). 1) to improve audio quality. 2) to help prevent RCE attacks on the destination client. 3) re-encoding at lower bitrates for low bandwidth clients. I don't really see the issue here unless…

3) is most certainly at play here, as Discord allows clients to set their preferred bitrate (RX&TX), which would not be possible in multi-party calls without re-encoding.

Wouldn’t it be possible to send a stream cipher encrypted packet of audio to a hub server where the codec has a “progressive” decoding mode? If I’m not mistaken, Opus can already do something like this. That way a client could set their desired bitrate and the server would truncate the packets before passing them off and doesn’t need to be re-encoded. This only works with a stream cipher though.

Maybe an audio engineer or cryptographer could chime in?

Re: Let's Reverse Engineer Discord

#103

Post by superkuh » Mon, Jan 13, 2020, 5:54 PM UTC

csunbird wrote: post #61

jokoon wrote: post #54

Wasn't skype originally P2P? I wish there was a simple windows voip client that was doing p2p voip. I often experience cuts with skype and discord, I think their servers can have a hard time handling low latency properly.

It was and because of that a lot of people were hacked, since skype could be used to run remote code by leveraging a couple of bugs existed in skype application. That is one of two reasons why Microsoft switched to server-client model instead of p2p connection. Other being having control of the service and with call and message history makes more money of course.

That is an interesting perception of history. What it looked like legally was p2p was working great and skype was massively rising in popularity. But the US federal government could not stand encrypted peer to peer communications. So they told their good friends over at eBay to buy the company. eBay messed it up and only bought the license for the name and not the actual code and p2p backend. Things continued working well for a while. But the feds still weren't happy. So they had their other friends at Microsoft actually purchase the technology and then immediately destroy it and switch to a centralized model.

You can read the story at: https://arstechnica.com/information-technology/2018/09/skype...

>For the second time, Zennström and Friis cashed in on selling Skype. That's because, instead of giving eBay the critical base technology that kept Skype going (the P2P system known as "Global Index"), Zennström's and Friis's company Joltid still owned it—they simply licensed it to Skype. The whole situation devolved into threats of litigation until a 2009 settlement gave Zennström and Friis a chunk of Skype ownership, which made them even more money when Microsoft bought the company.

Re: Let's Reverse Engineer Discord

#104

Post by dyeje » Mon, Jan 13, 2020, 5:59 PM UTC

joshschreuder wrote: post #28

dyeje wrote: post #22

Earlier quoted context omitted.

Discord trying to take on Epic and Steam to create a marketplace was perhaps the worst move I've seen in the past few years. Steam is entrenched and Epic is printing money. Discord needs to capitalize on its greatest asset: a massive community. To me, the obvious path forward is doing Patreon like features for servers and perhaps trying to break into the streaming market.

They have added more streaming features in recent months, so perhaps this is their pivot. Their idea of patrons is boosting servers for perks which is sort of similar but the price of boosting is far higher than Patreon sponsorship and there's no way afaik for servers to customise what the booster gets as reward (the whole server gets the reward)

I have noticed them pushing the streaming features, and I think it's a brilliant play. Cut Twitch out of the equation entirely, stream and monetize your community directly in Discord. I think it's also interesting in that Discord servers can be private so you open up the possibility of allowing content that Twitch shuns due to its public broadcast nature (e.g. adult content).

Re: Let's Reverse Engineer Discord

#105

Post by chrisan » Mon, Jan 13, 2020, 6:16 PM UTC

gzer0 wrote: post #100

gfodor wrote: post #83

Earlier quoted context omitted.

No, it’s not, because PERC is a proposal and is not implemented in any browsers.

That does not mean it isn't possible; the implementation simply has not occurred.

> That does not mean it isn't possible; the implementation simply has not occurred.

You can say that about almost anything.

The question is: is it possible today where it has an impact today in actual browsers today.

Future technology does not matter when there is no implementation

Re: Let's Reverse Engineer Discord

#106

Post by caffeinewriter » Mon, Jan 13, 2020, 6:50 PM UTC

jagger27 wrote: post #102

franga2000 wrote: post #21

Earlier quoted context omitted.

3) is most certainly at play here, as Discord allows clients to set their preferred bitrate (RX&TX), which would not be possible in multi-party calls without re-encoding.

Wouldn’t it be possible to send a stream cipher encrypted packet of audio to a hub server where the codec has a “progressive” decoding mode? If I’m not mistaken, Opus can already do something like this. That way a client could set their desired bitrate and the server would truncate the packets before passing them off and doesn’t need to be re-encoded. This only works with a stream cipher though. Maybe an audio engine…

It looks like Ogg Vorbis has theoretical support in the spec for something called "Bitrate Peeling"[1], but there is no functional implementation for this yet, and there's been an open bounty on it since 2004.[2]

This is a really neat idea though. Truncating the packet to change the bitrate per client without re-encoding.

[1]: https://en.wikipedia.org/wiki/Bitrate_peeling

[2]: https://wiki.xiph.org/index.php?title=Bounties&diff=196&oldi...

Re: Let's Reverse Engineer Discord

#107

Post by caffeinewriter » Mon, Jan 13, 2020, 6:51 PM UTC

ollien wrote: post #91

duskwuff wrote: post #40

Earlier quoted context omitted.

Keep in mind that a major use case for Discord is open voice chats (e.g, for gaming groups), not just organized person-to-person calls. Having the quality for a whole chat drop just because someone joined from a mobile phone would be a really disappointing user experience.

This is absolutely something that Discord does, though. I've had friends just drop the bitrate slider as low as possible in Discord just to make the whole channel sound awful

That's a channel-specific option though. You can set per-channel bitrate, but it's not something Discord does automatically to accommodate lower throughput clients.

Re: Let's Reverse Engineer Discord

#108

Post by holtalanm » Mon, Jan 13, 2020, 6:53 PM UTC

meowface wrote: post #82

numlock86 wrote: post #34

Earlier quoted context omitted.

Bring up Microsoft Teams maybe.

Teams is pretty good (and I suspect partly ripped off from Discord), but I don't believe it has the casual voice channel feature the parent wanted. You still have to manually initiate calls, like with Skype.

-> Teams is pretty good (and I suspect partly ripped off from Discord)

I think Teams is much closer to a Slack ripoff than a Discord ripoff.

Re: Let's Reverse Engineer Discord

#109

Post by ryukafalz » Mon, Jan 13, 2020, 7:12 PM UTC

Arathorn wrote: post #97

fwiw, the approach we're looking at in Matrix is to have E2E-encrypted SFUs, as per https://github.com/matrix-org/matrix-doc/blob/matthew/msc235...

This is exciting! I like Jitsi in general, but I would much prefer native conferencing.

Do you know if there are plans to support Discord-style persistent voice rooms?

Re: Let's Reverse Engineer Discord

#110

Post by meowface » Mon, Jan 13, 2020, 7:22 PM UTC

holtalanm wrote: post #108

meowface wrote: post #82

Earlier quoted context omitted.

Teams is pretty good (and I suspect partly ripped off from Discord), but I don't believe it has the casual voice channel feature the parent wanted. You still have to manually initiate calls, like with Skype.

-> Teams is pretty good (and I suspect partly ripped off from Discord) I think Teams is much closer to a Slack ripoff than a Discord ripoff.

True. I think it might take inspiration from both, though.