HOLOCHAIN P2P Apps Without the Blockchains Problems for Scale, Speed, Cost & Governance
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
Why
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.
How
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.
Benefits
Consensus on rules not data
Fast (Blockchains go slow and are expensive)
Cheap
Scales well
User centric
Application bridging
Identity bridging
Adaptable
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.
