implemented in commit 0d6bef358ecfc9703ebd732e22eaf5ef867a9c08 

 Just thought you might like to know what this thread looks like in Gossip.
https://i.nostr.build/M5jQ5.png

If I click on the "raw" button (the steak LOL), then I can see the content of the OP, so I know what you're replying to. 

 what do you think @Mike Dilger ? How about adding support for nip34 event kinds?
I created a nip34 for it
nostr:nevent1qqs8ynff07mq0regym20ctae6wary2ummfcsh843ew8fs4caluukyncppemhxue69uhkummn9ekx7mp0qgs2qzx779ted7af5rt04vzw3l2hpzfgtk0a2pw6t2plaz4d2734vng7laakp
https://gitworkshop.dev/repo/gossip/issue/724d297fb6078f2826d4fc2fb9d3ba322b9bda710b9eb1cb8e98571dff39624f
how very meta 

 Gossip isn't a git client or an issue tracker so I'm not sure we need to support these.  We also don't have any support for markdown yet. And there are a lot of features on our plate for the next 3 months I'm kinda swamped with them. 

 Totally understandable. Rather than displaying the full content I was thinking something simple to add a bit more context than 'UNSUPPORTED EVENT KIND XXXX'.
Something like:
'Git Repository: gossip' for repo events
'Git Issue: [plain text before first line break]'  instead of 
'Git Patch for [identifier in a tag with repo kind]' 

 Yes, just having a different label would be a big help. 

 It's a good idea to include an alt tag for events as per NIP-31 https://github.com/nostr-protocol/nips/blob/master/31.md so clients that don't handle the issue kind can still render something. 

 Yes an alt is probably a good idea. I was concerned about duplication but its only a oneliner. The context of what the kind is won't be communicated in the alt though.

 

 The alt text could have the context of what the event is and a gitworkshop URL, something like "git issue: <title>\n<gitworkshop URL>". 

 Yes. after all, a client that recognises the kind will probably have some sort of custom render. a client that doesn't should print the alt tag.
I'm not sure about including the gitworkshop url.
I don't think it is good for the UX when clients hard code links back to their own client. May be its ok there are so few nip34 specialised clients.
I really like the 'Open in' based on client recommendations from my WoT. There is a NIP for that right? 

 > I don't think it is good for the UX when clients hard code links back to their own client. May be its ok there are so few nip34 specialised clients.

Yeah I agree it's not ideal but is a way to let people know about the client. Alternatively a `client` tag can be used.

> I really like the 'Open in' based on client recommendations from my WoT. There is a NIP for that right?

Yes, NIP-89, it's a great idea to create an app handler for gitworkshop with all the NIP-34 kinds. I'll open an issue for that. 

 As long as the changes aren't extensive, I don't mind having a bit more detail into what the event is about. 

 Gossip isn't a git client or an issue tracker so I'm not sure we need to support these.  We also don't have any support for markdown yet. And there are a lot of features on our plate for the next 3 months I'm kinda swamped with them. 

 Good idea 

 I started to working on extracting bech32 nostr references from the content of events but it turns out that NDK does it automatically when signing events. pretty helpful. thanks @verbiricha 

 I actually meant to tag @PABLOF7z as he added the automatic tagging in NDK.
I'm not sad that I tagged @verbiricha as he doesn't get enough credit for all he does in the space. 

 Thanks for the shoutout! #NDK is awesome, even hashtags are added to the post when using them in the content. 

 Its interesting how clients show replies differently. Gitworkshop shows them chronologically so this reply has its proper context. Amethyst shows it reverse chronologically so it doesn't. Really it is a conversation in a thread.I'm not sure there is a good answer to this. Tweaking the UI sonit encourages nesting every reply feels wrong