• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Front-end Team Evolution Demo Video #1

@chinmi I think he meant the private part of the HD wallet will be encrypted. I'm pretty sure a pay code for every username will be public (hope!).
 
Thanks for the update, very good.

I think the name space should have two levels; a network name followed by "@username". A network name would be similar to TLDs e.g. "flights", "food", "news", "sexy" etc. If no network name is specified, then the "dash" network would be assumed. All other network names must be approved by MNOs via a proposal vote. If approved, the new owner would be entirely responsible for managing their username space. This is very important because:
  1. "@Joe", "flights@joe" and "food@joe" would be three different users, and
  2. it means DCG can significantly mitigate responsibility (and control) over name squatting / copyright.
Because network names are subject to vote, the proposal process would be reversed i.e. the treasury would receive funds instead of issuing it, thereby giving us more spending power.

The lease time for network names is up for discussion but for now I would suggest 5 years / 60 cycles, with the option to down vote and disable.
 
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?

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.

By comparison - consider the case with email. They would have to take pains to disassociate their identities from their email addresses in the same way, right? Even if many emails were intercepted - with PGP encryption presumably they'd only have from & to addresses, right?
 
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 ?

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.
 
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

Great answer @chuck. Glad to see you guys making progress!

1. Basic Question:
Why are you dealing with any sort of user/contact architecture?

2. 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.

3. Product Question: This all seems to be adjacent to infrastructure & the dAPPI you are building. Why take the risk? What problem are you solving?

Without seeing the code.. I'm just shooting in the dark, but if you had pubically accessible generic name level information around user/contact info at a network level it would get abused big time.
 
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?
 
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?

Actually, DNS isn't that good, is regularly abused by governments.

From what I understand, Civic would be a bad choice as they are essentially making it easy for data collection.

The important thing is, if dash could make a better DNS, possibly replicating the zone parts and ignoring all that third level country code stuff, then it would have a shot (a long shot) at giving people true freedom of speech.
 
Why are you dealing with any sort of user/contact architecture?
"Why" questions are always hard for me. It always invokes my philosophical side. So, apologies up front.

My personal opinion based on my growing understanding of the vision being presented here is this: In the distant future, identity & privacy is going to be extremely important. If Dash is going to be properly prepared to deal with the very critical issues of privacy & identity in the future, we must begin to take slow, methodical steps into the space. Not so far out as a rabbit in this case - ahead of the pack and first off the cliff, and not so slow as the turtle - left behind and consumed by the forest fire - or maybe the trick there is to dunk in the lake?

In any case - my very, very much biased opinion is that Dash is at the leading edge of this pack of freedom-finders. These groups who wish to protect humanity from those who would control and abuse our identities, and hence our communities of connected beings. We must tread carefully here but there is an important vector here manifesting that coils around government & central banking farm-base identities, and self-directed, reputation enabled, sovereign based identities.

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.

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).

Product Question: This all seems to be adjacent to infrastructure & the dAPPI you are building. Why take the risk? What problem are you solving?

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.

Of course, due to the limited nature of language, characters, and meanings - these will be naturally scarce items that correlate to natural reality. There is only one word that is "tree" in the english language. We understand that words, labels, and symbols have perceived value because they are the foundation of communication, and I personally believe that these labels are intended to be publicly utterable by & visible to all conscious beings. Isn't this the foundation of free speech?

It is because names are important that we must move slowly, and incrementally. The right way to start with anything big is with incremental, calculated risks. We are risking our platform on a "big idea". We believe it will add value to our platform by moving cryptocurrency from the very technical to the very verbal and repeatable. This movement will remove friction in making payments. No more swiping of cards, exchanges of characters, tapping of devices, scanning of chips, or biometrics.

Now you can pay someone with a single word.

Words that are public, open-source, MIT licensed by Dash Core Group, Inc. to function on top of the Dash blockchain.

And then - we make it easy for developers of the world to implement it in the words (code, language) of their choosing, on the devices of their choosing. IMHO, That's why we're doing both at the same time.
 
Last edited:
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
 
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

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.

Technically - I'm pretty sure that there is agreement among Dash Core that names will be exchangeable, & transferrable using a combination of the new transaction capabilities that have been designed and researched. This is most definitely subject to change, though. So I wouldn't expect everyone to be 100% happy with resolution v0.0.1 here.
 
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.
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.

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.
 
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.

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.

“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 ;)
 
“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 ;)

<snark> It's our new "Proof of Proposal" mining algorithm. We're just conducting the pre-mine now. </snark>
 
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)
 
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)

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.

For better or worse, the "@" symbol is used on forums and social media to identify users. It's the most widely recognized cue to mean "user".

I agree, english usernames should be case insensitive or lowercase only (just like graphene). But equally we must be fully internationalized.
 
So much of your info is out there anyway with the legacy financial system. This will not be any worse.
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?
Good luck swaying others...
That will be your problem if you go through with this foolishness...

I have no doubt you'll get continuing support from the SuckerNodes. Most just quit voting, so only the yes men still show up to the polls.

But, overall, this is a path to failure. You care only for getting the votes from MNOs, paying no attention that this is a non-starter for any potential new users, while driving away anyone already here by abandoning the reasons why they're here...

You point out that "people" (Joe Facebook) prefer convenience over privacy, but neglect the reality that Joe Facebook already gets more of both from the existing Bank/Fiat system...

If at any point a psuedonym is attached to a transaction, ever... It's worse than exposing a single address. It exposes everything, forever.

"then don't do business with Starbucks"

How about paying utilities? Just don't do business with them? There are tons of entities with which one is forced to do business, the need, not want, of which grants sufficient leverage to coerce this information.

What color is the sky on your planet?

I think you're so deep in the forest that you can't see the sky.

You've created a disincentive for Joe Facebook to use it, and eliminated the reasons existing cryptotards would use it... Alienating your current base while turning away new users. Brilliant.

You've gone Microsoft, but in a marketplace of abundant competitors with no embedded, proprietary market... You simply don't have the entrenchment/monopoly to make these demands.

The ever-shrinking echo chamber has swollen your heads more than I thought...

"Come use DASH! It's the total pain in the butt crypto that makes your entire transaction history public knowledge in the name of privacy!"

Lolwut? Seriously, this is absurd. If you can't see that then this project is in serious trouble...

Banks are better than this.
 
Last edited:
Back
Top