nostr:nprofile1qythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qyvhwumn8ghj7un9d3shjtnndehhyapwwdhkx6tpdshszymhwden5te0wp6hyurvv4cxzeewv4ej7qpqr0rs5q2gk0e3dk3nlc7gnu378ec6cnlenqp8a3cjhyzu6f8k5sgsl5kqdc Now when you post in Blowater's publc feed, it auto scrolls to your post once relay gets it.
LoL, please don’t answer my test spamming. I have switched to a new npub to not spam my followers
Test
test
Test
Wow, it's awesone! Does nostrr.com have a public API? I need to implement a "relay recommendation" page but writing a relay discovery algorithm is a big task.
NIP-11 has an optional icon field https://github.com/nostr-protocol/nips/blob/master/11.md#icon please set it so relay explorers and other clients can show it 🙏
Many relays just set /favicon.ico
That's fine, just that favicon.ico is usually low resolution, not beautiful to display as large image
I know why.
The icon Blowater uses is defined by https://github.com/nostr-protocol/nips/blob/master/11.md#icon
Most relays don't set it. Instead, they set a favicon.ico in their HTTP server.
Such as https://yabu.me/favicon.ico
how to block filter rest all IF just want to keep relay for dedicated direct n group messages only ?
My opinion is to have relay implement these kind of access control features instead of the client.
Of course, relay oriented features weakens the decentralization and relies more on trust.
This is an unsolved challenge. I am currently experimenting a new relay implementation for these kind of use cases.
Not sure what you mean LOL
Pro tip: relay operators, set an icon for your relay 
This user has cool profile picture 
Yesterday I had the privilege of witnessing the demos of the first nostr:npub1s0veng2gvfwr62acrxhnqexq76sj6ldg3a5t935jy8e6w3shr5vsnwrmq5 cohort here in Madeira. Mind completely blown. Everyone should check out these projects. People have no idea how good Nostr is going to get.
nostr:npub1dergggklka99wwrs92yz8wdjs952h2ux2ha2ed598ngwu9w7a6fsh9xzpc and nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft are legends for instigating this. Things are going to get insane.
Nostr FOMO every day
Unless a person has huge following on Twitter and generates income from it, there is no reason not to do it.
nostr:nprofile1qyfhwumn8ghj7ur4wfcxcetsv9njuetn9uqsuamnwvaz7tmwdaejumr0dshsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qqs04xzt6ldm9qhs0ctw0t58kf4z57umjzmjg6jywu0seadwtqqc75s5hh9lh This is more close to how I want auth to work
authentication thoughts:
NIP-42 is stateful that it's based on steps of message exchanges over a single websocket connection.
The assumption here is that only one private key, aka account, will use this websocket connection.
But, if a client implements multi accounts, this is no longer true.
The same websocekt connection will be used by 2+ nsec.
Therefore, embedding the auth event in the REQ is a better solution.
It's simpler to implement for both clients and relays and it allows sharing the same websocket connection of multiple nsec
Current NIP-1 REQ
["REQ", "sub id", filter1, filter2, ...]
We can do
["REQ-V2", auth event, "sub id", filter1, filter2]
so that the relay can know which npub is doing this subscription.
Stateless design is more elegant.
Thoughts?