There are a few different potential concepts here:

1. Multi-tenant app. One database, multiple sub-communities. This can be done by configuring a context to work as a sub-community, with its own subdomain, logo, feed and members. Each Space has same core schema, but presents as its own mini-network depending on what fields can modified by admins. Many apps like Circle, Skool, MightyNetworks work this way. We have a development version of it running on UNA.SO. There are some flows we need to test before releasing, so it's likely to be one of the early v15 features.
2. Multi-app network. Separate databases, different schemas, same Auth. This is possible now with SSO - setup separate networks, run one as an oAuth ID Server, and others as Clients. This way users can login to networked communities with same ID. It is possible to remove the "re-login" step in some situations, depending on your backend configuration. External SSO providers like Okta can be used as well.
3. Federation. Federation is similar to SSO-based multi-app network, in a sense that users only need one account to participate in federated networks. The difference is that there can be multiple ID servers, so some sites can issue and process authorisations and some can work as clients only. It is of course imperative that all servers comply with a "protocol" of the federation to ensure safety and compatibility. In a trustless federation complied with protocol can't be left to administrative decisions - instead it the protocol itself includes logic that handles account verification (aka "immutable identifier"). That's where politics begin - everyone wants to be at the helm of creating THE protocol for social IDs, not unlike various blockchain/crypto protocols (blockchains) are claiming to "get it right". Protocols don't interop directly either, so you have to denormalise data if you want to integrate multiple ones, which is akin to creating your own protocol again.

So, which one?