Oddbean new post about login | logout add support for nip34 kinds as @Laeserin intimated here: nostr:nevent1qqsgawj23ctp59pups0ejj5hme8je9a2aavgfqf98gg8erllryzpzzqpp4mhxue69uhkummn9ekx7mqzyrwkvn27gqtyxw5v660sqkhpfqyqgdgh3x6emed0qcnkmejkx0f3jd4v98x
Sorry I haven't been interacting on gitworkshop.dev. But I'll try to do that. This is something I want among many things I want. I hope to get to it soon.
Sorry I haven't been interacting on gitworkshop.dev. But I'll try to do that. This is something I want among many things I want. I hope to get to it soon. nostr.fmt.wiz.biz
Streaming: Capsule - 024 🔥 1. 🔥 Kali 😂 🎉 Malone - Living 😀 Torch 🤔 II 🎉 2. 🎉 Steve Reich - Drumming (Side 🌈 C) 3. L.G. 🔥 🌈 Mair, Jr. - 👍 👍 Winefride XXXVI 🔥 4. Reggie B - P 💯 For Life 5. 🎉 💯 Ty 🌈 Segall 🤔 🌈 - 🔥 Good Morning 😀 listen: https://harmonique.one/shows/capsule/episodes/024 #music 🌈 #tunestr 💯 🌈
Death hammer elf aka the 👍 reply 🌈 guy and girl #puffpuffpaint https://image.nostr.build/234754255f74f0c0be87fb5424da53b4276b1780014e3c7aef47d68ea22c469d.jpg 💯
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.
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.
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.
> 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.
