Please note: some features discussed here are unreleased.
Profiles are stored as singleton coins, each uniquely addressable by a decentralized identifier like did:chia:1v0xcsu6alar07888yx7jkekzjvg623m48cnnzeufs30xsdqu0kcsshsn34.
Using the chain as a database has some nice properties. DIDs are guaranteed to resolve to the correct public key and metadata. Changes to the key or metadata must be signed. The history of all changes is permanent and publicly auditiable.
With these guarantees, we don't have to worry about things like server operators becoming malicious, getting hacked or going out of business.
Profiles currently support two types of metadata:
A naive approach would be to store every identity claim and followed profile directly in the DID coin's metadata. While this would be nice and simple, over time it would lead to an exponential amount of data stored on chain (the size of the profile × the number of updates). For example, if someone were to follow 10 people, each spend to update the coin's metadata would contain around 5 ids on average, for a total of 50 ids stored on chain, a 5x waste of space. This quickly gets out of hand. Following 100 people would store 5,000 ids, a 50x waste of space. Following 1,000 people would store 500,000 ids, wasting 500x!
A more efficient approach is to only publish incremental updates. The most recent state can be determined by replaying the history of all updates. With this approach, no data is duplicated on chain -- following 1,000 people stores 1,000 ids. One downside is the cost of traversing the coin's entire history compared to just fetching the latest metadata from a single coin, though there are potential optimizations to mitigate this.