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
Adam Ierymenko [LibreList] Thoughts on decentralization and deperimeterization 2014-08-29 10:01:03 (6 years 1 mon 29 days 10:29:00 ago)
I wrote another post on my own views on decentralization... sort of a partial followup to the previous "I want to believe" one. I'm still working on a technical followup, but this is more of a theoretical one.


(Apologies if this is a double post -- the previous one I sent went out from an old e-mail address that was still in my webmail interface for some reason... shows how often I use webmail. It probably disappeared into the ether.)

David Burns [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-08-29 12:14:23 (6 years 1 mon 29 days 08:16:00 ago)
Here's the result when I add the feed to feedly, after previous steps (OS = ubuntu) seem successful:

Explore http://29.44.238.229/~api/feed.xml
Sorry. No feed found. Please try searching for another url, title or #topic.

I installed liferea and got the success!

Did feedly fail because its a webapp? Or just because it's feeble?
Dave

On Fri, Aug 29, 2014 at 7:01 AM, Adam Ierymenko <adam.ierymenko@zerotier.com> wrote:
 
I wrote another post on my own views on decentralization... sort of a partial followup to the previous "I want to believe" one. I'm still working on a technical followup, but this is more of a theoretical one.


(Apologies if this is a double post -- the previous one I sent went out from an old e-mail address that was still in my webmail interface for some reason... shows how often I use webmail. It probably disappeared into the ether.)


Adam Ierymenko [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-08-29 15:17:09 (6 years 1 mon 29 days 05:13:00 ago)
Heh.

I should clarify that: you have to do it from your own computer. That’s the point. I tested with an app called Newsfire, but it can be any local RSS reader, web browser, or URL fetcher.

The point is to make a trivial and goofy but hopefully hard-hitting demo of the fact that IP is in fact the P2P protocol we’re looking for (provided it can run without a ton of walls and moats in the way).

-Adam

On Aug 29, 2014, at 3:14 PM, David Burns <tdbtdb@gmail.com> wrote:

Here's the result when I add the feed to feedly, after previous steps (OS = ubuntu) seem successful:

Explore http://29.44.238.229/~api/feed.xml
Sorry. No feed found. Please try searching for another url, title or #topic.

I installed liferea and got the success!

Did feedly fail because its a webapp? Or just because it's feeble?
Dave

On Fri, Aug 29, 2014 at 7:01 AM, Adam Ierymenko <adam.ierymenko@zerotier.com> wrote:
 
I wrote another post on my own views on decentralization... sort of a partial followup to the previous "I want to believe" one. I'm still working on a technical followup, but this is more of a theoretical one.


(Apologies if this is a double post -- the previous one I sent went out from an old e-mail address that was still in my webmail interface for some reason... shows how often I use webmail. It probably disappeared into the ether.)



David Geib [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-08-29 19:55:53 (6 years 1 mon 29 days 00:34:00 ago)
It seems like you should be able to use any of the usual name resolution methods like DNS instead of using IP addresses. The names would only work for people with the software installed but so do the IP addresses.


On Fri, Aug 29, 2014 at 6:17 PM, Adam Ierymenko <adam.ierymenko@zerotier.com> wrote:
Heh.

I should clarify that: you have to do it from your own computer. That’s the point. I tested with an app called Newsfire, but it can be any local RSS reader, web browser, or URL fetcher.

The point is to make a trivial and goofy but hopefully hard-hitting demo of the fact that IP is in fact the P2P protocol we’re looking for (provided it can run without a ton of walls and moats in the way).

-Adam

On Aug 29, 2014, at 3:14 PM, David Burns <tdbtdb@gmail.com> wrote:

Here's the result when I add the feed to feedly, after previous steps (OS = ubuntu) seem successful:

Explore http://29.44.238.229/~api/feed.xml
Sorry. No feed found. Please try searching for another url, title or #topic.

I installed liferea and got the success!

Did feedly fail because its a webapp? Or just because it's feeble?
Dave

On Fri, Aug 29, 2014 at 7:01 AM, Adam Ierymenko <adam.ierymenko@zerotier.com> wrote:
 
I wrote another post on my own views on decentralization... sort of a partial followup to the previous "I want to believe" one. I'm still working on a technical followup, but this is more of a theoretical one.


(Apologies if this is a double post -- the previous one I sent went out from an old e-mail address that was still in my webmail interface for some reason... shows how often I use webmail. It probably disappeared into the ether.)




Eric Mill [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-08-31 21:36:34 (6 years 1 mon 26 days 22:54:00 ago)
I got the feed, served off your laptop! Oh that was great fun.

If my RSS reader (Newsblur) installed ZeroTier on all their servers, would I be able to use it to subscribe to this feed off of your laptop?


On Fri, Aug 29, 2014 at 7:55 PM, David Geib <trustiosity.zrm@gmail.com> wrote:
It seems like you should be able to use any of the usual name resolution methods like DNS instead of using IP addresses. The names would only work for people with the software installed but so do the IP addresses.


On Fri, Aug 29, 2014 at 6:17 PM, Adam Ierymenko <adam.ierymenko@zerotier.com> wrote:
Heh.

I should clarify that: you have to do it from your own computer. That’s the point. I tested with an app called Newsfire, but it can be any local RSS reader, web browser, or URL fetcher.

The point is to make a trivial and goofy but hopefully hard-hitting demo of the fact that IP is in fact the P2P protocol we’re looking for (provided it can run without a ton of walls and moats in the way).

-Adam

On Aug 29, 2014, at 3:14 PM, David Burns <tdbtdb@gmail.com> wrote:

Here's the result when I add the feed to feedly, after previous steps (OS = ubuntu) seem successful:

Explore http://29.44.238.229/~api/feed.xml
Sorry. No feed found. Please try searching for another url, title or #topic.

I installed liferea and got the success!

Did feedly fail because its a webapp? Or just because it's feeble?
Dave

On Fri, Aug 29, 2014 at 7:01 AM, Adam Ierymenko <adam.ierymenko@zerotier.com> wrote:
 
I wrote another post on my own views on decentralization... sort of a partial followup to the previous "I want to believe" one. I'm still working on a technical followup, but this is more of a theoretical one.


(Apologies if this is a double post -- the previous one I sent went out from an old e-mail address that was still in my webmail interface for some reason... shows how often I use webmail. It probably disappeared into the ether.)







--
Adam Ierymenko [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-02 11:07:42 (6 years 1 mon 25 days 09:23:00 ago)
Oh sure, that would work.

What I really wanted to demonstrate is this: how *easy* it would be to massively decentralize a lot of things if all the firewall/NAT cruft were out of the way.

Take Twitter for example. It lets me post tweets and follow other peoples’ tweets. It does a few other things but that’s the core functionality. What about that couldn’t be replaced by a web of bi-directional RSS reader apps? By bi-directional I mean a reader that is also a writer/publisher and that runs a little web server as a tray app or something… something very simple and built entirely on current open standards.

Now take Facebook… is it that different? It has some additional functionality but really how hard would all that be to implement if every device had a real address?

Reachability, bandwidth, scalability, all these are a lot easier to solve if IP could… umm… *actually be used*.

Think about all the stuff we already have that is built upon IP, and how all if it could be used in a less centralized peer to peer manner if IP were allowed to actually work.

We do not need complicated things like libjingle, WebRTC, Maidsafe, etc. All we need is IP. In the short term we can have this world using network virtualization layers and/or meshnets. In the long term we can adopt IPv6, assign every device a real address, and improve device perimeter security enough that firewalls can be junked.

The other great thing about IP vs. those complicated protocols is that it’s all open and simple and straightforward. All those complicated, fragmented p2p monstrosities have their own peculiar APIs and very complex specifications. That means that software built upon them cannot interoperate easily with other software built upon others. IP and open standards like HTTP, JSON, XML, etc. are designed for heterogenous ecosystems of interoperable clients and servers.

The idea with ZeroTier was to be, as I said in my secret RSS feed, “a complicated thing that gets out of the way so we can do simple things.” The idea of ZeroTier is for it to serve as a stepping stone *out* of the fragmented broken-IP world— to offer an anti-lock-in path back to open protocols over a true many-to-many flat Internet address space. It’s a project/product designed to make itself obsolete.

-Adam

On Aug 31, 2014, at 6:36 PM, Eric Mill <eric@konklone.com> wrote:

> I got the feed, served off your laptop! Oh that was great fun.
> 
> If my RSS reader (Newsblur) installed ZeroTier on all their servers, would I be able to use it to subscribe to this feed off of your laptop?
> 

Adam Ierymenko [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-02 12:35:23 (6 years 1 mon 25 days 07:55:00 ago)
I agree here too. There’s certainly other issues at work. But there’s a world of difference between a network where decentralization is easy and one where it’s almost prohibitively hard. The former might contain lots of market niches for centralized products, services, and trust chains, but the latter all but *prohibits* decentralized approaches to anything.

For decentralized networks, non-local firewalls and *especially* NAT present a “DENY ALL” rule that requires thousands of hours of “black art” engineering to overcome.

-Adam

> Network routing is certainly one important aspect of decentralization.  
> But suppose Google now served Search & Gmail via a ZeroTierOne Earth
> Address.  I'd think they would again quickly be able to create a rather
> centralized traffic point within the network topology because of:
> 
> 1. Ownership: company control of the server, its code, resulting usage data, 
>   screen space coming to attention of users, all useful for tracking 
>   and showing ads which brings monetization.
> 
> 2. Easy Deployment: current web technology makes it easy to control 
>   the client-side code from a server (javascript/browsers),
>   allowing to reduce latency and to do code upgrades without 
>   manual intervention on the client side.  Just go to "google @ ZT1 earth"
>   and enjoy.
> 
> 3. Sustainability: the resources (earned via ads, see above) to
>   invest into polishing the software and the experience, allowing it to
>   build new services (GOTO 1)
> 
> IOW I think there is more to decentralization than the network topology
> and the raw IP protocol.  However I do agree with you, Adam, that NATs
> are making it even harder to grow sustained decentralized deployments of
> software and services.  But we also need to consider monetization or
> economical sustainability, easy software distribution and well evolved
> forms of collective deployments of software.  
> 

Adam Ierymenko [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-02 12:52:36 (6 years 1 mon 25 days 07:38:00 ago)
Thought of another point about this…

Decentralization doesn’t necessarily imply that all peers are of equal size, just that all things have equal opportunity to be peers.

That being said, I think the current network deployment pattern pretty much guarantees the domination of the ecosystem by massive players by writing inequality into the network topology itself. Even if a more democratic many-smaller-players solution could win in the ecosystem and even in the market place, it can’t right now because it is too technically challenging to deploy.

> Network routing is certainly one important aspect of decentralization.  
> But suppose Google now served Search & Gmail via a ZeroTierOne Earth
> Address.  I'd think they would again quickly be able to create a rather
> centralized traffic point within the network topology because of:


Dominic Tarr [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-02 14:44:40 (6 years 1 mon 25 days 05:46:00 ago)
I was very happy when I first saw ZeroTierOne, and also thought your
"I want to believe" post was brilliant,
but I think there is another challenge to decentralization that simply
having addressability is not sufficient to address.

Security.

Building truly p2p systems must deal with not only regular distributed
systems problems,
but also the problem of incenting the participants in the network to
behave properly.
This is trivial if I own all the computers that run my system. But the
system runs outside
my own datacenter, on other people's computers then I need some was to
ensure that
they cooperate.

Now, "ownership" is a concept deeply imbued into human society, but
it's worth remembering
that it is essentially a solution to this same problem. It all boils
down to using coersion to ensure
that participants in society behave in a approximately helpful manner.
Animals don't really have
property. Sure, some animals have territory - but they tend to enforce
those "rights" personally.
So what they have is a "possesion" (a non-abstract form of property).
There are no absentee landlords in the non-human animal kingdom.

Humans on the other hand, have an abstracted notion of property, I
maintain control of my bicycle
by chaining it to something when I am not using it, and you maintain
ownership of real estate by
interfacing with systems of contracts and laws that date back
thousands of years. Basically, you just
punish people who transgress the property rights, this requires police
and lawyers and courts and prisons,
and a millitary to protect your property system from neibouring
property systems...

Given the property system, it's easy to build a distributed system,
you just have a datacenter,
and you can hire people to run it, and build it and if theyfdo not do
as you wish you fire them etc.

Now - if you want to build a true p2p system, a decentralized system -
that depends on people
freely choosing to run your program, and also choosing not to abuse
your protocol, or try to
trick or deny service to other nodes in the network. You can't apply
coersion to incent cooperation,
you probably don't know where the other computers are, except very
approximately,
and you can't exactly send a computer to jail

There is the distributed systems problems, but this is the easy part.
What if my blog post becomes insanely popular? will my laptop have to
serve terabytes of data?
what happens while I am disconnected from wifi inbetween cafes?
Obviously the answer is to distribute the data - prehaps you can get
my blog post from
other people who have read it, not just from me. If a few hundred
people from around the world
have seen it, then there is probably a pretty good chance that someone
currently online has it.
But then what if they refuse to serve it, or serve the wrong thing?
(this could be malicious or by accident)

What you do have is crypto, and information processing powers many times greater
than when the property system was created. Would it be possible to
create a system that enforced cooperation using just information?

I think this is possible, not just because there are computer systems
which achive this within specific
contexts, but also, because humans can already do this naturally.
Small scale groups do not use coersion,
they use information - everyone involved pretty much knows what is
going on, and if someone is being
abusive they get blocked out. Certainly, this system is not
invunerable, but it *is* a system.
A reputation system. It's not very scalable, and it's not very
accurate (human gossip is quite lossy)
but we do have something to go on here.

could you use crypto and computers to scale and secure a reputation
system, without giving any particular
node too much implicit trust?


On Tue, Sep 2, 2014 at 12:52 PM, Adam Ierymenko
<adam.ierymenko@zerotier.com> wrote:
> Thought of another point about this…
>
> Decentralization doesn’t necessarily imply that all peers are of equal size, just that all things have equal opportunity to be peers.
>
> That being said, I think the current network deployment pattern pretty much guarantees the domination of the ecosystem by massive players by writing inequality into the network topology itself. Even if a more democratic many-smaller-players solution could win in the ecosystem and even in the market place, it can’t right now because it is too technically challenging to deploy.
>
>> Network routing is certainly one important aspect of decentralization.
>> But suppose Google now served Search & Gmail via a ZeroTierOne Earth
>> Address.  I'd think they would again quickly be able to create a rather
>> centralized traffic point within the network topology because of:
>
>
Dominic Tarr [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-02 16:55:31 (6 years 1 mon 25 days 03:35:00 ago)
thanks Paul,

I'd just like to make clear that secure-scuttlebutt is *not* a crypto currency,
and does not use a proof of work scheme. I get the feeling that cryptocurrencies
are used as some sort of decentralization hammer. Don't get me wrong,
bitcoin is a brilliant design, but the assurances it gives you (total
ordering & consistency)
are just not necessary for many applications.

Secure-scuttlebutt is somewhere inbetween a blockchain (globally
consistent long chain)
and a DHT (maybe consistent, flat lookup structure).
To contrast with the Blind Idiot God concept from adam's
http://adamierymenko.com/decentralization-i-want-to-believe/

It's more like each individual node is their own centralized authority.

Richard, thanks ;)

Dominic

On Tue, Sep 2, 2014 at 4:25 PM, Paul Frazee <pfrazee@gmail.com> wrote:
> Adding some thoughts to Dominic's --
>
> The challenge to decentralizing the application layer is that it involves
> distributing authority.
>
> For instance, we need to authenticate users. The only distributed auth in
> wide use right now is PKI. Since PKI only works well for organizations, the
> user-identities have to live within the orgs. That's a centralizing effect
> that would still occur in an open IP/routing layer.
>
> After you've distributed identities, you need to distribute data-structures
> as well, or we rely on central nodes to keep data-bases. Then, the messages
> that construct the datasets need to be verifiable, so that Alice can rehost
> messages from Bob without possibly altering them. So there are three
> distinct challenges: authentication, message-verification, and dataset
> coordination.
>
> Bitcoin, for example, solves all three of these problems. Broadly...
>
>  - Authentication: RSA keypairs.
> (https://en.bitcoin.it/wiki/Address#Proving_you_receive_with_an_address).
>  - Message-verification: transaction signatures.
>  - Dataset coordination: the global blockchain and total ordering via PoW.
>
> After all that, you need to deal with abusive actors in the network (DoSers,
> attackers) and with schemes to share resources (bandwidth, sometimes
> disk-space). This is where the reputation system gets involved.
>
> For some interesting reading, I'll refer you to Dominic's project,
> https://github.com/dominictarr/secure-scuttlebutt.
>
>
>
>
> On Tue, Sep 2, 2014 at 4:44 PM, Dominic Tarr <dominic.tarr@gmail.com> wrote:
>>
>> I was very happy when I first saw ZeroTierOne, and also thought your
>> "I want to believe" post was brilliant,
>> but I think there is another challenge to decentralization that simply
>> having addressability is not sufficient to address.
>>
>> Security.
>>
>> Building truly p2p systems must deal with not only regular distributed
>> systems problems,
>> but also the problem of incenting the participants in the network to
>> behave properly.
>> This is trivial if I own all the computers that run my system. But the
>> system runs outside
>> my own datacenter, on other people's computers then I need some was to
>> ensure that
>> they cooperate.
>>
>> Now, "ownership" is a concept deeply imbued into human society, but
>> it's worth remembering
>> that it is essentially a solution to this same problem. It all boils
>> down to using coersion to ensure
>> that participants in society behave in a approximately helpful manner.
>> Animals don't really have
>> property. Sure, some animals have territory - but they tend to enforce
>> those "rights" personally.
>> So what they have is a "possesion" (a non-abstract form of property).
>> There are no absentee landlords in the non-human animal kingdom.
>>
>> Humans on the other hand, have an abstracted notion of property, I
>> maintain control of my bicycle
>> by chaining it to something when I am not using it, and you maintain
>> ownership of real estate by
>> interfacing with systems of contracts and laws that date back
>> thousands of years. Basically, you just
>> punish people who transgress the property rights, this requires police
>> and lawyers and courts and prisons,
>> and a millitary to protect your property system from neibouring
>> property systems...
>>
>> Given the property system, it's easy to build a distributed system,
>> you just have a datacenter,
>> and you can hire people to run it, and build it and if theyfdo not do
>> as you wish you fire them etc.
>>
>> Now - if you want to build a true p2p system, a decentralized system -
>> that depends on people
>> freely choosing to run your program, and also choosing not to abuse
>> your protocol, or try to
>> trick or deny service to other nodes in the network. You can't apply
>> coersion to incent cooperation,
>> you probably don't know where the other computers are, except very
>> approximately,
>> and you can't exactly send a computer to jail
>>
>> There is the distributed systems problems, but this is the easy part.
>> What if my blog post becomes insanely popular? will my laptop have to
>> serve terabytes of data?
>> what happens while I am disconnected from wifi inbetween cafes?
>> Obviously the answer is to distribute the data - prehaps you can get
>> my blog post from
>> other people who have read it, not just from me. If a few hundred
>> people from around the world
>> have seen it, then there is probably a pretty good chance that someone
>> currently online has it.
>> But then what if they refuse to serve it, or serve the wrong thing?
>> (this could be malicious or by accident)
>>
>> What you do have is crypto, and information processing powers many times
>> greater
>> than when the property system was created. Would it be possible to
>> create a system that enforced cooperation using just information?
>>
>> I think this is possible, not just because there are computer systems
>> which achive this within specific
>> contexts, but also, because humans can already do this naturally.
>> Small scale groups do not use coersion,
>> they use information - everyone involved pretty much knows what is
>> going on, and if someone is being
>> abusive they get blocked out. Certainly, this system is not
>> invunerable, but it *is* a system.
>> A reputation system. It's not very scalable, and it's not very
>> accurate (human gossip is quite lossy)
>> but we do have something to go on here.
>>
>> could you use crypto and computers to scale and secure a reputation
>> system, without giving any particular
>> node too much implicit trust?
>>
>>
>> On Tue, Sep 2, 2014 at 12:52 PM, Adam Ierymenko
>> <adam.ierymenko@zerotier.com> wrote:
>> > Thought of another point about this…
>> >
>> > Decentralization doesn’t necessarily imply that all peers are of equal
>> > size, just that all things have equal opportunity to be peers.
>> >
>> > That being said, I think the current network deployment pattern pretty
>> > much guarantees the domination of the ecosystem by massive players by
>> > writing inequality into the network topology itself. Even if a more
>> > democratic many-smaller-players solution could win in the ecosystem and even
>> > in the market place, it can’t right now because it is too technically
>> > challenging to deploy.
>> >
>> >> Network routing is certainly one important aspect of decentralization.
>> >> But suppose Google now served Search & Gmail via a ZeroTierOne Earth
>> >> Address.  I'd think they would again quickly be able to create a rather
>> >> centralized traffic point within the network topology because of:
>> >
>> >
>
>
Paul Frazee [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-02 18:25:57 (6 years 1 mon 25 days 02:04:00 ago)
Adding some thoughts to Dominic's --

The challenge to decentralizing the application layer is that it involves distributing authority.

For instance, we need to authenticate users. The only distributed auth in wide use right now is PKI. Since PKI only works well for organizations, the user-identities have to live within the orgs. That's a centralizing effect that would still occur in an open IP/routing layer.

After you've distributed identities, you need to distribute data-structures as well, or we rely on central nodes to keep data-bases. Then, the messages that construct the datasets need to be verifiable, so that Alice can rehost messages from Bob without possibly altering them. So there are three distinct challenges: authentication, message-verification, and dataset coordination.

Bitcoin, for example, solves all three of these problems. Broadly...

 - Authentication: RSA keypairs. (https://en.bitcoin.it/wiki/Address#Proving_you_receive_with_an_address).
 - Message-verification: transaction signatures.
 - Dataset coordination: the global blockchain and total ordering via PoW.

After all that, you need to deal with abusive actors in the network (DoSers, attackers) and with schemes to share resources (bandwidth, sometimes disk-space). This is where the reputation system gets involved.

For some interesting reading, I'll refer you to Dominic's project, https://github.com/dominictarr/secure-scuttlebutt.



On Tue, Sep 2, 2014 at 4:44 PM, Dominic Tarr <dominic.tarr@gmail.com> wrote:
I was very happy when I first saw ZeroTierOne, and also thought your
"I want to believe" post was brilliant,
but I think there is another challenge to decentralization that simply
having addressability is not sufficient to address.

Security.

Building truly p2p systems must deal with not only regular distributed
systems problems,
but also the problem of incenting the participants in the network to
behave properly.
This is trivial if I own all the computers that run my system. But the
system runs outside
my own datacenter, on other people's computers then I need some was to
ensure that
they cooperate.

Now, "ownership" is a concept deeply imbued into human society, but
it's worth remembering
that it is essentially a solution to this same problem. It all boils
down to using coersion to ensure
that participants in society behave in a approximately helpful manner.
Animals don't really have
property. Sure, some animals have territory - but they tend to enforce
those "rights" personally.
So what they have is a "possesion" (a non-abstract form of property).
There are no absentee landlords in the non-human animal kingdom.

Humans on the other hand, have an abstracted notion of property, I
maintain control of my bicycle
by chaining it to something when I am not using it, and you maintain
ownership of real estate by
interfacing with systems of contracts and laws that date back
thousands of years. Basically, you just
punish people who transgress the property rights, this requires police
and lawyers and courts and prisons,
and a millitary to protect your property system from neibouring
property systems...

Given the property system, it's easy to build a distributed system,
you just have a datacenter,
and you can hire people to run it, and build it and if theyfdo not do
as you wish you fire them etc.

Now - if you want to build a true p2p system, a decentralized system -
that depends on people
freely choosing to run your program, and also choosing not to abuse
your protocol, or try to
trick or deny service to other nodes in the network. You can't apply
coersion to incent cooperation,
you probably don't know where the other computers are, except very
approximately,
and you can't exactly send a computer to jail

There is the distributed systems problems, but this is the easy part.
What if my blog post becomes insanely popular? will my laptop have to
serve terabytes of data?
what happens while I am disconnected from wifi inbetween cafes?
Obviously the answer is to distribute the data - prehaps you can get
my blog post from
other people who have read it, not just from me. If a few hundred
people from around the world
have seen it, then there is probably a pretty good chance that someone
currently online has it.
But then what if they refuse to serve it, or serve the wrong thing?
(this could be malicious or by accident)

What you do have is crypto, and information processing powers many times greater
than when the property system was created. Would it be possible to
create a system that enforced cooperation using just information?

I think this is possible, not just because there are computer systems
which achive this within specific
contexts, but also, because humans can already do this naturally.
Small scale groups do not use coersion,
they use information - everyone involved pretty much knows what is
going on, and if someone is being
abusive they get blocked out. Certainly, this system is not
invunerable, but it *is* a system.
A reputation system. It's not very scalable, and it's not very
accurate (human gossip is quite lossy)
but we do have something to go on here.

could you use crypto and computers to scale and secure a reputation
system, without giving any particular
node too much implicit trust?


On Tue, Sep 2, 2014 at 12:52 PM, Adam Ierymenko
<adam.ierymenko@zerotier.com> wrote:
> Thought of another point about this…
>
> Decentralization doesn’t necessarily imply that all peers are of equal size, just that all things have equal opportunity to be peers.
>
> That being said, I think the current network deployment pattern pretty much guarantees the domination of the ecosystem by massive players by writing inequality into the network topology itself. Even if a more democratic many-smaller-players solution could win in the ecosystem and even in the market place, it can’t right now because it is too technically challenging to deploy.
>
>> Network routing is certainly one important aspect of decentralization.
>> But suppose Google now served Search & Gmail via a ZeroTierOne Earth
>> Address.  I'd think they would again quickly be able to create a rather
>> centralized traffic point within the network topology because of:
>
>

holger krekel [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-02 19:16:07 (6 years 1 mon 25 days 01:14:00 ago)
On Tue, Sep 02, 2014 at 11:07 -0700, Adam Ierymenko wrote:
> Oh sure, that would work.
> 
> What I really wanted to demonstrate is this: how *easy* it would be to massively decentralize a lot of things if all the firewall/NAT cruft were out of the way.

Network routing is certainly one important aspect of decentralization.  
But suppose Google now served Search & Gmail via a ZeroTierOne Earth
Address.  I'd think they would again quickly be able to create a rather
centralized traffic point within the network topology because of:

1. Ownership: company control of the server, its code, resulting usage data, 
   screen space coming to attention of users, all useful for tracking 
   and showing ads which brings monetization.

2. Easy Deployment: current web technology makes it easy to control 
   the client-side code from a server (javascript/browsers),
   allowing to reduce latency and to do code upgrades without 
   manual intervention on the client side.  Just go to "google @ ZT1 earth"
   and enjoy.

3. Sustainability: the resources (earned via ads, see above) to
   invest into polishing the software and the experience, allowing it to
   build new services (GOTO 1)
 
IOW I think there is more to decentralization than the network topology
and the raw IP protocol.  However I do agree with you, Adam, that NATs
are making it even harder to grow sustained decentralized deployments of
software and services.  But we also need to consider monetization or
economical sustainability, easy software distribution and well evolved
forms of collective deployments of software.  

best,
holger


> 
> Take Twitter for example. It lets me post tweets and follow other peoples’ tweets. It does a few other things but that’s the core functionality. What about that couldn’t be replaced by a web of bi-directional RSS reader apps? By bi-directional I mean a reader that is also a writer/publisher and that runs a little web server as a tray app or something… something very simple and built entirely on current open standards.
> 
> Now take Facebook… is it that different? It has some additional functionality but really how hard would all that be to implement if every device had a real address?
> 
> Reachability, bandwidth, scalability, all these are a lot easier to solve if IP could… umm… *actually be used*.
> 
> Think about all the stuff we already have that is built upon IP, and how all if it could be used in a less centralized peer to peer manner if IP were allowed to actually work.
> 
> We do not need complicated things like libjingle, WebRTC, Maidsafe, etc. All we need is IP. In the short term we can have this world using network virtualization layers and/or meshnets. In the long term we can adopt IPv6, assign every device a real address, and improve device perimeter security enough that firewalls can be junked.
> 
> The other great thing about IP vs. those complicated protocols is that it’s all open and simple and straightforward. All those complicated, fragmented p2p monstrosities have their own peculiar APIs and very complex specifications. That means that software built upon them cannot interoperate easily with other software built upon others. IP and open standards like HTTP, JSON, XML, etc. are designed for heterogenous ecosystems of interoperable clients and servers.
> 
> The idea with ZeroTier was to be, as I said in my secret RSS feed, “a complicated thing that gets out of the way so we can do simple things.” The idea of ZeroTier is for it to serve as a stepping stone *out* of the fragmented broken-IP world— to offer an anti-lock-in path back to open protocols over a true many-to-many flat Internet address space. It’s a project/product designed to make itself obsolete.
> 
> -Adam
> 
> On Aug 31, 2014, at 6:36 PM, Eric Mill <eric@konklone.com> wrote:
> 
> > I got the feed, served off your laptop! Oh that was great fun.
> > 
> > If my RSS reader (Newsblur) installed ZeroTier on all their servers, would I be able to use it to subscribe to this feed off of your laptop?
> > 
> 
David Geib [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-02 23:05:21 (6 years 1 mon 24 days 21:25:00 ago)
> Perhaps the simplest way to look at [secure-scuttlebutt] is as many simultanious master-slave replications

If the primary node is offline or busy you can get an authenticated copy of the data from one of the secondary nodes. So then how do you find out which nodes are secondaries for a specific primary?


On Tue, Sep 2, 2014 at 7:55 PM, Dominic Tarr <dominic.tarr@gmail.com> wrote:
thanks Paul,

I'd just like to make clear that secure-scuttlebutt is *not* a crypto currency,
and does not use a proof of work scheme. I get the feeling that cryptocurrencies
are used as some sort of decentralization hammer. Don't get me wrong,
bitcoin is a brilliant design, but the assurances it gives you (total
ordering & consistency)
are just not necessary for many applications.

Secure-scuttlebutt is somewhere inbetween a blockchain (globally
consistent long chain)
and a DHT (maybe consistent, flat lookup structure).
To contrast with the Blind Idiot God concept from adam's
http://adamierymenko.com/decentralization-i-want-to-believe/

It's more like each individual node is their own centralized authority.

Richard, thanks ;)

Dominic

On Tue, Sep 2, 2014 at 4:25 PM, Paul Frazee <pfrazee@gmail.com> wrote:
> Adding some thoughts to Dominic's --
>
> The challenge to decentralizing the application layer is that it involves
> distributing authority.
>
> For instance, we need to authenticate users. The only distributed auth in
> wide use right now is PKI. Since PKI only works well for organizations, the
> user-identities have to live within the orgs. That's a centralizing effect
> that would still occur in an open IP/routing layer.
>
> After you've distributed identities, you need to distribute data-structures
> as well, or we rely on central nodes to keep data-bases. Then, the messages
> that construct the datasets need to be verifiable, so that Alice can rehost
> messages from Bob without possibly altering them. So there are three
> distinct challenges: authentication, message-verification, and dataset
> coordination.
>
> Bitcoin, for example, solves all three of these problems. Broadly...
>
>  - Authentication: RSA keypairs.
> (https://en.bitcoin.it/wiki/Address#Proving_you_receive_with_an_address).
>  - Message-verification: transaction signatures.
>  - Dataset coordination: the global blockchain and total ordering via PoW.
>
> After all that, you need to deal with abusive actors in the network (DoSers,
> attackers) and with schemes to share resources (bandwidth, sometimes
> disk-space). This is where the reputation system gets involved.
>
> For some interesting reading, I'll refer you to Dominic's project,
> https://github.com/dominictarr/secure-scuttlebutt.
>
>
>
>
> On Tue, Sep 2, 2014 at 4:44 PM, Dominic Tarr <dominic.tarr@gmail.com> wrote:
>>
>> I was very happy when I first saw ZeroTierOne, and also thought your
>> "I want to believe" post was brilliant,
>> but I think there is another challenge to decentralization that simply
>> having addressability is not sufficient to address.
>>
>> Security.
>>
>> Building truly p2p systems must deal with not only regular distributed
>> systems problems,
>> but also the problem of incenting the participants in the network to
>> behave properly.
>> This is trivial if I own all the computers that run my system. But the
>> system runs outside
>> my own datacenter, on other people's computers then I need some was to
>> ensure that
>> they cooperate.
>>
>> Now, "ownership" is a concept deeply imbued into human society, but
>> it's worth remembering
>> that it is essentially a solution to this same problem. It all boils
>> down to using coersion to ensure
>> that participants in society behave in a approximately helpful manner.
>> Animals don't really have
>> property. Sure, some animals have territory - but they tend to enforce
>> those "rights" personally.
>> So what they have is a "possesion" (a non-abstract form of property).
>> There are no absentee landlords in the non-human animal kingdom.
>>
>> Humans on the other hand, have an abstracted notion of property, I
>> maintain control of my bicycle
>> by chaining it to something when I am not using it, and you maintain
>> ownership of real estate by
>> interfacing with systems of contracts and laws that date back
>> thousands of years. Basically, you just
>> punish people who transgress the property rights, this requires police
>> and lawyers and courts and prisons,
>> and a millitary to protect your property system from neibouring
>> property systems...
>>
>> Given the property system, it's easy to build a distributed system,
>> you just have a datacenter,
>> and you can hire people to run it, and build it and if theyfdo not do
>> as you wish you fire them etc.
>>
>> Now - if you want to build a true p2p system, a decentralized system -
>> that depends on people
>> freely choosing to run your program, and also choosing not to abuse
>> your protocol, or try to
>> trick or deny service to other nodes in the network. You can't apply
>> coersion to incent cooperation,
>> you probably don't know where the other computers are, except very
>> approximately,
>> and you can't exactly send a computer to jail
>>
>> There is the distributed systems problems, but this is the easy part.
>> What if my blog post becomes insanely popular? will my laptop have to
>> serve terabytes of data?
>> what happens while I am disconnected from wifi inbetween cafes?
>> Obviously the answer is to distribute the data - prehaps you can get
>> my blog post from
>> other people who have read it, not just from me. If a few hundred
>> people from around the world
>> have seen it, then there is probably a pretty good chance that someone
>> currently online has it.
>> But then what if they refuse to serve it, or serve the wrong thing?
>> (this could be malicious or by accident)
>>
>> What you do have is crypto, and information processing powers many times
>> greater
>> than when the property system was created. Would it be possible to
>> create a system that enforced cooperation using just information?
>>
>> I think this is possible, not just because there are computer systems
>> which achive this within specific
>> contexts, but also, because humans can already do this naturally.
>> Small scale groups do not use coersion,
>> they use information - everyone involved pretty much knows what is
>> going on, and if someone is being
>> abusive they get blocked out. Certainly, this system is not
>> invunerable, but it *is* a system.
>> A reputation system. It's not very scalable, and it's not very
>> accurate (human gossip is quite lossy)
>> but we do have something to go on here.
>>
>> could you use crypto and computers to scale and secure a reputation
>> system, without giving any particular
>> node too much implicit trust?
>>
>>
>> On Tue, Sep 2, 2014 at 12:52 PM, Adam Ierymenko
>> <adam.ierymenko@zerotier.com> wrote:
>> > Thought of another point about this…
>> >
>> > Decentralization doesn’t necessarily imply that all peers are of equal
>> > size, just that all things have equal opportunity to be peers.
>> >
>> > That being said, I think the current network deployment pattern pretty
>> > much guarantees the domination of the ecosystem by massive players by
>> > writing inequality into the network topology itself. Even if a more
>> > democratic many-smaller-players solution could win in the ecosystem and even
>> > in the market place, it can’t right now because it is too technically
>> > challenging to deploy.
>> >
>> >> Network routing is certainly one important aspect of decentralization.
>> >> But suppose Google now served Search & Gmail via a ZeroTierOne Earth
>> >> Address.  I'd think they would again quickly be able to create a rather
>> >> centralized traffic point within the network topology because of:
>> >
>> >
>
>

Dominic Tarr [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-03 11:04:25 (6 years 1 mon 24 days 09:26:00 ago)
david, the answer is that data must be encoded in the feed.

Say, for a twitter-like app, when you follow someone, you'd post a
message saying "i followed $DavidGeib" (where "$DavidGeib" is the hash
of your public key) and probably also include in this message a hint
about where you can find the node with that key (an ip:port)

So if you want to replicate with me, but I am offline, you'd look at
the data that you already have,
and see if you have any one that follows me, if so then those are the
secondaries.

On Tue, Sep 2, 2014 at 8:05 PM, David Geib <trustiosity.zrm@gmail.com> wrote:
>> Perhaps the simplest way to look at [secure-scuttlebutt] is as many
>> simultanious master-slave replications
>
> If the primary node is offline or busy you can get an authenticated copy of
> the data from one of the secondary nodes. So then how do you find out which
> nodes are secondaries for a specific primary?
>
>
> On Tue, Sep 2, 2014 at 7:55 PM, Dominic Tarr <dominic.tarr@gmail.com> wrote:
>>
>> thanks Paul,
>>
>> I'd just like to make clear that secure-scuttlebutt is *not* a crypto
>> currency,
>> and does not use a proof of work scheme. I get the feeling that
>> cryptocurrencies
>> are used as some sort of decentralization hammer. Don't get me wrong,
>> bitcoin is a brilliant design, but the assurances it gives you (total
>> ordering & consistency)
>> are just not necessary for many applications.
>>
>> Secure-scuttlebutt is somewhere inbetween a blockchain (globally
>> consistent long chain)
>> and a DHT (maybe consistent, flat lookup structure).
>> To contrast with the Blind Idiot God concept from adam's
>> http://adamierymenko.com/decentralization-i-want-to-believe/
>>
>> It's more like each individual node is their own centralized authority.
>>
>> Richard, thanks ;)
>>
>> Dominic
>>
>> On Tue, Sep 2, 2014 at 4:25 PM, Paul Frazee <pfrazee@gmail.com> wrote:
>> > Adding some thoughts to Dominic's --
>> >
>> > The challenge to decentralizing the application layer is that it
>> > involves
>> > distributing authority.
>> >
>> > For instance, we need to authenticate users. The only distributed auth
>> > in
>> > wide use right now is PKI. Since PKI only works well for organizations,
>> > the
>> > user-identities have to live within the orgs. That's a centralizing
>> > effect
>> > that would still occur in an open IP/routing layer.
>> >
>> > After you've distributed identities, you need to distribute
>> > data-structures
>> > as well, or we rely on central nodes to keep data-bases. Then, the
>> > messages
>> > that construct the datasets need to be verifiable, so that Alice can
>> > rehost
>> > messages from Bob without possibly altering them. So there are three
>> > distinct challenges: authentication, message-verification, and dataset
>> > coordination.
>> >
>> > Bitcoin, for example, solves all three of these problems. Broadly...
>> >
>> >  - Authentication: RSA keypairs.
>> >
>> > (https://en.bitcoin.it/wiki/Address#Proving_you_receive_with_an_address).
>> >  - Message-verification: transaction signatures.
>> >  - Dataset coordination: the global blockchain and total ordering via
>> > PoW.
>> >
>> > After all that, you need to deal with abusive actors in the network
>> > (DoSers,
>> > attackers) and with schemes to share resources (bandwidth, sometimes
>> > disk-space). This is where the reputation system gets involved.
>> >
>> > For some interesting reading, I'll refer you to Dominic's project,
>> > https://github.com/dominictarr/secure-scuttlebutt.
>> >
>> >
>> >
>> >
>> > On Tue, Sep 2, 2014 at 4:44 PM, Dominic Tarr <dominic.tarr@gmail.com>
>> > wrote:
>> >>
>> >> I was very happy when I first saw ZeroTierOne, and also thought your
>> >> "I want to believe" post was brilliant,
>> >> but I think there is another challenge to decentralization that simply
>> >> having addressability is not sufficient to address.
>> >>
>> >> Security.
>> >>
>> >> Building truly p2p systems must deal with not only regular distributed
>> >> systems problems,
>> >> but also the problem of incenting the participants in the network to
>> >> behave properly.
>> >> This is trivial if I own all the computers that run my system. But the
>> >> system runs outside
>> >> my own datacenter, on other people's computers then I need some was to
>> >> ensure that
>> >> they cooperate.
>> >>
>> >> Now, "ownership" is a concept deeply imbued into human society, but
>> >> it's worth remembering
>> >> that it is essentially a solution to this same problem. It all boils
>> >> down to using coersion to ensure
>> >> that participants in society behave in a approximately helpful manner.
>> >> Animals don't really have
>> >> property. Sure, some animals have territory - but they tend to enforce
>> >> those "rights" personally.
>> >> So what they have is a "possesion" (a non-abstract form of property).
>> >> There are no absentee landlords in the non-human animal kingdom.
>> >>
>> >> Humans on the other hand, have an abstracted notion of property, I
>> >> maintain control of my bicycle
>> >> by chaining it to something when I am not using it, and you maintain
>> >> ownership of real estate by
>> >> interfacing with systems of contracts and laws that date back
>> >> thousands of years. Basically, you just
>> >> punish people who transgress the property rights, this requires police
>> >> and lawyers and courts and prisons,
>> >> and a millitary to protect your property system from neibouring
>> >> property systems...
>> >>
>> >> Given the property system, it's easy to build a distributed system,
>> >> you just have a datacenter,
>> >> and you can hire people to run it, and build it and if theyfdo not do
>> >> as you wish you fire them etc.
>> >>
>> >> Now - if you want to build a true p2p system, a decentralized system -
>> >> that depends on people
>> >> freely choosing to run your program, and also choosing not to abuse
>> >> your protocol, or try to
>> >> trick or deny service to other nodes in the network. You can't apply
>> >> coersion to incent cooperation,
>> >> you probably don't know where the other computers are, except very
>> >> approximately,
>> >> and you can't exactly send a computer to jail
>> >>
>> >> There is the distributed systems problems, but this is the easy part.
>> >> What if my blog post becomes insanely popular? will my laptop have to
>> >> serve terabytes of data?
>> >> what happens while I am disconnected from wifi inbetween cafes?
>> >> Obviously the answer is to distribute the data - prehaps you can get
>> >> my blog post from
>> >> other people who have read it, not just from me. If a few hundred
>> >> people from around the world
>> >> have seen it, then there is probably a pretty good chance that someone
>> >> currently online has it.
>> >> But then what if they refuse to serve it, or serve the wrong thing?
>> >> (this could be malicious or by accident)
>> >>
>> >> What you do have is crypto, and information processing powers many
>> >> times
>> >> greater
>> >> than when the property system was created. Would it be possible to
>> >> create a system that enforced cooperation using just information?
>> >>
>> >> I think this is possible, not just because there are computer systems
>> >> which achive this within specific
>> >> contexts, but also, because humans can already do this naturally.
>> >> Small scale groups do not use coersion,
>> >> they use information - everyone involved pretty much knows what is
>> >> going on, and if someone is being
>> >> abusive they get blocked out. Certainly, this system is not
>> >> invunerable, but it *is* a system.
>> >> A reputation system. It's not very scalable, and it's not very
>> >> accurate (human gossip is quite lossy)
>> >> but we do have something to go on here.
>> >>
>> >> could you use crypto and computers to scale and secure a reputation
>> >> system, without giving any particular
>> >> node too much implicit trust?
>> >>
>> >>
>> >> On Tue, Sep 2, 2014 at 12:52 PM, Adam Ierymenko
>> >> <adam.ierymenko@zerotier.com> wrote:
>> >> > Thought of another point about this…
>> >> >
>> >> > Decentralization doesn’t necessarily imply that all peers are of
>> >> > equal
>> >> > size, just that all things have equal opportunity to be peers.
>> >> >
>> >> > That being said, I think the current network deployment pattern
>> >> > pretty
>> >> > much guarantees the domination of the ecosystem by massive players by
>> >> > writing inequality into the network topology itself. Even if a more
>> >> > democratic many-smaller-players solution could win in the ecosystem
>> >> > and even
>> >> > in the market place, it can’t right now because it is too technically
>> >> > challenging to deploy.
>> >> >
>> >> >> Network routing is certainly one important aspect of
>> >> >> decentralization.
>> >> >> But suppose Google now served Search & Gmail via a ZeroTierOne Earth
>> >> >> Address.  I'd think they would again quickly be able to create a
>> >> >> rather
>> >> >> centralized traffic point within the network topology because of:
>> >> >
>> >> >
>> >
>> >
>
>
Richard D. Bartlett [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-03 11:08:18 (6 years 1 mon 24 days 09:22:00 ago)
Dom that is the smartest thing I've read in a long time. Thanks for sharing xx


On 3 September 2014 09:44, Dominic Tarr <dominic.tarr@gmail.com> wrote:
I was very happy when I first saw ZeroTierOne, and also thought your
"I want to believe" post was brilliant,
but I think there is another challenge to decentralization that simply
having addressability is not sufficient to address.

Security.

Building truly p2p systems must deal with not only regular distributed
systems problems,
but also the problem of incenting the participants in the network to
behave properly.
This is trivial if I own all the computers that run my system. But the
system runs outside
my own datacenter, on other people's computers then I need some was to
ensure that
they cooperate.

Now, "ownership" is a concept deeply imbued into human society, but
it's worth remembering
that it is essentially a solution to this same problem. It all boils
down to using coersion to ensure
that participants in society behave in a approximately helpful manner.
Animals don't really have
property. Sure, some animals have territory - but they tend to enforce
those "rights" personally.
So what they have is a "possesion" (a non-abstract form of property).
There are no absentee landlords in the non-human animal kingdom.

Humans on the other hand, have an abstracted notion of property, I
maintain control of my bicycle
by chaining it to something when I am not using it, and you maintain
ownership of real estate by
interfacing with systems of contracts and laws that date back
thousands of years. Basically, you just
punish people who transgress the property rights, this requires police
and lawyers and courts and prisons,
and a millitary to protect your property system from neibouring
property systems...

Given the property system, it's easy to build a distributed system,
you just have a datacenter,
and you can hire people to run it, and build it and if theyfdo not do
as you wish you fire them etc.

Now - if you want to build a true p2p system, a decentralized system -
that depends on people
freely choosing to run your program, and also choosing not to abuse
your protocol, or try to
trick or deny service to other nodes in the network. You can't apply
coersion to incent cooperation,
you probably don't know where the other computers are, except very
approximately,
and you can't exactly send a computer to jail

There is the distributed systems problems, but this is the easy part.
What if my blog post becomes insanely popular? will my laptop have to
serve terabytes of data?
what happens while I am disconnected from wifi inbetween cafes?
Obviously the answer is to distribute the data - prehaps you can get
my blog post from
other people who have read it, not just from me. If a few hundred
people from around the world
have seen it, then there is probably a pretty good chance that someone
currently online has it.
But then what if they refuse to serve it, or serve the wrong thing?
(this could be malicious or by accident)

What you do have is crypto, and information processing powers many times greater
than when the property system was created. Would it be possible to
create a system that enforced cooperation using just information?

I think this is possible, not just because there are computer systems
which achive this within specific
contexts, but also, because humans can already do this naturally.
Small scale groups do not use coersion,
they use information - everyone involved pretty much knows what is
going on, and if someone is being
abusive they get blocked out. Certainly, this system is not
invunerable, but it *is* a system.
A reputation system. It's not very scalable, and it's not very
accurate (human gossip is quite lossy)
but we do have something to go on here.

could you use crypto and computers to scale and secure a reputation
system, without giving any particular
node too much implicit trust?


On Tue, Sep 2, 2014 at 12:52 PM, Adam Ierymenko
<adam.ierymenko@zerotier.com> wrote:
> Thought of another point about this…
>
> Decentralization doesn’t necessarily imply that all peers are of equal size, just that all things have equal opportunity to be peers.
>
> That being said, I think the current network deployment pattern pretty much guarantees the domination of the ecosystem by massive players by writing inequality into the network topology itself. Even if a more democratic many-smaller-players solution could win in the ecosystem and even in the market place, it can’t right now because it is too technically challenging to deploy.
>
>> Network routing is certainly one important aspect of decentralization.
>> But suppose Google now served Search & Gmail via a ZeroTierOne Earth
>> Address.  I'd think they would again quickly be able to create a rather
>> centralized traffic point within the network topology because of:
>
>



--

Richard D. Bartlett
Loomio co-founder


Paul Frazee [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-04 12:45:35 (6 years 1 mon 23 days 07:45:00 ago)
Bitcoin – it's a bit tiring. Sure it does solve these things in some
way.  It has to.

It's just a well-known example.


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.


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.


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.

What you can do with SSB is publish and delete edges between the logs. This is basically like signing a certfile in PGP -- you're establishing a relationship between the nodes. One kind of edge would be verification. Another might be a warning flag. That's how you build the reputation system.



On Thu, Sep 4, 2014 at 8:45 AM, Jörg F. Wittenberger <Joerg.Wittenberger@softeyes.net> wrote:
Am 03.09.2014 01:25, schrieb Paul Frazee:
> For some interesting reading, I'll refer you to Dominic's project,
> https://github.com/dominictarr/secure-scuttlebutt.
>
>

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

To illustrate: I'm currently working on some simple payment system. (I
picked "payment system" because that's something everyone understands
without explanation of the app's purpose; however it's only an
application which requires the features to be demonstrated.)

It works like this:

* Every "wallet" is a (sqlite) database holding a balance table of two
columns: amount and currency. (Together with some user interface.)
* Users can create orders (documents) to transfer some amount to some
other wallet. The receiver can either accept or reject.

(There is more, like maintaining nick names for wallets.  But those are
irrelevant at this point.)

The important point: the wallet must make sure that it no order exceeds
the senders balance and no receiver can accept the same order twice.
(The total the currency must not change.)

Having a eventually consistent database is not enough here: we can't
trust the peer to store a correct value.

Our solution is rather simple.  Each wallet is replicated (tolerating
byzantine faults) at several notaries.

For a small world (like 5-20 peers) this could be *all* peers, to
simplify the situation for the time being.  Now members of the group can
readily use it.  Any attempt to cheat does not work.

However: This can not transfer money beyond the boundaries of the
group.  (An incoming order would be signed by many notaries.  To no
effect: the group would only trust those notaries in the receivers set
and reject the order if the intersection of senders and receivers
notaries is too small.)

For a larger world byzantine replication does not work, because it comes
at quadratic communication cost.  Instead we would create "virtual
banks": groups of individuals each running a peer and *contracted* (as
in "having signed a legal contract") to keep it mostly online and
prevent fraud.  Such a group could be used as an intermediary between
wallets running at too disjoint groups.


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


Best

/Jörg

Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-04 13:20:45 (6 years 1 mon 23 days 07:10:00 ago)
Holger,

Am 02.09.2014 21:16, schrieb holger krekel:
> On Tue, Sep 02, 2014 at 11:07 -0700, Adam Ierymenko wrote:
>> Oh sure, that would work.
>>
>> What I really wanted to demonstrate is this: how *easy* it would be to massively decentralize a lot of things if all the firewall/NAT cruft were out of the way.
> Network routing is certainly one important aspect of decentralization.
> But suppose Google now served Search & Gmail via a ZeroTierOne Earth
> Address.  I'd think they would again quickly be able to create a rather
> centralized traffic point within the network topology because of:
>
> 1. Ownership: company control of the server, its code, resulting usage data,
>     screen space coming to attention of users, all useful for tracking
>     and showing ads which brings monetization.

So: we need to replace servers by some service running at the users end 
of the wire.

(Like some script running in browser's cache, secretly downloading 
missing components on demand from something akin to git.)

Two effects: a) no more tracking (+) b) no money from tracking (-).

> 2. Easy Deployment: current web technology makes it easy to control
>     the client-side code from a server (javascript/browsers),
>     allowing to reduce latency and to do code upgrades without
>     manual intervention on the client side.  Just go to "google @ ZT1 earth"
>     and enjoy.

Latency would be even better.  Once download.  Following requests are 
handled locally.

> 3. Sustainability: the resources (earned via ads, see above) to
>     invest into polishing the software and the experience, allowing it to
>     build new services (GOTO 1)

Bingo!  This kind of project can easily eat a lifetime.  It can burn 
thousands of <currency>, feed dozens of developers for a couple of 
years… and still eventually starve for being not profitable.

> IOW I think there is more to decentralization than the network topology
> and the raw IP protocol.  However I do agree with you, Adam, that NATs
> are making it even harder to grow sustained decentralized deployments of
> software and services.  But we also need to consider monetization or
> economical sustainability

Can't agree more.

> well evolved forms of collective deployments of software.

That's an oxymoron.

Developers will never allow collective deployments of software to 
evolve. They rather reinvent the wheel for "not invented here", "not the 
favorite language" or outright ignorance delivering old wine in new 
skins (Eth.

/Jörg
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-04 14:49:06 (6 years 1 mon 23 days 05:41:00 ago)
Dominic,

first of all: this is a great post.  I'm going to reply only to specific 
portions.

Am 02.09.2014 23:44, schrieb Dominic Tarr:
> I was very happy when I first saw ZeroTierOne, and also thought your
> "I want to believe" post was brilliant,
> but I think there is another challenge to decentralization that simply
> having addressability is not sufficient to address.
>
> Security.
>
> Building truly p2p systems must deal with not only regular distributed
> systems problems,
> but also the problem of incenting the participants in the network to
> behave properly.
> This is trivial if I own all the computers that run my system. But the
> system runs outside
> my own datacenter, on other people's computers then I need some was to
> ensure that
> they cooperate.
> Now, "ownership" is a concept deeply imbued into human society, but
> it's worth remembering
> that it is essentially a solution to this same problem. It all boils
> down to using coersion to ensure
> that participants in society behave in a approximately helpful manner.

The lesson to take away so far: at the end of the day there MUST be some 
way for one *user* to ensure other *users*  behave in helpful manner.

This is a social problem, hence we don't look for a technical solution.

We may however look for technical solutions to help.  Like supporting 
the user in selecting peers they know, trust (to some extend within some 
specific context and not another), talk to at all etc.

Zerotier seems to do a good job at letting them talk to each other. Good 
enough, you don't want a single tool responsible for everything.

> Humans on the other hand, have an abstracted notion of property, I
> maintain control of my bicycle
> by chaining it to something when I am not using it, and you maintain
> ownership of real estate by
> interfacing with systems of contracts and laws that date back
> thousands of years. Basically, you just
> punish people who transgress the property rights, this requires police
> and lawyers and courts and prisons,
> and a millitary to protect your property system from neibouring
> property systems...

We could also say: Property (as in "attributed & ensured by a legal 
system") is a virtual property (as in "being an attribute not having a 
physical component").

To decentralize therefore needs (among other things)
a) a component to model a legal system and
b) use (a) to model property
c) make sure that (b) is not tied to physical devices
d) provide proofs of (b) sufficient complete and obvious to be useful as 
evidence in a court case.

(The (d) I added because we better reject the idea of a pure 
machine-supported "proof" as applicable to humans for moral reasons.)

> Now - if you want to build a true p2p system, a decentralized system -
> that depends on people
> freely choosing to run your program, and also choosing not to abuse
> your protocol, or try to
> trick or deny service to other nodes in the network.

Who said that a user should ever *depend* on some people hosting your 
data without any responsibility?

Instead you want "some appropriate degree of decentralization". (There 
is no global jurisdiction either.  And we *should* abstain from 
invention, we need to *model properly* to actually model property.)

You want to depend only on responsible peers.  That's a trust solution 
again.  So not technical, but something the user MUST be able to 
decide.  (No matter how hard this is for the implementor.)

So the model of a legal system is actually important.  And "property" is 
the best example I know of.

If I chain my bike and you took it anyway, I'll need to find some 
witness who confirms that I'm the legal owner.

Translating this into "virtual space": if you manipulate my device in 
such a way that the state changes to "bike gone" (or if I completely 
loose my device, which is not different in that context), than I'd like 
to turn to my friends and ask them "please give me a correct copy of my 
inventory list again".



I'm well aware that I'm skipping here a lot of issues, but that's what 
it boils down to.

> There is the distributed systems problems, but this is the easy part.
> What if my blog post becomes insanely popular? will my laptop have to
> serve terabytes of data?
> what happens while I am disconnected from wifi inbetween cafes?
> Obviously the answer is to distribute the data - prehaps you can get
> my blog post from
> other people who have read it, not just from me. If a few hundred
> people from around the world
> have seen it, then there is probably a pretty good chance that someone
> currently online has it.
> But then what if they refuse to serve it, or serve the wrong thing?
> (this could be malicious or by accident)

These are *some* of those issues I skipped.  You are right: that's the 
easy part.  Once we got rid of the idea that we need servers the blog is 
no longer going to be on you laptop only.  It's going to be on the 
devices of the witnesses you choose for your blog as well. Those will be 
able to seed the distribution. Your readers will torrent the repository 
and compose your blog locally.

Malice or accident: if you witness don't do their job good enough on 
average, you probably want to exchange some for more reliable peers.  
(See above: this must be the users choice or it's too bad.)

> What you do have is crypto, and information processing powers many times greater
> than when the property system was created. Would it be possible to
> create a system that enforced cooperation using just information?
>
> I think this is possible, not just because there are computer systems
> which achive this within specific
> contexts, but also, because humans can already do this naturally.

I agree that using human society as the model is the most important step 
to be taken at this point.

We have property, right and contracts.  Every programmer will tell you 
that they can program everything they understand well enough to explain 
formally.  Why not these?

> Small scale groups do not use coersion,
> they use information - everyone involved pretty much knows what is
> going on, and if someone is being
> abusive they get blocked out.

I agree with the "everyone...knows" - in small groups everyone is 
usually "commissioned to witness" every ongoing process.

Though: being blocked out is a form of coercion.

>   Certainly, this system is not invunerable, but it *is* a system.
> A reputation system. It's not very scalable, and it's not very
> accurate (human gossip is quite lossy)
> but we do have something to go on here.

Feels as if I have missed something.  Dominic, which system are you 
referring to here?

> could you use crypto and computers to scale and secure a reputation
> system, without giving any particular
> node too much implicit trust?

Yes.  See above: I'd control whom I contract with to ensure those bear 
witness of facts I consider important.

This keeps the size of the network I have to maintain within reasonable 
bounds.  It make sure my secret and not so secret data goes only where I 
expect it to go.  And it scales because there is no chokepoint, since it 
does not need a global reputation system at all.

/Jörg
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-04 15:07:09 (6 years 1 mon 23 days 05:23:00 ago)
Am 03.09.2014 01:25, schrieb Paul Frazee:
> Adding some thoughts to Dominic's --
>
> The challenge to decentralizing the application layer is that it 
> involves distributing authority.
>
> For instance, we need to authenticate users. The only distributed auth 
> in wide use right now is PKI. Since PKI only works well for 
> organizations, the user-identities have to live within the orgs. 
> That's a centralizing effect that would still occur in an open 
> IP/routing layer.

So the alternative is web of trust.  Harder to implement, harder to attack.

And harder to make simple for the user.  (I'm really short on good ideas 
how to hide this from users.)

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

This would be the easy part.  We just create the data structures at all 
commissioned peers simultaneously.

This requires a small computational overhead, but still way cheaper than 
proof-of-work or some such.

> or we rely on central nodes to keep data-bases.

Let's outright rejected that for not being decentralized.

> Then, the messages that construct the datasets need to be verifiable, 
> so that Alice can rehost messages from Bob without possibly altering them.

If we did not fail when creating the data at Bob's, Alice's and two more 
(we should have at least four parties here for byzantine fault 
tolerance), they will be identical.  So we can checksum and verify. (In 
practice that's an integral part of the protocol.)

If Bob chooses to expand the list of "notaries" (as we call those 
devices commissioned to hold some data) than the newly added parties 
will have to check with the existing set and replicate the data. Sure 
they will a) check that they get the same checksum from the majority and 
b) check that the data matches the checksum.  (At least that the way 
BALL implements the concept.)

> So there are three distinct challenges: authentication, 
> message-verification, and dataset coordination.
>
> Bitcoin, for example, solves all three of these problems. Broadly...
>
>  - Authentication: RSA keypairs. 
> (https://en.bitcoin.it/wiki/Address#Proving_you_receive_with_an_address).
>  - Message-verification: transaction signatures.
>  - Dataset coordination: the global blockchain and total ordering via PoW.

Bitcoin – it's a bit tiring. Sure it does solve these things in some 
way.  It has to.

The only thing we do slightly different is the data set coordination.  
PoW is just not good enough.  It leaks information, is expensive and 
slow.  I don't want to wait a minute for the website to update.  And I 
want to run my copy locally on really small devices.  That's why we need 
more fine grained control than a single blockchain.  We have one 
"blockchain" (not exactly, but close) per object.  And we control 
(because we want to) who is supposed to maintain and audit that one.

>
> After all that, you need to deal with abusive actors in the network 
> (DoSers, attackers) and with schemes to share resources (bandwidth, 
> sometimes disk-space). This is where the reputation system gets involved.
>
> For some interesting reading, I'll refer you to Dominic's project, 
> https://github.com/dominictarr/secure-scuttlebutt.

OK, timeout.  I'm just recovering from a cold.  Huge backlog becoming 
even larger.

Best

/Jörg


Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-04 15:45:37 (6 years 1 mon 23 days 04:45:00 ago)
Am 03.09.2014 01:25, schrieb Paul Frazee:
> For some interesting reading, I'll refer you to Dominic's project, 
> https://github.com/dominictarr/secure-scuttlebutt.
>
>

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

To illustrate: I'm currently working on some simple payment system. (I 
picked "payment system" because that's something everyone understands 
without explanation of the app's purpose; however it's only an 
application which requires the features to be demonstrated.)

It works like this:

* Every "wallet" is a (sqlite) database holding a balance table of two 
columns: amount and currency. (Together with some user interface.)
* Users can create orders (documents) to transfer some amount to some 
other wallet. The receiver can either accept or reject.

(There is more, like maintaining nick names for wallets.  But those are 
irrelevant at this point.)

The important point: the wallet must make sure that it no order exceeds 
the senders balance and no receiver can accept the same order twice.  
(The total the currency must not change.)

Having a eventually consistent database is not enough here: we can't 
trust the peer to store a correct value.

Our solution is rather simple.  Each wallet is replicated (tolerating 
byzantine faults) at several notaries.

For a small world (like 5-20 peers) this could be *all* peers, to 
simplify the situation for the time being.  Now members of the group can 
readily use it.  Any attempt to cheat does not work.

However: This can not transfer money beyond the boundaries of the 
group.  (An incoming order would be signed by many notaries.  To no 
effect: the group would only trust those notaries in the receivers set 
and reject the order if the intersection of senders and receivers 
notaries is too small.)

For a larger world byzantine replication does not work, because it comes 
at quadratic communication cost.  Instead we would create "virtual 
banks": groups of individuals each running a peer and *contracted* (as 
in "having signed a legal contract") to keep it mostly online and 
prevent fraud.  Such a group could be used as an intermediary between 
wallets running at too disjoint groups.


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


Best

/Jörg
Dominic Tarr [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-05 06:51:59 (6 years 1 mon 22 days 13:38:00 ago)
jorg,

The short answer is no; secure-scuttlebutt is eventually consistent so
you cannot easily enforce invariants like that.

On the other hand, computers are fundamentally eventually consistent
because of the finite speed of light.
So, you are always building layers of consistency on top of eventually
consistent layers, so there is probably a way you could do this.

There is *probably* a way to do it, but I think that life is easier if
you embrace things like eventually consistency and
design things to work with those principles instead of attempting to
box them into something they arn't.

The feed in secure scuttlebutt is verifiable - just by using simple
crypto primitives (hashes and signatures) it's possible to verify that
they gave you the correct data, even if it was via a third party. You
do not have to trust them to not fiddle with the data because they
could not do that and avoid detection. But you *do* need to trust them
to pass on the data when they should. There is no straightforward or
general way to cryptographically prove that they did indeed perform a
such as relaying your data for you, hence we need to calculate a trust
value.

The thing you seem to be describing is certainly quite complex,
and currently we are focusing on figuring out how to design much
simpler things that do not require consistency.

Dominic



On Thu, Sep 4, 2014 at 6:45 AM, Jörg F. Wittenberger
<Joerg.Wittenberger@softeyes.net> wrote:
> Am 03.09.2014 01:25, schrieb Paul Frazee:
>> For some interesting reading, I'll refer you to Dominic's project,
>> https://github.com/dominictarr/secure-scuttlebutt.
>>
>>
>
> Got one question here: this seems to replicate data.  Does it protect
> against malicious updates too?
>
> To illustrate: I'm currently working on some simple payment system. (I
> picked "payment system" because that's something everyone understands
> without explanation of the app's purpose; however it's only an
> application which requires the features to be demonstrated.)
>
> It works like this:
>
> * Every "wallet" is a (sqlite) database holding a balance table of two
> columns: amount and currency. (Together with some user interface.)
> * Users can create orders (documents) to transfer some amount to some
> other wallet. The receiver can either accept or reject.
>
> (There is more, like maintaining nick names for wallets.  But those are
> irrelevant at this point.)
>
> The important point: the wallet must make sure that it no order exceeds
> the senders balance and no receiver can accept the same order twice.
> (The total the currency must not change.)
>
> Having a eventually consistent database is not enough here: we can't
> trust the peer to store a correct value.
>
> Our solution is rather simple.  Each wallet is replicated (tolerating
> byzantine faults) at several notaries.
>
> For a small world (like 5-20 peers) this could be *all* peers, to
> simplify the situation for the time being.  Now members of the group can
> readily use it.  Any attempt to cheat does not work.
>
> However: This can not transfer money beyond the boundaries of the
> group.  (An incoming order would be signed by many notaries.  To no
> effect: the group would only trust those notaries in the receivers set
> and reject the order if the intersection of senders and receivers
> notaries is too small.)
>
> For a larger world byzantine replication does not work, because it comes
> at quadratic communication cost.  Instead we would create "virtual
> banks": groups of individuals each running a peer and *contracted* (as
> in "having signed a legal contract") to keep it mostly online and
> prevent fraud.  Such a group could be used as an intermediary between
> wallets running at too disjoint groups.
>
>
> So if I wanted to build applications like that one on scuttlebutt...
> possible?  How would I make sure the wallet is always correct?
>
>
> Best
>
> /Jörg
Paul Frazee [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-05 13:59:28 (6 years 1 mon 22 days 06:31: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

Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-05 14:13:39 (6 years 1 mon 22 days 06:17:00 ago)
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
Dominic Tarr [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-06 03:28:23 (6 years 1 mon 21 days 17:02:00 ago)
Jorg,

Ah I had not heard of BALL, I have been reading through the documents
at the "whilepaper" link.
I think I can vaguely see where you are doing with this, but I would
like to understand how your replication
algorithm works. Do have have a link to a description of the algorithm?

Also, regards your notary system: how are notaries assigned to
officiate a particular "place"
(is that correct Askemos terminology?)

The data model in secure-scuttlebutt is very simple. There are
messages, feeds, and ids.
a feed is an append-only singly linked list of messages, owned by an
id. The id is just the hash
of the public key used to sign the messages in a feed. A feed may not
be signed by mutliple keys
and the key may not be reassigned. The idea is to optimize for
simplicity even over convenience.
This make both replication and verification conceptually simple. It is
not necessary to trust any
devices you do not have in your physical control.

I think this will be enough to implement "web 2.0" style "social"
applications such as twitter.
Maybe not as convenient as twitter, but decentralized, and ultimately
more flexible.
More flexible, because not having centralized control over the service
means I will not be tempted
to prevent other people building on top of it, as twitter and it's
like are increasingly doing.

Do you have documentation on how your notary system and data replication works?

Dominic

On Sat, Sep 6, 2014 at 12:56 AM, Jörg F. Wittenberger
<Joerg.Wittenberger@softeyes.net> wrote:
> Boah, what a mistake I made!
>
> It's NOT 80kLOC it's 80Kbyte.
> 60% for the HTML user interface, 932 lines "real code", including all
> the SQL and non-essential functionality.
> Only about 230 lines (pur functional code and again a lot HTML) one
> would ever want to manually verify to be sure it does not violate the
> required invariants.
>
> After all: it's supposed to be easy to audit, not prohibitive expensive
> and error prone!
>
> Sorry for the noise, I had to correct that.
> /Jörg
>
> Am 06.09.2014 08:34, schrieb Jörg F. Wittenberger:
>> The payment system (current draft) for instance is here
>> http://ball.askemos.org/A876f1fe6998ca9d43f2e66c11a3f0d4a
>> that is, this is one wallet of it. You want to log in using "public" to
>> find the actual thing.  It's controlled by a single (though having
>> 80kLOC large) source file:
>> http://ball.askemos.org/Aa176138e655369f8c01c3044ced70cfc
>> (be sure to read that in whitespace preserving source mode, do NOT let
>> the browser mangle it and skip XML comments).
>
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-06 08:34:56 (6 years 1 mon 21 days 11:55:00 ago)
Am 05.09.2014 15:51, schrieb Dominic Tarr:
> jorg,
>
> The short answer is no; secure-scuttlebutt is eventually consistent so
> you cannot easily enforce invariants like that.
>
> On the other hand, computers are fundamentally eventually consistent
> because of the finite speed of light.
> So, you are always building layers of consistency on top of eventually
> consistent layers, so there is probably a way you could do this.

This sentence feel to me as if you where taking owls to Athens.  I 
completely agree with you here.
With an exception in the subjunctive in the last half sentence: BALL's 
database replication is eventually consistent too and the invariant I 
wrote about is precisely what the next (agreement) layer at top of it 
provides.

> There is *probably* a way to do it, but I think that life is easier if
> you embrace things like eventually consistency and
> design things to work with those principles instead of attempting to
> box them into something they arn't.
>
> The feed in secure scuttlebutt is verifiable - just by using simple
> crypto primitives (hashes and signatures) it's possible to verify that
> they gave you the correct data, even if it was via a third party. You
> do not have to trust them to not fiddle with the data because they
> could not do that and avoid detection. But you *do* need to trust them
> to pass on the data when they should.

This is the point at which I call for the agreement layer and active 
replication.  Devices are down or disconnected for all sort of reasons.  
But only at a certain probability.  Keeping them up at about 2/3rd of 
the time is usually easy enough.  At this point a peer not passing data 
when they should can not avoid detection either.

> There is no straightforward or
> general way to cryptographically prove that they did indeed perform a
> such as relaying your data for you, hence we need to calculate a trust
> value.

Still this calculation of "trust value" I did not find.  Or did not 
understand.  I'm always interested in such things.

> The thing you seem to be describing is certainly quite complex,

Actually it's not.  Undergrad CS students took usually about three days 
interactive discussion to grasp the idea and a few weeks to build usable 
applications.  But is seems to be endless hard to get the same results 
using written documentation.

The payment system (current draft) for instance is here
http://ball.askemos.org/A876f1fe6998ca9d43f2e66c11a3f0d4a
that is, this is one wallet of it. You want to log in using "public" to 
find the actual thing.  It's controlled by a single (though having 
80kLOC large) source file: 
http://ball.askemos.org/Aa176138e655369f8c01c3044ced70cfc
(be sure to read that in whitespace preserving source mode, do NOT let 
the browser mangle it and skip XML comments).

> and currently we are focusing on figuring out how to design much
> simpler things that do not require consistency.

I see.  I filed a note to self for SSB under eventually consistent DB 
layer.  You see: Askemos does NOT depend on BALL as an implementation.  
I'm always eager to replace as much of our code with things from 
elsewhere until we can run our stuff without any reference to our code.  
THAT would be the implementation independence I strive for (and take 
away much of the burden of maintaining the code during my days as an old 
man – not there yet).

/Jörg

>
> Dominic
>
>
>
> On Thu, Sep 4, 2014 at 6:45 AM, Jörg F. Wittenberger
> <Joerg.Wittenberger@softeyes.net> wrote:
>> Am 03.09.2014 01:25, schrieb Paul Frazee:
>>> For some interesting reading, I'll refer you to Dominic's project,
>>> https://github.com/dominictarr/secure-scuttlebutt.
>>>
>>>
>> Got one question here: this seems to replicate data.  Does it protect
>> against malicious updates too?
>>
>> To illustrate: I'm currently working on some simple payment system. (I
>> picked "payment system" because that's something everyone understands
>> without explanation of the app's purpose; however it's only an
>> application which requires the features to be demonstrated.)
>>
>> It works like this:
>>
>> * Every "wallet" is a (sqlite) database holding a balance table of two
>> columns: amount and currency. (Together with some user interface.)
>> * Users can create orders (documents) to transfer some amount to some
>> other wallet. The receiver can either accept or reject.
>>
>> (There is more, like maintaining nick names for wallets.  But those are
>> irrelevant at this point.)
>>
>> The important point: the wallet must make sure that it no order exceeds
>> the senders balance and no receiver can accept the same order twice.
>> (The total the currency must not change.)
>>
>> Having a eventually consistent database is not enough here: we can't
>> trust the peer to store a correct value.
>>
>> Our solution is rather simple.  Each wallet is replicated (tolerating
>> byzantine faults) at several notaries.
>>
>> For a small world (like 5-20 peers) this could be *all* peers, to
>> simplify the situation for the time being.  Now members of the group can
>> readily use it.  Any attempt to cheat does not work.
>>
>> However: This can not transfer money beyond the boundaries of the
>> group.  (An incoming order would be signed by many notaries.  To no
>> effect: the group would only trust those notaries in the receivers set
>> and reject the order if the intersection of senders and receivers
>> notaries is too small.)
>>
>> For a larger world byzantine replication does not work, because it comes
>> at quadratic communication cost.  Instead we would create "virtual
>> banks": groups of individuals each running a peer and *contracted* (as
>> in "having signed a legal contract") to keep it mostly online and
>> prevent fraud.  Such a group could be used as an intermediary between
>> wallets running at too disjoint groups.
>>
>>
>> So if I wanted to build applications like that one on scuttlebutt...
>> possible?  How would I make sure the wallet is always correct?
>>
>>
>> Best
>>
>> /Jörg

Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-06 08:53:52 (6 years 1 mon 21 days 11:36:00 ago)
Am 05.09.2014 20:59, schrieb Paul Frazee:
 
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.

That's about the reason why I call for a division of duties.

"Notaries" (like google, yahoo etc.) to "just run some code" (user interface, ensure invariants in databases etc-).  So the identity is a) independent of the notary (you can just add or remove them like here http://ball.askemos.org/A876f1fe6998ca9d43f2e66c11a3f0d4a?do=notaries&version=17&login=public )


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.

That's how it works.

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,

I think so too.  Actually I think a simple registry in an Askemos compatible system would do.  Users would choose one or more registries and publish their peer's public key and status.  Plus some one-time code (TAN) to set the status to "compromised" when they lost control of their device.

Otherwise we currently work around this issue by having pretty short lived certificates.  I'm always horrified when I see certs being valid for years to come.  Ours last one month currently.

Lacking enough (independent) peers to make such a registry productive, we rely on second channel.  Call friends and tell them "please switch the box of, there is a problem, we need to gather the evidence".  If I reach enough (1/3rd) of them and they recognize my voice, the system will no longer reach agreement to any state change.  Problem mitigated.

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 compro mise, 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.

Hm.  I'd personally NOT like that.  I'd rather get my old account back to work (after some time at least).  That is: disable old key and replace it with a new one.  (That's at the end of the day the reason, why the key's hash is a *bad* choice for the account identifier. I'd always put a level at top of it mapping from this vulnerable key identifier to some stable one, where I can switch keys.  Sure this can always be done, it's just yet another layer to design into the system from the beginning.)

(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


Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-06 09:56:09 (6 years 1 mon 21 days 10:34:00 ago)
Boah, what a mistake I made!

It's NOT 80kLOC it's 80Kbyte.
60% for the HTML user interface, 932 lines "real code", including all 
the SQL and non-essential functionality.
Only about 230 lines (pur functional code and again a lot HTML) one 
would ever want to manually verify to be sure it does not violate the 
required invariants.

After all: it's supposed to be easy to audit, not prohibitive expensive 
and error prone!

Sorry for the noise, I had to correct that.
/Jörg

Am 06.09.2014 08:34, schrieb Jörg F. Wittenberger:
> The payment system (current draft) for instance is here
> http://ball.askemos.org/A876f1fe6998ca9d43f2e66c11a3f0d4a
> that is, this is one wallet of it. You want to log in using "public" to
> find the actual thing.  It's controlled by a single (though having
> 80kLOC large) source file:
> http://ball.askemos.org/Aa176138e655369f8c01c3044ced70cfc
> (be sure to read that in whitespace preserving source mode, do NOT let
> the browser mangle it and skip XML comments).

P S [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-06 13:40:03 (6 years 1 mon 21 days 06:50:00 ago)
Richard Dent [LibreList] Unsubscribe 2014-09-06 18:41:15 (6 years 1 mon 21 days 01:49:00 ago)
Jörg F. Wittenberger [LibreList] Re: [redecentralize] Thoughts on decentralization and deperimeterization 2014-09-09 11:30:40 (6 years 1 mon 18 days 09:00:00 ago)
Am 06.09.2014 12:28, schrieb Dominic Tarr:
> Jorg,
>
> Ah I had not heard of BALL, I have been reading through the documents
> at the "whilepaper" link.
> I think I can vaguely see where you are doing with this, but I would
> like to understand how your replication
> algorithm works. Do have have a link to a description of the algorithm?

A high-level description
http://askemos.org/index.html?_v=wiki&_id=617
more technical here
http://ball.askemos.org/?_v=wiki&_id=1339
(follow "consensus and synchronization protocol" for state machine 
replication

> Also, regards your notary system: how are notaries assigned to
> officiate a particular "place"
> (is that correct Askemos terminology?)

Apropos terminology: we did this in German explaining rather common 
terms to detail ad nauseam.

The phrase we settled on was "a notary is commissioned to audit a 
process".  (whereby "process" is any active agent).

But I want this to be good English.  So if "officiate" is better, we 
should switch.

To the point: notaries are a property of a place.  In the demo this part 
is not very pretty yet:
http://ball.askemos.org/A876f1fe6998ca9d43f2e66c11a3f0d4a?do=notaries&version=19&login=public
An agent (here the wallet application) can control the list of notaries.

There is nothing to prevent the agent from doing stupid things like 
removing all notaries.

> The data model in secure-scuttlebutt is very simple. There are
> messages, feeds, and ids.
> a feed is an append-only singly linked list of messages, owned by an
> id.

Which is pretty much the same structure as in Askemos: a OID is a 
canonical hash of some meta data of a frame (in the sense of key-value 
pairs).  The frame hold the current state (and hidden from the 
application layer some past state) of the application at the place.  It 
is the unit of replication.  I.e., a SSB feed corresponds to a place.

Message&message is another interesting topic.  We have two:
http://askemos.org/index.html?_v=search&_id=1302

>   The id is just the hash
> of the public key used to sign the messages in a feed. A feed may not
> be signed by mutliple keys
> and the key may not be reassigned. The idea is to optimize for
> simplicity even over convenience.

That's a laudable goal.

With Askemos we are looking especially toward "long term availability".  
After all contracts often cover many years.  That's the rationale behind 
treating all crypto as a plug in of some sort. It simply changes too fast.


> This make both replication and verification conceptually simple. It is
> not necessary to trust any
> devices you do not have in your physical control.

Same here.  Up to not trusting any single device outside your trust set 
with the update process.

>
> I think this will be enough to implement "web 2.0" style "social"
> applications such as twitter.
> Maybe not as convenient as twitter, but decentralized, and ultimately
> more flexible.
> More flexible, because not having centralized control over the service
> means I will not be tempted
> to prevent other people building on top of it, as twitter and it's
> like are increasingly doing.
>
> Do you have documentation on how your notary system and data replication works?

Hope so.  See above.  Also for the fun of it, try the search box in the 
upper left of ball.askemos.org and askemos.org (technical vs. 
"philosophy").  It is a sqlite full text search coming back with 
subject-predicate-object triples.  Often quite useful.

Questions are very welcome.  I'm working on the documentation side now. 
(Enough feature creep already. ;-)

Best

/Jörg

>
> Dominic
>
> On Sat, Sep 6, 2014 at 12:56 AM, Jörg F. Wittenberger
> <Joerg.Wittenberger@softeyes.net> wrote:
>> Boah, what a mistake I made!
>>
>> It's NOT 80kLOC it's 80Kbyte.
>> 60% for the HTML user interface, 932 lines "real code", including all
>> the SQL and non-essential functionality.
>> Only about 230 lines (pur functional code and again a lot HTML) one
>> would ever want to manually verify to be sure it does not violate the
>> required invariants.
>>
>> After all: it's supposed to be easy to audit, not prohibitive expensive
>> and error prone!
>>
>> Sorry for the noise, I had to correct that.
>> /Jörg
>>
>> Am 06.09.2014 08:34, schrieb Jörg F. Wittenberger:
>>> The payment system (current draft) for instance is here
>>> http://ball.askemos.org/A876f1fe6998ca9d43f2e66c11a3f0d4a
>>> that is, this is one wallet of it. You want to log in using "public" to
>>> find the actual thing.  It's controlled by a single (though having
>>> 80kLOC large) source file:
>>> http://ball.askemos.org/Aa176138e655369f8c01c3044ced70cfc
>>> (be sure to read that in whitespace preserving source mode, do NOT let
>>> the browser mangle it and skip XML comments).

:
: