uuid for Profile struct

[dauphin3]

It would be convenient to have a uuid field outside the BTreeMap to link to various things, like AgentPubKey

This would allow for changing the nickname, although I'm not sure if that is desired (but Im thinking there may be advantages for a static object linked instead of nickname) then that static object could be linked to the nickname/handle

perhaps it makes sense to make the uid the AgentPubkey

thoughts on the tradeoffs between have both, or just a uuid to linked to an Agent, or none of the above?

[guillemcordoba]

Mmm I'm not sure I follow. It is already possible to change the nickname, using the update_profile zome function.

What would be the objective of adding a uuid? To disambiguate between profile entries? I'm not sure what that would accomplish since we are only referencing actions that create profile entries, so those action hashes are always unique already.

[dauphin3]

this issue is what made me think of it
GeekGene/mewsfeed#88

also some potential advantages:
-tracking profile updates
-identifying spammers
-opening ways to link additionally metadata

[guillemcordoba]

I don't really understand why adding an UUID makes those things possible... Could you elaborate a bit?

[dauphin3]

we could start a discussion topic on the forum, see above link for chat about migration. for now I don't see it as a priority necessarily, I just wanted to make a suggestion while I was thinking about it

…

On Wed, Mar 22, 2023 at 6:00 AM Guillem Córdoba ***@***.***> wrote: I don't really understand why adding an UUID makes those things possible... Could you elaborate a bit? — Reply to this email directly, view it on GitHub <#56 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKZFIHFSH7IX7QYUTOGBZMLW5LSU7ANCNFSM6AAAAAAWDNPGFQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[guillemcordoba]

I'm going to close this for now as "not needed", because the ActionHash will always be unique for an agent creating a profile.