After messing around and trying to make the library compile, it would seem that the currently generated protobuf is outdated, along with a new folder that is passed to protoc, causing steam-protobuf to fail its generation.

Only the full Json string response is available.

In the version of the enum_dispatch crate, it seems to use some API that is not public, and breaks. The author of the crate has since changed the package to not use such API. See issue here

The Discord invitation link in SteamHelper-rs/docs/dev/README.md has expired.

The new link should probably be created with the "Set this link to never expire" option 😄

We can find in here a reference implementation in node.js of how the 2FA Codes are generated, but how should we deal with the API call? Ideally it should be in a non blocking way. What do you think?

Steam uses Google's Protobuf system for message serialization and communication, instead of JSON for example. On SteamDatabase/Protobufs repository, the protobufs are often dumped from Steam's internals.

Steam also uses an architecture named "Valve's Game Coordinator", which all messages are sent to this system instead of being directly sent to a game server. This relies on the user's account to be online in order to access the system.

At the steam-protobuf crate, the Protobufs module is set up and we are going to generate Rust code from it in order to serialize our messages to Steam. The ideal way would be to generate all protobufs once per update.

This is crucial to any operation involving Steam's Network and should be done next.

In order to properly code/decode steam messages (client, web API, etc) we need to fully port steam-crypto.

We can base our implementation on similar projects such as SteamKit/Crypto Helper files and DoctorMckay/node-steam-crypto.

This should not be too difficult, but there has to be some sensible checking because there are lots of details.

Now that the client is somewhat structured, we can start to think about how messages coming from Steam should propagate through the client, in a way the end-user can interact with them.

While searching for references, two libraries reactive libraries come to mind:

Teloxide and Serenity

Teloxide code is rather intricate, and I not sure I follow it completely.
Serenity is ok.

The event dispatcher:

The user could register "channels" that he is interested, such as SteamFriends(friends messages, friends persona status changes), or SteamUser(logOn, logOff).
This is what SteamKit2 does, and what message goes to which channel is kind arbitrary.

Then, the user can send outgoing messages, or answer to incoming ones based on his callbacks.

The basic flow would be the following, excluding the initial communication and heartbeat:

inc. socket message -> to packet message -> check if handler exists || -> no -> discarded
																			     \
																				   -> yes -> user callback -> message written on socket

We are open to new ideas!