Always on feature: keep generating new potoken at a X frequency and access using API

[unixfox]

@SamantazFox wants to generate new potokens every X hour in order to improve the user privacy.

So my idea was to have an internal cron that refresh the potoken every X hour. And this potoken and visitor data ID would be accessible on an API exposed through a webserver running in the program.

I know Invidious implemented another "helper" through IPC communication using a socket: https://github.com/iv-org/invidious/pull/4772. But I certainly do not have the knowledge to do that, and I don't think it's worth it for just two lines of text (potoken and visitordata).

Moreover, if it's just HTTP and JSON, anybody will be able to use this project very easily.

@FireMasterK what do you think? what are your takes on this? Would this suffice your needs for piped?

I'll keep a one time off argument for the people that are not looking for the CRON feature.

[MMaster]

Since you mentioned this I will add my 2 cents: my approach would be a bit simpler and more in line with recommendation of restarting invidious periodically - just generate new token each time invidious is restarted.

Since I run invidious and youtube-trusted-session-generator in docker I can just create script that runs yt-tsg, grabs the tokens, replaces them in config file (I use config file mounted to container instead of the env variable) and restarts invidious container. This script can then be called instead of usual periodical invidious restart with whatever you use (cron, systemd timer, etc).

But it is definitely not as robust as what you described and requires invidious restart.

[techmetx11]

@SamantazFox wants to generate new potokens every X hour in order to improve the user privacy.

So my idea was to have an internal cron that refresh the potoken every X hour. And this potoken and visitor data ID would be accessible on an API exposed through a webserver running in the program.

I know Invidious implemented another "helper" through IPC communication using a socket: iv-org/invidious#4772. But I certainly do not have the knowledge to do that, and I don't think it's worth it for just two lines of text (potoken and visitordata).

Moreover, if it's just HTTP and JSON, anybody will be able to use this project very easily.

@FireMasterK what do you think? what are your takes on this? Would this suffice your needs for piped?

I'll keep a one time off argument for the people that are not looking for the CRON feature.

I could maybe make it a feature in inv_sig_helper (opcodes for updating potoken/visitordata, and also accessing them)

This would avoid restarting invidious, while also keeping the potoken and visitordata updated

[unixfox]

@techmetx11

I could maybe make it a feature in inv_sig_helper (opcodes for updating potoken/visitordata, and also accessing them)

This would avoid restarting invidious, while also keeping the potoken and visitordata updated

I'm not entirely familiar with how inv_sig_helper works, but you are telling me that youtube-trusted-session-generator could send the po_token and visitordata IDs to inv_sig_helper?

Then Invidious retrieves the po_token and visitor_data from inv_sig_helper?

@SamantazFox any feedback about this?

[SamantazFox]

@SamantazFox any feedback about this?

I like it. It would mean that we could ship a single container for the "dirty" stuff, and have a single clean interface with invidious!

@techmetx11 I don't know how complicated it would be for you to run that python command asynchronously? Don't mind too much about the bandwidth to google, that is going to be used quite a lot!

[FireMasterK]

Moreover, if it's just HTTP and JSON, anybody will be able to use this project very easily.

@FireMasterK what do you think? what are your takes on this? Would this suffice your needs for piped?

Agree with this, this also makes it simpler for deployments and development since enabling encryption would be as simple as using https. If we're using a custom TCP/socket-based protocol, encryption, and running through different orchestration solutions could become difficult.

[unixfox]

So we, the Invidious team, came to the conclusion that we prefer keeping the communication simple by having an API exposed on HTTP server.

This will allow any project to use it and not directly locked for Invidious.

Since we don't know the future, we may have in the future some implementation not written in python. And having a simple implementation like HTTP server, will allow Invidious to use any implementation that follow the API standard used.