Dr. McKay

I just thought of a potential issue with using just the trade URL. Presently you have to construct an offer using a SteamID explicitly. Getting the ID from the URL opens sloppy implementations to the potential for users to send offers to other users. For example, a typical implementation currently has a user sign in through Steam's OpenID, then prompts the user for their trade URL. Both of these are sent to the bot. The offer is created using the authenticated SteamID, and the token is extracted from the URL. If the trade URL isn't for that user's account, the offer just fails. With the proposed new API, a user could enter someone else's trade URL. If the implementation doesn't check offer.partner, then unrelated users could receive unsolicited offers. Of course, we could add a note to the documentation to check offer.partner when you use a trade URL, but I don't really like the loss of the built-in safeguard.

The way I generally do it is set up a bot in node.js using steam-tradeoffer-manager, and create a Web server in that bot which accepts commands to send trade offers. Then use curl in php to command the bot to send an offer. I believe there are php libraries for interacting with Steam, but I don't personally think php is well suited for that task.

Yes, that will work fine. Note that on Windows, the sentry (ssfn) file that the client uses is hidden. The visible one is a decoy. The sentry file used by the client is named in config/config.vdf (if I remember correctly).

You can already create a TradeOfferManager for separate accounts within the same application.

I don't understand.

Here's an idea. Three options for createOffer(): manager.createOffer(steamID); // create an offer without a token. you can set it later manager.createOffer(steamID, token); // create an offer with a token manager.createOffer(tradeURL); // automatically extract the SteamID and token from the trade URL

Moved to general. I'm not sure what the limit is, to be honest. I believe that if you keep it to around 0.5 req/sec you should be good.

I've thought of that, but cookies can come from any source. For example, node-steam-user or node-steamcommunity, but there are also third-party sources. Really the refreshing should be done by your app.

That's rather difficult, as Steam just kills sessions whenever it feels like it. #1 is possible, although not likely to happen for v2. #2 is doable, although I'm not incredibly happy with just cramming a bunch of stuff into createOffer() #3 is doable without any breaking changes, although it's already relatively easy to implement yourself (just call getOffers() and check each one)

I'm planning on releasing a new major version of steam-tradeoffer-manager of v2.0.0. So far, what I'm planning to do is: Move token and message out of the TradeOffer#send() method and into methods like setMessage and setAccessTokenHard requirement for node.js v4.0.0 or later (currently package.json suggests that you need v4 or later, but v2 would make this an absolute requirement)This should be addressed.Since this is a major change and they're meant to be few and far between, there's no point in wasting it! If you have any suggestions of stuff that could be added, or things that have just annoyed you, I'd love to hear them!