Currently the only way to revoke a access token / refresh tokens is to ether for the user to remove the oauth app from they account or a oauth app to delete the app itself witch also revoke all tokens. If you have a access token leaked within the app you would need to revoke everything even if just one token was compromised. With the RFC 7009 it's a own spec ontop off the oauth2 spec that adds in a endpoint that allow to revoke just one token.

You also have the problem with client side apps that use implicit tokens. When the app/site ask to generate a implicit this token is valid for a year. If the user then want to logout off this site this token is still valid and often just deleted from the cookie / local storage. This open up for that a token that shuld have been revoked when the user told to "logout" is still valid and if someone catpured this token it's free to use whiout anyone knowing.

There are more info about this at https://tools.ietf.org/html/rfc7009
Other big API's like google has this.

Today's Mixer Android/iOS app update disables FTL by default, which will cause serious problems for any MixPlay games that depend on a low latency stream.

Our main MixPlay game will now become unplayable for anyone on mobile, unless they've re-enabled FTL. Obviously we'll be telling people to enable it, but there's likely to be a large amount of player churn with people thinking "well, this thing sucks" and dropping out before they realise it's because FTL is disabled.

Whilst the logic for having FTL disabled by default on mobile is understandable (and probably even preferable for non-interactive streams), it would be very helpful if developers could set a "requires FTL" flag on their MixPlay projects that either automatically enables FTL when a viewer loads the stream, or shows a warning dialog ("This interactive stream may not work properly with FTL disabled. Would you like to enable FTL [Yes|No]").

Hello. I'm Vien from GoStream Jsc. We're building a livestream tool that allow people to add image, text even video while live streaming.
We also support multiple cameras, from high-end webcam, DSLR to smartphone ios and Android. You can use any device you have as an extra camera, in the same location or not.
The best feature is deep linking with social network like Facebook, Youtube, Twitter. The host can ask viewers a question then viewers comment to answer. And we can show the result on the live stream. Even pick a winner by lucky draw. Many mini game we're developing.
Demo https://www.facebook.com/saharkalilvines/videos/d41d8cd9/2277900149105322
I think we can cooperate , please contact me if you feel interested, email : viennt@gostream.vn
Thank you

TL;DR: Add events in the API for timeouts and bans.

Currently, the API is limited for what events we can see that moderators have done, we are able to see deleted messages, chat cleared, and purge events, however, we currently are unable to see ban or timeout events. As a mod myself ban and timeouts are definitely a big part of being mod and I would do this a lot, I also know that sometimes streamers like to ban/timeout for different reasons and it would be nice to have an event that shows who banned or timedout a user so the streamer can talk to the specific mod about their own rules. Mods can also misbehave and abuse their powers, currently, it would be almost impossible for the streamer to pin down the moderator doing the actions of banning more specifically as a purge event will be thrown when a timeout occurs and that is available in the API. Adding the ability to see these events would be very helpful for tracking what mod does what in your channel.

With the Beam Chat Bot API, you get several pieces of information about a particular user chats in your channel. You can figure out if they are a sub, moderator, pro user, staff, etc.

What you can't find out though is if they are a follower.

Most of the bots on beam do raffles. The majority that do raffles, also support "subscriber" and "follower" based raffles as well.

The Chat API tells you a person is a subscriber, but doesn't tell you if they are a follower. The only way you can figure out if a user is a follower is to use services like the Beam REST API and possibly Carina to track newer followers since the connection to the chat was made.

The problem with the REST API is the way you have to do your queries. To pull list of all the followers within the channel, you can only pull 50 at a time. So if we take the case of someone having 5000 followers, that's 100 REST API calls to pull follower information.

You can only do 100 queries within a minute due to rate limiting, so when trying to do giveaways, you're gonna hit issues with this if you're method is to pull all followers at one time for caching.

Other APIs allow you to query a user for all the people they are following. While the rate limit is higher, there are definitely scenarios where this is unmanageable. The call to do this is 500 calls a minute to query each user about their followers (and you can only get 50 at a time). So in the case of a FOLLOWER based raffle, if someone enters that has 5000 followers, and you're attempting to figure out if this particular user is following your channel, you can potentially waste up to 100 of those queries with just one check.

Right now, a few of the bots are using MULTIPLE IP addresses to get around the slowness and rate-limiting issues of the REST API to simply check if a person talking in your channel is a follower or not.

The new feature request is to add "FOLLOWER" as a role in the Beam Chat API along side of "Sub, mod, user, pro, staff" and others.

As soon as you have a streamer that regularly gets THOUSANDS of people in their channel and they want to do a follower-based raffle, this is going to greatly impact the ability to query the REST API.

Putting the FOLLOWER as a role within the Beam Chat API will greatly reduce traffic to the REST API endpoint server each time someone wants to run a follower raffle, and as a streamer who has been on this beam for awhile, EVERYONE likes to run follower raffles.

Please make this happen!