Why did we make the decision to wipe our main chat room? Are we crazy?! (a bit, probably...)
If you are reading this, you are probably aware that we "rebranded" our server here at Discord and changed the name to EC || Bot & Dev || General with a few minor
internal changes. This was announced in this channel more than a month ago in the first week of April, and (as mentioned in that post), it was already a bit late. We were already really focusing towards that and the post made it official.
We've been doing a lot of work outside-the-scenes and only a few members here that are involved directly know the details, but we're working on some cool things. One of the goals of this server is to look at, play around, and experiment with other collaborators and the best-in-class software(s) to get really awesome designs to an even higher standard. We aren't a big server by any means, but every Bot is carefully picked, studied, tested in a secondary server we use for internal matters/development stuff, and then pushed here.
Our MusicBot section, for example, contains all types of Bots within several Discord libraries, and that's the point! For MusicBots, LavaPlayer (made in Java) is miles ahead of anything else as it is built for the task, so the Java-based MusicBots are some of the best out there in comparison. This is just due to the amazing work of Sed @ LavaPlayer and the guys/gals who really push JDA - the Java Discord API (which we use) - and keep it up-to-date (faster) than any other library. Combine this with LavaPlayer and it results in those bots having significant advantages.
Still, we have 4 LavaPlayer/JDA bots: .AnotherMusicBot, .Music [ ! ], .MusicAI, and .MusicFB [;;] are all in this category. They are customized forks of MusicBots - and are all open source. If they are all the same library, why four? The answer is simple! Each of the bots has at least one feature we consider to be unique and/or important to it, and our goal is to take the best from bots and make things even better. We will go over the details below.
First up is JavaMusicBot made by ducc, who operates the bot under duccBot. Our fork of it - .AnotherMusicBot - is a very well made MusicBot. It has a command to reorder songs in a queue, say moving a song from position 12 to 1, etc. This (personally) is a very important feature. It also has a radio "directory" to quickly load curated radio stations.
.Music [ ! ] was the first LavaPlayer bot that I used, and it remains the "simplest" of the four here. But, don't let that fool you, as it is very well made. It is extremely lightweight and designed for self-hosting, which results in a two minute literal setup and ease of usage. As any LavaPlayer bot, it works with a TON of sources including local files, YouTube, SoundCloud, and more. It has a nice, modern paginated output for the queue, and was developed by jagrosh, who also made the Spectra moderation bot which we use for a heavy part of our moderation tasks. The bot is in the 24/7 channel and features loading playlists, which we have running on autoplay 24/7. It has the ability to stay in only one channel and have commands issued to it from only one text channel, so it is ideal for this.
.MusicFB [;;] is a fork of the infamous FredBoat, which is a very large (100K+ servers) MusicBot, the biggest dedicated MusicBot by far on Discord. This fork of it has several features, as well as "ignores" a lot of the heavy things that come with a bot of this magnitude. Because of the size of FredBoat's public / Patreon bots, the development is very focused (as it should) on scalability and has to follow a separate set of design standards (partially). If you aren't familiar with Sharding, Discord requires guilds >1500 in size (some leeway here to 2500) to use their Sharding system, which seperates each set into groups. If one shard goes down, you can restart or manage to balance the bot so all your users don't go offline. This is like load-balancing, and is very important for any bot of FredBoat's scale. As such, there are a lot of features we simply don't need, like strong localization for tons of languages, ShardManagers, several database implementations, a lot of extra administration tools and in-app updates, etc. These are super neat features though, and we use them as needed too. One of the BEST features of FredBoat is that the developers are very open to any idea, and as such it has some unique capability. The main one? Spotify support. Yes - it can play Spotify playlists. We've tested and tweaked it and it works fine for even LARGE 1,000+ track playlists. Continue reading below to find out more -
(cont'd) How does FredBoat get to work with Spotify? Well, it's simple...sort of ;) We can't play Spotify directly, but we can get the track on YouTube or SoundCloud. YouTube uses vp9/ogg and OPUS for about 70% of their videos, perhaps more now, and vp9/vorbis for another 10% or so. There is a small percent that still use things like AAC, but YouTube is actually majority outputted in the ogg container and OPUS format! This is great, because, well, Discord uses OPUS as the output codec! So we can avoid, if possible, re-encoding with something like ffmpeg and skip it all together, passing the direct source to Discord. This is what LavaPlayer was built on, and it results in massive performance in the right cases. What if you use .MP3? What if it's not OPUS? Not a problem! LavaPlayer still handles these well by using direct, low-level libraries in the project for codec's, bypassing ffmpeg. Now we get a free API key from Spotify and use that to read the playlist information. This is done within the Spotify API. After we get the tracks, we concurrently search YouTube and SoundCloud, giving preference to YouTube and then SoundCloud, before giving up and skipping the track if it's not on either (which isn't that common). We then dump the URL's and viola - we can play as normal. We can export with FredBoat and get the full playlist of URL's. It takes a few minutes for a 500+ queue playlist, but for most playlists (100 songs), it takes about 15 seconds. Simply ;;play
from Spotify, and the bot will do the rest. Besides Spotify, it has the same seeking and other features I'd expect, and is a great bot in the collection.
So what is .MusicAI? It's AIBot, a smaller but very well designed bot. It is open-source, but (as .AnotherMusicBot is) -- this is not "designed" foe easy self-hosting. No worries! With some tweaks and changes we are happy to have the bot in the collection. AIBot (or .MusicAI here) is more than just a MusicBot though. It has a lot of things like banning/moderation tools, a few fun commands. and a nice search-array. You can search things like IMDB, GitHub, Google, various Meme sources, Urban Dictionary, and Tenor/Giphy in one clip. It also has a VERY nice page output, that is 100% modern to Discord standards, if not ahead. It is beautiful and has all the utility right. It is missing one command, however, which is the move song command that I mentioned, so we're working on that right now! Otherwise, it has the same feel of the .AnotherMusicBot - just very well designed visually with the modern embed/pages/reaction-buttons. Neat!
STILL WITH ME?!
Now we leave the realm of Java/JDK/LavaPlayer. What is left? Well, our resident bot "Nebs" right now (it changes names, who knows!) - is the classic, almost infamous Python Music Bot that is the "standard" bot referenced by people. It was one of the first bots that was designed to be easy to setup for self-hosting but with some advanced stuff too, like playlist management, permission systems and roles, all configured in a file before startup. This makes it good for a lot of guilds. It uses youtube-dl to work with a TON, and I mean almost any source of playback. The bot uses ffmpeg like normal to encode and does not have a native OPUS followthrough, so there is that to keep in mind. However, there are no current alternatives to LavaPlayer right now directly, so it's moot to go on about that. However, youtube-dl gives a lot of flexibility in the output, and ffmpeg supports more codecs. We have a customized version here (as the parent branch of the bot is long overdue for an update; they are waiting for the release of a newer/major build of the Discord Python library that it is made in. This is a decent bot, but with the ease of something like jagrosh's bot for example, and made in LavaPlayer, it is not on the top of my choices. This was my first MusicBot (sort of, my first standalone one) - and it is the most mentioned one out there. Again, it is well documented and easy to customize. Also, many people like Python, so it bodes well. Personally, i am not a big fan of Python, but we have some added features to the bot (such as basic rewind and forward, seeking, reordering the queue command, and some random stuff like broadcasting messages to all users) -- these are cool, and it's good to diversify!
Last for now is .Spot, which isn't in the MusicBot section. This is Nadeko, yes (run!) - many HATE Nadeko, and it's widely regarded as garbage by most of the API community. The reasons for that are mixed, and the honest developers will agree that the major gripes are really that it doesn't follow the Discord.NET (C#) library, but rather uses a customized fork. Nadeko is a full-feature bot, and it has so many things that it can get very confusing. It doesn't have the most ideal design patterns, as it aims to be an all-in-one bot. For example, the prefixes are based in its SQLite database, and things like Music respond using different module prefixes. This is fine in single or small setups, but it is bad design practice generally to "hog" these prefixes as other bots tend to use them. They are also all common ones. Nadeko started using a custom fork of Discord.NET because, at the time, the C# library was not well progressed for Audio. It was therefore a modded version and the actual audio handling is done using an "in-house" buffer system with C# ActionQueue() and other methods. It does not follow any regularity with the Discord.NET library, which now supports the Audio implementation fine. I did not work on the modified version of Discord.NET, but having done a lot of updates to Nadeko (as this was my first ever MusicBot and my first bot when I actually made my guild) - I've done a lot to "fix" the issues and run a custom version of Nadeko. My goals with it are not to rewrite the Music logic, as I was going to do that before looking at LavaPlayer and realizing that this was not going to be comparable unless making a C# LavaPlayer-type backend. So, I simply optimized and fixed the bugs in the Music portion of Nadeko, and the result is that no one who has used the version I run has been able to crash it - which happened hourly for many users before. Any-who, the bot also has what I call "respect Discord's design policies" changes, or API compliance. I think it is important to understand that developers wish to have the most functionality, but they also put limits in for a reason. Things like rate limits, design practices, etc. are there to ensure that the API stays healthy and expandable. So, even if you disagree, that should be respected. As a result, I removed things like rotating role colors, and user-presence logs that show when a user goes offline, online, or idle/dnd. These kinds of things make Nadeko regarded as pretty bad in that community, but my aim is really to just have variety (and I'm used to it as a tool for other things, including heavily adding features - many which are pushed to the parent branch - in the Quote Commands. You can get in touch with me and I will link you to my GitHub fork where it is explained in a LOT of detail. The bot is always kept up-to-date with the parent branch. We remove the rotate role color feature as it is way, way too limited in expandability. This also results in the modular, SQLite-powered Nadeko to have logging only for one server, which I suspect is a consequence of having things like UserStatus presence updates. You can easily turn it off (and almost everything else) with Nadeko's permission system, but this is not how one should assume everyone acts. It is standard to enable it, and most do enable it, not realizing that they can be ratelimited all the time - again, respect the Discord API designers! I explain more on GitHub. The result of the fixes, which also include a proper implementation of the open source Program-O they use, on nginx with TLS vs. Apache and no encryption allows for a pretty smooth ride. Also fixes some minor (but nasty) bugs - one of which allowed the auto-restart/update script to be a valid startup command, resulting in a deadlock loop until it was killed. As much shit as there is about Nadeko, it is UNLICENSE, and thereby fully open. It is supported well, and very "diverse" as it is just massive in scope. The Music section has all the right stuff by design: the move position, seeking, and saving playlists as well as appending them are all features that are great. It also has embed output and decent (not as good as AIBot) - but very modern - output with clean queue handling. Sadly, it's caveat is really mostly that it relies on YouTube and Soundcloud API directly. You need to obtain a free API key from Google to use many things, and the YouTube searches are done through the API. With SoundCloud, until recently you had to get the key yourself, but they are slow - so Nadeko includes one. Music is only for self-hosters. Our Music module runs differently than the Nadeko dev branch as it fixes a major bug which caused the bot to crash and hang. I don't have the personal time to rewrite the YouTube logic, and even if I did, it would not fix the issue of a proper manager, which LavaPlayer does. However, I am comfortable with Java and C# (they are also similar) - so I've done a LOT more work on it than I did with the Python-based bot mentioned earlier. Sound quality is good and uses standard ffmpeg. The bot doesn't have any of the classic fast seeking, super-easy templating for setup, or other stuff JDA/LavaPlayer do, but it works fine. It is not as efficient, and as it is reliant on the API, which Google tends to randomly change sometimes, it will break. Also, it only works with YouTube/SoundCloud and some radio links, as well as local folders directly with mp3/WAV/FLAC. However, you need to use the proper option and switch between (vs. most bots that just accept all as one and format later, the bot here is picky - you can't play a radio directly from the regular play song URL and need to use the radio load command). These are just some examples. Anyways, I haven't used it for a while as I have focused on other projects, and prefer the LavaPlayer-based solutions, but I still keep the modded branch I have documented and up-to-date. It does have a lot of my own documentation and I make sure to fix the issues of API compliance. Namely, the rotating roles and presence-updates are very troublesome and pose the biggest issue to most critics, with good reason. I don't think it should be an option. Sidenote: I say this because the usual response is "it's fully open, give them the option!" - while I do agree that this is generally good, it's not always good. Case here is that even if 90% of users are "respecting the API" and disable the presence and role-color rotation features, which you can do in one second, a % will still see the feature and use it. After all, why is a feature then? This results in either full-do whatever or having some restraint. In the case of daily rate limit exceptions (you should never really hit these) - this is a problem. The presence updates just don't work, even in small guilds, and we recorded (as a test) over 30 rate limit exceptions in a month or so time. It may not seem like much, but over a benign act that is a lot for a program to be doing. This is also a 40-user test, not a 5,000 user server. These are issues that I do take head-on. I am not partial to most of these things, but like I said, the goal of the server is to have a diverse/library selection of bots, made in different Discord dev groups.
- Wow, that went long! Sorry, had to explain Nadeko (.Spot here) in detail to clear up in detail. So lastly, what did we wipe everything for? Well, those are just a few of the things we've been doing. We also are getting awesome results with recording audio from Discord directly, which we process from raw OPUS strings to clean, raw PCM and then output to whatever format we wish. This has proven to be an excellent source of many things, and the VOIP clarity of OPUS now allows Discord to truly compete with Skype's voice platform (and soon, video!) -- the recording tool we use is very easy thanks to node-opus and the relative simplicity. We have done a ton of audio analysis on these and find that it offers an excellent way to hold even interviews. With someone outside a professional studio or the like, podcasting via. Discord voice-chat will likely be something you hear about, and we're happy to be supporting that.
-OK, vlexar, you still didn't tell me WHY DID YOU WIPE...?! Breathe. Imagine having a server like the one I described. Now, take another server that is dedicated to all-things in Anime. If a user searches using Discord's extensive searching tools for something, they will have a hard time pulling out the stuff related to their topic. We had a brand shift, and now will have (hopefully) discussions, examples, and other things that we want users to search for and not find things that are off-topic or irrelevant, or prior drama. We therefore took a calculated turn to do the tedious task of wiping the main and our staff discussion channels. As you may know, we already have a longstanding policy and have automatically wiped most of our sub-channels every few days for privacy, per our Server Rules, but we mentioned that we don't wipe the main room and our staff ones, for example. Not anymore - we did today. And it sucks doing it! Because Discord doesn't allow >2 week old messages to be deleted through the BULK_DELETE_MESSAGE bot-only endpoint, we have to use the much slower, standard MESSAGE_DELETE endpoint for 90% of the channel messages, which turns into a many hour ordeal. We are a small server, but we wiped over 100,000 messages in our main channel. Whew, well it is over. Note: we do take a archive backup of the channels we deleted today, in-case. We store these offline, in full encrypted drive. It is just the public data archive of the chat. I am not a Discord server admin in the sense that I cannot access anything you guys can't, besides the server settings. But no IP or anything like that, just the chat log of public discussion. We will delete these after a few weeks if no need arises.
-We will have giveaways of all sorts of things in the VERY near future, so look out. Feel free to invite friends whom you think share this interest, and we're happy to have like-minded individuals. If you want to join us behind-the-scenes, you can shoot me a PM and let me know your story - or e-mail directly at
-Thank you for reading this post. I know it was super long, but this is our "rebrand"-proper: so I wanted to lay things out right. Also, if you've been here from the start, we haven't forgotten you - thank you. If this is not your cup of tea, we understand, and we have all our save channels including the
#nsfw-pics, "gambling", and other fun things. We also are always looking to play around with that. Nothing has changed in that sense, and our basic structure still is all set. So while this may be Dev related, it also is a lot of "spammy bot stuff" (but respecting rules) - hence Bot & Dev. The EC part is there as a homage to our original brand, and the General ending completes the idea that the server is still the same "chill" place if you want it to be. We are broadening up, if anything, and are excited to do so.
-Look for the first giveaway soon....and talk later,
Subscribe to EC || Bot & Dev || General
Get the latest posts delivered right to your inbox