Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's Reverse Engineer Discord

medium.com

Post reply on HN
Print view View original

91–100 of 115 posts

Re: Let's Reverse Engineer Discord

#91

Post by ollien »

duskwuff wrote: post #40
FractalParadigm wrote: post #24

Earlier quoted context omitted.

Could they not just drop the quality of the whole call down to the lowest bandwidth allowed by a user? I feel that would reduce a computational burden on Discord's end, while allowing the lowest client-to-client latency

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

Re: Let's Reverse Engineer Discord

#92

Post by dubcanada »

tyingq wrote: post #70
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…

There's this: https://twitter.com/discordapp/status/857339272231309312

That's from 2017, it is entirely possible that was true in 2017 but not now.

Re: Let's Reverse Engineer Discord

#93

Post by smolder »

mapcars wrote: post #39
Animats wrote: post #26

Discord privacy policy: In an ongoing effort to better understand and serve the users of the Services, we may conduct research on our customer demographics, interests and behavior based on the information collected. This research may be compiled and analyzed on an aggregate basis, and we may share this aggregate data with our affiliates, agents and business partners. We may also disclose aggregated user statistics in…

Is discord known to be used in corporate sector? I think so far it's dominated by Slack and Discord is mostly used by games/communities.

I know political campaigns are using it... foolishly, I'd say.

Re: Let's Reverse Engineer Discord

#94

Post by heydabop »

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.

> Discord allows clients to set their preferred bitrate (RX&TX)

Where? All I see is setting bitrates on channels, but not on the client/app as a whole.

Re: Let's Reverse Engineer Discord

#95

Post by heydabop »

rasz wrote: post #65
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 tens of megahertz of one CPU core per re-encode, clearly out of the question with todays norm being ~ 4GHz 8 core CPUs, that or they are spyi^^^ recording everything for 'metrics/analytics'.

CPU time is irrelevant for re-encoding due to bandwidth reasons though. If a client requests 64kbps voice, sending it packets at 128kbps and letting it re-encode once it has them is pointless.

Re: Let's Reverse Engineer Discord

#96

Post by atesti »

ihuman wrote: post #86
atesti wrote: post #71

The article links to https://github.com/tenable/DiscordClient but this has been deleted. Does someone have a mirror?

I'm confused. The link in your comment leads to a live repo.

It's working for me, too. When I wrote my comment, there was just a 404. Maybe it was restored?

Re: Let's Reverse Engineer Discord

#98

Post by uncle_j »

munmaek wrote: post #79
rawfan wrote: post #75

Earlier quoted context omitted.

I actually know many opensource projects that moved from the clunkyness of Slack to Discord. In all fairness, though, the recent releases of Slack made it pretty snappy.

My 70 kb/s connection disagrees. I was barely able to get slack to load, when it did load.

I work in an office with poor reception and it is quite annoying that these apps don't really work unless you are on 3G or better.

Re: Let's Reverse Engineer Discord

#99

Post by CoolGuySteve »

SamuelAdams wrote: post #84
CoolGuySteve wrote: post #31

Earlier quoted context omitted.

Yeah my company has the worst time with Skype, but nobody takes you seriously if you mention Discord even though it’s much more reliable and has more features.

What enterprise support plans exist for Discord? Is there a support person you can call if something goes down during a business-critical timeframe? Can HR or other staff access chat logs of their employees? If so, how far back do the chat logs go? A day? A month? Forever? How long will it take to train staff on using this software? Some people get really freaked out by a new UI - they don't think about what they're…

Good thing we're not an enterprise.

Sounds like you just manufactured a bunch of problems for yourself with no benefit. Talk about an enterprise state of mind.

Re: Let's Reverse Engineer Discord

#100

Post by gzer0 »

gfodor wrote: post #83
gzer0 wrote: post #52

Earlier quoted context omitted.

End to end encryption in WebRTC is indeed possible even if you are using an SFU, this is achieved via Privacy Enhanced RTP Conferencing (PERC). [1]. https://www.callstats.io/blog/2018/06/01/examining-srtp-doub...

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.
Post reply on HN