discord.js-selfbot no longer maintained. migrate to python selfbot?

[SendToNull]

Not sure if you saw this, but the author of the discord.js-selfbot project is no longer maintaining it aiko-chan-ai/discord.js-selfbot-v13#1743.

I was curious what your plans moving forward are. As stated in their post, discord rarely makes any breaking changes so this should be good to use for quite some time, but I imagine at some point there will be a change that breaks some functionality.

[longnguyen2004]

As you're probably aware, this library is written in JavaScript, while discord.py-self is in Python. Adapting this to Python is probably possible, but would take a great amount of effort that I don't have on hand. I also don't have much experience in Python compared to JavaScript, so even if I set out to rewrite this library in Python, it won't have the same quality as the original JavaScript version.

If things get bad enough and this library doesn't work anymore, then maybe I'll look at rewriting it in Python. No guarantee that it'll be done though.

[dolfies]

dpy-self maintainer here 👋

I've been watching this project for a while and it's very cool :D

If / when the time to switch comes, if y'all are interested, I'd be more than happy to work together on first-class support for some of the video stuff directly in the lib. Currently all that's supported is sending voice packets, same as dpy. I've expanded on voice documentation here, but as you can probably tell it's woefully incomplete...

[aiko-chan-ai]

The djs sb library won't break for a long time, but I'll probably make a new selfbot port if djs gets a complete TypeScript rewrite. I'd love to support this library natively, but the old djs architecture is quite complicated for that.
Btw, Happy LNY 🔥

[longnguyen2004]

Hello, I'd be happy to port this over to Python if needed. However, I'd advise against fully integrating this library into either djs-self or dpy-self. The bulk of this library is in the media handling part (processing AV packets, maintaining AV sync, ffmpeg settings, etc.), not the signaling part, and it's in a constant state of flux. Having everything integrated would mean that I wouldn't be able to push updates and tweaks as often as I want to.

What I'd like to see is moving the signaling part into the main library (so starting and managing the Go Live stream can live within the main library), and the media handling part with all its gory details can live in a separate library and be more frequently updated. Not sure yet on where the packetizers should live though, or whether we should rip out everything and use aiortc or libdatachannel-py instead, but we'll deal with it when we get there. For now, this library works fine enough.

(made another wall of text, hope you don't mind 😅)

[dolfies]

Yeah, fully integrating everything would probably not be the best option, though the d.py voice impl does already have harnesses for managing stuff like ffmpeg settings as it has multiple included first-party source implementations (though none of this is written by me, it's all from upstream d.py :p). it's all designed to be very extensible and configurable, and if we were to build on it I'd like the API to stay the same so actual video feed processing can be done by users (e.g. using a project like this). "Batteries included" first-party impls are nice but not a necessity at all

happy LNY :)

[M7mdxzxa]

Looking at this i rememberd that there was an python discord video stream project called strawberry, not sure if that would help but here it is: https://github.com/justfoolingaround/strawberry