Kraken equivalent[1] of Get Users Follows offers a way to sort query results by either creation date, last broadcast or login name. There's also a way to sort results in either ascending or descending order. Helix however doesn't offer any ways of sorting results of your query and results are always shown descending without giving you the option to get those in ascending order.
In case you need to fetch exactly the first follow or get followers that have been live last, it becomes problematic if your query has lots of results - you'd need to paginate through all of them and then go through all of them again and sort them on your end. Please add those features to Helix endpoints if possible.

[1] https://dev.twitch.tv/docs/v5/reference/users#get-user-follows

Having written one and a half client libraries for IRC now, I wish Twitch Chat was exposed over a more consistent protocol.

• Allow read-only access to chat messages (and other related live data and events) via PubSub, with clean re-designed JSON Chat message payloads
• No longer identify channels and users by their login name, use user IDs for all purposes
• Send messages via an API call

Most importantly, I would expect a redesigned API to think of edge-cases in a better way than IRC currently does. For example, what happens on IRC if a channel gets suspended, or a channel you are joined to changes name? What happens if the user you are logged in as changes their name? What happens to the connection if the oauth token you logged in with is revoked or expires? Those are just examples of edge-cases that occur in real applications, and that are not documented yet crucial to providing a stable consistent connection to chat. You would expect a client library to handle these things.

It would of course also be nice to fully observe chat states such as your own moderator state, your own badges, your own login and display name, your own color, your emotes, etc. in a clean way.

Add a occured_at timestamp that tells you when the content in the clip was actually streamed.

Clips API objects have a created_at timestamp which is when the user made the clip but this can be months or years off from when the content in a clip actually happened if a clip was made from a VOD which makes created_at useless for a lot of use cases.

Even for clips from livestreams this is an issue as users can cut clips from a 2 minute (90 secs?) window so the actual content of two clips with the exact same created_at timestamps can be completely different, which is surprisingly common in streams of fast paced games.

occured_at can sometimes be calculated manually with the VODs created_at timestamp (from /helix/video) + the clips vod_offset (from Kraken clips API, helix doesn't have vod_offset) as long as the vod is still alive. Once a vod expires (or is deleted for channels with permanent VODs) it's not possible to calculate that timestamp for a clip anymore.

Use cases:
* Displaying clips in any form of time based ordering or filtering
For example nobody wants to see a clip from two months ago when filtering for clips from the last week just because it was made three days ago from an old VOD
* Deduplicating clips with the same content
* Finding clips that happened right before or after a clip

Basically for almost anything you'd use created_at for occured_at would probably be better, having to do all of that with created_at gives a terrible user experience as the results will be off from what a user wants or expects.

Pagination on some Helix endpoints, such as Get Streams, is just bad, and can lead to endless looping. So here are some suggestions.

The goal of any solution would be for any dev paging through any Helix endpoint to have a clear and reliable indication of "there are no more results, you can stop pagination". And if for whatever reason that can't be indicated, the endpoint should safely return an empty data array rather than looping the user back to the start.

Currently, the final page of the Streams endpoint still contains a cursor (for use in before) so simply relying on the lack of a cursor can't work.

One solution may be for Twitch to validate the cursor on their end, so for example if that final cursor is used as the after value, rather than returning to page 1 (like what would happen with any request lacking or having a bad after value) there could be a check and if that cursor isn't appropriate for paging forwards then there could be a response with just an empty data array, and a cursor that allows paging backwards still with before but the same after object in the cursor so any repeated use will just return to the same final/empty page rather than the start.

Another suggestions that has come up would be for the inclusion of an additional pagination value in addition to the already existing cursor that the endpoint returns that can be a simple flag to indicate if there are more results (this could also be used to indicate if you're on Page 1, so unable to use the before param).

A final suggestion would be is if it's possible to encode metadata related to the pagination state in the cursor, so Base64 decoding it could give a dev details such as if they're on the final page, their current page, etc... I don't think this would be the most user friendly option though, as ideally devs shouldn't need to touch with the Decoding of a cursor.

All of these ideas should be non-breaking, as they don't change has cursors function, from the dev side of things and I think the first option, of the final cursor returning a page with an empty data array could be best as this could stop any endless loops in existing implementations, where as additional flags wouldn't help until the dev integrates that into their apps.