[PA RFC-0003] PeerAssets Alias/Proof-of-identity protocol

[peercoinops]

What is the motivation to look up by alias which can be easily squatted and/or induce collisions rather than the other keyed fields (twitter, reddit, email account) ?

[peerchemist]

@mhps

Suppose two DACs use PA Alias to identify its members. What if Bob Smith uses @bob to register at one DAC and Bob Carpenter uses @bob at the other DAC. They are both legit. Then someone who needs to deal with both DACs has to know the two @bob’s are different, and generally has to make sure he knows all such cases of all DACs he does business with ? It;s quite a burden.

You are seeing it wrong, DAC will operate against the pubkey hash (address) and not the alias. For DAC it is important to verify the ID of the person seeking some role and for that it is only important that address is linked against social media accounts or email. Naturally DAC will verify against deck id and not against deck name which can be squatted and duplicated.

@peercoinops

Agreed. As this is a RFC it is good to try and address this now.

It is already addressed. Each deck has unique cryptographic hash, distinguishable from all others. Deck name is irrelevant information on the protocol level.

[hrobeers]

@mphs @peercoinops

There doesn’t need to be a centralized registry, nor would you want to enforce unique names on a first come first serve basis.

To check an identity, you always need a reference point. And for every relationship this reference point can be different.
Some examples:

• You know someone in person: that person can easily provide you his identity asset id (unique as it is the deck spawn txnid)
• You know someone from twitter: that person has published his signed assetid on his twitter feed, now you can find and validate all other social media accounts.
• …

The identity’s asset id is it’s unique identifier, like DNA in real life. Like in real life a name is not unique.

There is no need for a central registry, as an identity has no value without a reference point.

[peercoinops]

@hrobeers

Then we are saying the same thing. This RFC does not require it’s own or an additional registry. Though it does bootstrap using existing decentralized registries such as github, twitter or other social media. The asset id is a cryptographic hash and will be unique.

The confusion or discussion mainly revolves around the choice to use an alias which can be easily squatted and collided with. Using the asset id is fine.

Quoting the RFC
“A blockchain client (wallet) will be able to easily translate @Bob to a
Peercoin address like PDF4NNGBGRSxnRJPyNQyMHqffqbXEtRy5T.”

Ok, so how is this done easily? If there was no alias, then doing it easily would be use one of the decentralized identities such as Github or social media or to use the asset id.

@peerchemist

It is already addressed. Each deck has unique cryptographic hash, distinguishable from all others. Deck name is irrelevant information on the protocol level.

The alias is not a cryptographic hash nor is it any form of decentralized identity. It’s an easy and relatively inexpensive to create string. It’s understood that the asset id is used on the protocol level. Though the RFC clearly states that the client can easily translate the alias to an address, when in fact a determined spammer can quite easily make it the opposite.

Look, this is an interesting project. Though if the RFC states something is easy, it should explain why this is so. Existing solutions like keybase exists and this project is now adding another feature alias and claims it’s easy. Though in fact the alias must resort to either the social media accounts or asset id when there is a collision (which can be inexpensive to induce).

[hrobeers]

yes I agree, it is good feedback on the RFC.
The alias is just a name that can be used as a filter mechanism, it is not correctly reflected in the RFC.

[peercoinops]

@hrobeers

yes I agree, it is good feedback on the RFC.The alias is just a name that can be used as a filter mechanism, it is not correctly reflected in the RFC.

Thank you. I think this is all that is needed. Unfortunately we took a side step though looking forward to more great features!

[peerchemist]

@peercoinops

Look, this is an interesting project. Though if the RFC states something is easy, it should explain why this is so. Existing solutions like keybase exists and this project is now adding another feature alias and claims it’s easy. Though in fact the alias must resort to either the social media accounts or asset id when there is a collision (which can be inexpensive to induce).

This is not an project. This is RFC document proposing PeerAsset protocol extension to support explained features.
It is entirely up to client implementation to cover proposed features in a way which is best for user.

Now, regardless. I stay behind my “it is easy” and will show it in code once I have time to do it.

[Nagalim]

The way I see it, the assetID is the actual alias. It is unique and can always be identified by anyone downloading the chain. The @ alias I see as a nickname. The way I see it, this is done to avoid squatting, so people won’t rush to snatch up all the high-profile assetIDs. Generally, using the @ alias is enough, most people have different names. But in the case where there is chance or danger of collision, the assetID (or other things like alias registration chronology like @thehuntergames mentioned) can be used to be absolutely sure of getting the right address.

[peercoinops]

@peerchemist

Now, regardless. I stay behind my “it is easy” and will show it in code once I have time to do it.

So there is something preventing someone from easily duplicating all identify metainfo? What might that exactly be? From the description it sounded like only the asset id is a cryptographic hash and is unique. If there is a collision for all the identify information, then the user or client must do a lookup to some other service (either social media account or gpg fingerprint verification or something) to vet the asset id.

Though I guess we will have to wait for the code since it is unable to be expressed in the RFC.

[peercoinops]

@Nagalim

The way I see it, the assetID is the actual alias. It is unique and can always be identified by anyone downloading the chain. The @ alias I see as a nickname. The way I see it, this is done to avoid squatting, so people won’t rush to snatch up all the high-profile assetIDs. Generally, using the @ alias is enough, most people have different names. But in the case where there is chance or danger of collision, the assetID (or other things like alias registration chronology like @thehuntergames mentioned) can be used to be absolutely sure of getting the right address.

Agree