Vencord integration

[Uneccessary]

Description

I'm always frustated using Discord as it is.. and Vencord just makes it it better, it has a lot of useful plugins (also for privacy), it's privacy friendly, it's opensource it has a browser extension for Webversion and also userccript, it support cloud sync which you also can selfhost and a lot more cool stuff :3

Suggestions

A optional setting for Webcord itself to enable Vencord integration (which could be done by installing the Vencord Extension in the Background for example)

Alternatives

No response

Additional Context

https://vencord.dev/

[dreamsyntax]

Just my opinion, but that would defeat the purpose of this project. WebCord already provides you with the same feature set of "for privacy" - blocking the same telemetry their client does.

You can use that project with the official discord client. Not to mention, many of the functionalities it provides would not work given the dependencies discord has vs webcord. It doesn't really make sense to have it apply to this project.

It would also probably lead to plugin bug reports from users on webcord vs their supported client. A headache for everyone working on either project.

[Janrupf]

I don't necessarily think this would defeat the purpose of this project.

My perspective on the situation is that WebCord provides me a usable Discord client on Wayland and generally fixes a lot of the quirks the official client has. For me personally it would still be interesting to inject stuff into the client, since WebCord doesn't touch Discord's UI (nor is it a goal of WebCord).

Generally speaking, modifying the Discord UI is not something WebCord does or wants to do, but it could still provide you with the tools to do so. This would also be interesting to for example get RPC working using arrpc. The probably most simple way would be to provide a folder in which the user can place additional preload scripts which then could do the required setup for stuff like Vencord.

[SpacingBat3]

Agree with @dreamsyntax in some ways, plus there's also a reason that WebCord implements stuff (like CSS theming) in different ways, that are specifically designed not to change anything that could indicate you're using WebCord or not (which personally makes it better IMO and be more consistent with the current vision of the project, yet with some quirks like some CSS themes being broken). Also I'd hate to integrate with any specific project for mods and indeed, there are people that even seem right now to report the problems with mods that were integrated unoffically with WebCord, causing only the confusion (since they speak about the features in the client I haven't implemented). Also I disapprove a lot of mod designs, since they usually gain a lot of permissions over the client, which means one people going mad to be enough for controversy to happen. This (almost) happened in the past with the Node dependencies, I'm aware of happening that the second time.

And the fact of instability around the Chrome extensions and even the lack of permission management or verification around there in Electron is another thing why I'm kinda against continuing any work around it, in fact I'm more into client's extensibility over JS scripts run with limited permissions and API access with some kind of hard-coded read-only dir that could be accessed only by system administrator and should not allow modifications by non-admin processes, but that possibility is very limited to Linux (since I suppose currently most Windows and macOS users install WebCord in user-writtable locations, already allowing for any program running in their context or as admin/system to do whatever they want with the client and its modding). But even that thing would be a bit problematic to implement, e.g. in terms of choosing the context or actually deciding if this solution is good enough to be secure enough.

So yeah, you can see a bit that extensions kinda collide with WebCord's view on the security - I don't want for anyone but user to customize the client in a way it disables some securities or puts him at risk of some malicious activity within the client. Or at least, I'm working hard on limiting that factor... And the vision about the WebCord giving some control over how client works to user or aiming to become the actual privacy-focused client rather than focusing on yet another client that is special from Discord in way it offers mods - ArmCord has that vision, I suppose. I've also kinda inspired on Caprine when designing WebCord, at least what's good of it and also by looking onto its design before Facebook/Meta broke it (I don't think Caprine is right now as great client as it was in the past, at least the last time I've used it not all features were backported for the current Messenger webpage). And yes, Caprine obviously did not support modding, any kind of JS injection other than with DevTools or tweaks other than themes.

[SpacingBat3]

Anyway, as pointed out, I do not plan integrating with any specific mod implementation. Extending the client by your own scripts, making it easier to bundle the code at build time or any WebCord-specific extension implementation is a different thing and definitely outside of this issue's topic. Therefore I'll close this feature request.