P2P/ Distributed Network Protocols

Headsup: my personal plan for responding to Christopher's criticisms of Holochain is to contrast several candidate protocols/frameworks for economic networks: Holochain, SSB, and ActivityPub. Might even put a little DigLife in there. So I don't want a new thread that is only focused on Holochain.

I'll discuss Christopher's criticisms as best I can, but thought it would be more useful to look at a bigger picture, using those criteria as well as some others.

Given that I will contrast several protocol candidates, ok if I just post my response here? (I'll write it elsewhere and post a link here.)

it may be reasonable to point out here that I have not just levelled criticism at the holochain offering. From the starting point of deconstructing the components of a platform I helped to build, I have shown how a brilliant idea is been wrapped inside a deeply counterproductive cocoon of corporate vendor lock in. I have been clear how to leverage the real value of the idea, within the wider context of existing mature tools.

Is the essence of your criticism that, at least at this stage, participation in holochain is dependent on software from the holochain organization? (Although the software itself is open source.)
And it would have been better to specify a protocol which could be used by agent software developed in one of many existing frameworks (e.g. Wordpress), using external "Policing Neighbourhood DHTs"?

(I like the term Neighbourhood DHT, by the way...)

yes. it is also true that the "requirement to embed a vm", which is the root of the need to developa complete ecosystem from scratch is not agent-centric and the sole effect is to create time commitment to the holochain company, not the tech, or the movement

bare in mind I spent months making this clear. as the Second programmer that ever committed full time to the project

I suppose the essence is, that holochain spent 95% of their time building a platform, which had no clear purpose in the agent centric space, and 5% jerry rigging a dht to connect these "agents" together. technically it is a much much simpler problem to create policing neighbourhood dht nodes, as a protocol and sample client. I suggest a useful prototype could have been built within 6 months, allowing community developers and app coders to begin exploring the agent centric path.

the result, of course would have been some respect, maybe some fame, but not fortune.

I have nothing at all against people raising capital by saying whatever they like, but i do feel a duty to point out what I see to be the energy black hole inaccuracy, that drove (drives) that money into that organisation.

the "at this stage" is an issue. if hochain continue to present the idea that "a new internet of freedom" is the result of starting again... effigy they know to be categorically fake, and people start reinventing thousands of wheels... then great. but.... this movement does not need that kind of time sink, nor that kind of inaccuracy in it's core.

the idea that they have built their own "rapid app development stack" to connect with their embedded vm is.... purile.

it's not just that it is dependent, it is that the dependency rejects about a decade or 15 years of ecosystems, all of which are perfectly valid components of the "agent centric" ecosystem. if that makes sense.

Some of it makes some sense, but the emotionally-laden expressions (fake, purile, vendor-lockin, etc) get in the way of analysis. As well as cause some people here to cringe. I understand that you feel mistreated, and give you some slack about it, but it does distract.

Lol. Bob, the fact that you choose to imply emotionally laden projections onto my words is a common place behaviour in groups such as these. Reducing the "potential emotional context" to zero, to "avoid ..." what is it Arthur Brock calls it "disruption", is just a weird brand of oppression, implemented by people who don't have real world experience of managing disagreement. The truth is, all of my analysis makes perfect sense, and my words are carefully chosen from a large vocabulary. I could have chosen "less potentially emotionally laden words", but I'm much more interested in expressing myself, than pretending that Holochain have'nt done what they have done deliberately, with awareness. My safe space credentials are thorough. The idea that use of the word "purile" is somehow "cringeworthy" is ... oppressive in the extreme.

Definition of purile: "Nowadays, puerile can describe the acts or utterances of an actual child, but it more often refers (usually with marked disapproval) to occurrences of childishness where adult maturity would be expected or preferred"

^ -- That is my actual opinion, based on my experience. Disregarding it as "an expression of being mistreated" is the kind of bizarre behaviour of people trying to lead a scenario where they are half way between one universe (managed hierarchy) and another (folk network). I applaud your attempts, but have to disagree. Perhaps you can learn something from this?

If you want to comment on the content, go ahead.

Now... a "Zero emotional version", for the.. "cringers" (should they actually exist), is:

1. Criticism of State of the Project

   • Not a federated protocol
   • DHT not developed to deliver core promises of Holochain narrative
   • In order to create Holochain apps, developers must learn an arbitrary, immature new language form, where there is no justification for its existence.
   • Educational material embeds, implicitly around "OPT-OUT Security" as a core requirement of agent-centric, where actually the concept of "DNA" of a holochain app is demonstrably not agent-centric, and the concept of "OPT-OUT" security is... --- (now here I would insert a feeling, since for me, that is how I would choose to express my depth of understanding, but since that would get somehow related to me being mistreated, something I have never said or implied, rather than me having 30 years of experience of logical analysis... let me find an accurate, vulcan expression..... ) --- absolutely impossible, a-priori impossible with even a basic grasp of rational systems design, and possibly most importantly, devalues to zero the incredible power of GIT and Hashing in general (where Holochain is a technology built upon a deep understanding of hashing)
   • the decision makers are explicitly aware of all of this

2. Criticism of the process

   • Creating a federated protocol, with matching example client (in wordpress, django, whatever) would have required vastly less effort
   • The decisions makers were aware of this
   • Creating the arbitrary embedded VM platform is an enormous amount of work, that had no purpose other than to support the value proposition of Holo. (vendor-lockin)
   • the decision makers were explicitly aware of all of this

3. Looking forward

   • whilst I have no problem with Holochain acquiring money from the mainstream with this brand of misdirection, I do believe that this kind of community should avoid putting time into learning the arbitrary platform they have created.
   • The core idea of an "agent-centric" proof of truth, is, brilliant, and however that is implemented, be it through the project I have committed to complete by September, by someone else, or by Holochain, matters not too much to me.
   • Im pretty sure I have consistently applauded Holochain for the invention of this idea. I hope that I have been able to help people to grok what it really means.

Thanks for the less emotional version. It is a lot more clear.

and point 0. from above (which is the opening description of the prezi, should anyone not have looked it over) is
0. The Holochain concept of a "Policing Neighbourhood DHT" is absolutely brilliant. It is a federatable protocol that is extraordinarily flexible in many ways. Possibly the most valuable flexibility of it is that it effortlessly models the growth of communities from small to large, something that the other blockchain technologies cannot do.

Going further, what this agent-centric model does is allow communities to try out ideas into wider ecosystem with very low cost and very low impact. The results of a mistake in a smart contract on Ethereum can be enormous, whereas Policing Neighbourhood DHT apps can be tested in their organically interested community, and then grow, die or maintain as the ecosystem desires.

Research into the implementation details is strongly indicated, and I am grateful to have contributed to least one fork of the Holochain organisation that has found good funding to do exactly that.

oh, and fake was a typo, was suppose to say false... sorry :)

Here's a comment link to the first draft of my attempt to compare Holochain, ActivityPub, and SSB, incorporating Christopher's criticisms as I understood them maybe an hour ago.
https://docs.google.com/document/d/14Naw_P2Lsqnf5EMRQYWugEB5KuxtLro61VWiPTtdg4o/edit?usp=sharing

I will also be sharing this with some people from Holochain, ActivityPub, and SSB, and may get comments from them.

@christopher7 I am very interested if you can implement your ideas in e.g. Wordpress. Or I'd personally like Python better...

I am grateful to have contributed to least one fork of the Holochain organisation that has found good funding to do exactly that.

I remain interested in such things and will add them to our list of candidates.

Whether Chris is right or wrong I totally disagree with the idea that he shouldn't express himself freely or frankly or that his choice of words is a distraction and it seems to me that it is you who are rather missing the point if you think that to be the case. The criticism that he is making of Holochain is an extremely serious one - that they are introducing unnecessary levels of complexity to an important task that can be accomplished more simply and efficiently by other means. Given what is at stake here - the creation of new economic models that can guide us away from the path of collective self-destruction that we are on and towards a future of balance and regeneration - I fail to see what there is to not be upset about IF what Chris is saying is accurate. Surely you get that waiting 15 years to birth a new economic paradigm that could be created in 18 months (say) is a bit irresponsible given that climate scientists have told us that we will have passed the point of no return with respect to global warming if we don't turn things around within the next 12 years?

I have met the Holochain team in "real life" and I think that they are a really cool bunch of people with really great ideas. But Chris's criticism should simply be assessed on their own merit, and I am not technically savvy enough to make that assessment. Do you have any rebuttal to make to his claim that what they are trying to do could be achieved more quickly and efficiently using Wordpress or Python? Also, can any of you point me in the direction of resources that will give me a better idea of what "agent-centric" means in this context?

Hi Adam - I agree, criticism is useful, but we need to understand the context. Why is Christopher saying these things? Is he a disgruntled ex-employee? Does he have reason to try and damage the Holo reputation? I hope not - but the facts are not clear...
I don't want to ignite flames but, in relation to Christopher's assertion that he was fired, folks at Holo told me "it's a bit hard to "fire" someone who never signed their contract in the first place." - and - "...He was not part of the core team from a month of the start of the project, for example. Not close." They also explained that the Prezzi in inaccurate and based on the Go prototype version rather than the current Rust release.
The idea that you could build something akin to what Holo proposes in Wordpress is incredible. But, like Bob, I'll be very interested to see it if it appears in September!

Context is important but can sometimes be very misleading. The validity of Chris's criticisms is analytically distinct from the validity of his grievances. Suppose Chris's grievances are justified and can be validated. Does that validate his criticisms? Suppose Chris's grievances are unjustified and can be shown to be spurious. Does that invalidate his criticisms? The answer to both questions is of course "no." The most that can reasonably be said is that if Chris's grievances are spurious his criticisms might [italicized] also be spurious, and best explained in terms of his subjective sense of grievance as opposed to the specific matters to which he is expressing concern. I think that it is entirely legitimate to at least consider that to be a possibility, but not to assume that it is a foregone conclusion that that is indeed the case before having assessed the validity of his criticisms on their own merit. Reflecting upon your comments I do feel, however, that Bob may have had a point when he referred to Chris's language as "distracting" although I don't think that it is his language that is distracting, per se, but rather his expressed grievances towards Holochain's "decisions makers" and the suspicion that this can create about his reliability as a witness and commentator about Holochain architecture, as expressed in your comments. However, the irony is that by conflating and confusing the validity of his criticisms of Holochain architecture with the legitimacy of his grievances towards Holochain the organization you are incurring the exact same logical error that you are (implicitly) accusing him of. Please understand that this is not intended as a pointed criticism of you. I am simply very much invested in trying to ensure that people in this space can find ways to have good faith discussion and debate without falling into the destructive dynamic of accusation and counter accusation.

Based on what I know so far, I would say that Christopher's ideas are worth considering, beyond whatever grievance he may have against the Holochain organization.

I am trying to treat it all in that light, which is partly why I am trying to put the grievance issues off to the side.

Yes, thanks Bob - I appreciate that spirit!

NOTE: My original response was really long-winded; I've edited and clarified it. Please let me know if I've pared it down too much and made things unclear.

Holochain proselyte here, dyed-in-the-wool, drank the Kool-Aid, etc. (Just kidding; I've been known to critique aspects of Holochain that I'm sceptical about. But full disclosure, I am on the Holo team as a developer mentor.)

I've made lots of long-winded comments on Bob's document, but I thought I'd summarise them here.

First, I'm intrigued by Christopher's observation that the 'policing DHT' is the really valuable thing here in terms of a Holochain 'protocol'. I think he's bang-on. For those of you who aren't familiar, here's how the Holochain story goes:

• You and I are sovereign agents. We each carry our history with us as a 'source chain', an immutable journal of events.
• I want to buy a coffee from you. I claim that I've agreed to abide by the rules of this particular currency, as expressed by the first item in my chain, the 'DNA hash' (the hash of the rules, typically expressed as executable code).
• My DNA hash is nothing but an assertion or a promise -- you can't see whether I'm running the right rules; all you can see is a hash (again, this is something Christopher calls out -- the system is trustless). So you ask me for my whole chain and audit it. Once you're satisfied that I've abided by the rules (that is, that I have the money I'm trying to give you), you engage in a transaction with me.

There are three problems with this:

• I might be lying about my history. The hashes check out, all the transactions abide by the rules, but it hides the fact that I deleted the record of me sending $5000 to someone else.
• In order to be satisfied that my chain is in a correct state, you may need to audit the state of the people who've sent me money in the past (and the people who've sent them money, etc). But maybe those people are offline.
• This auditing of my entire history, fanning out from this present moment, is terribly expensive even if everyone's online.

The DHT mitigates these problems by keeping a memory -- a memory of everyone's actions (fixes the problems with chain rewinding and offline agents), and a memory of which of those actions are invalid, which speeds up auditing immensely. Anyone who finds that their peer has broken a rule can publish a warrant against their actions, which spreads through the network. Eventually the network as a whole sees me as a bad actor and pushes me out -- like an immune system. Simple rules that create a fairly resilient complex system.

So that's the core of the Holochain protocol. Mutually sovereign peers, publicly stating their voluntary participation in various sets of shared rules, publishing journals of their actions based on those rules, and committing to spread, validate, and store those actions for each other. A validating/policing DHT.

This is the opt-in security that Christopher describes. It answers the question, "how do I trust your actions/claims when I don't know if I can trust you?"

The goal of the Metacurrency project is to enable the creation of rich, robust P2P economic and social networks. Their design stands on two pillars:

1. Provide a communication protocol that allows agents to trust each other (the aforementioned DHT).
2. Create a way for communities to author their shared agreements, which are then communicated over that protocol. This is why they're building the Holochain app dev stack.

You can use the protocol by itself if you like, and that's just fine. As Christopher says, it's a brilliant idea. But the Metacurrency folks always had in mind that this was merely a carrier for the real exciting stuff -- the actual human exchanges that make these imagined networks come alive. Instead of expressing your agreements as source code, you could draft up a document describing them and then let people create their own implementations. That's totally fine (in fact it would be a neat experiment to do just that, with the hash of the document becoming the DNA hash). As long as you use the same communication protocols that other nodes written in other languages are using, you'll be just fine. (As long as you've interpreted the agreement correctly; otherwise the network will eject you.)

Holochain's offering (yuk, I feel like I'm verging into evangelist territory; please forgive me) is a minimal viable framework to make the development of these shared agreements easy. I'd argue that existing frameworks (e.g., Django, WordPress, ASP.NET) are great but they're designed with assumptions about HTTP and mutable databases, so each implementer of the Holochain protocol would end up writing a lot of boilerplate to implement things like source chain management, P2P gossip*, the base rules about validation, warrants, etc. These are the things that Art and Eric decided ought to be included for free in a reference implementation, and along with a nice API for writing DNAs, they form the 'subconscious' rules that every DNA will probably want to have anyway. One of the core commitments of the dev team is to make it easy to build these apps.

(* Note: the P2P gossip / DHT library will be released separately, so you could theoretically incorporate it into your own framework.)

This makes up the core of the Holochain runtime. So yes, it is a heavy focus on the non-protocol aspects of Holochain, and perhaps time will show that it was too heavy a focus. But I don't want to get into fortune-telling -- we want the ecosystem to grow rapidly, and from this side of things, having a relatively complete framework seems to be the best way to make that happen.

Art thinks I'm downplaying the importance of having one single runtime engine (the 'VM' and the core lib). He says that it's crucial for you to be able to trust your own copy of the rules if you expect to be able to play by the rules of a network. (I don't disagree with that.) In his opinion the only sane way to make that happen is to have rules written down as source code, run deterministically and unambiguously by a particular VM, connecting to a particular implementation of a base API that does the bulk of the work for you. My thought is that it's not exactly imperative but, given how easy it is for a programmer to make mistakes, this consistency is pretty darn important and nice to have. Consider the consequences of being shut out of an economic network because you're running an implementation that misinterprets the rules.

(Note: Christopher's critique of the unfit-for-purpose DHT bolted on awkwardly to the original Go-based prototype is totally valid. The DHT they used was Kademlia-ish, borrowed wholesale from the IPFS project, and apparently it took the team a lot of work to shoehorn it to fit their needs. The DHT in the beta version will be specifically designed to suit Holochain's resilience model and will be very agent-centric.)

oh, I forgot to address a few specific critiques:

• The Go-based prototype was just a prototype. A first iteration designed to probe the design for flaws and iterate into something better. The JS engine in particular was slow and clunky.

• Because of practical realities (that is, there are only so many devs working on Holochain) the app dev stack is necessarily opinionated. For now we're only really supporting Rust as a DNA development language -- it seems to have good support for bringing in all sorts of external third-party libraries, and the compiler imposes a lot of nice guarantees in the way of type safety and memory safety. That may feel like vendor lock-in, but I'd argue that it's no worse than browser manufacturers demanding that you use JavaScript. (Actually we're looking for people to help build support for other languages, so if you know of any really bored, independently wealthy developers...)

so a couple of things.

1. where's the documentation on the dht protocol, and the specification of how the dht will manage bad actors, etc? Is there actually a functioning sharded, policing dht implementation in any form?

2. this paragraph pretty much sums up the situation in my eyes:

"He says that the only way to guarantee that is to have rules written down as source code, run deterministically and unambiguously by a particular VM, connecting to a particular implementation of a base API that does the bulk of the work for you. My thought is that it’s not exactly imperative but, given how easy it is for a programmer to make mistakes, this consistency is pretty darn important and nice to have"

I mean? what? what does this mean? it basically says "it's difficult for a programmer to ensure they have xyz version of node.js or wordpress installed, with xyz version of an npm package or plugin". except of course it's not. it's trivial to automate such a requirement.

this kind of word / logic abuse runs deeply through holochain's marketing driven spiel, and right through their formal documentation. I find that makes me feel uncomfortable and on my guard, and I'm yet to see a functioning tool.

where is the protocol definition? and sample implementation? it seems to me that there is none, and that, somewhat perversely, all that actually exists is an immature, monolithic RAD platform that tries to solve the same problems as the www.

Hey there. Not much time to respond (busy morning), but I'll do my best:

I mean? what? what does this mean? it basically says "it's difficult for a programmer to ensure they have xyz version of node.js or wordpress installed, with xyz version of an npm package or plugin". except of course it's not. it's trivial to automate such a requirement.

I think the gist is not that it's impossible for a dev to put together the right stack -- you're right; a well-written install script or Dockerfile can pull in all the right things. I think what he means is that, for a given set of rules, two people writing two separate implementations will have trouble getting them to jive perfectly enough that you don't see their respective users unintentionally forking into two separate realities. Nothing more. Nobody's bound to a specific implementation. Does a fully built reference implementation from the Holochain team lock you into a certain stack? Sure. Will it run the risk of being a monoculture because of first-mover advantage? Possibly. These are choices that everyone has to make when they choose a framework. I guess the advantage with web frameworks is that there are now a lot more of them than there used to be (if you don't like ASP.NET you can switch to Django, and they both speak web) whereas the Holochain ecosystem is considerably less mature.

Anyhow, I'm just trying to convey someone else's opinion as accurately as possible. Not trying to defend it; just presenting it for other people to make their own opinions. I've got opinions of my own; I personally think it's hard but not impossible to create two separate implementations that nonetheless are perfectly interoperable.

where is the protocol definition? and sample implementation? it seems to me that there is none

this is very true -- that part is still being designed based on feedback from the first ill-suited implementation borrowed from IPFS. I think the plan is to build the implementation and specification at the same time. I've seen the initial design doc though, and it was quite interesting.

@pauldaoust1

I've seen the initial design doc though, and it was quite interesting.

One of my own criticisms (or comparisons) of Holochain vs SSB is that the SSB community works out in the open, all the time, discussing everything, as they live in the software they are building. As they say, that practice expands their consciousness. Do you think this is a place where Holochain's business plan and organization might be affecting their design and development practices? Vs SSB's lack of business plan?

@bobhaugen yeah, I love the stories I've heard about SSB development, especially re: cobudgeting and using SSB to talk about SSB. Oh, and Git-over-SSB. Re: whether our business plan and focus is affecting our dev practices, that's certainly possible. My story about the history of the Metacurrency project is that they worked for about a decade trying to bring something to fruition, but tight (probably nonexistent) budgets meant that it was always tough going. Perhaps they decided that the only way to bankroll continued development sustainably was to build a business, some sort of business that would give them a compelling excuse to build out their open-source project. (Like perhaps a business whose core product was dependent on the maturity of said open-source project -- in other words, Holo hosting.)

Right now I'd say we're def leaning towards cathedral-style open-source. And I'd say business needs are pushing our current dev culture to an extent: while issues are created and discussed in the open as GitHub issues on the public repo, and solutions eventually land and are reviewed as PRs on same repo, the roadmap lives elsewhere. A lot of daily discussion happens in private channels too. I think the reason for this is not that we want to shun people and stay in our ivory tower, but simply that our core dev team needs to stay focused and productive on the road to beta. (Ask me for more details if you're curious.)

That's not to say we don't want to be bazaar-style. We've been trying to attract core contributors, especially to help build out documentation and support for other programming languages. I think we could certainly push ourselves to grow re: creating a bazaar-friendly culture though, and it's something we're starting to work on.

(And also I think we're in that awkward early stage where not a lot of people outside the core team are even interested in contributing yet.)

you are repeatedly conflating the idea of being able to write An App onto a federated implementation of a PNDHT, and the absurdity of many different people writing the same app in different languages.

you know you are doing that

as I said initially, holochain have not even tried to develop a policing neighbourhood dht. the idea that somehow wasn't a priority is an astonishing lie to the community (either then or now). there isn't even a specification document lol.

you are repeatedly conflating the idea of being able to write An App onto a federated implementation of a PNDHT, and the absurdity of many different people writing the same app in different languages.

I appreciate you calling me out on that, but I honestly am struggling to understand what you're referring to. Could you quote the specific spot where I'm muddying the two? (Also, re: "the absurdity of many different people writing the same app in different languages" I didn't know that we were in agreement on that point; I thought you were saying that two developers should be able to write two separate implementations of one app. Perhaps the fact that I didn't understand that is why you believe I'm conflating two different things?)

no i don't feel like it's a flame war. I am avoiding pointing out which parts of the fluff and background I know to be untrue, bc in the end no one cares.

"I think what he means is that, for a given set of rules, two people writing two separate implementations will have trouble getting them to jive perfectly enough that you don't see their respective users unintentionally forking into two separate realities. Nothing more. Nobody's bound to a specific implementation. Does a fully built reference implementation from the Holochain team lock you into a certain stack? Sure."

• no Paul, this doesn't make sense. your comments here are designed to point out that Arthur and Eric have some sort of logical, altruistic reasoning for building and enormous monolithic, from scratch execution environment that traps everyone away from the mainstream www ecosystems. your logic is that a federated protocol implies a potential mess within a single app, and that "building a reference implementation ameliorates that". it simply isn't true. npm literally does all the things necessary to create a "runtime stack"..so does WordPress. so does every modern package managed ecosystem.

the only justification for building an embedded vm is "opt-out" security, which doesn't exist.

why on earth would two developers build different implementations of the same app? how would that work? having a federated protocol, with an implementation of a PNDHT that farms validation out via hooks over rest / socket to any other software is the canonical implementation. creating simple libraries that wrap the hooks into function / api calls onto any other platform is trivial.

it is, as was my original point vs holochain on this thread, utterly unconscionable that holochain are hog teaching people to make holochain apps without having even tried to build a PNDHT. it is equally telling that I talked about all of this until I was blue in the face to utter brick walls and word salad from the founders

it is true it is they who used open grass roots language to pull together a group and then viciously grabbed the legal reigns when critical mass was achieved.

pretty sure the prezi makes all that clear

@bobhaugen "... contrast several candidate protocols/frameworks for economic networks: Holochain, SSB, and ActivityPub."
Can't wait to see it.

So we've managed to boil down my criticism of the Holochain implementation to:

"If your box was hacked, what difference would the DNA / WASM architecture make" - the answer being of course, none at all.

If the WASM Architecture is designed to output Holochain Apps that will run efficiently on a raspberry pi, why not just use an existing RAD tool?

These two things kind of compete with each other, because the reality, in my rather detailed opinion, is that the design was to create a vendor lock product.

But your comments are made on out of date or incorrect assumptions. Holo is not aiming for "vendor lock in" - it will be open source. You and I will be able to download the code and run our own private p2p networks without having anything to do with Holo HQ - so how could we be "locked in"?

@olisb I think the 'vendor lock-in' critique is more aimed at the amount of attention spent on building a reference implementation with a specific set of technologies and a specific vocabuluary/API, and that hints strongly that Holo wants developers to be dependent on them so they can keep their hosting business alive (@christopher7 you can correct me if I'm wrong). The pattern of a DHT sharing and validating individuals' histories doesn't explicitly need the Holochain stack with its weird lingo (zome functions, validation callbacks); all it needs is people agreeing to use a particular gossip protocol with a particular set of message types and promises to hold the network in coherence, which acts as a carrier medium for application-specific vocabularies. Forcing a particular app dev framework into that good pattern creates the opportunity for us to command the market and make it hard for anyone to offer competing implementations.

And he's right about the pattern being able to stand on its own. I think we could do more to clarify the distinction the DHT from the app dev framework, and after reading Christopher's comments I think I'll start doing that. (TBH I was never quite clear where the protocol ended and other stuff began; @christopher7 your materials really cut through my muddy thinking in the past few days. This might sound disingenuous, but thank you!)

But the pattern for agent-centric data integrity in untrusted networks is only one half of the picture. I think what really excites Art and Eric is the application-specific vocabularies that will be built on top of that, and to that end they designed what they think is a good base toolkit for building them. You might hate it and want to design your own, and I'd really love to see new implementations come into existence. I'm a bit chagrined that all we have right now re: the DHT pattern are vague ideas bandied about in talks + an early prototype, but given that we haven't seen a massive interest in people wanting to build alternative implementations (probably something to do with the fact that the reference implementation isn't even alpha yet), I think that drafting up a detailed spec at this time would be putting our energies in the wrong spot. (Which is why the white paper has also languished in draft mode.)

l. I was WORKING THERE. they weren't vague ideas, it's mathematical analysis that forms the foundation of the entire public message.

building a runtime platform from scratch is an awful idea. I was there.

lol.

it's been two years. best of luck to you, and your new friends. xx

Okay, yeah, "vague ideas" was probably the wrong choice of words, but I'm trying to be less wordy in response to feedback. I was referring to our public materials, esp Matt's talks which are vivid but intentionally light on details (wrong audience for a spec). Yes, the white paper, in spite of being unfinished, lays out the proofs that define how and why the DHT works. I shouldn't've ignored it. But you have also asked to see a detailed spec that makes it possible for third parties to build their own implementations, and I'm apologising that we don't have anything like that.

"And he's right about the pattern being able to stand on its own. I think we could do more to clarify the distinction the DHT from the app dev app framwork...." Hey @pauldaoust1 could you please do that, as you've said, and keep us in the loop? I think that would be a super cool thing for you to do that would help to restore trust - at least from my own perspective on things.

Hey @pauldaoust1 you say: "But the pattern for agent-centric data integrity in untrusted networks is only one half of the picture. I think what really excites Art and Eric is the application-specific vocabularies that will be built on top of that, and to that end they designed what they think is a good base toolkit for building them." Can you please expand upon what exactly is meant by "application-specific vocabularies" and what pragmatic value they can serve? I spent a week with Eric, Nico and Raymond Powell in October '17, and also met and spent time with Christopher earlier that year. I really love all of these guys, and respect all of them. But I find Christopher's criticisms quite persuasive. One of the things that Nico said to me about crypto and distributed computing when I was staying with him was "I don't think that it's going to be a winner takes all situation." So let's hope that ALL of these projects and project proposals happen and are a Big Success and thank you for everything that you are doing in support of that happy inclusive outcome in which all truths and good ideas are honored and everything that you are doing and will do to contribute to that.

I would like to know:

1) Whether anyone has any come-back to Chris's rather serious criticism that what Holochain are trying to do could be achieved more easily and efficiently using Python or Wordpress?

2) If so is anyone trying to do that? and

3) Can anyone tell me if "agent-centric computing" has a history that pre-dates Holochain and/or where I should refer to in order to get a high-level understanding of the concept?

1) I am not trying to do a come-back, but to understand if his criticisms are accurate, and also to compare those three candidate protocols on those and other criteria.
2) Christopher says he is trying to create a protocol and software that will embody his ideas. More in comments in that comparison doc. I hope he can do it.
3) I wrote about the general ideas in this and other documents starting in 2016, but the name for it came from Holochain.
https://docs.google.com/document/d/1bCunbrSmqUbfK2JLw-ND1iOeEPHU_HX_eo4juAepLyo/edit?usp=sharing

Whether they coined the phrase, I don't know. But I and several other people have happily borrowed and re-used it. I usually give them credit, as in this more recent doc: https://github.com/valueflows/vf-apps-agents/wiki/Agent-centric-computing

Thanks very much Bob - much appreciated - I'll take a look at all this tomorrow.

on 3 - this discussion about building a "protocol-coop" alternative to Uber on Holo helped me get my head around the agent-centric concept... https://open.coop/2018/07/09/holochain-commons-engine-cooperation-scale/ ... UI design is going to become a lot more challenging / interesting for agent-centric apps...

oh, and "holo is like airbnb for web hosting".
you mean "like web hosting, but only for holochain apps"

we are trying to create interoperable components that work together.

um. you mean like the thousands of node.js libraries, or wordpress plugins that do almost anything you can conceive of?

PNDHT. absolutely brilliant idea. nodes can be run in any kind of box. using other people's machines to run your own decentralised app, that you pay for. isn't that called "the cloud". yes, but it's the cloud made up of everyone's spare computing power... what if they turn their machine off? well so my data is available on 20 different nodes, and Holo will spin up another instance of my app in real time on another machine. really. that sounds amazing..good luck. I'm quite happy to run mature things on the cloud, or on my own device. but I wish you luck.

the truth is that the PNDHT can be add as a protocol to the existing enormous ecosystem called "the world wide web", creating decentralised proof of truth..this is absolutely awesome, but it's not obviously monetizable into the tens of millions to the creators. it seems to me that recognition, that simple recognition, and supporting the grass roots just isn't enough, which is fine . the www is built from decades of work on protocols such as html, cors, dns, and hundreds of millions (at least) of person hours on nginx, node.js, WordPress,, digital ocean, aws etc. "creating a new internet [world wide web]" is (sorry Bob) utterly purile.

and just to be clear the renewable energy thing was my chat. hahahahahahaha. funny how stuff I make up off the top of my bread becomes part of someone's narrative.

Matthew is a sweetie. and an excellent speaker. best of luck to Holochain and Holo.

Thanks very much Oli - I'll take a look at that shortly.

We've done some work on what we think is the appropriate UI/UX for agent-centric economic networks.

Short version: it is a combination of social and economic networking, with your economic interactions appearing in feed streams like your social interactions, often about the same topics. Combined with graphical overviews showing the network context the interactions are happening in.

@ivan116 is working on it, and early versions are in use in Fair Coop and soon with a Holochain demo.

thanks Bob, I'm going to start a new thread on this as I think it is really interesting

Re agent-centric: don't forget this https://www.loomio.org/d/3wDCtkoG/structuring-the-oae-around-agents from @lynnfoster and it mentions something even earlier from @olisb

what of course is fascinating is the cognitive dissonance of Oli talking about a contract, firing, and grievances as if his sentence makes sense, which of course it does not. "pretty hard to fire someone who hasn't signed a contract". is it? what does that mean? really look at it. in detail. :) lol..

btw, who mentioned anything about being fired? I certainly didn't?...

anyway. what Adam said (thank you Adam).

just as a point of fact, I said you could build a WordPress plugin that allowed one to create holochain app using WordPress ui, post types and validation code. which would work alongside some implementation of a PNDHT node implementation. I fink there is a prett clear parallel between the schema / dna stuff in the holochain code base. point being the analysis of the need to have a complex internal "dna".structure that prohibits the proticol being federalised in the first instance.

as to "how can it be vendor lock in" there is loads of detailed discussion about that, I fink it's clear the question isn't rhetorical, at least to me.