Login

Redecentralize

We’ve had enough of digital monopolies and surveillance capitalism. We want an alternative world that works for everyone, just like the original intention of the web and net.

We seek a world of open platforms and protocols with real choices of applications and services for people. We care about privacy, transparency and autonomy. Our tools and organisations should fundamentally be accountable and resilient.

Home

Parent
Paul Frazee [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-05 13:59:28 (4 years 10 mons 13 days 09:29:00 ago)
 
Exactly. Identity is the unsolved problem for decentralization.
 
Don't understand that remark.  So far I've been under the impression that it's not hard to decentralize identity per se.  (Use a canonical hash proofing some interesting property. The property could be simply a key or better a certificate proofing additional information together with the key.)

What's hard to decentralize would be human-meaningful names to those identities.

Or did you address something else by "identity"?

Sorry-- I've been writing quickly. "Identity" as in authentication, of who you are, and what you do.

If our goal is to depend less on central hosts, then user data needs to move freely from one host to another. It would be hard, for instance, for me to jump from gmail to yahoo because my identity is stuck @gmail. I'd have to update my online accounts and call up my friends. But maybe I prefer yahoo's interface? Well, tough luck.

So the solution is RSA keypairs. If users sign their messages, it matters less who hosts and carries them. I could jump between yahoo and gmail any time. I could jump to any number of applications and hosts.

But we haven't nailed certfile-distribution at scale yet, so that's why I call it an unsolved problem. I think the web-of-trust is inevitably what we'll need, but PGP has a few critical problems. For one (1) the people that sign certificates can't revoke the signatures after-the-fact. If there's been a keypair compromise, the owner has to publish a revocation cert (you... did make a revocation cert, right?) and distribute it before too much damage is done. For two (2) there's only one kind of relationship in PGP's WoT, the "verified by my signature" relationship. Trust is a probability-decision (eg what are the odds this guy's really the bob he claims to be?) so you'd benefit from a richer set of signals. There are other kinds queries you'll want to make: what are the odds this guy's going to defraud my business, or drop the contract before the job is done?

This is what gets my excited about SSB -- it's a keypair that publishes a verified log. Rather than having users sign each other's certfiles, you can have their feeds publish the verifications. (1) If there's a compromise, the same peers can publish a warning (revoke the verification). That gives a more usable solution to "my account may have been hacked because it's sending weird emails" -- you create a new account, call up your friends, and have them flag off the old account for a new one. (2) More generally, SSB can publish a lot of different kinds of relationships between the nodes, because it's cheap to publish new edges in our WoT graph. That can lead to a richer data-set.

Jörg, as to your book-keeping example, Dominic's answer is better -- SSB isn't really perfect for that. But my contention is that a large part of any system is holding the participants accountable for their activity. If the users operate under identities within a WoT, you have a lot more to hold them accountable with. That's the basis of the reputation system I'm talking about.

Paul


On Fri, Sep 5, 2014 at 7:13 AM, Jörg F. Wittenberger <Joerg.Wittenberger@softeyes.net> wrote:
Am 04.09.2014 19:45, schrieb Paul Frazee:


Got one question here: this seems to replicate data.  Does it protect
against malicious updates too?

It creates a verifiable log only -- the content of the messages is an application concern. We're looking at CRDTs to deal with convergence, but the systemic model for security is the reputation system.

CRDT = "Cambodian Rural Development Team"  ;-)  Ah, no "commutative replicated data type".  I love abbreviations.  Though I don't see how the operations in question could ever commute.  Either I got money before I can spend it or I can't spend it.  What am I missing?

This reputation system would be interesting to me.  But I can't find much about it.


So if I wanted to build applications like that one on scuttlebutt...
possible?  How would I make sure the wallet is always correct?

It is possible. Trust is the hard part in all of this. Once you have trust, then book-keeping is eventual consistency.

Hm.  Isn't this saying "no, SSB is a data replication layer, you need something like an agreement on top to establish trust"?  (Though once I have that agreement, reconciliation is relevant only for nodes which missed the update itself.)



After you've distributed identities, you need to distribute data-structures as well,

This would be the easy part.

Exactly. Identity is the unsolved problem for decentralization.

Don't understand that remark.  So far I've been under the impression that it's not hard to decentralize identity per se.  (Use a canonical hash proofing some interesting property. The property could be simply a key or better a certificate proofing additional information together with the key.)

What's hard to decentralize would be human-meaningful names to those identities.

Or did you address something else by "identity"?

Thanks

/Jörg

: