Any way to limit bandwidth usage?

[pizzaserved]

Summary

Limit bandwidth usage

What is the feature request for?

The core library

The Problem

2 bots have already used 2GB of bandwidth in 5 days. It adds up if you use proxies. Is there a way to only subscribe to channels that interest me? It looks like the on_message[_edit] is called for every channel the bot is in. Can we limit it to only 1 channel/dm?

The Ideal Solution

• Limit on_message subscriptions to only 1 channel/dm
• Maybe even a feature to manually start listening for messages, and then stop listening. I have some state managment and I'm only interested in messages while I'm in a particular state (say 'active' out of 'starting', 'idle', 'active', 'stopping', 'stopped'), so most of the bandwidth is wasted

The Current Solution

No response

Additional Context

No response

[visions4k]

im on mobile right now but i attempted to write a sample, its untested but should work

def restrictchannelEvent(channelID):
    def decorator(func):
        async def predicate(*args, **kwargs):
            message = args[0]
            if message.channel.id != channelID:
                return
            await func(*args, **kwargs)
        return predicate
    return decorator

@restrictchannelEvent(1234)
@client.event
async def on_message(message):

if you do end up testing, let me know what happens

[pizzaserved]

im on mobile right now but i attempted to write a sample, its untested but should work

def restrictchannelEvent(channelID):
    def decorator(func):
        async def predicate(*args, **kwargs):
            message = args[0]
            if message.channel.id != channelID:
                return
            await func(*args, **kwargs)
        return predicate
    return decorator

@restrictchannelEvent(1234)
@client.event
async def on_message(message):

if you do end up testing, let me know what happens

thanks, is there an alternative for when subclassing discord.Client?

and does this actually prevent the message from being received, thus saving bandwidth? at a closer look, it seems it just prevents on_message from being called, but the data it is indeed received by the machine, since you have access to message.channel.id (and thus to other fields from it)

[dolfies]

Check out the brand new guild subscription docs!

[pizzaserved]

Check out the brand new guild subscription docs!

nice! is this a new api from discord or an optimization in this library? sounds good, anyway.

so if I get it right: once I have a reference to a guild object (a DM in my case), I'd use Guild.subscribe() and on_message and on_edit_message will only get fired by members of that guild?

[dolfies]

nice! is this a new api from discord or an optimization in this library? sounds good, anyway.

It's kind of both. They recently updated the guild subscriptions API so I decided to properly implement it in the library and expose it for power users!

so if I get it right: once I have a reference to a guild object (a DM in my case), I'd use Guild.subscribe() and on_message and on_edit_message will only get fired by members of that guild?

on_message() will always fire for DMs and guilds with less than 75k members, but yes you would use Guild.subscribe() to subscribe to guilds with more than 75k members.

[pizzaserved]

nice! is this a new api from discord or an optimization in this library? sounds good, anyway.

It's kind of both. They recently updated the guild subscriptions API so I decided to properly implement it in the library and expose it for power users!

so if I get it right: once I have a reference to a guild object (a DM in my case), I'd use Guild.subscribe() and on_message and on_edit_message will only get fired by members of that guild?

on_message() will always fire for DMs and guilds with less than 75k members, but yes you would use Guild.subscribe() to subscribe to guilds with more than 75k members.

oh, I see.. so basically there's no difference for cases like mine, i.e. it's not a bandwidth saving feature. it's a pretty odd decision for them to allow people pull all their channels at once, while most of the time you just want 1 channel

[dolfies]

nice! is this a new api from discord or an optimization in this library? sounds good, anyway.

It's kind of both. They recently updated the guild subscriptions API so I decided to properly implement it in the library and expose it for power users!

so if I get it right: once I have a reference to a guild object (a DM in my case), I'd use Guild.subscribe() and on_message and on_edit_message will only get fired by members of that guild?

on_message() will always fire for DMs and guilds with less than 75k members, but yes you would use Guild.subscribe() to subscribe to guilds with more than 75k members.

oh, I see.. so basically there's no difference for cases like mine, i.e. it's not a bandwidth saving feature. it's pretty odd decision by te guys from Discord to allow people pull all their channels at once, while most of the time you just want 1 channel

The difference is you don't get member events for guilds you're not subscribed to, which is a pretty big bandwidth save

[pizzaserved]

this really confused me now, since you said "on_message() will always fire [...]"

can you kindly clarify what should I call to minimize bandwidth as much as possible while only receiving the messages from a single DM?

subscribe/subscribe_to?

[astolfoismywaifu]

@pizzaserved I would recommend to look at the documentation which explains it in detail. To save the most bandwidth set guild_subscriptions to False when creating a Client then subscribe to whatever servers you want to listen to (taken from here. I don't know if dms work in the same way but thats the basics. It also helped reduce lag a lot for me especially on accounts with many high member count servers.

Edit: Just realized the docs were already linked above ... oops