10 sats \ 2 replies \ @ek 10 Feb \ parent \ on: Bitcoin adoption using Ecash - use case scenario bitcoin
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.
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).
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