Okay, where to start..
- Will you extend this to payment codes for other cryptos? I am not suggesting we host multiple chains! But it seems to me, this could easily manage the keys for, say, bitcoin. Usernames that worked with bitcoin (and others) would be a huge deal
Because a) no one holds just one coin / token, and b) it would be a highly effective way to switch people to dash / upsell our benefits.
- Why would we extend this to other coins?
I only hold one coin, why hold more if you believe in the project more than the rest?Because a) no one holds just one coin / token, and b) it would be a highly effective way to switch people to dash / upsell our benefits.
The future is not one coin, there will always be multiple coins, in the exact same way we have multiple programming languages; different use cases and preferences. Blockchain interoperability is the future, in the same way TCP/IP was the joining of different philosophies.
I gather the answer is no, but just to clarify, will a person's contact list be visible to others, whether through viewing their profile, or blockchain analysis, or other methods?
I'm sure many people consider this sensitive information.
We haven’t addressed this, specifically, yet. However, we believe the results of our research data and system designs will be able to maintain security across the 2nd tier network of masternodes, and the assets they protect in DashDrive.I assume (guess) you will be using round-robin dns for the DAPI. How are you going to deal with security, especially at a state level, where dns has sometimes been compromised.
We are thinking/arguing/debating/dreaming/designing/POC’ing/re-implementing really hard about this issue. This issue is the core of the Evolution Platform that is expected to be the flagship product for Dash Core Group, Inc. for some time to come. We really don’t get a 2nd opportunity to get this right if we get it wrong. Blockchain Usernames are possibly the single most discussed nouns among Core developers since September 2017.I still think you need to sit down and think hard about username management. I know they are not free, but name squatting will still be a major issue.
If you send them a contact request, or if you accept their request, they will have what they need to send you a payment. A contact request/confirmation (in DashDrive they are the same thing) is an entry in your userspace that says, "Hey XYZ, here's a public HD key you can use for paying me, and it's encrypted just for you." (The "Hey XYZ" part is publicly visible, the HD key part is encrypted.)1. If someone wanted to pay me and I gave them my username, would I first have to accept a contact request from them before they're able to pay me?
Yes, this is a topic of concern. Registering usernames will cost a few cents of Dash, which helps a little bit. But usernames as property is a huge, thorny topic, and we haven't found any easy answers. For now we're not doing anything special to try to prevent a username market from developing.2. (repeated question) Is there any reason for concern that malicious parties will set about registering tens of thousands of usernames, just to try to use up as many desirable namespaces as possible?
Using the analogy of Alice, the California medical marijuana dispensary operator who is supported by local government, but vilified by the federal government:2) ALL blockchain user CONTACT REQUEST TRANSACTIONS (& associated state transitions) will be PUBLIC and VISIBLE on the blockchain
2.1) When a blockchain user response to a contact request, one part is only decipherable by the receiver. Someone else cannot distinguish between an approval and a rejection. Furthermore, they can't tell if you have declined, then re-asked yourself, or first accepted, then removed... This "series" of "states" on a "blockchain user object" are "opaque" (not decipherable).
2.2) Right now, in the prototype - everything is transparent and not cryptographically protected. Dash protocol developers have encryption securities planned, not yet implemented, in the system design.
Interesting. So the way I understand your reply, it will not be possible for Amanda to accept tips from her viewers on her Dash username, except if she accepts (or sends) contact requests from each of them ?If you send them a contact request, or if you accept their request, they will have what they need to send you a payment. A contact request/confirmation (in DashDrive they are the same thing) is an entry in your userspace that says, "Hey XYZ, here's a public HD key you can use for paying me, and it's encrypted just for you." (The "Hey XYZ" part is publicly visible, the HD key part is encrypted.)
I can't yet confirm the future plan that contact requests will be encrypted. It seems reasonable to expect, but we'll likely have to prioritize it appropriately. I think we'll clear up plans for that soon. The rest seems about right.Using the analogy of Alice, the California medical marijuana dispensary operator who is supported by local government, but vilified by the federal government:
If she makes contact requests of all her local organic suppliers, the DEA will be able to observe the contact requests, but NOT know the status of the requests or any transaction data that takes place between them.The best practice for Alice and her suppliers is, for business purposes, to use a username that is anonymous and in no way connected to their identity. If the DEA does not know their username, they will not be able to observe their contact requests. In the future it is planned that contact requests will be encrypted, so even if the username is known, the contact request cannot be seen.
Is this correct?
The system design (as I recall from ~ 2 months ago) may have zone in which part of the registration transaction includes a newly generated public address for use in default "pay-by-name" schemes. This way Amanda can receive funds to this address just by using the name on-protocol - but those funds would be known, public, and not private (unless later mixed, of course). This was designed specifically as a "tipping" address. I would have to go back and confirm that it's still in the design. I understand there's been some modifications.Interesting. So the way I understand your reply, it will not be possible for Amanda to accept tips from her viewers on her Dash username, except if she accepts (or sends) contact requests from each of them ?
Great answer @chuck. Glad to see you guys making progress!First a clarification: A "person" will NOT have "their" contact list readily available. The Dash protocol & Evolution platform is not designed not collect or store any identifying information of "persons".
2) ALL blockchain user CONTACT REQUEST TRANSACTIONS (& associated state transitions) will be PUBLIC and VISIBLE on the blockchain
Actually, DNS isn't that good, is regularly abused by governments.Perhaps something like Keybase or Civic is a better platform for username management to prevent squatting in the namespace? Why try to do this internally when all of the difficult work for e.g. phone/email verification and bundling disparate internet identifiers together and releasing that information selectively could be handled by a platform specifically designed to manage what identity data is shared?
"Why" questions are always hard for me. It always invokes my philosophical side. So, apologies up front.Why are you dealing with any sort of user/contact architecture?
Agree. I personally hope that a wildly successful competitive market of identity provision services arise atop the Dash Evolution Platform to help bring freedom to all sovereign beings. (See I'm all philosophical now).Difficult question: Why is that not handled outside of dash core, like 3rd party, other devs, etc? There could be several companies that could exist just to handle users, data contracts, and authentication to the dash network.
We are giving individuals the ability to claim what is essentially an inalienable right to a namespace of their choosing represented on the Dash blockchain. We will help them cryptographically protect it with a private key. With these namespaces, many data objects will be traded very easily - because they can be named. One thing I've always concluded in software development is that names are important.Product Question: This all seems to be adjacent to infrastructure & the dAPPI you are building. Why take the risk? What problem are you solving?
That's the money quote.With these namespaces, many data objects will be traded very easily - because they can be named.
That hasn't quite been worked out, AFAIK. I'm making some limited arguments for a moderated trading management system - but I'm pretty sure I don't have team agreement that Dash Core Group, Inc. should be managing the scope of this idea - in which case I agree. I think there's a lot of uncertainty about how the names should be managed, post-acquisition/registration, and we have limited examples that are decentralized and open source in nature. I'm personally open to suggestions & musings here.Sold usernames on Dash Evo platform will be completely useless won't they? Because you can never know whether the seller has kept a copy of the Private key, so it's highly unsafe to use a bought one. Or can you change the Privkey associated with a username?
So I'd gather usernames don't really have resell value, but they could probably be used for phishing
We are working on an on-chain and deterministic masternode system which will allow all DAPI clients (and other SPV type clients) to query and verify a masternode list. This will require an initial (hardcoded or from DNS) list of nodes to be known, which can then be used to query the current masternode list with additional SPV like proof data. If individual entries from your known-nodes list are failing or malicious, other nodes from your list will compensate this. After this process succeeds, the resulting masternode list can be reused later to re-initiate the process, which will then be faster, as less nodes are likely to have failed or being malicious, and also because only diffs to the previously verfified masternode list need to be transferred.2. I assume (guess) you will be using round-robin dns for the DAPI. How are you going to deal with security, especially at a state level, where dns has sometimes been compromised.
“When the DIPs have been finalized” - this has to be the quote most used in the Evo project lol. If I had a dollar evertime core said this I would be retiredWe are working on an on-chain and deterministic masternode system which will allow all DAPI clients (and other SPV type clients) to query and verify a masternode list. This will require an initial (hardcoded or from DNS) list of nodes to be known, which can then be used to query the current masternode list with additional SPV like proof data. If individual entries from your known-nodes list are failing or malicious, other nodes from your list will compensate this. After this process succeeds, the resulting masternode list can be reused later to re-initiate the process, which will then be faster, as less nodes are likely to have failed or being malicious, and also because only diffs to the previously verfified masternode list need to be transferred.
The verification basically verifies that the masternode list is actually confirmed on the longest-work chain, using SPV (merkle proofs) like methods. So it should be pretty secure and reliable. We will publish more details in the upcoming weeks when DIPs have been finalized.
<snark> It's our new "Proof of Proposal" mining algorithm. We're just conducting the pre-mine now. </snark>“When the DIPs have been finalized” - this has to be the quote most used in the Evo project lol. If I had a dollar evertime core said this I would be retired![]()
The problem is, usernames need to be speakable, that is to say, imagine you are giving your email / web / username to someone on the phone. When you say "dash", you would have to clarify and say, "the dash symbol". It's a common mistake when people choose names. "TenX", for example, is a bad name because you have to actually say, T E N X.About usernames:
Maybe it would be a good idea to use the keyboard key "-" called Dash (also called hyphen) as part of the usernames.
Just as domain names use the "." ("Dot") and email names use the "@" ("At")
It's not so flashy as the "@" or "#" but it reinforces our brand.
My dash username could be "-Elmo" pronounced "dash elmo"
(Also, like domains and emails lowercap and Uppercap should be the same. Elmo = elmo)
It won't be any better, either... So why not stick with the familiar? Why go to all this trouble when what Joe Facebook is already doing is better in his eyes?So much of your info is out there anyway with the legacy financial system. This will not be any worse.
That will be your problem if you go through with this foolishness...Good luck swaying others...