Federation and Cross-Cloud Features
Federation lets compatible cloud servers interact without becoming one centrally controlled server.
Separate federation capabilities
- Standard cloud federation can support cross-server shares and contacts when both servers are configured correctly.
- A compatible NuQloud Talk files module improves file sharing in cross-cloud conversations on updated participating servers.
- The Federation Registry app provides a directory interface, local publication settings, and truthful empty or offline states.
Files in federated Talk conversations
On compatible participating clouds, the current Talk files module creates recipient-specific, read-only native shares. Selecting a file already in Files shares the original in place; it does not create a public link or publish to QDN.
Web clients can show file cards and Shared items entries. Supported native Talk uploads are also delivered through background jobs, and mobile clients can open the announcement's link for their own cloud after signing in. This link resolves an existing authorized share; it does not grant anonymous access.
Delivery can be delayed by background jobs or an offline peer. The module cannot enable an upload that Talk itself rejects in a remote conversation. Both clouds need compatible versions and a trusted federation relationship. Do not assume that removing a conversation participant automatically revokes every earlier share; ask the owner/provider to verify the underlying sharing permissions.
Discover clouds and opt-in profiles
Current registry source implements QDN discovery, public document publication, individual profile opt-in/removal, and instance-authority checks. It is no longer only an empty directory foundation. Your provider must configure the integration and validate it on the deployed cloud before you rely on it.
- Open Federation Registry from app navigation when available.
- Search and filter Clouds or People.
- Check a listing's authority/verification state before relying on its claims.
- To publish your own presence, review what Include my public profile will disclose, then use Review and publish only if you intend that data to be public. Publishing uses a linked named Qortal account and may incur a QDN fee.
A normal user publishes a minimal cloud pointer with only their own opted-in profile. An authorized instance publisher can publish a richer directory of individually opted-in profiles. The reader checks the canonical cloud's HTTPS authority proof before accepting that directory's bulk user list; a role string alone is not proof of authority.
Remove my profile removes local opt-in. Publish again, and coordinate with the instance publisher when needed, to update existing QDN directory records. Removal is not a promise to erase copies or caches held elsewhere. Never publish an Authentication File, private identity material, or another person's profile.
What discovery does not do
A directory listing does not create a trusted-server relationship, grant access to files, or add a remote contact. Those are separate authorized operations. Do not confuse an AI tool's registry-record publication with proof that a cloud is authoritative or that every registry reader consumes that record format.
The registry remains an evolving capability. Full expiry/withdrawal handling, abuse/reporting policy, interoperability and release hardening require further work and deployment acceptance. Do not assume all clouds or users are listed, that every record is verified, or that all planned federation handoffs exist.