Practices to follow to make API "federable"?

I am NOT an Apollo user/customer, at least not presently but am working on a (our) customer-facing GraphQL API for a product we sell as packaged hardware boxes.

I’d like to make that API “federable” with other GraphQL services our customers may have (unknown, not developed by us) and we may, in the future, decide to federate those boxes with other services we offer.

Are there any practices to follow to make this smoother, beyond just following GraphQL specs? I am particularly concerned about the naming / namespacing… Do I need to prefix every type with a unique prefix (not exactly nice) or would federation middleware be able to handle same-name types from different back-ends? Any other considerations?

Does Federation or will Federation 2 and/or Router have some way of (re)mapping and equating types of same or different names from different back-ends?

UPDATE 1: Another, but still related, concern is the customer/user-defined data - in our case “fields” (UDFs) and relations (UDRs, some call them links). “Metadata-defined data” may also explain it. Present (incubating) implementation exposes these as full-blown fields of their own in the GraphQL schema, which makes them convenient and equally easy to access, while being fully typed (as they are defined). They are isolated in a field dedicated for them to have their own namespace and prevent clashes with our own fields but that’s it. This makes our GraphQL schema dynamic, although not frequently changing. Our schema is, thus, programmatically generated based on metadata/model we otherwise have. How does this affect Federation 1/2/Router?

UPDATE 2: Does Federation make use of @specifiedBy to map/recognize equal types? Is there a registry, somewhere, of those specification URLs? GraphQL only gives examples of two (UUID and URL). RFCs don’t focus on types and may talk of multiple and may have multiple versions. Other common types may not have steady/permanent and/or accessible URLs. Examples: ISO-8601 timestamps (RFC 3339 but not really, this is ISO), IEEE EUI-48 (no accessible dedicated spec), common integer subranges, email addresses, host names, addresses, ports, phone numbers, mobile device IDs, colours, country/location codes, SIN/SSN numbers, credit card numbers, etc.

Anyone? Apollo guys?