0 sats \ 2 replies \ @freakoverse OP 17 Sep 2023 \ parent \ on: The ICANN Problem, Solved with Bitcoin and Nostr via Nomen nostr
/6: For me personally, while this solution is interesting, I wouldn't be a fan of it. I think a better solution would be to just have high-profile entities to just mention their order of claim. Ex: Someone took "Amazon" and then the actual Amazon that we know comes in and registers, they'd just market themselves as "Amazon:2" or something, and browsers/clients, over time, may suggest a "popular" domain to be pushed at the top and writing the domain and/or highlighted.
/7: This is interesting... in terms of decreasing the issue of someone not knowing if a name is shadow-claimed or not, why not, referencing the proposed solution in /6, have a list for those who haven't revealed their claimed name after X blocks (let's say 48 hours worth of blocks of 10 minutes as an example), would be put on that .shadow list (or browsers/clients would do the calc themselves to see if they unsalted their transactions within the X amount of blocks), otherwise it's a valid claim. This might be the smallest compromise to protect people from front-runners and decrease the risk of someone having already taken their name.
/8: No comment on this. I like it =3
/6: For me personally, while this solution is interesting, I wouldn't be a fan of it. I think a better solution would be to just have high-profile entities to just mention their order of claim. Ex: Someone took "Amazon" and then the actual Amazon that we know comes in and registers, they'd just market themselves as "Amazon:2" or something, and browsers/clients, over time, may suggest a "popular" domain to be pushed at the top and writing the domain and/or highlighted.
What you’re describing here sounds more like squatting prevention. 6 describes putting all of the ownership data on chain so the indexer doesn’t require data from Nostr to maintain a chain of custody.
Am I misunderstanding what you mean?
/7: This is interesting... in terms of decreasing the issue of someone not knowing if a name is shadow-claimed or not, why not, referencing the proposed solution in /6, have a list for those who haven't revealed their claimed name after X blocks (let's say 48 hours worth of blocks of 10 minutes as an example), would be put on that .shadow list (or browsers/clients would do the calc themselves to see if they unsalted their transactions within the X amount of blocks), otherwise it's a valid claim. This might be the smallest compromise to protect people from front-runners and decrease the risk of someone having already taken their name.
Interesting! We could also make it so if they don’t reveal their shadow claim in 48 hours, their claim is invalid, making it impossible to sit on any claim for a long period of time.
reply
Ah, sorry about that, I got my order wrong. The first and last should've been switched. Here's the correct ordering:
/6: No comment on this. I like it =3
/7: This is interesting... in terms of decreasing the issue of someone not knowing if a name is shadow-claimed or not, why not, referencing the proposed solution in /6, have a list for those who haven't revealed their claimed name after X blocks (let's say 48 hours worth of blocks of 10 minutes as an example), would be put on that .shadow list (or browsers/clients would do the calc themselves to see if they unsalted their transactions within the X amount of blocks), otherwise it's a valid claim. This might be the smallest compromise to protect people from front-runners and decrease the risk of someone having already taken their name.
/8: For me personally, while this solution is interesting, I wouldn't be a fan of it. I think a better solution would be to just have high-profile entities to just mention their order of claim. Ex: Someone took "Amazon" and then the actual Amazon that we know comes in and registers, they'd just market themselves as "Amazon:2" or something, and browsers/clients, over time, may suggest a "popular" domain to be pushed at the top and writing the domain and/or highlighted.
reply