Oddbean

nostr:nprofile1qyw8wumn8ghj7argv43kjarpv3jkctnwdaehgu339e3k7mf0qydhwumn8ghj7argv4nx7un9wd6zumn0wd68yvfwvdhk6tcpzdmhxue69uhhqatjwpkx2urpvuhx2ue0qyv8wumn8ghj7enfd36x2u3wdehhxarj9emkjmn99uqsuamnwvaz7tmwdaejumr0dshsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qqsd6ejdteqpvse63ntf7qz6u9yqspp4z7ymt8094urzwm0x2ceaxxggcg6f8 nostr:nprofile1qyw8wumn8ghj7argv43kjarpv3jkctnwdaehgu339e3k7mf0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgmwaehxw309a6xsetxdaex2um59ehx7um5wgcjucm0d5hszrnhwden5te0dehhxtnvdakz7qpqm3xdppkd0njmrqe2ma8a6ys39zvgp5k8u22mev8xsnqp4nh80srq0z5fhc nostr:nprofile1qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzemhxue69uhkwun9v4h8xmm4dsh8xurpvdjj7qgswaehxw309ahx7um5wghx6mmd9uq35amnwvaz7tmwdaehgu3ww35x2umpd4jkxct59e5k7tcprdmhxue69uhhw6r9v96zu6rpwpc8jarpwejhym3wvdhj7qgmwaehxw309a6xsetxdaex2um59ehx7um5wgcjucm0d5hsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qy88wumn8ghj7mn0wvhxcmmv9uqzquqjyy5zww7uq7hehemjt7juf0q0c9rgv6lv8r2yxcxuf0rvcx9ep007x7 I want to do the following and need your opinion if that fits somehow into your nkb approach so it becomes a nkbip or a nud or...: I want to publish metadata about learning resources via nostr. Though I'm unsure what the most nostr like approach is. I began with putting all that metadata as stringified json in the `content` field. People didn't like it and from what I heard, you got the same feedback (i didn't see any complaints in this nip though :https://github.com/nostr-protocol/nips/pull/1454). Anyways I already have a detailed spec I want to use for the metadata (e.g. https://dini-ag-kim.github.io/amb/latest/ it's in german, but the examples at the bottom should be clear). My approach would be to translate that to tags with positional arguments, e.g. ```json { "kind": 30142, "created_at": ..., "content": "", "tags": [ ["d", "https://oersi.org/resources/aHR0cHM6Ly9hdi50aWIuZXUvbWVkaWEvNjY5ODM="] ["r", "https://oersi.org/resources/aHR0cHM6Ly9hdi50aWIuZXUvbWVkaWEvNjY5ODM="] ["id", "https://oersi.org/resources/aHR0cHM6Ly9hdi50aWIuZXUvbWVkaWEvNjY5ODM="] // or maybe use `r` for reference tag, might make search easier ["name", "Wurzeln konstruieren: Die Schnecke des Pythagoras"], ["description" "Eine Beschreibung..."] ["author", "", "Christian Spannagel"], ["image", "https://av.tib.eu/thumbnail/66983"] ["about", "https://w3id.org/kim/hochschulfaechersystematik/n37", "Mathematik", "de"], ["about", "https://...", "Geometrie", "de"], ["resourceType", "https://...", "Video", "de"], ["inLanguage", "de"], ["keywords", "Pythagoras", "Geometrie"], ["license", "https://creativecommons.org/licenses/by/3.0", "cc-by"], ["source", "https://av.tib.eu/", "TIB AV-Portal"] ["published_at", ...], ], "pubkey": "...", }``` I have the feeling that our projects have some stuff in common, your approach is a lot more elaborated. My question are: Where would you suggest to discuss this kind of stuff? What are your opinions? Thanks!

Thanks for the hint! I looked at this one, but I don't just want to reference, I want the metadata to *live* on nostr. Currently some teacher publishes a learning resource somewhere at attached some metadata like subject, taught competencies, appropriate educational level and so on. And then this data is fixed. In current infrastructure approaches it is not easy to adjust this metadata. Maybe it was published with subject biology, but you want to add chemistry as well and add some description on how you used it in chemistry. Nostr is like made for this. People can fork the metadata and add their suitable Infos to it. The resource stays the same though referenced by the uri where it currently lives. If you then think of WoT facilities you could provide a user lots of relevant services like when they search for content you can sort results based on their social graph and take into account with what resources (or their metadata) users already interacted with and so on.

30040 is essentially a container, but one meant to be in a feed. Been thinking about these events that aren't best suited for a feed - which might require a new kind. I think the recommended practice would be to use a different event kind that has the same functionality of 30040, but explicitly not for feeds. The other option would be to use 30040 with a specific boolean tag for `feed=false` or something similar, but I think that practice is discouraged. Zap.cooking uses a tag for 30023 events to only pull in recipes. https://njump.me/naddr1qqekwmr0wa5kueedwfhkcmrn8gkhycth94mx2empdckhxatndp5j6en0wgkkzttgv4skcarg0ykkymm0wd6zzq3qc6dhrhzkflwr2zkdmlujnujawgp2c9rsep6gscyt6mvcusnt5a3sxpqqqp65wenuyur