Amount Of Server Boosts

[Skillz4Killz]

Hello 👋

Would it be possible to show how many boosts a member has in a server? I wanted to use Server Boosting as a way to unlock VIP features on my bot but I can only reward each user a maximum of 1 server VIP unlock because I can't tell how many boosts they are giving.

Recently, Server Boosting allows as many boosts as you like, this means a user could boost my server 3 times and so I want to allow them to have 3 servers with my bots VIP features. This would encourage more users to give more boosts which means more money in Discord, more cool server perks for me and my users get cool bot perks in their servers. It is a win, win, win.

Only having a timestamp showing when they became a booster isn't really helpful besides telling me that they are boosting. It's basically just a boolean at that point. An integer showing how many boosts a member has given would a perfect.

Thank you.

[NovusTheory]

Just a small comment to add. This could go hand in hand with giving bot access to https://discordapp.com/api/v6/guilds/GUILD_ID/premium/subscriptions as it contains all the boosters for a server and includes a user multiple times if they have multiple boosts applied.

I would like to think of this as unlikely and assume Discord will just add a premium_count to the guild user object.

[msciotti]

Just want you to know this is being discussed internally. We intentionally haven't put this in the API (or in the client) because of some negative behavior we thought could arise, such as people being targeted for boosting/not boosting/how much they boosted. We unfortunately saw some of this behavior in the original launch as well.

Raised this again today—just so ya know!

[fhebuterne]

@msciotti Do you have any news ? I've created a topic on discord forum, some other users and me are very interested by this feature : https://support.discordapp.com/hc/fr/community/posts/360056250092-Add-information-to-see-who-boosted-server-twice-on-UI

[bartico6]

@msciotti Any updates on this?
Also, is giving people additional roles (as a token of gratitude, of course) for boosting a given amount of times negative? Is synchronizing boost status/count to, say, a game server, considered negative?

Could the negative behavior problem be solved by allowing users to hide their boost count (or, even, the fact they're boosting at all!) on a per-server basis, and give bots & admins an endpoint that allows them to view people who have their boost status shown? (this would require the role to be removed/reapplied to boosters when they toggle that setting, though)

Technically speaking the problem of potential "targeting" for the fact of boosting already exists, through:

The sidebar icons

The notifications

in fact the notifications reveal the boost count anyway lol

The role itself

so you could combine opening up the API for querying who has boosted & how many times with allowing people to hide the fact they're boosting completely.

I also am not sure I understand the concern. Is the worry that admins will bother their boosters, or that non-admins will bother boosters?
For the former, it's a difficult issue to solve authoritatively since it should be the user's choice to leave the server if they're being targeted by staff, and honestly it sounds like the kind of thing you should be encouraging. Servers with abusive staff generally die out so it should be a problem solved by way of natural selection. For the latter, a role permission could be included to toggle ability to "view boosters", allowing admins to set up who can see boost statuses (such as admins, moderators, maybe other boosters?) eliminating the "non-boosters poking fun at boosters for spending money" factor completely.

If the issue is that owners/admins/mods will "beg for boosts" - it's already the case. It's heavily rewarded by the platform so everyone wants it and everyone asks for it.

[stevenobird]

Like @bartico6 mentioned, Server Boosting is quite present in servers that are using it, and boosters are visible in many ways on the client side.

So I honestly cannot imagine why such an information is kept secret on the API side.

[msciotti]

While I appreciate the suggestions for all the granular permissions around visibility of boosting in our API, that is frankly a bit too intensive for what needs to happen here. I think it's also rather important to remember that bots aren't users and don't operate at the same scale. Yes, a given individual could go through the "Nitro Boosting" rank of a single server and bother them for some reason, or the opposite and DM a bunch of non-boosters begging them to boost.

However, you're talking about one person taking a lot of time to do this at meaningful scale. A bot that's in a couple thousand servers could—and I'm speaking purely in worst case scenario hypotheticals—do it all day, every day, for every person in that server (respecting our rate limits, of course).

That being said, I will raise this internally again. It is very unlikely that we put robust permission sets in our API around visibility of boosting. It will either be that we are comfortable exposing it in our API, or we are not.

EDIT: Scratch what I said, I was misreading my own API docs. Considering that we do expose premium_since in the docs for a boolean boosting/not boosting, what I said is rather irrelevant. I've raised it again, though it will be in the hands of the time that works on our Nitro and boosting stuff to decide.

[Octolus]

Looking for this, is it not available?

[AruMoon]

Need this feature

[GolfingSuccess]

I would really like this feature as well. The problem with @bartico6's remark is that Discord doesn't show how many times a user has unboosted, so a bot can't just determine the boost count from those messages.

[DigitalCommodore]

Why is this closed? At the moment, you offer bots partial boost monitoring functionality and a user full functionality. If you were concerned about users being unfairly targeted, that was a discussion for when you guys decided to give a system role, server notification, and a badge to users who boost, wasn't it?

The current implementation is as though someone did the work for users, and wandered off halfway through implementing it for bots.

[GolfingSuccess]

@DigitalCommodore It looks open to me...

[DigitalCommodore]

Oh, hell. That's what I get for getting grumbly before I'm done with coffee -_-

[Skye-31]

That only says that they have boosted once. What if a user has boosted multiple times? That information just isn't revealed. Also, at time of this issue creation, there was no guarantee which role was a booster role (before role tags were released).

[bartico6]

This isn't needed. Just look at all members with the boost role. It's harder but it's doable.

Even though the role tag exists to determine "boosting or not", it's already possible as part of the user json (premium_since) as @msciotti said - determining the exact number of boosts from a given user still isn't possible via API, but it should be - that's the point of this issue.

[Octolus]

Still needing this, can't believe it is not a feature. I want to give my members special privileges based on how many times they boosted!

[bartico6]

Any updates on this?
It was supposedly raised to the team over 6 months ago, surely there's been some decision we could hear about by now, right? :p

[mjkzy]

bump

[xpierroz]

Is there any way to show the boosters? And how many times they boosted? I saw it's possible, but I don't know how. Thanks

[GolfingSuccess]

What we've been discussing above is that we can't know the amount of boosts one has on a server. We can only know whether a member has boosted or not, but we can't see the difference between 1 and 30 boosts.

[erkinalp]

I think the booster role should be deprecated and https://discordapp.com/api/v6/guilds/GUILD_ID/premium/subscriptions should be made privacy-gated (both user-side and guild-side). If a user chooses to hide boosting status, others should see 0 boosts regardless of actual boost amount. If a guild chooses to hide boosting status for some roles/users, guild users should see 0 boosts from those users, regardless of actual boost amount. Those privated boosts, for backwards-compatibility purposes, should be reported as if done by an anonymous pseudo-user when queried.

[xpierroz]

I don't know how this is possible, but i'm sure this is possible. Here is a proof. Maybe we just need to put our Discord Booster Role in a config file or anything like that, and the bot will write every people with the role. But, my question is, how the bot can know when they boosted??

[Rapptz]

This isn't about fetching that information. That's already available -- you can check premium_since in a member object to see when they boosted. However you can't see the amount of times they boosted which is what this issue is about.

[stevenobird]

Are there any news on this? Has there been an internal discussion, and with what result did it end up with?

This shouldn't be a big issue in general, since official Discord Clients are indeed receiving that information (but maybe using reserved/private endpoints). Exposing it to the API can't be so crititical - like already mentioned, you are able to fetch certain information...

• how many users are boosting a server (Guild -> premium_subscription_count, premium_tier)
• how long a user is boosting a server (Guild Member -> premium_since)

You even can fetch messages and filter them by type - when is a user boosting, when a guild reached a premium milestone.

Would be awesome to get a status update from you guys :)

[GolfingSuccess]

Are there any news on this? Has there been an internal discussion, and with what result did it end up with?

This shouldn't be a big issue in general, since official Discord Clients are indeed receiving that information (but maybe using reserved/private endpoints). Exposing it to the API can't be so crititical - like already mentioned, you are able to fetch certain information...

• how many users are boosting a server (Guild -> premium_subscription_count, premium_tier)
• how long a user is boosting a server (Guild Member -> premium_since)

You even can fetch messages and filter them by type - when is a user boosting, when a guild reached a premium milestone.

Would be awesome to get a status update from you guys :)

Fetching boost system messages isn't enough to know how many times somebody has boosted, because, when a boost is retracted, there's no announcement about it. Plus, even if there was, there's no guarantee that every such event has been captured by a system message, or that the respective system message still exists.

[bartico6]

Are there any news on this? Has there been an internal discussion, and with what result did it end up with? This shouldn't be a big issue in general, since official Discord Clients are indeed receiving that information (but maybe using reserved/private endpoints). Exposing it to the API can't be so crititical - like already mentioned, you are able to fetch certain information...

• how many users are boosting a server (Guild -> premium_subscription_count, premium_tier)
• how long a user is boosting a server (Guild Member -> premium_since)

You even can fetch messages and filter them by type - when is a user boosting, when a guild reached a premium milestone. Would be awesome to get a status update from you guys :)

Fetching boost system messages isn't enough to know how many times somebody has boosted, because, when a boost is retracted, there's no announcement about it. Plus, even if there was, there's no guarantee that every such event has been captured by a system message, or that the respective system message still exists.

He isn't saying what we have is sufficient, he is saying what we have already exposes the information Discord employees claimed to want to protect, therefore rendering the "well we don't want people to be targeted" point void.

[ghost]

Hello to all Discord developers. I'm glad to know that they are concerned with the users' experience.

However, it is important to note that there are more benefits than harm in exposing this data, after all, if the problem is to induce the user to boost the server, this problem already exists. If a server owner really wants to, he/she can try using other methods (like a wacky crawler that uses the standard automated messaging), or else do everything manually. So personally it seems to me that you are trying to delay the "inevitable".

Anyway, as I said, there are more benefits than harm in exposing this data, for example:

• Boost event: can you imagine if your bot sends a message to every boost you receive? It would look so cool! This behavior is already partially possible, but it still doesn't work when the user boosts twice.
• Privileges based on boost level: if a user boosts a server twice, it means that that server has a special meaning for this user, so why not give greater rewards to this user?

Finally, it is important to note that every user is already induced to boost a server, based on the rewards that Discord itself gives (special message, badges and special roles), so why couldn't the owners of the servers do it too?

[sudofox]

We let people who boost gift a "Nitro Booster Ticket" to themselves or a friend once per month. It looks like this:

Isn't it cute? It can be redeemed for some fun perks on our website, including this snazzy badge on your profile, shown on the website and Nintendo 3DS version of our application:

Nitro Booster: Showed how cool they (or a friend) were by boosting the Sudomemo Discord server.

But there's trouble in paradise. We have some people who have boosted twice or more and are rather confused that they can't give out another one. Though this is explained in our Help Center, we still get support requests about it from people who never really read about it before boosting a second time because they wanted to give another friend of theirs a Nitro Booster Ticket.

The one and only reason we can't give them proportionate rewards is the lack of this information via API, which means repeated disappointments to our users. Not a great experience!

If this info was present, it would be a simple matter of...

if ($user->premium_count > $boost_tickets_given_this_month) {
   // allow giving another nitro booster ticket
}

and just like that, problem solved.

[HilbertGilbertson]

As with many here, my frustration around this issue similarly dates back to Nov 2019, when I implemented a means via one of my guild's websites for boosters to create their own role or emoji, and wanted to give both benefits to those who used both of their nitro boosts on the guild. After all, the information was accessible to the user via {guild}/premium/subscriptions, so why should it not be available to bots?! (as also noted in #1714). I was - and still remain - baffled.

I can appreciate the explanation offered last year by Mason, except it really doesn't hold up to scrutiny. As others have noted, the subscriptions data is already there. If the fear is that boosters might be targeted for boosting/not boosting/how much they boosted, they already can be; the only difference is that it won't be automated. Any user need only pop open the network tab when browsing the server boost status page and the data is right there for them to see at any given time.

If there were some malicious guild owner hellbent on 'targeting' boosters based on the number of boosts, or because they dropped a boost, or the length of time spent boosting etc, this is already possible, because the information is there for them to use in doing so. 🤦

Equally it is already relatively simple to track - by automated means (length of time since the boost message event) - how long a user been boosting and use that information to reward longer term boosters on a different basis to those who have boosted for a shorter period of time. This leads to the absurdity that we can set up automated means to 'target' (or perhaps additionally reward) boosters based on length of time boosting, but not on the number of boosts.

From all I have seen in this thread, the endpoint being inaccessible to bots is not preventing 'targeting' of boosters. If anything it is really only preventing more innovative means of rewarding members who boost (such as with @sudofox's use case). Be it Patreon, OnlyFans or otherwise, platforms should enable creators to reward their subscribers based on the level of their contribution. This isn't about 'targeting' boosters who only give one boost, but ensuring that a member who, say, gives three boosts gets some recognition for it, and potentially some greater bonus(es).

[GolfingSuccess]

The simple answer, @HilbertGilbertson, is that initially they didn't expose the endpoint to bots due to worries. And they haven't had the chance to revisit or prioritise a change to that policy.

To change that policy, someone inside Discord would likely need to write a proposal weighing up the pros and cons, and share that with their team. That takes time.

Since this GitHub issue is still open, this task is likely on their radar, or in their backlog, and they simply are busy with other things!

I don't know if "number of excited users" is a serious metric they consider when deciding what tasks to prioritise, and if it was, it's likely that other tasks have "more excited users" and deliver more impact.

And... how are we obstructing them from doing anything right here, again? Who said that your "number of excited users" criterion is why we advocate for this feature?

[GolfingSuccess]

And... how are we obstructing them from doing anything right here, again? Who said that your "number of excited users" criterion is why we advocate for this feature?

I don't really understand your question.

All I'm saying — there's probably no point in saying it — is that all we can do is be patient, respectful, and hope that eventually they get around to the things that we as individuals want.

We are all often passionate about the things we want, I just wanna remind folks that our wants are != Discord's priorities.

(FWIW, I complain about other platforms all the time... but at least those other platforms either are getting consistently worse or stagnating.)

Not so sure I agree about the "patient" part, given that it's almost a year and a half since this was initially brought up and nothing has been done about it. The last official response we have gotten is from over a year ago, here.

[HilbertGilbertson]

All I'm saying — there's probably no point in saying it — is that all we can do is be patient, respectful, and hope that eventually they get around to the things that we as individuals want.

Surely this goes without saying when it comes to any issue, and hence I am left wondering what exactly the point of your interjection was. I can well appreciate that there are processes behind every decision and that good things come to those who wait. I don't think anyone here is suggesting that this specific issue should be Discord's number 1 priority, but this has been bugging some of us for quite some time. We're at v8 of the API (and heading into v9) and there hasn't been an update on this issue in over a year. There have meanwhile been bumps and requests for updates above, and nothing has yet emerged.

[sudofox]

I genuinely believe that the potential for good here outweighs the potential for bad.

Discord has created an excellent carrot-on-a-stick :carrot: in the form of server levels. It's heavily incentivized to get boosts, and more boosts = more nitro/individual boost sales. Server owners also can incentivize boosting a server to the members to offer the members extra perks as well, which almost does Discord's work for them: the server owners have come up with ways to incentivize behavior that earns Discord $$$ and, save for some extra bandwidth from voice traffic, costs them about as much as flipping a few bytes in a database. Win win! The server owners are doing Discord's marketing work for them.

Imagine how much more NItro/boosts could be sold if the server owners could tier rewards. That's money on the table, @msciotti . Let us server owners flog all those Boosts and Nitro subscriptions for ya. We won't even ask for a commission - but maybe spare a vanity URL for us, eh?

Pictured below: Discord after they adjust their API to return a premium_count value for bot users

[erkinalp]

@sudofox but only once users can hide their premium status from others.

[sudofox]

@sudofox but only once users can hide their premium status from others.

Due to the core design of boosts working to show off the fact that you're supporting a server (boost icon next to your name in server list, default hoisted and colored role, profile badge), we can say that the ability to hide this fact is already implemented:

[mjkzy]

I mean having literally multiple users commenting on this yesterday just shows how much people want it. I do believe good > bad in this situation too. Hoping this comes soon.

[erkinalp]

@sudofox I mean anonymously server boosting a guild, not retracting a boost. You cannot do that now.

[HilbertGilbertson]

@sudofox I mean anonymously server boosting a guild, not retracting a boost. You cannot do that now.

The point @sudofox was making, @erkinalp, was that anonymous boosting would seem counter to the core design of nitro boosting, and that your suggestion (including even removing the Nitro Booster integration role) appears in conflict with this feature request.

If you would like nitro boosting to be anonymous (and the Nitro Booster role to be removed etc) perhaps you should submit your own separate feature request, where you can justify use cases for it.

[erkinalp]

No, the two are coupled because bots can process that information way faster, and exposing boost amounts of each user to bots would mean a decreased second order privacy. An option to boost anonymously by default (while still keeping the ability to do so under your name) would compensate by providing an opt-out increase in the user's first order privacy (providing less data in the first place). Community moderators are not Discord's marketing staff. And anonymous boosting ability would bring more crowd to support Discord, who currently avoid that due to various concerns (For example, a government employee avoiding server boosting to prevent claims of favoritism or bribery. If anonymous boosting existed, that person could easily boost them without issues because no one besides Discord would know that person allocated the server boost to that guild).

[A5rocks]

I believe you're mixing up different levels of anonymity?

At the level you're talking about, you might as well just get a burner discord account and call it a day.

After all, if you're boosting a server, you probably approve the community and think that nobody will witch hunt you for doing so. Anonymous boosts make no sense in that case: if you feel unsafe in a community but are boosting it, what's up with that?

[sudofox]

@erkinalp [...] An option to boost anonymously by default...

While it's fine that you've got your own ideas for how Nitro Boosting should have been implemented differently, the concerns you're expressing are far outside of the scope of this issue. If I were to put Discord's current implementation in terms of anonymity and self-expression, as the functionality stands right now, we could say that this issue is requesting an API change from getting

User#1234 really likes the Foobar server

to

User#1234 really, really likes the Foobar server

which really makes no difference since we already know which users are boosting.

[erkinalp]

Please listen. Exposing boost counts and dates to bots without a way to hide them amounts to making the billing history of user public except the payment method itself, and that concern is indeed legitimate. Keep in mind supporting a community by subscribing to a community perk does not mean agreeing with that community in whole. In cases you do not agree with the community's ideals but still want them to have perks and benefits, you would want to boost anonymously.

[sudofox]

You should really find another place to express this particular view. This card is not about anonymous boosting. It's about getting the number of boosts, per user, programmatically, information which has never been private in the first place. If you think that Discord should add anonymous Nitro Boosting then by all means, put in a feature request! I won't stop you.

However you are at this point distracting from the purpose of this issue. Such a change to the API would not make any previously private information public. It would enable server owners, who have added their own bots under their control, to poll boost counts for whatever reason they'd like to do so.

[erkinalp]

It's about getting the number of boosts, per user, programmatically, information which has never been private in the first place.

And I am trying to explain you all that retrieving them at human scale and rate and bot scale and rate are not the same things. You get a significant hit in your second order privacy in the latter case.

[HilbertGilbertson]

And I am trying to explain you all that retrieving them at human scale and rate and bot scale and rate are not the same things. You get a significant hit in your second order privacy in the latter case.

I don't see what that has to do with this issue. In any case, you initially used this thread to propose even deprecating the Nitro Booster integration role - are you really going to suggest that wasn't outside the scope of this issue?! Evidently you have a gripe about boosting and privacy (including wanting to remove even the Nitro Booster role), and you are suggesting fundamental changes in the way that boosting operates, which is not the purpose of this thread. As @sudofox so eloquently explained above, this feature request concerns a very small change to allow data that is already public to be read by bots. You are intervening to argue that the data should not be public in the first place, and want changes that go in exactly the opposite direction.

If you want to argue for an overhaul of the way boosting works, deprecation of the integrated role, anonymous boosting and public boosting, etc, then by all means go ahead. You can open your own feature request where you try and justify it. You can even reference this issue if you feel that it is vaguely related. But this is becoming off topic and unprofessional.

Back on to the issue at hand...

I hope that, over a year having passed since the last update from @msciotti, we can receive a follow-up soon. I would very much like to know whether this request has received any further consideration. As I expressed above, and as many here have sought to demonstrate in illustrating their proposed implementations, the practical benefits (of enabling bots to know how many boosts a user has contributed to a guild) really seem to outweigh any speculative harm. Hopefully the relevant team is able to reach the same conclusion.

[charlieTheBotDev]

Just want to cover this because I don't think it was that explicit.

The fact that there is an endpoint inaccessible to bots that has this information means that any malicious use of this information is already possible by simply loading the data client-side or self-botting (yes, this is against ToS but abusing the data would be as well so why wouldn't they do this too?)

Effectively that means that malicious users already have access, yet legitimate users do not - which seems crazy to me.

I think the privacy concern of someone else's bot on my server having access to this data would be mitigated by adding an explicit permission/server intent to disallow their access to the endpoint (as with the likes of 'View Channels' for instance) which would be disabled by default for all existing bots

Considering all this, and the fact it would be such a trivial change to the API, it's a bit weird that this ticket is still outstanding

[erkinalp]

adding an explicit permission/server intent to disallow their access to the endpoint (as with the likes of 'View Channels' for instance) which would be disabled by default for all existing bots

Yes, I defended that, with an additional guild-granular ability to hide boosts on the user's side. But that per-user setting is crucial, otherwise millions of users will leave Discord, observing that their payment history is open to uncontrolled data mining by bots. There is a reason many people, including a computer engineer like me, use cash in many day to day payments.

[sudofox]

@erkinalp I'd like to make you aware that your continued not-relevant comments here are disrupting this thread. While it may seem that we are against your ideas and your principles for privacy, we aren't. The reason why you continue to receive a negative response is that you're posting them in the wrong place.

We understand that you have issues with the core design of Discord Nitro and Boosting, which makes information like whether or not a user has Nitro and how long they've had it available, as well as whether they're Nitro Boosting (via the profile badge), and that the current design of the feature makes these things visible to other users in a way akin to cosmetics or rank on a Minecraft server.

There are many spaces where you can debate this. But what is not up for debate is that these features are already implemented in a way that makes this information already public. Nitro Boosters make up a very small portion of overall server populations. Bots would have to be in all the servers the user is potentially boosting to even form sizable datasets, and the biggest bots already have to go through a specific vetting process for certain data access above x number of servers. The changes requested in this card would not make any difference in what's accessible.

I have one last point to make: the change from "is nitro boosting" to "has x active nitro boosts" does not reveal any payment history. It's just an integer and it is specific to user's relationship with the guild itself. Furthermore, there are many ways to get Nitro that don't involve the user actually paying for them, chiefly the "Gift Nitro" feature which Discord feels is so important that it needs a button directly next to the file/image upload button in the mobile app UI. Also, there's no way to tell which kind of Nitro they have: regular or classic. Same badge for both. Therefore there is no definitive way to tell if the user is paying Discord or not, or even how much they're paying.

Please feel free to continue championing your proposed design for a privacy-centered Nitro. But take it to a forum where it's relevant. That's all we ask.

[kerryphisher]

I would like to know how many times a user has boosted a server.

[erkinalp]

chiefly the "Gift Nitro" feature which Discord feels is so important that it needs a button directly next to the file/image upload button in the mobile app UI

Gifts should also be user specific, and users should be able to disable gift reception, without the gifter knowing.

[GolfingSuccess]

chiefly the "Gift Nitro" feature which Discord feels is so important that it needs a button directly next to the file/image upload button in the mobile app UI

Gifts should also be user specific, and users should be able to disable gift reception, without the gifter knowing.

Those are all valid opinions; however, our point is that you should voice them in a relevant discussion, or create one if there's not one already.