Please add a sentence that the .content can have a tag list structure just like NIP-51. We can copy-paste that and use it here. :)

This feels really rushed. nostr:npub1g53mukxnjkcmr94fhryzkqutdz2ukq4ks0gvy5af25rgmwsl4ngq43drvk should be considered a potential solution, but it's not even a NIP yet (unless I am missing something).

> I don't think a home relay is sufficient because there are plenty of more complex situations it wouldn't cover. For example, I may post to a paid relay, but I cannot expect people to copy me in on a thread at a paid relay that they may not be paying for.

Sure, but in practice, people have to add tons "read" relays to download all notifications from everywhere to account for Nostr apps that are not following NIP65 directions yet (it's optional after all). The overcrowding of read relays breaks the concept of the preferred/home relays.

Clarifying that NIP-65 should only contain home relays is important.

If we want to use NIP65 to only advertise to others, then there isn't much to do. But if we want to use it for the user's own applications (which I think we should, we need more)

On the advertising, I think read/write labels are terrible because they need a point of reference (who is reading/who is writing). Each user should just have "home" relays where all of their posts are supposed to be found. There is no need to specify read or write. If I am writing a DM to you, I will send it to all your home relays. You send to my home. If we happen to share the same "home" relay, both apps should use that.

On the user's own needs, there are other labels like "search" (which NIP-50 relay to use for searching things), "global" (which relays to use when on a "global" view), "notification" for all relays to use when searching for notifications (today's read), etc.

We need public and private relay lists, similar to NIP-51.

I think nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c wanted to do a few changes to it but I don't know what those are.

But we have to make event/relay finding easier.

I have been wanting to code it on Amethyst but the NIP text is too cryptic right now. I can barely get my head around it.

Snort.

We need to fix NIP-65. nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c

Well, I know how to build a retina scanner if you ever need one :)

But an iris scanner is probably easier. Just keep in mind that both Iris and Retina do slightly change over a long lifespan.

If everything you have is tied to having access to your eyes you might lose everything on a simple cataract surgery.

Are you saying we need Neuralink? :)

Working on other stuff, like private DMs, local database, etc.

Nostr Wallet Connect and Remote Procedure Call. RPC is just dev code for make a request, get a response as opposed to nostr, which is subscribe once and wait for many responses.

So, in nostr I can just subscribe to you. On am RPC, I must make a call every time I need to update the value.

I am basically doing this:

if (event.kind == 5393) {

response.setHeader('content-type', "text/css")

response.send(event.content)

} else if (event.kind == 5392) {

response.setHeader('content-type', "text/html")

response.send(event.content)

} else if (event.kind == 5394) {

response.setHeader('content-type', "text/javascript")

response.send(event.content)

}

Nice! It's just a few numbers. We can make a NIP if this goes forward and formalize them further for your needs.

The main goal is to not pollute kind 1s with code while helping clients figure out how to display these new events correctly.

Having the NWC interface is good and people should feel free to code it. I just don't know if it's applicable to Amethyst yet.

Maybe this creates a new class of Nostr-native Wallet apps. Who knows..

Why use a Kind 1, though.. It would be better if you create your own kinds, like I just did with Nostryfied here:

https://nostr-webserver-3c29f7957ffe.herokuapp.com/e/7b8a47b1c97b449e842bc0186e89102874ea801b041c822fdecac50f2f3d91b2

Who wants to see your lightning wallet's balance directly on Amethyst? I am torn on this.

Is it a privacy risk? Does it even make sense or should we use the UI space/coding time for something else? Since this is an RPC, when should we call the NWC server to get the updated value? Every second? Once a day? After each zap? Since you can spend your sats outside Amethyst, it will most likely be an out of sync value nevertheless.

nostr:nevent1qqsyaa0psaqntl8anjzuvx3w3rsmvl5g4lw6u39wztysgy4aulw5tnqpremhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet59upzprpmyelfmd4sz92f3np7lngc0528fpjfgzhgl7thsf4emq7jqkrhqvzqqqqqqyquj32u

Android Studio is the way to go. Everything else will make you slower.

Code is open. Anyone can pay for an audit. :)

Send me an example event ID when this happens. I need to understand what stemstr is doing first.