The code is here if you want to write an issue: https://github.com/getAlby/nostr-wallet-connect/tree/main
Installed it, made a connection with Amethyst, though I don't have a LN channel set up, and yet I can still "Zap", confirmed in NWC as shown in the "current usage", and in Ameythst as indicated by the increased number and highlighted zap icon, but nothing was actually sent of course. (Expected an error or something but it "went through".
nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z
(I would tag Alby too but couldn't find them here)
nostr:note1ysd5d09dwfk8feht2gfjfhclz7f84pgz6v4m2y5qvda2e4gmc2ms7f053h
https://nostrcheck.me/media/public/nostrcheck.me_1878177119148209561689082208.webp
https://nostrcheck.me/media/public/nostrcheck.me_6201368857080751761689082237.webp
if you kill and restart the app, is it still there? If it is, the zap event is wrong, if it is not then we have a bug in the payment error codes.
Not really, but it was recently added to the Generic Repost here: https://github.com/nostr-protocol/nips/blob/master/18.md
The `k` tag is being discussed in many other event kinds. So, I would say just use it. We can change the lists NIP later.
If you like peanut butter or almond butter, buy some, roast them, and put them in the food processor with a dash of real maple syrup for 15 mins. Boom. 10x the flavor of any store-bought product.
You are welcome.
GM.
Tech/engineering doesnt matter for onboarding. Design does.
As vezes tento postar um vídeo e o app fecha. Vídeo pequeno de 3mb via nostr build. Isso tem acontecido com relativa recorrência. Tem ideia do que possa ser nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z?
Ao postar o vídeo? Nunca vi acontecer. O vídeo tem algum formato específico ou vem de algum lugar? Eu sei que o nostr build tem alguns problemas com vídeos ultra comprimidos do what's app, mas não a ponto de fechar a app. Me manda o vídeo quando acontecer?
Wish there was a way to have #Amethyst combine Threads and Conversations together into one feed nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z
Me too. But they are two different mental models. It's very hard to use the two together
Take a look at NIP 46 and the nsec bunker. https://nsecbunker.com/
User search seems to work well, but content search is lacking. Their search doesn't find things posts that are loaded in their trending for instance.
We have lots of work to do yet.
nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z I found after adding some alternative reactions, that liking is now a little janky.
What do you think about having a default reaction, allowing that for single tap, double tap gives options, and long press stays as the way to customize the button?
Double tap to default like might also work better.
Wait, can you detail what is janky? Are the rection popup buttons janky to appear, to disappear? Or are the notification scrolling janky?
Mostly because everyone is afraid of requiring a torrent client in each nostr client. :(
I also don't know if it will be fast enough. The experience I have had with torrent is that it's extremely slow for social media scrolling.
Yep, it can be an IPFS, a torrent link, or any other hash-based decentralized data storage. As long as anyone can rebroadcast the file to other places and clients can just automatically find that new server, it should be fine.
Then build it. Let's see it. I built and shipped my approach. It works fine with many relays and I have been using it for other things at the foundation. It works. You keep claiming it doesn't scale but you haven't even tried it.
NIP-96 still keeps the relay name in the reference in the text:
````
["url", "
"],
```
Which is exactly the thing I want to run away from. But it is an improvement.
I didn't. You said "file relays list". I don't understand why you would want another list of relays. There is no difference between files and nostr events.
You keep suggesting centralizing solutions... It's quite depressing. I don't think you understand what we are trying to achieve.
There should be NO relay list in the event that has the HTTP content. It's FULL decentralization from any server. Not a single domain name.
The relay list is either set up by the reader's user or dynamic, like on the Gossip model for instance. It starts with whatever the author is using nowadays. If it cannot find via author, it starts hitting every other relay. Exactly in the same way, we find Nostr events right now.
More importantly, anyone MUST be able to back up and re-broadcast the content to other relays. Those new relays then could be used to download the content that was cited in the text without any updates... just like magic.
True, real decentralization.
That's not the point. The point is that a client should find out where the content in the relays they sign up for. Not in a fixed server used by the author.
The content could be on any relay. And can be broadcasted to more if other people want that access. And relays can be connected via DNS/HTTP.
What you cannot have is the domain name of a server that can cease to exist locked into the text.