Nostr Web Client

Replying to

bumi

that can not be… can you open an issue and share your logs?

and we need to get Damus and all clients to implement feedback on the payment.

fire and forget and hope everything works is not enough user feedback.

esp. as there are still many new moving parts (clients, relays, nwc. zap publisher,…)

and I am not happy about such general claims/FUD.

The Fishcake (nostr.build) 2y ago

I apologize that it sounded like a spread of general fear, uncertainty and doubt. That was not the intention.

The reality is, fire and forget is the current mode how at least Damus works. I also understand that we are in the early stage and things are not well tuned. The experience with one tap zap is vastly different from the wallet payment where you get solid confirmation that payment is settled.

On the topic of the logs, we did experimentation yesterday with #[3] and it was clear that something didn’t work. I also have experience with zaps hanging until I restart the client and rezap. It is usually happens when I switch between cellular connection to wifi or switch apps. It is similar to what happens with connections to nostr relays.

I am not sure what logs I can provide to help with troubleshooting, but I am sure that the problem is not likely with NWC service itself, and likely to be with the client sending the request to make the payment.

Lastly, I’ll refrain from making notes of this nature in the future for the fear of being misinterpreted. 🐶🐾🫡

Reply to this note

Please Login to reply.

Discussion

bumi 2y ago

sorry, I did not want to sound harsh. please always keep the comments coming, we all try hard to build the best Nostr experience and make things better and I really really appreciate your input. You made NWC and the tools around already so much better.

We still have a lot of moving parts here. NWC problems have to be fixed in NWC. Client problems have to be fixed in the client.

If the client can not send the payment request then NWC can not do anything.

The client needs to be resilient there and also give the user feedback.

From my side zapping is still the most unreliable that I see right now. Too many zap events are rejected.

And clients (damus) needs to give users proper feedback.

With the logs I meant the NWC application logs (you run your own, right?) The app logs information about received events, payment status and responses.

There we should see what goes wrong - if NWC receives the event, if not we need to look at some other part.

The Fishcake (nostr.build) 2y ago

My node rarely has issues with sending, only happened a few times when I get phone into that rare cannot connect state. I’ll lookout for this and send logs from NWC 🐶🐾🫡

phil 2y ago

I presume you received that zap I just sent? My NWC zaps seem to be working fine at the moment.

The Fishcake (nostr.build) 2y ago

Yes!🐶🐾🫡

bumi 2y ago

we have:

client -> relay -> nwc -> node -> nwc -> relay -> client ; and nwc -> relays -> zaps

The Fishcake (nostr.build) 2y ago

Yes, I am aware of the flow. I suspect the issue is mainly at client->relay->NWC point. Likely relay->NWC. Connectivity on mobile is unstable and may get into some sort of lockup timeout. I am sure there are cases where NWC-> node may have problems, but I haven’t seen those on my node at least. 🐶🐾🫡

bumi 2y ago

the mobile connectivity one is interesting. I don’t know how clients behave there… this is something I need to test more.

The Fishcake (nostr.build) 2y ago

Try going into different states of the app. Open, put into background, switch connectivity (cell->wifi or wifi->cell), bring it back into foreground. And any other scenarios. Maybe use other apps while client in bg. 🐶🐾🫡