Mauk [1494436]

Hello, I know this could technically be considered a feature request, but the messages and events API selections [b]can't[/b] be efficiently used for a majority of purposes, so much so I'd consider it an API design bug. Please, bear with me. There are currently 3 selections we can use to retrieve messages and events: [i]Notifications[/i]: Returns the number of unread events and messages [i]Messages[/i]: Returns the list of the last 100 messages [i]Events[/i]: Returns list of the last 100 events [b]There are two main problems with this. [/b]First, the API responses are not gzipped. Downloading both lists takes whopping 30KB, while a gzipped version would be around 5KB. That's a significant bandwidth overhead. It wouldn't be a problem if we could reliably cache the lists, but this leads us to... The second and more important problem: users of the API [b]can't[/b] display notifications without requesting the whole list [b]every time[/b]. The number returned by the [i]notifications[/i] selection isn't enough for us to be able to cache the list. As long as it is different than zero, we have to download the full list. If we are trying to get updates every 10 seconds, à lá City Watch, it's very likely we'll have to request both lists every 10 seconds. [i]Why can't we use the "unread messages and events" number from the notifications selection?[/i] Let's see: T+0min: Request [i]notifications.[/i] Unread messages: 1. Request [i]messages[/i]. Display notification and cache list. T+1min: Request [i]notifications[/i]. Unread messages: 1. Great, we don't need to display the notification because we already cached that... Or did we? Full picture: T+0min: Request [i]notifications.[/i] Unread messages: [b]1[/b]. Request [i]messages[/i]. Display notification and cache list. T+30s: Player reads message. T+50s: Player receives a [b]new [/b]message. T+1min: Request [i]notifications[/i]. Unread messages: [b]1[/b]. Great, we don't need to display the notification because we already cached that... Except we didn't. As you can see, the number of unread messages is not a good indicator and can't be used for lots of use-cases. For us to develop a dependable notifications system, the [i]notifications[/i] API isn't that useful (it fits other use-cases), and we need to request [i]messages,events[/i] every single update. That's okay, really, but the problem then becomes bandwidth: at 30KB per request, it could consume GBs of data per month. I know there's currently no filtering in the API, but instead of adding a generic filtering system, I'd request at least a "timestamp" parameter for lists. Consider making https://api.torn.com/user/?selections=messages,events×tamp=XXX&key=YYY return a list containing only the messages and events with a timestamp greater than XXX. The [i]messages[/i] selection should also include the sender's nickname. Yes, we can get it with the user id, but that's an unnecessary round-trip that adds a ton of latency and bandwidth. I'd argue that 99% of use-cases (yes, I took this out of thin air.. please show me examples otherwise) will not use a message title without a sender name, so why force a second request on everybody? Plus, it wouldn't use that much extra bandwidth, especially if gzipped (certainly much less than a whole new request -- and also, gzip excels at repeated content). Thank you!

Chedburn [1]

Why not just new 'unseenmessages' and 'unseenevents'? That only show messages and events that have not been seen on Torn by user?

Chedburn [1]

`timestamp` has been added for messages and events. On messages, I've also changed "from" to "ID" and "name" of sender. I expect this will be live tomorrow.