How does Funkwhale's Federation / API Security / Library visibility work?

tarator

Hello,

I have some problems to understand how the settings for Federation, API security and Library visibility work together.

If I have the following settings:

Federation: enabled and public index enabled
API Security: requires authentication
Library visibility: Everyone on this instance

Will it still be possible to share my library with users on other Funkwhale instances?
Is there some documentation where the behaviour of this setting is explained in detail?

Maybe can anybody try to add this my funkwhale library to his instance?

egon0

tarator
I tried to follow your library but only got the following error:
Could not fetch remote library Error while fetching the library: HTTPSConnectionPool(host='funkwhale.projecttac.com', port=443): Read timed out. (read timeout=10)

gcrk

tarator To answer your specific question some additional details:

You can enable or disable the federation, which basically means if your instance is allowed to fetch music from other servers and share music with other servers. This is possible restricted by the two other settings.

You can allow visitors of your page to consume content without being logged in. This might be useful for publishers or creators running their own Funkwhale instance. This way the content is available without authentication. Users from other instances are able to consume the content even if this is disabled, since they are authenticated. On the other side users are not able to see anything if there is no public content. This setting is a technical one, which allows admins to restrict the load on the servers, if they want to.

The library visibility defines per library who is able to consume the content. You can use the library only on your own, share it with your pod or with anyone. Please note you are responsible to follow your local copyright laws if you don't own the rights on the content. This setting is done by the user who uploads the content.

I hope this sheds some light. If you have further questions, feel free to ask!

egon0

egon0 Nevermind. It seems to work now and I have successfully sent a request to follow your lib via one of my funkwhale pods.

tarator

Pperfect, thanks.
I approved your request. Can you see library content/play it?

The problem with the Read timed out. (read timeout=10) is something I also noticed on other instances. This seems to be a common problem with fediverse software. Trying it again 2-3 times normally solves the problem. I also noticed this behaviour on the Diaspora* network.
I think it's caused due to database performance on many pods/installations. The first request lasts sometimes longer due to heavy db-fetches. Once the database has fetched the necessary data, it can handle a subsequent request faster (in less than 10 seconds. I think the timeout should be increased. A default of 30 seconds should be enough.

egon0

tarator Pperfect, thanks.
I approved your request. Can you see library content/play it?

Playing music also seems to work. So all things are set up as you wanted, I think.

egon0

tarator The problem with the Read timed out. (read timeout=10) is something I also noticed on other instances. This seems to be a common problem with fediverse software. Trying it again 2-3 times normally solves the problem. I also noticed this behaviour on the Diaspora* network.
I think it’s caused due to database performance on many pods/installations. The first request lasts sometimes longer due to heavy db-fetches. Once the database has fetched the necessary data, it can handle a subsequent request faster (in less than 10 seconds. I think the timeout should be increased. A default of 30 seconds should be enough.

Yeah, 10 seconds timeout is a little bit low. I also think some sort of redis/memcached caching for some of the federation related stuff could improve everything, but I'm not very deep in the federation stuff and don't know if this would be a viable option to "fix" this problem.

gcrk

This errors occurs due to the views of Funkwhale being synchronous mixed with an insufficient number of webworkers. Its probably not even possible to have enough available and the "real" solution would be to handle this exchange of keys in an asynchronous manner. Its a known issue, but it requires a huge amount of refactoring to make it work.

For now you can simply hit the button again after it failed and it will most likely work than 😉

egon0

gcrk For now you can simply hit the button again after it failed and it will most likely work than 😉

4 Times was a charm on this specific test. 😉

tarator

Thanks for the elaborated answer!

gcrk

I am going to lock this discussion. To help others, feel free to select a best answer to make the information easy available 🙂