You want to say chaos, you could do a at everyone.
Did we press the start the event button? Oh yeah. Nice. Look at us using our own features.
I should open up.
This, this was supposed to send a push notification, that happened.
You have push notifications enabled for discord.
We're gonna have a talk after this.
Feel like it should. I'll I'll ask Ricken them later. Yeah.
In.
Incuses. The first time I have used my watches breathing mode.
So some people got to push notification but I didn't get pushed notification, I don't know, Discord's hard to use.
Okay, let's just give people one minutes to trickle in.
Better from Brooklyn 99 is an amazing dog. Agree cheeky.
500 people is that enough to start? I've hundred people that's make us feel good enough about ourselves to kick it off.
Yeah, I think we can start rolling. All right. Jake rude. What did Jake say? I just came from another 500 person stage channel. I had to drop off of that one. I was a true. I had to practice a little bit. Oh wow. Oh that's fun. That's a good.
Oh, you know what? Are we in stage discovery? Yeah, we got oh, that's probably what happened? I think people probably came in through that.
That's fun. All right. Sounds like it's dealt with. All right, so we get going. Yeah, let's do this. Let's do it. Well hello everyone and welcome to the DDAV stage channel. So just the heads up before we get started, we're recording this session. So you don't have to, you still can.
If you want, you can share it if your friends missed it afterwards. We'll post it. So, my name is Ian, I'm an engineering manager, and I'm joined here by Mason the product manager for the Batson API team at Discord along with pretty much the entire Bots team and about 500 of you.
And today, we're gonna have some fun. We're gathered here for some updates on some of the latest stuff that engineers on the team are building. And we've narrowed it down to four big changes that we've been cooking up. We've managed to get three discord. Engineering staff in here and then there's Mason and together, they will talk through some of the changes that we're making.
And it's honestly very exciting to me just to be able to straight up present our work to the whole community. This is something that we'd like to do more of earlier. So, something to remember, is that the people you're hearing from today are developers just like you. Some of them were actually hired from the from the community, you're gonna see bugs, you're gonna see stuff that is work in progress.
We're not showing off completed projects today. I and you might hear about some of the challenges that our engineers encountered, their blood sweat and tears, such as the path that we choose as developers. There's only one problem with all this. We want to show you the things that we built, but we're in a stage channel.
So you have two options. You can close your eyes and imagine what we're talking about or you can follow along in the stage info channel, where we'll be dropping links to demos, and docs and other stuff. So, all the all the, the visual stuff, and the stuff that you can read and play with are going to be in the stage info channel.
And then, of course, there's kind of like general chat in the stage discussion channel. So I don't want to spoil any changes all that them. Take it away. We're going to go through these changes first and then we'll follow up with Q&A from users submitted questions. So that's it.
Is there anything that I missed Mason or anyone else up here? Sounds like a plan. All right. Well, so first up confusingly is another person named Ian, He is working on big upgrades to the attachment user experience. So in, I will let you take it away, Right. There are a lot of you.
So I know I speak for myself and a couple others today. When I say it's kind of the first time we've had to do a presentation to this many people. So little nervous bear with us a little bit. But however everyone I'm Ian too also known as Dash and I'm here to talk about uploads So I know everyone is attached to uploads and slash commands but you know, here at Discord we have a bigger image that they're part of.
So let's file away this lash command portion of that for a second here, No buttons aside. I kind of do want to talk about uploads more more in general than just three slash commands. We know you've been patiently, waiting for kind of the option type and and all of that.
But I kind of want to talk a little more about the process discord has up. Hold on one second. That was the wrong video and and kind of how we've developed this feature in general here. So when we're what, when you kind of start these projects, we we kind of break them into pieces.
Here we have the API side of file uploads and then there's the UI side of it and with slash commands, one of the big promising things that we do as a team, is we make this UI integrated and first party in the client and a big part of that that you axes having that built-in flow?
That's very crisp with a k. I so all of our projects we kind of start with discussions here and we talk about, you know, how should these work do? We want them to be kind of a kind of how they are today, where they're attached, as part of the message, alongside the message content, or do we want them to be in a field itself as part of a type.
And ultimately through that discussion we decided that the tight made more sense. And then you know the discussion kind of goes into okay, well how does the UI flow work for that? Do we want to make it open the image attachment model? Do we want it to just display any user information like alongside the message on and through different mocks?
Iterations, we kind of realize like that attachment model was creating a lot of friction. We felt that if we instead kind of attached files to the chat input in a way that stickers do or the mobile discord client did, things felt a lot cleaner and just more more was communicated to the user, their attention wasn't being pulled in different spots.
We weren't kind of pulling them around all these different sides of of the application. Like, you know, you you're focus is on the message authoring experience. So through that, when we start to work on that, we realize that this was true for not only slash commands, but just users in general, this UI was actually a really nice and we wanted it for just general users.
So one of the really kind of neat things about discord is we have a culture with very few boundaries where we're able to. Well, maybe, maybe berries is better word. Alright, we have a culture with very few barriers to what we can go in and and actually like work on.
So we were able to take this idea and run with it and actually like go to implement it for regular users and, and their day-to-day uploads. And I think that's a really neat part of working at discord is that we're empowered to go and do this. It's not like the message team owns this so they would be the ones to go in and implement it and our team is, you know, very restricted to slash commands.
I think the culture is more that we all have ownership over the entire product and if it makes sense to go in and work on this area, we're first to do so and you can see in the videos I uploaded, like that's kind of what we've done here. Anyway, we're also able to do more than just that.
So as part of this changes we realize like okay we can actually pull in a lot of longstanding, user requests here, we've heard of them. A lot of people that they wanted the ability to add image all text descriptions or, you know, maybe mark an image as having a spoiler on mobile, not just having to use the file name hack.
So, you know, we started to pull in those things as well and include them as part of this work. Yeah, so some of the videos I share, there's a three different spice levels there, depending on what you're looking for, you can kind of see what we've done here. We've added this new UI for the main user flow where people can upload multiple attachments.
Now they can add all text to images, they can, you know, go in and marketing spoiler. There's always great integrations and then the next step of this process is now. Okay. Let's let's take this new UI and now plug it into the slash command experience and I think you can kind of see how it will.
We'll attach a little bit but like the pills will match up to these attachments and we'll have a much kind of cleaner integration there. And I think the UX will be a lot stronger for it, then having to go through the upload or having having, you know, your direction and your attention pulled, all these different places in the app.
So, in the video, you'll see like as mentioned, these are working progress features. So, there are a couple of bugs or inconsistencies there, but for the most part, it's now functional and we're just trying to all, shut up, get it out. And then the integration between the API and the actual UI here, will kind of begin.
And hopefully, we'll get that out soonish. But, you know, I think this this feature in particular, is a really just a cool case study in how just score teams kind of go from discussing a feature, how best to get it to work, to actually getting into implementing it and and pulling in different areas of the product that can be better outside of your teamscope outside of, you know, maybe maybe slash commands in general, but you know how the bot team work can impact the client as a whole.
And I think that's pretty cool. You know, discord encourages kind of product. Ownership is a holistic thing, not just like feature ownership and yeah, it's just one of my favorite parts about working here and that's about all I have to say on it. I think very cool in another great accomplishment.
Very ends around the world. We got a question about whether alt text is going to be retrievable. Here the API. Yes. So it will be it'll be part of the attachment objects, they'll have a new field there, we're still working out some of the details on the final API IPR is up right now.
Got some feedback on it, working through that but hopefully we'll have more information on that soon but yeah should be fully functional for bots as well as users, which I'm super excited about.
Awesome. Well, we can't stop now. We're going to keep moving on next. We're going to hear from DevSnack so they are working on an awesome new slash command option type and I will let them say the rest. Hello everyone. Let me just post my links here in stage info.
So I have been working very hard on a new interaction type for autocompleting options. Basically, this comes from a very common feedback. We have about how many options you can have for application command choices. And basically we want to allow that to be expanded infinitely really in a couple of ways.
We want you to be able to have lots and lots of choices, obviously, and we also want you to be able to allow users to discover these choices. So for the immediate I'm being, we are only addressing the first part of that. So basically what we have done is we have a new interaction type which allows you to basically, as the user is typing.
Instead of you sending up a list of choices in the application command create as the user types, you will receive interactions with the content that they've typed and you can respond to that with a bunch of choices. And that's basically the the feature and a nutshell. So there's a, there's a video demo in the link and as well as there's a server where you can try out the command if you want to see more of that.
And basically yeah, that's what we're trying to enable here. There's also, there's also some API docs in the document here if you're various about that sort of thing. Basically, one of the things we wanted to enable was allowing you to sort of use this feature in ways that are not necessarily obvious.
So we've enabled, the entire context of what, the user's typed to be sent, which means you might, for example, have like the ability to use one option as a filter and then a second option as the exact search input that a user might be looking for and then both of those will be sent to your bot as a user type.
Data and returning it. And we also, of course, wanted to leave this open for future extensions to how this data might be presented. For example, allowing images to be shown sort of like the githy antenna commands.
Yeah, I think that's the the high level here.
I don't know if there any questions or not but yeah and most people get it somewhere wondering about limits on the number of options I guess at every layer right? Maybe we can walk through that. Yes. So if you want to upload like static voices, like you would do today, I think that's 20.
And with this new model each time, the user types, a character you can return an additional well, not additional, but you can return 20 options or up to 20 options. I should say for them to be shown. So, basically, within each completion, you have 20 items. So there's, it doesn't sound like a lot but because it's, you know, for each character, they type, it's pretty focused on what they've, you know, what they're looking for.
So it works pretty well, is the important thing here is that they on their end, they can search through it however, many options they want, right? They just have to choose the top 20. Yeah, I mean you just have to be on your on on the side of the bot.
You could have you know as big of an index as you want, you're just returning information that may be relevant and that can be very you know, a loosely to find on relevant. We've seen some pretty cool ideas for how this feature might be used and like with like game inventory systems and stuff.
So there's a lot of freedom in terms of how it works. And you know, the options are displayed and like the exact order that you return them. We don't like mass with that or anything. So you can you can do some cool stuff.
Very cool. Some people are wondering. What's the deep downs on the front end? Yes. So it's about. I gets like one one update every half. Second. Um so like I mean as a person is like typing words in that it feels pretty quick. I think what one of the main things we want to avoid here is like spamming a bot with like you know zillions of these requests.
So it's a little bit on the high side for now. I don't think in practice, it feels delayed or anything but you know, moving forward, we're always, you know, open to adjusting these things as people use it and have feedback. So and what is the, what's the response time that you have to respond to one of those requests?
Yes. So right now the response is the initial interaction callback. So I believe that's three. You have three seconds. So I think there there are some use cases for which that may be really easy. There are others for which you may be, you know, more pressed to get data in.
For example, if you wanted to like aggregate data from another external API so you will have to treat this as a custom, you know, a special path within your application, you know, if you want. It's so it's a search index, basically. So, you have to, you know, be able to index that, yeah, index that data quickly.
It. All right, we we have a handful of other questions. I maybe we can start a thread for this. So, we just keep the the main discussion. Moving that sound, okay? To the rest of you.
Yes, the people have spoken. Okay, autocomplete thread incoming. So next thank you very much, David snack. Next we're going to hear from Voltana who is completely upgrading the internals of the text editor that we all know and love and use for messaging which has also enabled significant upgrades in other areas and I will let her speak about that.
Hey, yeah, so hi everyone. I am Botana Shira engineer. Mainly focused on working on the desktop client, or web client. What my main project is this quarter. I guess if folks is on a lot of internals, I'll try to give you guys quick history and try to talk about it as much as I can, but I don't think I'll have nearly as much to share, but history of the chat input in general.
Is this component, goes back way, way before I started here. So and I may hopefully, I'm mostly right on this, but we didn't always have the what you see is what you get editor that you see today or quite a while. We had just a normal plane text editor.
Had a few a bit of mention support but not the live. Parkdown preview. You see? Now it didn't have mentioned objects, as you typed it. You can actually go back to this to the old editor through one of the options and user settings, but you don't really want to do that.
Some people might issue you don't the new editor was built around a really cool library called Slate. It gave us the tools to add those objects. As you typed them, briefly mark down and also all of the components needed to build slash commands. But unfortunately slate itself went through a massive upgrade, a full rewrite really that while it brought a lot of cool features and bug fixes that I personally was interested in.
We were effectively lost the old version just because of the amount of work it would take to upgrade to their new IPI. And yeah, it's just not time. We had, we could really invest as our team was smaller but and be lost the old version. Pretty much presented. A lot of challenges for when we built these slash commands.
UI and is why you see it working the way does today. Let's make sure everyone's on the same page. I'm just gonna post quick gif of what sash commands look like. Now, since I realized there might be some non-developers in here,
It. So the UI we have today is certainly usable. It's we've been listening to the feedback continuously and we've made some improvements, we've added some autocomplete types, make it easier to use. And while it's better than it was the original launch, it's not the best. It could really be a main problem.
At least that I see is that information is spread out all over the place. You type an option and you have to look up and see the description for what you're typing, which is fine. But then you type a few letters and suddenly there's an autocomplete, you have to look even further for that.
When you're done typing the value, there's a third place you have to check to make sure that was actually dots, a bad value typed and see if there's an error, if there is an error, you have to go back to the option and then see what you did wrong.
And that kind of flow makes a feel like you're looking everywhere but where you're actually typing it is not the best experience. Errors also other issues with the current systems such as all concept of opening and closing pills isn't very clear to new users. It works for people who they like developers who are used to just tapping through everything but not not the best experience for users.
We also don't support multi-line inputs, which has been a longstanding request from you guys and things. Like copy paste are to fall apart as you have more complicated inputs. So yeah, my main project is this quarter was to investigate what what the editor look like. If not only, we upgraded to the latest slate version of slate and got the new features that they they they've added over the last like I think two or three years.
But what could we build if we also did a full overhaul of that system and that brings me to the media. Why that I haven't been building a charmer drop into stage info.
Yeah.
Yes. So the idea was to build something. That was more. Akin to what you see, just a normal forms online. The whole idea of opening and closing fills was removed entirely the required options to run, a command are at automatically inserted. When you select that command to make it more obvious, what you need to run it.
We ended the validation state directly inside the editor where you're typing. It supports multi-line input now, so it's easier to do since you're actually typing inside an object. And if you look really, really closely you can see. We've also been experimenting with different positions for autocomplete as well.
Yeah, I think that is alien. I also be dropping a notion dock that pretty much covers what I just said, and a bit of extra info around IME travels with this kind of system.
Thank you. Voltana gonna look forward to that notion. Doc think we have a couple questions around optional parameters, multi-line input, anything that you want to address now, or should we let the of a feature to do the talking? I mean, if there are questions, I've probably already missed them.
They're a thread going. There's not a thread going, we should make it. That then um I can talk about the optional parameters really quickly, just because I've seen that come up a little bit. We we're still figuring out exactly what optional parameters you're going to look like because the way that Thomas work happened was that we have this idea to make these things that we're calling editable pills, sort of like these boxes that you can write in that look like little forms.
And in doing that, we realize that being so far out of date on slate was causing us a huge problem. So voltana became the expert in slate against her own well. And now that like once all of those changes land and we're happy with it, we can sort of go back and look at the slash command pieces.
In particular like optional, arguments of that makes sense.
Oh, okay. She'll post. The notion link and tight, and if you have more questions, head over to the thread, we got to keep moving to make sure we have enough time for a community questions. So the last topic that last new topic, we're going to talk about today, is permissions.
We're going to hear from Mason who spent the last 40 days, meditating, and fasting. In order to find clarity with a new improved application, commands permissions interface. So Mason is here to show us and tell us more about it. Thank you for the wonderful introduction couched in biblical references.
Makes this feel very official and important. All right, let's talk about permissions. I'm gonna link something in stage info. You will see that. Mine is a lot more writing as you go through these links. It's a very fun game of guess. Who's the PM amongst all of the engineers?
So permissions, we know that what we've got right now is just sort of, not quite cutting. It. There's a few big questions that we've been trying to solve through design and research over the past a little bit and those sort of questions and needs are as follows. Moderators need to be able to control who can use certain commands That's possible.
In today's system with the overrights of users and roles, but it's hard to access. Moderators also need to be able to control the channels in which people can use commands, which is not possible right now. Sort of baked into the discord UI. A lot of moderators as we were talking to them.
Also talked about a desire to want to use more bots. That there are cool things out there but those developers have not integrated permissions systems and so they can't like feel safe using them in large communities. And then finally developers, all of you, those that we've talked to and all the ones that have given us so much feedback since the original version which we really deeply.
Appreciate needs to be able to put same defaults on their commands. So that they don't. So that administrative type commands. Don't get abused before. Moderators, have a chance to tune permissions. So welcome to your new application. Command permissions page, I will say the following designs are all working progress as we sort of finish up the remaining like user testing that we've been doing and design iterations.
The problems that we're trying to solve is really the core of it. What actually, ships might look a little bit different than what is shown in this stock as we build it and try it and test it with actual people. But, but let's talk about this. So at the top, when you open up an application in your integrations page, you'll be able to manage access to its commands.
You can start by setting roles members and channel access on the application itself, which all the commands will sort of inherit. So by default applications are available to everyone in all channels, turning a toggle on grants, access turning it off the NIS access. So if you wanted to, for example, make an entire applications commands private, you can remove access from add everybody and not, you know, add anyone else.
As you can see in the screenshot below, you can also give access to only a few individuals by turning off, everyone and adding in specific roles or users. And you can also allow words and I ask access and specific channels or categories. And they work sort of similar to however rights work right now.
So, if you want a command to be available in an entire category, except for one channel in that category, you can turn on the category and turn off that channel. For example, obviously bought some applications have tons of commands, and you don't necessarily want to manage all of them individually, but sometimes you do.
So, we have this concept of syncing, much like channel permission overrights on a specific command can be synced to its parent application. And what that means is that as you go and update me, six and change who has access and where any synced commands like slash band here will change accordingly, and you don't have to worry about making sure that you update each individual.
One. If you do want to change things specifically because there's a specific set of moderator commands or you just want to have that more granular access. You can go into an individual command and change the roles and members that have access and the channels that have access. And it will, then become unsynked, which means that as the parent application changes, the command will not change as a nice point.
This works for slash commands and context menu commands. Those are all sort of under the umbrella of application commands, plus any other new types of commands that we might add on the future? Should also just work in this system. I want to talk a little bit about those same defaults that we talked about.
So a huge point of feedback was as developer. I need to be able to put same defaults on my commands. And we're going to do that. The specifics palace is going to work, is not a hundred percent finalized. There are some difficult technical questions to solve to make this work, but this problem is one that we want to solve in.
Here's our first idea, the default permissions field that's currently on commands, is going to be changed right now. It's a boolean, which means like globally on or off. And we're going to change it to a string that accepts a bit mask of permissions. Like a lot of our other permissions fields that would be a breaking change.
So in current API versions, we might like make a new field and then migrate that's still to be determined. But you sort of understand the end goal, when you make a new command, or your bot is added to a server. For the first time, we'll check the roles in the server and create proper overrights for those commands based on the permissions that you've given to in practice, what that means is if you create a band command with default permissions eight, which is the admin bit when it's made, only people that have the roles that have admin permissions will be able to use that command.
Similarly, if you create a secret command with default permissions, I don't know this. Ridiculously long number that command will be disabled for everyone except the roles that have created an invite manage web hook and send permissions, you know, whatever that can junction of permissions is and if no one has that set of permissions, then the command will be inaccessible until a moderator goes and changes it.
So this way, when, when your bot is being added to a server for the first time or you're making new moderation commands, you don't have to worry about that sort of that lag time in between the command being made and being accessible and a moderator going and changing it.
It should be, you know, pretty default safe. And of course you can choose not to do these things. Finally we want to talk a little bit about the general concept of manning permissions as a developer. This system can be done entirely in the discord UI. So if you don't want to go through the effort of hooking up your own custom permissions, or you might not know how, or you might not think it's important to your application.
You don't have to moderators and administrators have the freedom to go into these settings and update them. However, they would like and you actually don't have to worry about it at all, but if you'd like to and we know that many bots have extensive permissions systems and web dashboards and and all of that, great stuff.
You can change these permissions on the commands as well for your own application. So you can keep things in sync with your web dashboard and and what's in discord or if you want to, you can create your own permissions and bucketing system and have them enforce with member role and channel access inside of Discord.
If you want to sort of use both of the systems together. Yes, finally, I can kill my web dashboard. There are some super complex web dashboards out there. I will not pretend that this will necessarily solve all of them, but I think it can solve a good chunk of them and if that is some work that we can take off of developers hands and that's fantastic.
You know, the more that you can worry about just making good stuff and less about all of that, I think is a win.
Um we have a thing going for this with a cool prototype that you can click around. In last time we shared a figment link it exploded, so we aren't able to do that. But as we continue to make updates to this, we'll share more and maybe we can figure out some sort of way to, to do, you know, some cool beta testing with this one.
It's when it's ready and built. That's a that's our thoughts on permissions.
All right. Thanks Nathan, I'm gonna create permissions slash command permissions thread in the see, somebody made one already permissions questions on stage, info. You're right. Someone else already did it. So we're good. Great. Well, that brings us to the end of the first part of this stage. One question, hiding commands versus having them disabled.
In this system, commands will still be disabled, not hidden. That is still on our road map and a separate thing that we are going to do. Hide-and-commons on the back end is a really difficult technical bit of work. And the first thing that we were doing is figuring out.
What are all of the reasons that we might want to hide commands from people? This permission system being one of them and once we sort of understood all of that architecture. Now, we can tackle. What is the best way to hide them on the back end? So, it won't happen in the same update, but this update directly impacts our ability to do that.
So move it before we move on, just want to reiterate that everything you all have seen here. Today is work in progress, it's not released yet. Parts of it, our subject to change parts of it are incomplete. So we're happy to answer questions and clarify where we can, but stuff is in progress.
So, with all that behind us, we're gonna move over to the queue and a. So a lot of you submitted questions on the slider which was in the in the discord API announcements channel, as well as the the topic in stage discussion. So couple notes on the Q&A before we get started.
Thank you so much for all of your questions. We had over a hundred eighty in order to make the best use of everyone's time here. We went through the questions beforehand and tried to avoid duplicates where possible we got a handful of each, for some of the topics that you see in the slide.
Oh, so if you don't see your exact question, just know, we did see it and add it to our documents, where we track them, where we track what we're hearing from all of you. And what's important? What's on your mind? We also got a bunch of off topic questions, which we didn't put through, but we've passed along that interest and feedback to other teams internally that work on the stuff you're asking about.
So they know that this community is interested in those features and then lastly, because we'll only be able to answer a handful here live today, we'll also be posting a written Q&A with responses to some of the detailed feature questions that were submitted and we'll post answers to like the top, 40 or so.
By the end of the week, I think questions are still open for submission and voting just a reminder that when you're submitting questions, you know, where we're all human here or reading through them. It's a lot easier for us to understand and take in your feedback if it's informative and productive.
So with that said, questions page is in the channel topic. I just posted there and we will get started. Most, if not all the questions are going to be answered by Mason Mason, are you ready? Let's do it to it. You'll be sucking my voice by the end of it.
Okay, first question is, what do you guys ever actually go through the feature requests on the GitHub repo instead of just leaving them in limbo forever? Some do get an official answer but others don't and people have to find out about it from a third party or have a pinned issue with all the approved slash denied requests.
Yes. So we actually do go through those some somewhat regularly but we can probably be better about making sure that communication happens more often each week on our after our Monday stand-ups. I believe we go through the issue tracker side of it first to look for any new bugs that come up to make sure that we're not like missing.
Anything that's super broken the discussion side of it. Sometimes gets bubbled up independently. If there's some interesting ideas, but we also use that side as feedback for our planning processes. Like, what are the big things that people want? What are some things that we should be? Considering what our questions that are being brought up that we haven't thought about.
Um, I agree that there are a lot of things in those discussions that sort of just sit there. It's actually for a reason. There are a lot of great ideas that we might just not be doing right now, right? But we don't want to lose them, so we don't want to just close ideas, even if they're not happening right now because they might not actually like they might not be bad ideas, they might be good ideas and we want to make sure that we keep them around and let the community comment on them and vote on them as things change over time and maybe priority shift as far as the pin issues.
We've actually attempted to use those as more of a like timeline sort of thing. Like here's some features that are coming to address this question, they're not intended to be like a replacement but we do look at these, we do look at them very frequently. We could probably be better about trying to leave comments on them about this is a good idea but we can't get to it right now.
This is probably not something that's ever going to happen. There's not very many of those or hey, this has been taken in.
Cool. I'm going to try. Not to say thanks Nathan because people need funding when I say yeah, yeah, maybe maybe one thing that we can do is come up with a like a label on them. That that's sort of says that we agree that this is interesting, but it's not going to happen right now.
So we're leaving it open, but it's not actually a limo.
Yeah, that's a good idea. Thanks Mason for that idea. Thanks telling me. Thanks. No problem. So I I I want to skip, I've been asked to skip down to the music box question because that's something that you know comes up frequently. Indeed as questions simply anything to say about music bots going offline.
Yeah, it's it's certainly been a few weeks, hasn't it?
So as you as you all know and rhythm and groovy are unfortunately offline, they acknowledge that they received communications from YouTube, asking them to take down their bots and they complied in doing so you know they were they were breaking YouTube's terms of service by getting audio the way that they were.
We love listening to music together and we know how important it is as a thing that people do together on discord. Innovation and creativity are really important to us, that extends to our developer community, but also to artists and musicians and all of those folks that have their own rights on things, right?
So I guess take this as a soft reminder that much in the way that you can consider discords terms of service when you're building things, consider the terms of service in the rights of other services as well. That's that's really all we can share about this, but yeah, at a certain it is unfortunate.
In a week, it's been a week. It's been a month. Yeah, it's all blending together. Next question is from someone who claims their name is suspense. Could we get some sort of regular updates on what's being worked on? What bug was fixed? What new feature from GitHub, discussions are being considered is being considered similar to what Mason used to post on GitHub on.
The slash commands master list almost every week. Yeah, we should definitely do this, what they're referring to for that slash demands masterless which some of you might not know about is that back at the beginning of this year slash last December, we launched slash commands to a public beta and collated.
All of the feedback that happened and said, okay here's all of the stuff that has come through. Here's what's going to happen. Here's what's not going to happen and why, and we're going to call this RV one doing that for big project, things is great, but I sense that it would be even better if we could do it in a more regular cadence.
We are, we're definitely looking into ways to communicate these timelines better and more transparently for all of you. And not just necessarily cheer is the list of things that we are going to fix for this big thing that's happening, but uneven more regular, cadence of, here's the stuff that we're thinking about and here's some of the small and big things that have happened.
One thing that I point out is that the master list that was originally, did have issue we've moved that format over to discussions. So there's that API plans discussion and that is updated regularly For those who may not know about it. Next question. Well, you consider increasing the amount of slash commands and application can have.
We can certainly consider it, but there's no current plans. I don't say that to be a never, but a, there are no current plans two things to consider one. We still need to do the work to make slash commands, and subcommands, and groups better, more accessible easier to use.
And once we do that, I think we will find that they are more useful than we currently see them as the second half of that is a like technical problem of if we up the limit to let's call it a thousand commands, right, 50 bots in a server, a thousand commands per bought.
Some person on an old. Android phone is probably going to have their phone explode in their hands from all that data that gets sent. So, upping limits is not actually like there are reasons why these things are in place, and as I sit here with my iPhone 11, whatever it wouldn't really affect me.
But we have a global base of users who have a lot of different devices and we have to make sure that it works for everybody.
Okay, thank you very much, Mason. Thank you so much for that answer. I'm just expecting it quickly. Say that I'm working on manually, I'm meeting everyone who got muted for spam. Sorry about that everyone. Sorry everyone. That's where you get for being polite to Mason. Okay, let's keep moving.
Do we have some sort of loose roadmap for upcoming interactions features? Not that. We expect hard dates, but just an idea of what's coming next. Oh, yeah, I think this sort of goes to the previous question of, can we share time lines, and roadmaps better? We have it in that current pinned github discussion about slash commands improvements, and there are some general interactions not slash commands specifically stuff thrown in, but as we do forward planning, which is starting soon, and as we plan, for next year, we want to figure out ways that we can be more transparent about what's coming in the stuff that we're thinking about.
Great. Next question, is whether it be a sort of date option, type or slash commands eventually? Yes. Not currently in the scope of like the stuff that might be happening over the next quarter or so, using strings for date. Times is annoying. It's it's very bad for general discoverability for users for consistency across how different places in the world, right dates.
Right now we're focused on the stuff that needs to exist to have parity, but that is a good example of like a feature request. That is a good idea and it's not happening right now but we don't want to lose it. I'm just support, ISO strings, only that is a possibility, but you have to consider that like I don't even know that I could format an accessory off the top of my head, right?
Like I would have to go to the internet to find something. That tells me what the string is and then copy paste it. So, not a great user experience for people. Actually trying to use commands.
All right, we got a good one next. Do you plan on taking a more productive approach towards supporting library developers or more specifically Python developers? Now, that Danny decided to step down and does their specific library? You think we should shift our focus to now that discord dot pi is gone?
Yeah, it's a great question. There's three questions in here. So let's let's answer all of them. Do we plan on taking a more proactive approach supporting library developers? Yes, we do stuff to support library developers today and we do plans to take a more proactive approach in supporting the voices of all of the developers on our platform feedback and suggestions comes to us at a number of different ways.
Right now we have GitHub issues for bugs get hub discussions for feature requests. There's public channels like what we're doing here right now and in these events to try to get the community more involved in more aware, and we also do have private dedicated channels that are open lines of communication between discord and library, developers and discord and large bot developers on the platform.
When we launch new features, we proactively reach out to developers. In those private channels, asking them for feedback, and suggestions and making changes accordingly. I'm I think every feature this year at this point, has had communication with them in some way. I might be missing one or two and I apologize if that's false but it is like, literally part of our rollout and part of our development process to say, here's some ideas that we have.
Here's the problems that we're trying to solve. What do we think about it? Our vision is to make feedback more public and more open. We know that you want more transparency and to be part of giving that feedback, it's very difficult to do that. Effectively when we are talking about, like, going from talking to 30 people, to talking to thousands of you, but it's necessary and events.
Like these are the first step in figuring out how we can do that.
Do we plan on taking a more proactive approach to support Python developers specifically? So when we're building things for developers, we're building them in a language agnostic. Way intentionally Python isn't the only language that people use although it's incredibly common and we, of course, love it ourselves. We intend to build open APIs that people can wrap in the ways that are most comfortable for them.
If there are specific things that we can be doing to help Python development specifically that we aren't doing today. We'd love to know. You can offer those suggestions on our GitHub. Discussions pages. And lastly, with any stepping down from discord pi, is there a specific library that we think that you should shift to?
I don't have one by name right now. There are a ton of great developers out there and we want to give them a shout out who are jumping into help maintain that project and and create forks and and what the next thing might be. So I think there's a lot of great options and you should go check out those forks that are being created or new blibras that are being built to see which ones work for you.
But of course, we recognize the work that Danny did in building discord by over the past six years, whatever. It's been. And we hope that the ones that come after can be just as great.
Thinking listen for answering that question. Next up. Okay, we have a few question about the coolest spot that we've seen. I actually eat. I don't know if this is the real yet, and a fake. Again, 30 and or 40 end, I couldn't have been me. I didn't plant this question.
What? I do that based and have you seen any cool bots lately? The Game Boy emulator bought with buttons was really cool. Oh yeah. That was neat. Where did that come from? There's this game boy bot.
And I saw it somewhere to that was pretty cool. It was on reddit. What about you? Anything else, other, you or other in one. I had any other cool things that you've seen with buttons. There's a minds beeper bot that moves developed on, that has been probably the singular most popular thing and a bunch of servers.
I'm in, it's only a couple buttons, but people love that thing. It's it's a lot of fun. Yeah I was gonna shout out the mine. Sweeper bot to that was really cool. I wish I sucked less at minesweeper.
All right, no job much. And everyone else. Okay the next question is is there going to be a new badge for developers in the future? Oh God.
Let's never say, never because God only knows what decisions will be made in the future. I will say we have learned our lesson badges are cool. They can be done without causing a lot of problems. The way that we originally did it caused a lot of problems. So I think if there were ever to be any badges for developers in the future, we would need to think really, really long and hard about all of the things that come with it when you give people access to something.
Cool.
Yeah, all right. Next question is they're gonna be a new badge for the developers in. Wait, I'm just reading that same one again. Next question, really? Please. I, I've already had a long period gonna keep asking me until I change. My answer. Is that how this is gonna work?
Yeah. Okay. Have you signed up permissions for buttons? Sometimes it would be helpful to have buttons enabled disabled, depending, on permissions smile. That's a good question right now. Buttons are pretty like dumb, quote unquote, as far as state and permissions go intentionally. We wanted to leave them more open and see what people did with them.
For example, like they're not tied to the use / commands for mission because we knew that in in many places where buttons might be used for reaction roles bots, you'd want to be able to press buttons when you can't send messages or can't use commands, I'd like to hear maybe more about the use cases for this and if it and maybe thinking about, could this be solved by like a femoral message buttons and ephemeral messages instead, which is something that can be done.
But if there's a need for this or want for this, I think we'd love to hear more.
Next question. Would we ever see an improvement on audit logs? For example, knowing if about deleted a user's message or if it was a self-delution oh boy, I am not on audit log expert. Um,
I think it sounds reasonable. It's not something that I've currently thought of, but I think it sounds like a reasonable request like I go bother JK built the auto log, right? No. There is some thought to it though. That the audit log can get super spammy. I know that and we intentionally try to keep it useful, right?
So some of those things can be spamier than you think that they might be and it's why we haven't made some of those changes. I don't know about this one. Specifically, I'm not the expert, but there are experts here who you can talk to
Okay, next question. Probably the last question, are you working on improving communication between discord and developers? Recently, very big changes, such as the privilege. Message intent had been rolled out without notice or discussion with us which will break many. Many bots. Yeah, I think we touched on this a few questions ago.
Yes, we very much want to work on can improving communication between discord and developers as a whole. We have communication avenues with library developers and with large bot developers. But when it comes out to the rest of you, it seems surprising so much on the way that we talked about timelines.
And when our new features coming and can we give better roadmaps? We we do want to figure out a way to be more transparent with the broader developer community, about things that are coming without making it to like thrashy, like, oh, could because priorities change and things shift and and what happens, one month might actually get moved to an X month because of reasons.
So, talking about sort of the big problems that we'd like to solve and ways that we're thinking about doing it. I think is valuable.
Okay, is there any sort of like last one hiding in the weeds in here? That might be interesting. How is hack week? How is hack week? Yeah, let's talk. Let's talk about hack week. I enjoyed hackweek. There was some really fantastic projects. I finally got the time to make to finish up my bot.
That bridges. Figma comments into discord. Figment is our design software, and you can leave comments, and it. But if you want anything like me, I'm so used to discord notifications that trying to read anywhere else is just an impossibility. So I try to bring as many notifications into outside places into my personal discord channels as I can.
So, that was a fun, a fun project to sort of finish up. Maybe, maybe we can end it with the you other four talking about what you did for half week.
Sure what our, what are discord notifications? I'm not familiar with that. What do you mean that? Just you you have notifications on for discord? Mason. Again, we're gonna have a talk after this. I'm yes. So, I did a happy project where we took the documentation website and rewrote it in next JS and MBX.
And I kind of worked with some community members to to make a more of like a open source version of the docs. I guess so one of the things that you can do is like you get the preview when you work on it, you don't have to like publish it and deploy it to actually see the changes show up.
You can actually see how it looks on, like pork quests and things like that, which is pretty nice added a light mode, which I know a lot of you probably won't want. But is incredibly important for accessibility reasons, like, dark mode for some people is really hard to read to the point where, like, they're not able to actually.
So having light mode is, as quickly important to, to make the community is inviting and like inclusive as possible. And it also just allows us to do cooler stuff if we wanted to, like embedding other react components within the, the documentation itself. So like if we wanted to put a button playground, where you can play around with all the different options and like, actually see what that would look like.
In discord, it would give us the platform to do that. I'll hedge this all with, you know, this might never ship. It was just something we did for a week to check it out, but we had a lot of fun doing it. And I think it was really cool getting to work with the some community members who were also interested in this and, you know, they participated too.
And I had a bunch of fun with that.
Don't who else did a hack? We think I I could I guess real quick. I built a crappy slash command builder that maybe one day we can put in the developer portal. Like a UI for managing slash commands just a hack.
I worked with a team of people on enabling you to add slash commands to users instead of guilds.
Who knows if that'll ever ship or not but pretty cool. It was pretty cool. It was very cool.
Entana, do you want to share your hack week?
I mean I my slate upgrade was my heck weeks so but you know more like hack month. There you go. Full time. I just worked through hack week but made it happen. All right, folks were we're a little bit over time. Thank you. Everyone not just Mason. We want to do this regularly, we really enjoyed this.
I hope you enjoyed learning about attachments. Autocomplete, permissions, / commands, all the Q&A, hope that was a little useful. Like, I mentioned earlier, we're gonna follow up on UNA that we didn't get to really looking forward to next time. Thank you so much for taking time to be with us.
Have a good one. Take care everybody.
Good work