Funkwhale 1.4.0 feature highlight

Hi everyone 👋

It's time for our first semiannual minor release! As mentioned before in a previous update, we've decided to start shipping minor releases on a more consistent schedule so that users aren't left wondering when they can expect something new.

Let's take a look at some of the new things shipping in Funkwhale 1.4.0!

Laying the groundwork for faster radios

petitminion has been hard at work implementing some new features for Funkwhale radios. Funkwhale 1.4.0 ships support for caching radio tracks into Redis. This change lays the groundwork to make radios much faster by keeping the list of radio tracks in-memory. We'll add support for this in the frontend app in an upcoming release.

This change also brings support for a new v2 endpoint for radios, which lays the foundation for a much cleaner and more extensible radio feature in future 🏃‍♂️💨

Maloja plugin improvements

phw updated the Maloja plugin to add more information to payloads. Maloja submissions now include:

1. Duration
2. Album artists

The plugin now also gives users the option to disable server-side metadata fixing if it's causing issues. This change brings the Funkwhale plugin much more in-line with Maloja's specification 💪

New server settings

Funkwhale 1.4.0 introduces a new version of the Nodeinfo endpoint. As part of this new specification, we've added two new instance settings:

• Server Location: The country or territory in which your server is located.
• Moderation languages: The language(s) spoken by the server moderator(s).

This information will be used to give users more information when looking at the pod picker, so it's worth updating these new settings!

Improved superuser creation

Funkwhale is built on top of Django and uses a lot of its built-in tooling on the back end and the command line. Server admins have always needed to interact directly with the manage.py script to perform tasks on the back end, including the initial creation of the superuser account.

In Funkwhale 1.4.0, we've moved this functionality into our own management script. This means that the superuser account must follow the same rules and limitations that apply to other accounts, such as not allowing blocked usernames. We've also taken this opportunity to clean up some of the underlying code for assigning permissions, so consider this a cleanup exercise 🧹

Migrate in-place imports to S3

In the past, migrating from on-server storage to S3-backed storage had one major failing: in-place imports did not update properly. This is due to how files are referenced in the database. While normal imports that are mirrored on S3 can just have the S3 URL added to them, in-place imports use an absolute filepath that makes them a bit more challenging to move.

To resolve this, we've added a new management command to update in-place imports that have been moved to S3. Admins can now:

1. Upload their in-place directory structures to an S3 bucket
2. Run the inplace_to_s3 management command with a reference to the source folder

And that's it! The database is updated with references to the new S3 locations taken from the .env file ☁️

That's it for now! We're still working on a bunch of stuff under the hood to improve our front- and back-end experience for all users. We'll post again once we have a release candidate ready for 1.4.0 🐳