0 sats \ 6 replies \ @ek 9 Feb \ parent \ on: Bitcoin adoption using Ecash - use case scenario bitcoin
Off-topic: SN uses NIP-23 for crossposting and it's confusing since it doesn't show up on the "normal clients" like Primal on Snort. At least I couldn't find them there.
How nostr works (or is supposed to work) becomes more and more intransparent imo which is bad for UX
I think is how it should be, what should be shown in Primal or Snort are the comments on posts, not the posts itself. If you use Habla or Yakihonne you'll be able to see them all.
@Eobard isn't bax UX, you can NOT have a client that show everything related to a npub. The trend look's like there are different clients for different kinds (of notes and other stuff).
And make sense to me, it's just the beginning and it's good to differentiate and create multiple opportunities in the market. If the client does not satisfy your need, use another one
reply
@ekzyis did you see this? An interesting correlation
No, I didn't, thanks for the link! We have some stuff regarding this in the pipeline (to be precise, @bitcoinplebdev has). I have some reservations against using NIP-41 though which I mentioned in the PR. Regarding using NIP-01 for comments: I am not sure how edits should work in that case without breaking user expectations (also mentioned in the PR).
However, I have an idea: the frontend does only sign events and our worker in the backend publishes the most recent one for an item when the edit timer ran out. So for every edit, the client signs the event and sends it to the backend
I might didn't think this through yet though. I just came up with this idea while replying.
I will add this thoughts to the ticket.
And make sense to me, it's just the beginning and it's good to differentiate and create multiple opportunities in the market. If the client does not satisfy your need, use another one
Yeah, I agree. My main pain point with nostr is just that it's sometimes not clear if something is not working or if it's working as expected and I am just missing something (use a different client for example).
reply
Great idea! I think this is a good middleground approach. Relying on paramterized replaceable events seems a bit fickle. It works well for nip23 long-form events but even then clients are taking a long time to implement it and I know a lot of relay runners don't like/support replaceable events.
Since currently a user already has to resign on an edit of a crossposted item the UX should be the same if we have worker broadcast it after edit window.
One thing we would want to consider is what to show in item-info for a crossposted item DURING the edit window. Currently it will either show
crosspost to nostr or nostr note