I think it would be pretty cool if there was a way for different polyphony forks to interop.
Say, for example there are two forks of Symfonia named Symfonia A and Symfonia B, which both implement their own features not already present in the "base-set" of features dictated by the Spacebar protocol.

If a user connects to Symfonia B while having their account on a Symfonia A instance (assume that federation exists), it would be cool if that user could access the additional features which Symfonia B offers, even though they created their account on Symfonia A.

Say, symfonia B has an additional "Birthday" attribute, which is publicly visible on your profile. Maybe Symfonia B could relay information on how this additional attribute looks like through some sort of standardized API, so that the users' client can know how to deal with this information?

This idea is just a rough mind-sketch, but hopefully a cool one :)
I'd love to hear your thoughts @Zert3x

I'd like to set up unit/integration tests for the server, where applicable. These things have saved my butt countless times in other, collaborative FOSS projects, which is why I'd like to see them here too.

A way to serve a message to different users, or different views of the same channel, without copying the message in the database.
Server-side counterpart of polyphony-chat/chorus#481
Design can be copied from spacebarchat/server#291

In my opinion, a chat service can only be released for public use if there are adequate moderation tools for instance moderators and admins to use. The Polyphony Server should come with the tools necessary to handle the day-to-day business on an instance with a lot (say thousands, if not more) users and protect instances from abuse

Thinking about the actions listed at https://docs.joinmastodon.org/admin/moderation/ might be a good start, although things like user storage limits and manual account approval already come to mind for features not found on the linked website.