HOLOCHAIN P2P Apps Without the Blockchains Problems for Scale, Speed, Cost & Governance

From IIW
Jump to: navigation, search

HOLOCHAIN P2P Apps Without the Blockchain’s Problems for Scale, Speed, Cost & Governance

Tuesday 5F

Convener: Matt S.

Notes-taker(s): Heather Vescent

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Holochain is an alternate to blockchains.

How we do distributed data integrity - holochain.

releasing alpha on friday

It's open source


1. users in control

2. no dependence on 3rd party

3. works the way users expect

4. maximize adaptive capacity

Humans need new ways to organize themselves. We need more adaptive models.


Each application has its own holochain.

Take the best parts of blockchain and bit torrent.

Shared validation rules - agreeing on the rules

Hash chains (one for each user)

Distributed hash table (for each application)

A separate chain for each user. you have your own log of your own activity on my device. each application has its own holochain, which means you have your own chain for each application for each user.

Every holochain has 3 parts

1. application code

2. local hash chain (an append-only tamper resistance log o the users own actions)

3. shared storage (a distributed hash table for only the content in the app)

q: does the hash table have history? do I get to add data and pass it along?

a: you would be able to sign it, but not able to alter the stuff I have signed.

In a distributed system, there is no absolute ordering of events. One person could receive things in a different order from someone else?

Example: peer to peer message

1. Installation (on your divide in your local source chain:

1: add application code as first entry: application code lets other know you are using the same app.

Q: versioning?

A: there is no versioning: we are running identical code.

Q: so you have your own runtime execution?

A: yes.

2. Generate keys and add as 2nd entry: keys enable others to

a. route content (hash is an address)
b. send encrypted messages
c. verified signature

Sending a message

1. write message

2. validate new data (sanity check

3. store data in new chain

4. signs in chain

5. store DHT

Expect users to also be hosts


Q: Can we have backups of source chains?

A: yes

I'm finding the best path, by queuing the nodes around me, until I find the best path, and then I send the message.

this is a routing protocol, with a stable network in it. time transient.


Consensus on rules not data

Fast (Blockchains go slow and are expensive)


Scales well

User centric

Application bridging

Identity bridging


analogy: humans speaking english, each have a knowledge of english (although they are not running the exact same source code so there might be misunderstood).

Holographic storage, to adapt to the new things to propagate through the system.

This leads to adaptive capacity.

Micro apps and meta applications - create custom UI that works for you.

Version control: ? how do you get people to migrate apps all at once

should be able to bridge platforms

Clutter: peer to peer twitter

Current model is the app developer is a dictator model

DPKI - building another application that is a distributed public key infrastructure. Interested in talking to people to set up identity servers. social key revocation.

Ambition: we think the world works better when individuals get to pick the way their apps work. We want to get people used to this user centric way. This is different from network centric blockchain.

Larger context: CEPTR: out of the meta-currency: interoperable communication systems that mimic biology communication, building social coherence and social risk. Ceptr.

Pcubed - protocol for pluggable protocols.