This proposal is awesome, it’s like having namecoin on peercoin and then some. I want to talk about the technical details. Namely, using vout[1] and vout[0] both as P2TH tags. If you simply made the alias a separate vout[0] tag, you would completely separate assets and aliases. Then, you could hard code both tags into the peerkeeper client and with only a little bit more work you could have the standard peerkeeper validate both assets and aliases while keeping them separate. This makes it so someone only interested in asset issuances won’t have to wade through all the alias issuances. As aliasing allows squatting, the number of aliases may be very large while PA numbers may remain more limited. Separating the tags seems to me to be not only simpler (only using vout[0] instead of both that and vout[1]) and also more efficient (allowing people to look at PAs without looking at aliases). I do not know the code well enough to make statements about the work involved, but in my mind it doesn’t seem that hard to point to two vout[0] tags instead of just one and just sweep both addresses when you want to validate the entire PA+alias network.
Very good. Some quick questions:
Can any of the metadata field be left blank?
All the metadata items have to be used to define an ID, right? One has to distinguish {Bob, bob@yahoo} and {Bob, bob@gmail} ? If a user changes her email address will she have to transfer all her old aliases to new ones?
Does every node have to load the entire blockchain to verify an ID ? It’s like everyone is his own DNS? What if there are millions of users and many have transfered their IDs.
Yes, any and even all metadata fields can be left blank.
If one changes his email address he can simply issue new card_transfer to himself with updated email address. Protocol favors the latest card transfer as valid one.
Yes, just like with PeerAssets you need the entire blockchain to verify the deck properly. If there are millions of ID’s that is same as when there are millions of Peercoin transactions and that should not be a problem.
Beside, I expect that end user light clients will rely on API rather than chain parsing for all things PeerAssets.
And all old credentials remembered by other entities need to be changed? It seems a hassle having to e.g. re-register in a forum which you have had a lot of posting, points, messages just because you changed email.
I think you have misunderstood something. Nobody remembers anything, blockchain remembers.
I thought the alias is used to identify oneself. Can you provide a usecase?
Usecase for alias feature:
Me and @hrobeers start a (2of2) mulitignature alias deck named “@peerassets_devel” and transfer the card to some of our shared addresses. And we post it around as a donation address for PeerAssets project, so users can send donations to “@peerassets_devel” rather than typing or copy/pasting the address.
Alias is just easier to handle by humans.
What happens under the hood of the protocol aware client: read the “@peerassets_devel” string, find the matching PeerAssets deck_id and find the last owner of the one and only card on that deck. This address is the recipient.
Actually this is a decentralized version of P4C. And with the linking to github and signed commits, donators can verify that they aren’t donating to a faked address, making a man in the middle attack much harder.
So a change of a social network id or email address will change the identity but the world only uses the deck name to identify a person.
Deck is used to identify the person. (for example alias is deck_name)
If anything changes one just transfers the card to himself with updated information.
what if there is a second deck named
peerassets_devel?
is the first on timeline that counts then?
You are talking asset squatting/duplicate names.
It is up to user (or his client) to figure out which one is correct, no other way around it.
I imagine that future pa-alias clients will verify which is properly validated and which one is obviously spam/scam.
So client should tell the user which deck has verified card.
Relying on deck age is rewarding quick hand squatters.
So there would need to be some sort of distributed or decentralized registry mapping names to addresses? Or everyone would need to come up with their own way to advertise their name to address binding?
It is up to usecase / community to decide on that. I will verify my alias against twitter and github accounts with usernames “peerchemist” and client should be able to verify that those match my alias username.
I thought the PA Alias will guarantee that there is only one @peerassets_devel. Since PA Alias doesn’t then it is not hard to mess up a deck name by using the same deck name but different meta data.
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.
It will be a problem for PA Alias adoption.
There is no namespacing and collisions are very easy and likely to occur. I’m not sure how this is a good thing and essentially defeats an otherwise good idea. Is there a reason shortnames with easy to induce collisions are being considered? If this is the case then some sort of registry should also be included in the design.
Agreed. As this is a RFC it is good to try and address this now.