* Start work on extracting remote communication
* ok
* Dockerfile fixes
* More fixes
* Prepare /Api/Announce and /Api/HeartBeat
* Decrease publish race conditions
* OK
* Misc
* Misc
* Misc
* Move Steam group part back to ASF core
* Finally implement match actively v2 core
* Update RemoteCommunication.cs
* Use single round exclusively, report inventories more often
* Use randomization when asking others for assetIDs
* Add support for license and crowdin
* Kill dead code
* Fix return type of inventories
* Fix responses for good
* Unify old backend with new
* Report whole inventory, always
Helps with optimization on the backend side in terms of inventory fetching
* Update RemoteCommunication.cs
* Determine index of each asset and tell server about it
* Update AnnouncementRequest.cs
* Fix ASF screwing up with the order
* Fix warnings
* Misc rename
* Final logging touches
* Add --input-cryptkey argument
* Improve readability of argument parsing
* Make the compiler shut up
* Remove German translation again
* Revert switch expression
* Fix unused cryptkey
It seems to be late
Previous implementations had several problems when dealing with trade holds:
- User could've configured max trade hold duration to 0, and still accept trades with hold when he's the cause of it, this is unwanted
- There is virtually no way to ensure that the other party is willing to accept our trade hold even if we allow it, so expose that detail.
This precisely answers quite rather but not impossible situation of having a trade hold with ASF 2FA, e.g. due to moving authenticator, but we're also now ready for "perpetual" trade hold with ASF 2FA, in case it ever happened.
This way, we:
- Expose to other users our max trade hold duration preference
- Users validate both their own and listed user's trade hold, and if it exceeds either their own or user's limit, bot is not considered for matching
- It also resolves problem of accepting trade offers from other people when we're on trade hold ourselves
My latest "research" resulted in learning that under the hood, Steam unix time seconds is bullet-proof not only for year 2038 but for uint range as well. While I do not expect to be alive by 2106, let alone ASF still being operative, it makes sense to base our time on the correct backend implementation regardless.
Small breaking change for people using `GetUnixTime()`.