3 sats \ 0 replies \ @freakoverse OP 18 Sep 2023 \ parent \ on: The ICANN Problem, Solved with Bitcoin and Nostr via Nomen nostr
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.
/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
-
If it's possible for them to censor or steal, then it's a possibility and that is indeed a fact. The whole nature of Bitcoin, as an example, is not trust but verify.
-
I'm not that technical of a person, so I can't properly respond to this, however from my colleagues who are knowledgeable about it, and from seeing alt solutions, it's a hurdle but not that big of a hurdle.
-
I'm in agreement here.
-
I'm not saying people should rely on it, it's just a step in the process, which I did mention after that, browsers would have native support for these new Nomen domains. Heck, if they can go straight to native support / having a browser with native support built-in, and forget about the extension, then by all means. It's just a bonus.
-
I mean sure, but in that regard, both who want to follow and be followed, at least for me and others, would like to have a concrete name that people without a doubt would know it's me or them. Considering I view ICANN as an issue, then NIP-05 is just a temporary ducktape solution.
We're probably not going to move forward with the discussions in regard to points 2 and 3. We have our base stances on those from the looks of it so will move on from it.
In regards to point 1 however, yes, I'm in agreement here (aside from the issue of having btc, that is an 'issue' everywhere), as it was mentioned/implied in the post. With that said, it's only a matter of time before the UX part becomes sexy (discussions about that is already underway by interested individuals).
Yes, I'm aware of zaps, I love em =3
But no, while I appreciate buzz-sentence of "All Your Models Are Broken", they aren't actually, and they will be used. The only note about that is those traditional models would be modified to fit the nature of nostr.
....yes?
Why do you think there's no way to make money with nostr, on the developers' side that makes the client (app/website)?
Just read it (yet to test it). Pretty cool!
Still digesting it, but one question (I'll save other questions for later):
After the initial creation of a NAMESPACE ID with a bitcoin address, where there's a <NAME><OWNER PUBKEY> (owner nostr public key i'd assume, correct?), if I'd want to transfer the ownership from myself to another person, would I have to use the exact same bitcoin address to do so, or any bitcoin address is fine but what's required is the signature of the nostr address of <NAME><OWNER PUBKEY>?
As there are dangers to anonymity, there are dangers to being public.
What's the actual solution? Have the choice of both, decided by the person themselves.
I have this account, I have another personal account, and I have a public professional account. One is anonymous, another is semi-anonymous, and the third is public.
Just read up on it a bit. Seems good.
Basically, after everything is done for example:
"hey fred, send me 0.5 btc to freakoverse.sats" (assuming wallets take the first person to take the name based on date/block)
or if I'm paranoid "...to freakoverse.sats@800890.2"
(@block.line).
Got a few questions for this though (not sure if they're answered by someone, so will have to dig for them):
- can you attach an IP address to a .sats name? (if yes, then would browsers be able to read them and have normal website functionality, assuming they'd support the ordinals and sats name systems)
- can you have anything other than ".sats", create your own TLD, or have non at all?
- can you modify the content of a .sats ordinal, like changing the btc address (and IP if that's possible in point 1).
- are there normal non-custodial wallets that support this yet, like Trust Wallet or Blue Wallet.
Wouldn't the incentive be that they'd be rewarded with those naming tokens and they can:
- use them themselves (use incentive)
- sell them (financial incentive)
- get network fees as people update their tokens (financial incentive)
well, shittokens are now on bitcoin with ordinals, which I was against but it happened, so *shrug
Might as well make use of it and have it solve the ICANN problem.
I'm not a technical person, so I don't know how or can this be implemented, but I'm just presenting the idea to make bitcoin as the source of decentralized authority instead of ICANN for human readable addresses, for websites or for bitcoin addresses.