the @ menu (tag user in message selector) only appears when the when @ is at end of compose box
testing if kind 1 replies to to git issues show up in chachi. maybe its a reply kind 1111 maxi?
no kind 1, only 1111. actually I think I still gotta implement fetching replies from outside the group lol.
I listened to your podcast with nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspr3mhxue69uhksmmyd33x7epwvdhhyctrd3jjuar0dak8xtcppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7208x3z. I enjoyed your discussion of different styles of interaction and how different tool align to them / create experiences suitable for them. Interactions around git issues and PRs aren't all the same and don't all happened in one place. Github provides a consistent UI which is geared towards one style of interaction. On nostr there are many tools which create different experiences. Relays and kinds can be used to separate discussion. This could enrich the overall experience or degrade from it depending on the choices we make. I'd be interested in exploring with you and the community how can we nudge things in the right direction. Not all 'other stuff' content types have the same desired outcomes. Some want to maximise engagement. Some want to create healthy and fulfilling social interactions. Some, like git issues and PRs, want productive conversation that is actionable and easy to review and get up to speed with. The right approach for podcasts might not be the right approach for git issues. Right now the deep threads that happen in kind 1 comments lead to conversations that are hard the review after the fact, particularly when there are multiple birsts of activity common on git stuff. Perhaps its not inherent to thw threading approach but down to the UX of reviewing them in gitworkshop And other clients.
Do note that when I created NIP-17 the primary use case was to route sats from the users of the system, to the developers that contribute, via git commitments.
I've had ideas how to integrate that for a while but not quite got to it.
Awesome! It was all designed around on-chain FWIW. It's a big reason nostr got built. Key is that pubkeys are used in the ledger. Excited to see what you come up with!
Before you get too excited, I did mean more generally users sending sats to contributors :-)
> Not all 'other stuff' content types have the same desired outcomes. Some want to maximise engagement. Some want to create healthy and fulfilling social interactions. Some, like git issues and PRs, want productive conversation that is actionable and easy to review and get up to speed with. 100%, with chachi my goal is to give you a window to all these other stuff but not create a worse version of specialized tools for those content types. In the future I'll use NIP-89 to allow you to open everything in apps endorsed by your follows and community to interact with certain types of content in a better way. > Right now the deep threads that happen in kind 1 comments lead to conversations that are hard the review after the fact, particularly when there are multiple birsts of activity common on git stuff. Perhaps its not inherent to thw threading approach but down to the UX of reviewing them in gitworkshop And other clients. Threading is a core part of the app and something I want to get right but I still haven't worked on a lot. I really like the approach @nielliesmons proposes of having direct replies show under the post and flattening replies deeper than that into a chat interface. This can work for any content type and using the same kind 1111. > I'd be interested in exploring with you and the community how can we nudge things in the right direction. Same, this is a really challenging and fun experiment! 🫂