Text archives Help


Re: [projectvrm] OneName


Chronological Thread 
  • From: Dan Blum < >
  • To: Bart Stevens < >
  • Cc: Phil Windley < >, Jim Bursch < >, ProjectVRM list < >
  • Subject: Re: [projectvrm] OneName
  • Date: Thu, 10 Apr 2014 09:32:34 -0400

Finding Heterarchy - The question of heterarchy has popped up in a couple different threads. I wrote a post on it a few days back and wanted to get that in front of this group. Apologies for the duplicate posting of this note on a few different message threads.

The Respect Network (and the Extensible Data Interchange (XDI) standard) provides a hybrid solution for  naming, addressing and communications topology 

- Personal clouds (which may be self-hosted or CSP-hosted) communicate peer to peer with each other, and with business clouds
- Cloud addresses are decentralized, expressed as UUIDs in XDI syntax
Cloud names are stored in an XDI registry to allow for opt-in discovery and for reputation management. You can have multiple and/or pseudonymous names. Multiple names shouldn't be corelatable by other members but we do maintain one reputation for a member's names.
- The architecture allows for multiple, distributed peer registries and reputation systems in the future. 

Please see this blog post - Finding Heterarchy - for more information.
Best regards,
Dan Blum
Respect Network
Chief Privacy and Security Architect 


On Tue, Apr 8, 2014 at 7:44 AM, Bart Stevens < " target="_blank"> > wrote:

You should check ethereum as well

Doc already sent out my recent piece On Names and Heterarchy:  http://wnd.li/nqW9XT

OneName and similar systems use the Bitcoin algorithm (but, as I understand it, a different blockchain) to record key-value pairs without any centralized infrastructure, without any single point of failure. 

The mapping that OneName is recording is between a name of your choosing and a profile. Here’s mine: https://www.onename.io/windley 

Don’t let the fact that this is a Website fool you. The website isn’t referring to a database to retrieve the profile (although there may be a cache involved). Rather it’s referring to the blockchain, a distributed data structure that anyone can have a copy of. Bitcoin (see http://www.michaelnielsen.org/ddi/how-the-bitcoin-protocol-actually-works/ for a great intro to how this all works) is used to ensure that all the copies are eventually consistent with each other, even in the face of entities who would purposefully try to keep that from happening. So, with the proper software, you could look up ‘windley’ in the OneCoin key-value store and retrieve my profile information without any centralized authority intermediating your query. 

How does that relate to VRM? I believe most people on this list believe that centralized authorities who intermediate interactions and transactions will eventually have incentive to act in a way that is not in your interest or be subverted by those who have such an incentive. Therefore, heterarchical systems are a way to avoid such problems. But it’s fairly far down in the infrastructure chain from a VRM solution. 

As for scalability (several people have mentioned this). There is nothing in the OneName technology (at a conceptual level, I’ve not done any kind of formal review) that won’t scale beautifully. When Kevin Cox talks about “it” not scaling, I believe he’s referring to the idea of names themselves, not any specific technology for creating key-value mappings. But it can’t create any more meaningful strings of letters and digits in a single namespace than any other system. 

In my blog post I outlined several alternatives to names. That said, I think we’ll always want names for referring to things and we’ll often have requirements that those names be in some kind of global public directory. I don’t think we can blithely say “we’ll never need names.” Technologies like OneName and Namecoin will be useful for solving those problems. 

On a related thread, check out Keybase.io. It is NOT a heterarchical system. It is decidedly centralized. Nevertheless, their approach to linking my public key to other identities I’ve already established is quite interesting. This is a form of directory that allows you to find me and send me private messages with some social assurance that the address really is mine. Check out my Keybase.io profile here: https://keybase.io/windley (you’ll note I’m snapping up “windley” everywhere I can).  This is an example of why we may not need global directories of user names. So long as you can find me, be assured I’m the person you’re looking for, and then use that method to get a unique address, you’ve got much of what you need. 


Is anyone here familiar with OneName? How does it fit in the VRM space?



How OneName Makes Bitcoin Payments as Simple as Facebook Sharing
http://www.coindesk.com/onename-makes-bitcoin-payments-simple-facebook-sharing/

https://github.com/onenameio/onename
"OneName is a protocol for a decentralized identity system (DIS) with a user directory comprised of entries in a decentralized key-value store. OneName currently uses the Namecoin blockchain, but any decentralized key-value store may be used.

"Users are added to the OneName directory via an entry into the key-value store, where the key is the username and the value is the profile data (in JSON format).

"The OneName protocol provides formatting specifications for usernames and profiles and defines conventions for OneName profile crawlers/explorers (which read from the key-value store, digest profile data, and display profiles).

"Nobody owns or controls OneName and users are in complete control of their data.

"With Bitcoin, private keys provide us with complete control over our funds - nobody can move it without our permission. In the same way, OneName private keys provide us with complete control over our identities - no individual or entity can usurp our usernames or modify our public data or control the release of our private data without our permission.

"OneName is open source, has a public design, and is for all to take part."



Jim Bursch
310-869-5340

 
 " target="_blank">
 
@jimbursch







Archive powered by MHonArc 2.6.19.