From a quick glance, I think it all looks fine, did you have any specific questions?
Hi nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspr3mhxue69uhksmmyd33x7epwvdhhyctrd3jjuar0dak8xtcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszxnhwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mf0ss9zgs , would you mind to take a look at this? I need some suggestions related to NIP-32 🙏
Discussion
Thank you. I think i want to make sure about label namespace.
Is it ok to state "L" namespace multiple times as long as it was clear which reference of the namespace? In language labelling i made two namespace using "ISO-639-1" for public use (different apps/clients can freely query it) and "app.nfrelay.language" for internal use.
Yep, the second argument to l disambiguates. You can get some false positives when querying on occasion, but it's very easy to filter out client side.
I see. Glad to hear then.
What do you think about multiple label "l" structure that i have shown in language or topic labelling? Do i need to change something in those cases?
Example:
Note/post which has multiple languages
["l","en","ISO-639-1"], ["l","ja","ISO-639-1"]
Note/post which has multiple topics
["l","science_and_technology","app.nfrelay.topic"], ["l","arts_and_culture","app.nfrelay.topic"]
Yep, I think that's totally kosher. I also like what you did with the `label_score` type things. People often misuse nip 32 to be a key/value store, but meta makes plenty of sense to include.
Ah, thank you. It clears probably all my doubts with event structure migration. I think i can start slowly implement the new structure and deprecate the old structure in the following weeks.
Oh, I thought NIP-78 has been used for that. I think there was library to make key-value storage using NIP-78.