0 sats \ 11 replies \ @mo 9 Feb freebie \ parent \ on: Bitcoin adoption using Ecash - use case scenario bitcoin
I know you don't need our zaps, it's just a form of appreciation, please do accept it with joy!
Custodial isn't decentralized, if substack shut down your guides are maybe lost? it would be worth doing a backup somewhere else... what about NIP-23 on nostr?
NIP-23 on nostr?
crap no one is reading. Once you post a long form is lost in the plethora of other posts. Nobody will look for your long posts. That form is not for keeping a nice organized blog or newsletter, is just for long rants, that will catch only actual attention. after few days nobody will know that post exist.
I don't understand why people hate substack. I find it handy and I personally don't give a shit if they shut down all my posts someday. I always keep a backup that can be imported anytime in another form of blog platform. I just want people to go to a single place to read my guides, that's all.
reply
reply
I like substack
reply
what about NIP-23 on nostr?
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
reply
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