Implementation of item broadcasts on source servers

[KTVS]

I was curious how the server implements those chat messages when someone acquires an item from a trade, and I ended up stumbling across a sourcemod plugin that you made a little while ago here. The questions I have are pretty specific, but seeing this plugin made me think you might have the answers. I mentioned in another thread that I was running into rate limit issues for Steam's inventory, so these questions all spawn from the goal of avoiding those limits.

Is the fact that a user acquired a new item told to the server by the user themselves? Or is the server forwarded these events from steam for all user's in the server?

If the item notifications are sent by the client, what's stopping someone from spoofing these messages?

If the server gets special events, is it possible to write an 'inventory listener' program which is a partial implementation of a source server for the sole purpose of knowing when a user obtains new items? If so, would it be able to listen to an arbitrary user? Or is there some kind of authentication information that needs to be forwarded by the server to steam in order to subscribe to those itemAcquired events for each user?

[Dr. McKay]

I've never actually first-hand tried to figure out how servers are notified of items being acquired by users. That plugin just hooks the message that the server sends to its clients (which is what triggers the native chat message), suppresses it, extracts the data from it, and sends its own messages. It's an event called item_found, and it's generated by the server in response to some notification that an item was found.

The following is my best guess as to how it works:

When a TF2 client joins a game server, the server authenticates their Steam app ticket. Once that's done, the GC sends the full contents of the player's inventory to the server, which keeps it in a memory cache. This is necessary so the server can make sure you actually own the weapons and cosmetics you're equipping. As long as the player is connected, the GC informs the game server in real time of updates to the player's inventory (in the same way that the GC informs the player's game client of updates to its own inventory). When a player connected to it receives a new item, a game server receives an "item created" message (SO_Create), and then the game server extracts the item's data (using the origin field to determine the acquisition method), and then broadcasts item_found to all its clients.

The biggest problem I have with that explanation is that I don't think the origin field changes to "Traded" when an item is traded for, so how would a game server determine if an item was traded for? Maybe the origin field in the GC's item data changes to Traded but the origin field in the API doesn't or something.

Edited December 27, 2021 by Dr. McKay

[KTVS]

Based on your assumption, it really comes down to if Steam is okay communicating inventory updates to a non-secure server. Correct me if I'm wrong, but it looks like the authentication of the app ticket only needs to be done on secure servers, and as long as that authentication step doesn't need to be 'passed on' to whatever inventory server is spitting out item events, then it might be possible to subscribe to an arbitrary user's inventory events from an insecure server.

This at least gives me a bit of hope to keep pursuing the idea.

[Dr. McKay]

Apptickets need to be validated by all servers, secure or not. I highly doubt that you'd be able to subscribe to an arbitrary user's inventory.

[KTVS]

Ahh I see. I also suspected that it might not be possible since that would feel like an oversight if it was, but I was looking for a concrete reason to believe that it wouldn't work. If app tickets must be validated, then that would be a reason.