Archisteamfarm: Ability to get gifts via gift token

[TheSergiooo]

Hello there! Not a long time ago i mistaked #499 as something i've met before. The point is that sometimes its proficient to buy game directly in steam, send it as a gift to your bot, and farm it out. And all hapens well if you have your bot in your freind-list. But lets look at one of these situations:

1. You dont have bot in your freind-list.
2. You've got a gift from some site/service in a token form

Then you would have some problems with redeemeng a gift.
Also i would like to say that i dont have my bots in my freind-list. I just really like to keep it short.
So, what i did, is i created a new function IsValidGiftToken with regex ^[0-9A-F]{16}$. Then implemented some simple code in ArchiWebHandler:

string request = SteamStoreURL + "/account/ackgift/" + token;
return await WebBrowser.UrlHeadRetry(request).ConfigureAwait(false);

(got a crash after i removed 'const' ,not sure if it)
Next, there were no problem to implement a new function !getgift <Bot> <token>
It works just fine. Bot accepts and redeems gift shortly after executing a command. This command helped me to redeem some gifts.
So why i didnt a PR? Dirty code, <Bot> instead of <Bots>, no response check, possibility to merge it with !redeem.
I was trying to fix it all by myself, but i stuck at the point where i was thinking: shall i forward or distribute a token? Right now im pretty confused with "How its all should look like?", basicaly because i haven't enough expirience to code it in a good way.

P.S. I've got a strange crash after recoding. Not sure now if UrlHeadRetry could stable work with not constant string, tested well only with const string, Anyway, all you need to do is a GET with cookies.

[JustArchi]

Command-wise I don't see it as an issue, but you should definitely check if you can't achieve what you want already with reverse-engineered ArchiHandler.RedeemGuestPass() which is being used for implementing AcceptGifts in ASF. Using AWH for web-based commands should be the last thing to do, once we're sure there is no better way to do this from within Steam network.

Regarding any kind of forwarding and distributing - this will be only possible if gifts include information about what packageID they're about to add. If they lack that info, don't even bother. I don't know if it's possible to get that info from the gift itself - you tell me.

[Ryzhehvost]

First of all - I'm still not sure if this is the best idea. If we ever implement #499 there will be certainly a better way, but so far we not have it the suggestion sounds legit.

What I wanted to tell - I doubt that forwarding possible without implementing #499 first, because, if I remember it right (you may want to check it), after you try to accept the gift - token gets invalid, even if you didn't actually received the gift. Also, this will interfere with current accepting gifts implementation (it only works for you because of this, because just accessing /account/ackgift/<token> is not enough for redeeming). Because of this I think it's a bad idea to try to merge it with !redeem, in the best case we will achieve different behavior of command depending of what we send as a parameter, and that's not a good way - commands behavior should be predictable.
I don't even know if we need this command with syntax for multiple bots at all. I just realized I never tried to use !redeem with both multiple keys and multiple bot names, I should really investigate how it works, maybe this will give me an idea about usability of similar command for gift tokens.

And, in any case - then there is one more problem to be solved - regexp ^[0-9A-F]{16}$ can match bot name, if the name is exactly 16 characters. Unlike keys (they at least have dashes) this can cause troubles to users who use descriptive names for bots. Can't say how important this issue, as I have no statistics of bot naming. Maybe @JustArchi could parse bot names with statistics = true and check if we have something that match this pattern?

[JustArchi]

Bot name is not important, every command supports n arguments, and n + 1 with bot name included - this is no different. Yes, there are many commands which can't make use of <Bots> and would be fine with <Bot> alone, but actually implementing exclusive support for <Bot> syntax when <Bots> is already implemented is waste of time - both machine during compilation, and your own one as a programmer.

I don't like this idea that much either and I definitely won't accept half-broken behaviour - if we ever want to add command like this, we must answer following mandatory questions:

• Is it possible to use ArchiHandler.RedeemGuestPass() for redeeming? If not, there is a very good chance this should not be added in the first place, unless there is practical example for this (I'm not sure how ackgift works, if it just uses token and then forwards gift to guest passes that AcceptGifts can parse, then it's OK, since we have logic for that already, and it's just adding one more gift to the queue).
• Can we read packageID from the gift? If not, any forwarding/distributing is out by definition. And if we can, are we able to keep gift unused and forward token further? If not, any forwarding/distributing is out of the definition as well, unless we added #499 before, and adding that is not on TODO list at the moment.

And definitely this is out of !redeem function that is already 3x longer than it should be. If anything, this should be another command.

BTW, @Ryzhehvost - #499 has nothing to do with it, since if we even implemented that, it would be simply sending gifts through direct gifting, and ASF already has support for it in AcceptGifts - those two issues are mutually exclusive, and do not depend on each other.

[Ryzhehvost]

499 has nothing to do with it

It has, because

those two issues are mutually exclusive

And #499 is better and more native implementation. If we will have #499 - this function is useless.. But I'm not ready to start development of #499, and if I understand it right - you don't want to implement it in the near time too (and I completely understand why). So, in the meantime we may have this, if @TheSergiooo thinks (at least) he will use it, and when(if) we implement #499 - we can just deprecate this command (or leave it as is, if it does not cause us any problems).

I'm not sure how ackgift works, if it just uses token and then forwards gift to guest passes that AcceptGifts can parse

Yes, that's how it work. If you receive the gift by email and follow the link from it in the web browser, where one of asf bots logged in - you will never be able to redeem it, because after the link is opened ASF will see it in the queue and redeem it before you are able to press "accept".

And if we can, are we able to keep gift unused and forward token further?

No, we can't. Just checked it, second account gets this error:

An error was encountered while processing your request:
There was a problem redeeming the gift. Please try again later, or contact Steam Support for assistance.

[JustArchi]

Then solution proposed by @TheSergiooo is fine by me - we'll have a command that requires AcceptGifts to be set to true and allow to "claim" gift with given token for bot account, which will be automatically redeemed. This is the whole point of this, and it sounds good to me, definitely a lot better than implementing #499 - and a lot easier too.

[JustArchi]

And due to complexity of this, there is no forwarding included whatsoever - if we ever want to implement any forwarding, it should be implemented in a function that is dealing with AcceptGifts natively - this command would just "claim" the gift and add it to the parsing queue.

But I do not recommend starting any work on forwarding, unless you want to reverse-engineer yourself. A command for claiming gifts is OK though, since it's only a bridge to ASF logic that is already implemented, but forwarding/distributing would require a lot of work which I don't even want to do myself, and in this case it's usually too much to bother yourself with (which doesn't mean that I wouldn't accept such PR of course).

[Ryzhehvost]

On a second thought - I'm unsure if this idea will give any profit.

Let's see, to send gift to the bot this way, one will need:

1. Buy a gift, and send it to your own email.
2. Open email, and copy token from the gift link
3. Send the command with token to the bot.

Without this command, one will need:

1. Invite bot in question to friends.
2. Buy game and send it directly.
3. Remove bot from friends.

Unsure which way is faster and more convenient. Of course, it will be much more useful if you received gift from someone or bought a gift link on some gray market.

Actually, while thinking about this suggestion and #499 I came to one more idea, but I'll put it to separate issue, to not clutter this one.
Nevermind. I tried to go into details of it and found it not so brilliant as it seemed.

[TheSergiooo]

First of all, i would like to thank you very much for your response. I've got answers i wanted.

But I do not recommend starting any work on forwarding, unless you want to reverse-engineer yourself.

Thats a relief. I've already done some code that works just fine without forwarding and then stuck. Now i will try to clear my code and make a PR with !getgift

On a second thought - I'm unsure if this idea will give any profit.

I would like to implement this feauture not because it would be easier to send gifts - no, it's because right now, only way to redeem a gift token is trough steam website. And even if you would get a small amount of tokens, maybe just 10, then redeeming would start to become a headache

[KazeZlat]

@JustArchi we can get appID or subID from game picture src in <img> tag in email (if it exists)

Just checked my email with tons of different emails with different games:
SubID - http://cdn.akamai.steamstatic.com/steam/subs/49788/header.jpg?t=1447456033 (giftmail with Deus Ex Collection)
AppID - http://cdn.edgecast.steamstatic.com/steam/apps/513320/header.jpg?t=1488452427 (giftmail with Alice VR)
And it always have package name (like Deus Ex Collection (RU/IN/CIS)) in alt attribute.

^[0-9A-F]{16}$ can match bot name

@Ryzhehvost just add /ackgift/ to regex and then remove it from result string.

[Ryzhehvost]

@KazeZlat asf does not get emails, so it can't parse it contents.

[KazeZlat]

@Ryzhehvost just take a look of what I wrote in #499 (oh wait, you have already :D)

[JustArchi]

Now i will try to clear my code and make a PR with !getgift

:+1:. I think !ackgift command would be better, but that's misc naming though. Remember to requrie AcceptGifts in this command, same like !input requires Headless.

[Ryzhehvost]

With recent changes from Valve it's impossible to send gifts to email, and thus no way to get token, am I right? If it is so - this issue is probably obsolete and can be dropped.

[KazeZlat]

@Ryzhehvost you can still do this for previously bought gifts, but yea, someday it can be dropped.

[JustArchi]

Due to recent gifting changes from Valve there's no point working on this anymore, if nobody coded anything regarding this yet. Therefore I'm closing this issue, at least until it is possible to make use of it for newly bought gifts.