If I’m not mistaken, Reflector is the kind of the tool that picks mirrors based on different aspects, not just by which is fastest or close by. And if my memory serves me right, it actually picks mirrors based on their sync date with the upstream rather than speed by default.

You might want to check your configuration and set it to prioritize the mirrors based on the aspects you want.

Huh, on my Arch PC there’s no even a request to accept the invite link within the browser, as long as I have any (mine, official) Discord client opened (i.e. browser does just redirect me to the opened client in order to proceed), with the closed client though there’s a request to log in and with that I can accept the invite link within the browser. So again, no XDG or custom protocols are involved for me. So really I have no clue how you’re doing this.

I should be saying that I use Firefox and X11 for testing, but I’m more than sure that whenever I would use Wayland or X11 it won’t matter, webpage shouldn’t have a way to detect this and behave differently. So I have no clue how to even trigger Discord to use their protocol over WS without setting up anything extra. I’ve been also using the discord package as of the client.

Also from what I see with the steam, you can register the protocol with MIME and .desktop but discord does configure neither of these. So it doesn’t seem like this would be a thing anymore, but again I might be mistaken or maybe Arch packagers don’t want from Discord to register their protocol, I dunno.

Sorry if these are dumb questions.

Nah it’s fine, for me these might occur dump for a reason I’ve been into development around the Discord for a while and actually partially reimplemented their WS/IPC handling a bit for my own use within Node.js (I mean it’s FOSS so anyone could technically use it as well).

So what does that mean for trying to open links from browser in discord desktop app? Its a trivial thing, but it would be nice to have it.

That, as long as Discord or any site running within the browser can connect to the local ports on your computer (I believe Discord should use ports within the range 6463-6472), via the WebSocket API in JS, the one could send an invite link request directly to the Discord or even for other stuff like RPC or page redirection – this works by Discord in the browser doing a check for any Discord client opened and just communicating with it directly if found via locally-executed JS. So there should be no XDG involved in the process and there’s no need to configure Discord in order to handle links, at least if you open links like https://discord.gg/[code] in the browser.

Do you mean in the context of discord? Like you haven’t encountered many sites using discord for links that lead to discord, or in general. Do most sites use https for their invite links?

I just haven’t seen any of the use for their own protocol and honestly I couldn’t find the docs either for that once I was dealing with the implementation of the URL handling. However, if you’ve noticed like some people or pages using that instead, I would love to be proven wrong – I guess I could consider then working on that within my own client if it is worth it to implement it and their protocol is not something like the legacy implementation.

I don’t think XDG is really useful here, I’ve honestly haven’t met much use online of “discord:” protocol – I see more of regular “https:” links instead. As a dev around Discord clients, I know it rather uses a WebSocket server or maybe even Unix sockets as well for the 3rd party applications to communicate and share any info, including the invite code.

I guess this highly depends on package maintainers, Node already provides funding in package.json for much less invasive funding requests (and that can also be disabled) and you might also block executing the scripts during package instalation which are sometimes used for advertisement. I think this was a lot worse in days NPM didn’t support funding, especially for projects depending on a huge number of dependencies. But I’m not that old Node/JS dev to tell how things were back then in reality.