td session storage path

[zizhuangfly]

background: I use tdlib for my private usage, currently I run the program by jupyter notebook of online service for some scheduled job. question: the runtime is all fresh every time it runs, so when it's scheduled to run or restarted, it need to be supplied with confirmation code or password to login and authenticate, as telegram will treat is as a new device and fresh session. I suppose that there must be some session/token file being saved after login, which I can stores and supply to tdlib to avoid inputing codes, thus make the job run automatically without any human Interaction. so if that's the case, where is the session file stored? and how can I tell explicitly to tdlib to use it?

[levlam]

Telegram isn't supposed to be used and TDLib can't be run in storage-less environment. Telegram apps must store state and continuous write and read access to a writable directory is required for this.

[zizhuangfly]

yep, I totally agree with you. the environment is not as fully storage as general pc or vps/server, but It is not completely without storage system. I can store the session/token file in somewhere (like kv store or something the system supplies) for later use, which I can store and copy to the target path before running TDLib so that telegram will take it as the same device and session as before. So the question is where I can find the session/token files after log in, maybe the file is a sqlite db or a collection of files, and it just does not matter. Hope I made it clear, if not, please tell me, I will try to explain with more details as I'm not so good at English. ps: I can succeed log in using TDLib in that system and that is to say the system supply a writable and readable storage for use, it is just not persistent but temporary for one-time use, which I can manually handle as above. Thank you!

[levlam]

This is not enough. There is nothing like "token" in TDLib. The full state must be persisted.

[zizhuangfly]

OK, so where the full state is stored, whatever the stored format. I can dig in and duplicate the state.

[zizhuangfly]

even if the state consist of some generated files and hardware recognize information like mac address, It's ok. please help.

[levlam]

You can't duplicate the state, Telegram can't work this way. You must use the modified by the previous run state for the next run.

[zizhuangfly]

OK, got it. after reading the doc, I found the database_directory and files_directory parameters which are just what I am looking for. I said "duplicate the state" actually means storing files for later use and then copy/download back, not manually manipulating the files. sorry for not expressing clearly. this is what I'm gonna do: save another copy of the binlogs/sqlite db to somewhere after telegram.stop() (as it's temporary and will disappear after restart) , and when restarting, copy back the backups from there before log in. I've tried and it works. could you tell me what is the default authenticate TTL before it expires and does it support to be configured through the api?

[levlam]

If you persist exact content of the database directory between launches with all modification done during run time, then it should be fine.

Everything is the same as in all Telegram apps. If session is active, then it is valid forever.

[zizhuangfly]

some more questions:

1. if I don't care or need any chat history like msgs/files/stickers, and never call get_chat_history or some other similar functions, then the msgs/files/stickers won't be auto downloaded/retrieved from server in the background by TDLib, is it true?
2. If I set use_file_database, use_chat_info_database, use_message_database all to false, then whether I call such involved query functions or not , TDLib won't save msgs in local cache/files, is it true?
3. If TDLib do download/save a copy of msgs in local storage, then does TDLib has any public "clean-up" api support? eg. clear all chat history or clear by chat_id

[levlam]

1. It depends. Generally, a lot of data must be received from server.
2. The flags disables storage of the corresponding data between app restarts.
3. No.

[zizhuangfly]

thank you so much for support! ♥️♥️