Depends what you are trying to do with that data, exactly. Can you tell us how you’ll use it later?
While you can store some additional details in the JWT’s metadata, that is not a good “general purpose” storage place, so I’d suggest that you create a signup form that populates your database (and your code can access it to pull up those details for logged in users afterwards), and don’t try to use identity to store the data, since we don’t have a good method for you to export it (vs your database, where you control its provenance).
OK so in my case I can just store some top level metadata and relationships between users in something like faunaDB.
However in that cause, maybe it would be better to store the Users themself in FaunaDB then I would have relational integrity with user links, unless there is a nice way to mirror users in Identity with a users table in Fauna.
Apologies for resurrecting an old thread, but could you expound on this please @fool? I know that there are some underlying reasonings to ensure folks know - both App and User metadata stores are visible by the client-side library, though only the User metadata is editable from the client library - so things that the client shouldn’t be able to see shouldn’t be stored as metadata in either bucket… but given an understanding for that constraint, are there more reasons to not store metadata in GoTrue? Or is it just the exportability of the data long-term?
PS for others, there is an outstanding issue for adding a private metadata mechanism to GoTrue, but it’s not yet implemented.