Here's the low-down on how nomadic identity works.
You've got an ID. Let's say it's "Fred Flintstone".
Sign this with a digital signature.
You've got a current web location. Let's say it's https://example.com
Sign it with a digital signature.
Send these four pieces of information anywhere. When it arrives at the other end, the site at the other end will connect to your current web location with a "well-known URL" and ask for the info packet for your ID and with this signature. This returns some basic information, along with the public key you need to verify both signatures.
If you change web location, repeat the process. Bad guy cannot assume your identity without your private key because the same public key needs to verify both your ID and the location, and you *always* verify through a callback to the current location.
The callback requirement is what makes this work.
But once the identity has been verified, you can store these four bits of information. Put the ID bits (ID plus signature) in one table and the web location bits in another. You can have many web locations for one identity. What makes this work is that if you wish to communicate with the same site again, you send the same four pieces of information, and the site at the other end always has to callback to your location to retrieve the communications. It does not need to verify the signatures ever again, unless you post from a new location.
So next time you post as Fred Flintstone from https://myother.crazy.website,
the verification process is repeated, but to all the other sites you've ever communicated with before, you're still Fred Flintstone.