The point of an open source federated communications tool is that you can make your own federation if you want to, with your own policy.

Yeah, but it clashes with the mail analogy that is used to promote federation.

But what makes me wonder is the choice of words "based on matrix" instead of "using matrix". So even if you wanted you couldn't federate.

Assuming they do wish to maintain interoperability, you can use matrix while extending the base "events" that are sent to clients. So it may be that essentially Teamspeaks client/server will support the main specification "m.room" events, such as joining, leaving, adding/editing titles, etc, while also exposing their own "com.teamspeak.event" addons (which might be invites to voice channels or recordings or something specific like that), which so long as the client says "oh hey, I know those, speak them to me" will work fine, and any other client could still get the basic chat functionality.

I'm not sure how exactly this works with server <-> server federation, I've never actually looked at that spec.

https://matrix.org/docs/spec/client_server/r0.6.1#types-of-r...

Reminds me of Jabber and how GTalk was first able to talk to anyone out there before they locked it down with their custom modifications to the protocol.