nostr:npub175nul9cvufswwsnpy99lvyhg7ad9nkccxhkhusznxfkr7e0zxthql9g6w0 will #NoorNote be able to let us input multiple nip5 ids in our bios? 🙏
Discussion
Not yet. Why is that a thing?
Wanted for managing leveling access. Gating relays behind relays behind relays 😅 and stuff
I don't get it tbh. Is there a NIP for that?
it's just kind 0 metadata.
animestr.xyz is the only client i know doing it currently but looking at this for building a kidstr relay
Ok, will look into it insh'Allah, shouldn't be too hard.
But I need free NIP-17 inbox relays more urgently tbh. So I can implement secure messaging. Would be nice if I could preconfigure Noornode for that.
#NoorNode doesn't support nip17 yet.
You can try
wss://auth.nostr1.com
this is the test instance.
Otherwise the
www://relay.0xchat.com
is probably best and most used
wss not www for 0xchat relay 🤦🏻♂️
messaging should really be a separate client though, right? don't over work yourself for first release. 😅
You have no idea bro what I've been cooking for 2 months now bro 😅
More like
https://video.nostr.build/c6587d5363fe3f84f87bc5424d5fdecc415accc05b77a54a14ea8de4d7515ab4.mp4
That wok has seen everything lmao 😂
I checked it out. Bro, it's soft-corn. And it's really in early alpha stage. So if there's no other real use case and no NIP or spec, then honestly, I'm not going to implement it yet. I mean, I couldn't even if I tried.
See this thread:
Alexandria is doing it too. nostr:npub1q6ya7kz84rfnw6yjmg5kyttuplwpauv43a9ug3cajztx4g0v48eqhtt3sh nostr:npub1m4ny6hjqzepn4rxknuq94c2gpqzr29ufkkw7ttcxyak7v43n6vvsajc2jl did a PR ever get made for this?
Nope, but other clients are just doing it because it is effing stupid not to do so.
But why?
Can't speak for other clients use case (although it seems related to trust scoring and access control leveling) but the aim I have with these is that nostr:npub1updmknky86nsph84rstlh0yymqpeg9l9f62qgxwvd6a75f3pvzxqxv83nv is making children's content so we will want a kidstr relay + client which requires access level amnagment beyond what most clients are pursuing. nostr:npub1t6jxfqz9hv0lygn9thwndekuahwyxkgvycyscjrtauuw73gd5k7sqvksrw has outlined some of the ideas behind getting there in their articles. Multisig (parent/child) npubs + nip5 id access leveling for different permissions types is a good way to manage this.
A few examples could be: 1, #NoorNode uses nip5s to whitelist special otherwise paywalled bonus content from #PodSystems 2, #NoorNode hosts a group chat for SAIF that is nip5 whitelisted 3, #PodSystems uses nip5s for moderator access leveling. 4, we use nip5s for a sisters only relay 5, #NoorNode uses a nip5 to limit access to certain kind/post types on the relay (like only livestreams or articles).
I will stop there but point is there are many use cases for this and it seems silly not to pursue the possibilities.
Oooh! How many clients you know are doing this now? I'm exploring this for a kidstr relay + client implementation.
Animestr, all of the stuff at GitCitadel (or they will, as it's on the list to do), and... Dangit. I know that there are another couple but I can't remember at the moment.
No "big" clients yet, but I don't care about those aside from being annoyed at their devs for not getting the utility and SIMPLICITY of implementing it.
😏👍
hey nostr:npub16vjln603hfsfhremp627jle4ycm6p23grjjqrm04rrdwupldyfnsjx88a2 how much of a lift would it be to add this feature to Yakihonne?
Hmm i guess we have to take a look at this and see how it goes 🤔
It's pretty straightforward, you can check it out in my profile JSON or nostr:npub17veg2gt7ja4dnjhs23jyttvpqlde3ajevlxuumxwghnqmgqwuv4q78cc5z's. It looks something like this:
Structure:
content = JSON string with all the fields (including just the first NIP-05 for compatibility)
tags = Array with all the NIP-05s as separate ["nip05", "..."] entries
Other clients only parse content.nip05, so they see one. The ones that support it read the tags, so they see both.
In theory you could add multiple lightning addresses as well (lud16) which could help when a custodial lightning service has downtime.
Yes. It got stuck in PR with so many corrections, that I pulled it back to fix it and make a fresh attempt.
Intended use case is for relay access control and user trust scores. That's a pretty desireable use case regardless of how other clients implement it.
So paying for more NIP-05s means more trust?
We can give NIP5s away to whomever for all it matters. That's not the point. It's how they get used in a trust relationship. It is simply easier for a relay operator to whitelist a nip5 domain at scale than it is to manage each individual npub.
Amythest might be able to do this too. Will have to check
No but it will be
