Improvements to ONS 0.3 rfc #25
Conversation
Users frequently have more than one name, so they should be represented as an array Name objects have one type and zero or more attributes Update example with suggested types and attributes
URL is a more general concept with applications beyond websites url objects have one type and zero or more attributes Update example with suggested types and attributes
This list should be capable of representing a profile on any website, not just well-known sites. The proof property is removed as it will be replaced with a more general proposal.
Include the ability to set attributes for images.
Users may have more than one email address, and they may also use other email-like services.
The IM section includes instant messaging and voice chat methods.
A user might posess more than one PGP key, and may wish to associate other types of keys Changed section to an array
users may wish to assocate physical location information with their entry. provide a scheme and suggested attributes
remove obselete Basics section, replace with a section for text information
move proofs to a seperate Namecoin entry, whose format will be specified in a seperate rfc
|
Do you have any examples of people using more than one GPG key per identity? We searched around and couldn't find any evidence for this. It would make more sense IMO for someone to make more than one identity on ONS. Here is one good resource: http://security.stackexchange.com/questions/29851/how-many-gpg-keys-should-i-make Would love to hear about your rationale for this update. |
|
I know people who don't realize that GPG keys can have more than one email address (identity) associated with them. Some people might have a personal key, and an employer-issued key. GPG keys can be made to expire, and a user may wish to keep an old key listed for historical reasons and also their current key. Let me turn the question around: Why restrict identites to a single GPG key (single anything)? Every 1:1 restriction you add to the specification like this closes off a certain number of use cases. Every time you do this you should have a rationale for why it makes sense to exclude those users if you want to have a useful open specification. |
|
@justusranvier I get what you're saying. We were just trying to balance simplicity with flexibility. We figured that if 99.99% of people behaved in a certain way and only 0.01% deviated from that norm, then adding additional complexity to the protocol would not be not worth it. You bring up some good scenarios in which users would want to have more than one PGP key per identity at a given time. The way I see it is this: if they are in fact non-rare cases, then it totally makes sense to support multiple PGP keys. |
|
How serious are you about making this an Open Naming Specification? If you're just trying to make something that's immediately useful to onename.io and nobody else, then balancing simplicity with flexbility in the specification itself (as opposed to the end user application) is the right way to go. If you want this to be a spec that gets wide adoption across more companies and apps than just yours, then build the spec with the needs of others in mind. This doesn't mean you need to implement every feature allowed by the spec in your application right away - it means putting the right foundations in the spec so that when you're ready to use them, or if somebody else wants to use them right away, there's no need for a disruptive version changeover. |
|
We definitely want this to be something for everyone. "Open" is right. |
|
Many of the aspects of this proposal came from the conversations in this related thread on the Namecoin forums: |
All the implicit 1:1 relationships in the previous version have been represented as one-to-many, because users will desire to, for example, attach more than one name or GPG key with their identity.
In order to make the schema as useful as possible to as many applications as possible, all arrays and objects are generic, with object types and attributes used to attach semantic meaning to them.
This means it should be possible to create applications that can properly display an entry without needing to understand every object semantically, and application or users can add their own attributes and types as needed.
Proof has been moved to a seperate entry, which will have its own rfc. Proving identity data should also be generic, with any identity being capable of offering attestations for or against any claim made by any user.