In the Fission model, users own and manager their DID, not the service. Unfortunately, due to Zooko's Triangle (a trilemma, illustrated below), a raw DID is not particularly user-friendly. Further, all resources in Fission are based on immutable data. This is an intentional separation of concerns: a handful of mutable pointers are much easier to manage in any setting, especially a distributed one.
These constraints mean that the model is flipped from existing systems: the user is in complete control of their data and identity, but they need help with human-readable distribution. These may absolutely be self-managed or self-hosted, but in all cases one needs to reserve some portion of a shared namespace.
The temporality of mutable pointers implies some unavoidable latency (speed of causality limitation). Wide distribution needs to happen over some well known channel, of which all but a sneakernet are generally owned by a group of people.
"Rental" of these top-level pointers from one-or-more registries gives the user the ability to widely distribute their mutable pointers as human-readable names. There is nothing special about any particular name that they give their data; nothing is stopping them from registering as many names in as many distribution channels as they wish.
There are many approaches to this, including key networks and blockchains. The only of these methods that is universally supported today is the Domain Name System (DNS). DNS is a decentralized, global key/value store with support from every internet connected device.
The mapping of names to DIDs is provided by DID-in-DNS, with extensions for large self-describing keys (e.g. 2048-bit RSA public keys).
The mapping of the data root (CID) of a Merkle tree is stored in a DNSLink. At time of writing, Fission represents this at _dnslink.${username}.files.fission.name.