b1naryth1ef

We've put a lot of work into our clients and our backend to make sure the impact of being on 1 vs 100 guilds is negligible. It helps that most of the folks building Discord are power users in a bunch of servers (so we feel the pain of poorly optimized paths early). Generally if you don't look at a server often it shouldn't effect the performance of the app / bandwidth usage. I think we have some more blog posts in the works regarding some of these topics so look forward to those!

We won't have support initially but as a Linux user internally I'm definitely hoping to push for it, and I see no reason why it wouldn't get built!

Ah sorry I misunderstood you. We keep the original image around and provide different sizes for different platforms/resolutions/dpis/etc.

As mentioned in the post, one of our core product features is preventing your IP from being shared. Given that requirement, images shared in chat have to be proxied through our infrastructure. When doing this we save a lot of money and improve client performance by reducing image sizes.

vips (Go binding) is included in the benchmarks mentioned in the post, but at the time of running them (~10 months ago) vips pulled 51482954 ns/op on a 1024x1024 test image, where as pillow-simd managed 3324135.3035 ns/op.

GCP has a virtual networking stack to support a bunch of crazy (and awesome) features Google has built. Unfortunately the complexity here seems to hurt power-users like us. In this case it appears that for some unknown reason the node failed to program its network stack when coming up, meaning it was completely unavailable (even the metadata service used internally by google failed).

Yup this, our privacy policy plainly states that we're not in the business of making money from your data. We have various provisions which limit how and when we can share your data.

Thanks, we try our best with these. Past experience has shown they can be very valuable, and help everyone at the company get context on the system and how we handle failures.

Reliability testing is definitely something we're interested in as we spin up more SRE/reliability focused individuals, but also has probably the least amount of cost-benefit for us (compared to engineering effort on improving the things we know need work). Some of the failure in the system we experienced is related to issues we know about, but haven't prioritized (read; had time for) yet.

For the library, we believe the bug is related to hackney and the fact it uses the high priority setting for its pool process. For some reason (this is the part we're not entirely sure on, and still spending some time investigating) this high priority process got stuck and consumed all of the scheduler time (presumably related to the earlier API degradation), breaking the distribution port and the application in a weird way. Oddly enough the systems we run on are SMP, so in theory one rogue process should not be able to have this effect.

Ahhhh, thats actually something we're aware of. Currently direct calls run on an entirely separate set of metals vs. everything else (this was mostly to help us test/measure video & screenshare rollout). Unfortunately some providers seem to be having issues with DDoS filtering over-triggering when they see video traffic, which negatively impacts the whole server. Something we're hopefully fixing in the short term!

Very possible you saw a slight interruption around 11:30PST for around 10 minutes until we found and decommissioned the host that experienced this problem. We generally don't update status until we can verify impact/source, we see tons of limited outages from ISPs misbehaving.

Can you give more explicit examples of the bad audio quality you experience? I'd be happy to forward this onto our native team to look into if there are some concrete things they can look at. Generally 99% of the audio issues we see people experience are due to ISP/peering/DDoS/etc issues, most of which are handled automatically by our servers within a few minutes.

Bad and hard to grok code can be created in any language. Even more-so in languages that have more syntax complexity than C.

(Discord Dev here)

Hey Alex, this definitely sounds like a miss on our part, so apologies.

As you know, we're fans of uws and not including the original license was a screw-up in our automation. We're working on fixing it and immediately releasing it with the proper license. I've also asked support to follow up with you directly in case there are further issues.

For the contact, either opening an issue on one of our repos or emailing our legal team (abuse@discordapp.com) would have been guaranteed to get you an accurate response. Unfortunately the verbiage you used in the email is very similar to that used in other support tickets we get for our API, and our team (as they did in your case) forwards users on to our API chat which can provide more in-depth/advanced support.

Discord desktop is electron. Only our iOS app is react native. We spend quite a lot of time and effort optimizing performance however, something thats required given the number of large servers with many thousands of concurrent users.

fwiw, here is our postmortem from the incident: https://status.discordapp.com/incidents/dj3l6lw926kl

No worries, thanks for the response anyway!

Coming from a company that regularly goes down to DDoS attacks :thinking:

Mind emailing me some details? az@discordapp

The point of our service is that chat is persistent. You can scroll back through time and read all the messages you sent. Users are free to delete whatever they sent whenever if they wish, but for almost everyone persistent chat history is a huge feature. Also important to note that as of the numbers we released last July we receive around 40 million messages a day. The public stats released about iMessage suggest that 2 billion messages are sent per day.

Our realtime messaging is done over Websockets using either JSON (for web/non-native) or ETF (http://erlang.org/doc/apps/erts/erl_ext_dist.html). Almost all user-based actions are sent over our HTTP API using JSON.

- E2E/OTR encryption is something some of us are interested in, but due to the nature of our platform probably isn't going to happen anytime soon (we'd want to do it right, which requires time and effort).

- Some libraries support connecting through user accounts, and there are various third-party tools for "linking" chat rooms, incl. some client plugins for irssi and such. We don't officially support it, but it's definitely possible.

- Search is currently live on our alpha-testing client, and should be rolling out globally soon. It's also possible to save or log channels through the API fairly easily.

We've adamantly stated many a time that we will never sell users data, or put ads in the app.

What features in particular? The most common one we hear is search, which is actually implemented and undergoing internal testing before a public preview soon.

Yup. We (discordapp) had to manually spin up our own stuff to route around the issue. Not great communication from Google on this one, status page update took ~20 minutes.

Drop me a line (andrei @ discordapp.com) and I'll at least take a look.

(Discord Dev here) Awesome to hear Discords a good fit for workplace environments too, we've heard a couple success stories around remote teams swapping. Search is a huge priority for us, but its also something we wanna spend time getting right. e.g. soon!

The best way to do this right now is to "mute" channels by clicking the bell icon on the right of the channel header (or opening the server notification settings, or right-clicking the channel name). You can then easily hide all muted channels, providing a good way to get a condensed or filtered view of large servers.

They don't.

I would imagine they don't use it for exactly that case. Imagine a case where most of AWS is having critical problems, you would want (at the very least) control of your DNS to attempt a partial recovery of service for some portion of your customers that have providers who respect DNS TTL's.

This just sounds like whining about having to write an implementation from scratch.