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!
Well, are you ever going to provide a better way to deal with 10+ servers? The left-side server UI is terrible. The icons aren't enough to figure out which server is what and it desperately needs some form of sorting or categorizing (being able to create custom groups of servers, for example per game or any arbitrary list of servers). I end up continuously pruning my list so I don't have more than 10 because it's so bad.
WoW alone forces me to have 1 server per class, then 1 server for every guild I'm associated with. Forget about any other game.
No need to be so rude and entitled about it. Especially considering you're probably not paying for the resources you're consuming. Even if you are, it's rude.
I bet it's on their todo list to handle that use case and no doubt there are other priorities.
It's been years without any improvement at all. So yeah, I'm annoyed. I'd even be happy to give them money monthly, but the apparent priority of this issue is at the bottom of their list, if it's on there at all.
If a guild is completely muted (including @everyone), and I don't open it, do you have a rough estimate of how much resources it uses? In theory, it should be zero, but in practice, does is the server sending me updates about messages even if I'm muted?
It depends on the activity of the server. But generally, you're only receiving message create events and updates to the server. But you aren't receiving things like member list updates, presence or typing events from the server until you focus it initially.
Additionally, we unsubscribe you from these events if you unfocus the server for a given amount of time.
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.
You should seriously consider doing this for your mobile client; the worst thing about Discord is that it eats mobile data if you're uploading lots of images.
Data aside, my phone takes pictures at ridiculously high resolutions. Whenever I go to send pictures with discord, it takes a good 30 seconds and half the time it'll just break.
As an aside, I wish the "share" button would share a lower resolution image instead. I don't mind storing the full quality picture, but handling a 10mb image is seriously silly.
The other side of this is if you're on mobile data and they decide to resize the images on the client then people will complain about the app eating up battery life because it's using so much CPU to resize the images. Plus, they won't have the full size image to share with people you may be chatting with on desktop. If you want to not use so much data while uploading images then you should probably resize them yourself or just not upload images unless you're on wifi.
There's no reason this couldn't be a two-step process, resizing to something reasonable on the client then fine-tuning it on the server. I'm presuming you don't see the need to start with multi-megapixel images.
> I'm presuming you don't see the need to start with multi-megapixel images.
Might be a fair presumption today, but might not be for the future with hiDPI screens, VR etc... for the relative storage costs, it'd be better to have the original, and then you can programmatically run from there.
Today's hiDPI screens can already display more detail than your eye can perceive. The issue wasn't about storage costs, it was about transmission costs which still matter for the foreseeable future.
Perhaps, but I think you can compress current-day phone images considerably without losing any actual image fidelity (because the sensor pitch significantly exceeds the lens resolution, and .. noise).
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.
That is indeed very odd! Thank you for sharing. Hackney, through another library, is used in a telegram api wrapper that I wrote up. Though my stuff usually runs on a $5 vps, nothing with multiple cores.
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.
Anecdotal, but direct calls are pretty unusable for me. I'm on the west coast, and when I attempt calls to the east cost, it frequently cuts out. The workaround was just creating a server and using a voice room in it. This had drastically higher call quality. I assume this is ISP/Peering related, but to see such a night and day difference between voice channels and direct calls leads me to believe that there's something that can be done on your end.
Complaints aside, I love the service. Echoing what avree said, long term monetization worries me. I would like to see discord survive, but its story looks similar to Trello right now in terms of monetization.
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!
I've been using voice calls regularly, and it's occasionally been problematic. Yesterday it was behaving as though it had absolutely insane packet loss (occasional robotic sounding fragments would make it through, otherwise the line was dead) without any indication of high jitter or packet loss - I had to resort to stupid workarounds to get it working. Move convo to a server -> change server to Central from West (why can't this be done for regular calls!) -> instantly working perfectly.
FWIW, it generally works pretty well, and overall, Discord is a fantastic product that I'm happy to be using.
FWIW, a serious feature that I would pay you money for right-here-right-now is the ability to multitrack audio. Let me give you many dollars to route each voice to a separate Soundflower channel, so that I can mix them outside of Discord, and I will give you said monies. I'm pretty sure you're even sending unmixed streams down? But I can't get at them!
This probably involves not being Electron (from my own adventures in the area), so I don't hold out much hope, but it keeps Discord from replacing Extremely Expensive And Bad solutions like SkypeTX for me.
The first thing I was thinking is using PulseAudio somehow. It has some bad image issues but its swiss-knife-of-audio-routing chops are undeniably present. It's Linux only though, so probably wouldn't be useful here.
I'm trying to figure out what the actual context in question is, particularly in terms of technical connectivity. Is this being used for remote DJing? Or conferencing? Or an audio recording situation?
If you're prepared to throw money at the situation, it's possible this may be fixable with a simple bespoke solution. I say "possible" because, unfortunately, I just did some digging and found https://bugs.chromium.org/p/chromium/issues/detail?id=453876:
> Unfortunately we don't support multi-channel > 2 nor multiple devices at the moment.
> ...
> Are there any future plans to support these two features? Is this a w3c issue or a Chrome issue?
> ...
> I am quite skeptical about this; I was told this requires a huge change in our WebRTC-side infrastructure, but I am not sure what the current status is.
> The spec indicates getUserMedia can be configured with 'channel count', so I assume this is Chrome issue.
That immediately nukes WebRTC :(
Could make for a fun project. I'm very fascinated with audio handling myself and this sounds interesting, but I'm unsure I'd personally have the skills (or mental stamina/attention span :< ) to be sure I could follow through. I'm also only on a Linux box, which brings up the platform-native problem.
It's fine - you actually saw it, which is cool :) some of my other past replies have gone completely unnoticed
I see. I get the impression this is collaborative podcasting with multiple people that have multiple microphones. (I can't figure out why else you'd need multichannel A+V transport.) FWIW, it does sound like Skype is probably your best bet for the time being (unfortunately). It's simple, it works for everyone, etc.
Occasionally we notice the robotic voices when service has really degraded. But when it's operating normally, it seems like mumble sounds better.
It's also annoying having to adjust each users volume slider individually, I wish Discord would just do that automatically and normalize the levels of everybody.
The point of capability-secure design is that it's possible to prove that a chunk of code, regardless of its nastiness, cannot take certain actions.
In particular, in this case, it sounds like the offending code:
* Makes outgoing connections with sockets
* Alters the flow of execution outside its scope
Both of these flaws can be mitigated if the ability to do these things is closely-held and not available to all code.
It's true that object-capability languages like E, Monte, Pony, etc. cannot stop you from writing bad code. But they can automatically prove that your code only is as bad as it appears to be, and not any worse via skulduggery.
This code is running on a dedicated Zynq SoC on the miner, where it's treated more as "firmware". Any capability based system running on this SoC would be designed by Bitmain, so they could just backdoor it as well. In addition, the software is required to make outgoing connections, for the stratum mining protocol.
Hard to grok was probably one of the main requirements in this case, so this whole sidebar doesn't mean much in this context. The writer of this code has no interest in safe or lucid.
