Kind1 puts the text in the content. That’s what we did… putting that much text in a tag just felt wrong. Sorry! 🤷♂️
Discussion
I understand this part from a convention standpoint but it ultimately does not really matter (tags or content is completely arbitrary at the end of the day).
I agree with the people here that there would have been multiple sollutions to this situation, and plenty of room for coordination, that will also allow you to easily filter events that dont include a transcript.
They might have come out a bit hostile out of the gate, but understand its mostly dissapointment.
Also understand that Nostr only has 1 commons, which is not that of the servers/relays, something other protocols try and fail because its stupid. Nostr's commons is that of the immaterial (loose) coordination on standards. And we don't have a police, and technically you can do whatever you want, but commons only thrife when participants forgo immediate opportunity for the sake of long term accrued benefits.
People see you taking immediate opportunity and see the opportunity cost of that action, which explains why they are not happy.
I hope you can reflect and can come back to the table at some later moment in time.
words of wisdom. that's why you get paid the big zaps.
Putting that much text in a tag just doesn’t make any sense, if we are basing what “nostr” is off of kind1 posts.
When you say “nostr”, that’s what it is… kind1 mostly. All these other NIPs are fighting to survive. I don’t have to respect all of them. That’s the point of permissionless development. Audio posts are barely used on nostr, and nostr itself is barely popular as is.
Well, it seems you took very little time reflecting.
My 2 cents:
The transscripts should be seperate events, that reference whatever event it is they are transscribing. This has a couple of benefits;
1: transscripts can be produced after the fact;
2: transscripts can be produced by anyone;
3: transscripts can apply to all sorts of events.
It would allow your client to provide transscripts for voice events that appearently did not have any.
This way your usecase can leverage stuff that is already out there, and other clients can ignore transscripts if they want to.
This set-up will benefit clients that would want to provide a good experience for deaf people for example, that can now addopt this broader transscript standard.
All a clients has to do, is also query for transscript events related to the stuff it wants transscripts for.
