Requirements for a protocol for agent-centric P2P economic networks
Bob Haugen
Public
Seen by 117
Here's my current definition of agent-centric. I'll explain what I mean by protocol in this list of proposed requirements:
* Must be a protocol
* Must have an openly published specification.
* Any independently-developed software that follow the specification must be able to use the protocol to communicate with other software components that do likewise.
* Must be agent-centric, where agents can be individuals or groups, and each agent must be able to control their own identity, interactions, and data, and select their own software to use, as long as the software follows the protocol.
* Must either use a common economic vocabulary to communicate, or be able to translate their ingoing and outgoing communications into a common vocabulary.
* The protocol itself must be managed as a commons in the Elinor Ostrom sense.
* Must be able to provide reliable local [consensus](https://en.wikipedia.org/wiki/Consensus_(computer_science) among the participating agents in a scope agreed upon by the participants.
* More on this requirement in a comment.
Some people might disagree with this requirement, but
* I think, at this stage of the evolution of the general intellect, the protocol needs to work on the World Wide Web. Can provide private spaces as needed, but accessible via a Web browser.
There is no single protocol that satisfies all of those requirements at this time.
Several candidate protocols were mentioned and discussed in this previous thread. None of them is adequate by itself. Yet.
If you don't like google docs, here is an open source framapad with the same info, but without all those comments. Altho that doc is also open for comments.
I don't want to repeat all of those arguments here. I want to discuss how to move forward and assemble a protocol that does meet all of those requirements, and any others that people want to propose. At some stage of discussion, I will create a poll or two to allow people to weigh in on the adequacy of the requirements and maybe, if we are lucky, on the proposals for moving forward.
Bob Haugen Wed 16 Jan 2019 9:02PM
My personal plan is to follow all the developments in Holochain and SSB, and learn from them, but focus on adding local consensus between ActivityPubs.
The first part of that will be figuring out the data and logic requirements for individual vs group agents, and how they need to interact. I'll start that somewhere in ValueFlows and report back here with the URL when I start posting something. If anybody wants to join me in that exploration before then, ping me here.
Deleted account Thu 17 Jan 2019 5:42AM
Thanks so much for inviting me to this thread. I really appreciate the opportunity. I do not have a technical background but am working towards gaining an understanding of these topics as I recognise their immense importance
Bob Haugen Thu 17 Jan 2019 12:08PM
@adamwaterhouse I am responding to a comment from you in that other thread here, because I am done with the other one.
Can you please expand upon what exactly is meant by "application-specific vocabularies" and what pragmatic value they can serve?
https://www.valueflo.ws/ is an example of a common vocabulary for economic networks. It came out of early conversations in this Loomio OAE group.
We will use that same vocabulary for economic network projects using Holochain, ActivityPub, and SSB. And maybe Solid.
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."
We agree. I think that the economic network protocols in particular will either converge and interoperate, or those that don't will die.
Bob Haugen Thu 17 Jan 2019 3:24PM
Looks like I already started exploring the diffs between personal and group agents in this issue: https://github.com/valueflows/vf-apps-agents/issues/1
So I'll just keep going there for awhile.
If it is not obvious to you that this exploration is necessary to think about local consensus mechanisms, I hope it will be by the end.
Greg Cassel Wed 16 Jan 2019 3:24PM
I strongly agree with your analysis and requirements. Thanks @bobhaugen for concisely articulating this.
Bob Haugen Wed 16 Jan 2019 4:13PM
Re
The protocol itself must be managed as a commons
See this proposal to use federated ActivityPubs to manage ActivityPub spec changes
Christopher Sat 19 Jan 2019 10:49AM
Right. Thats the right kind of question in my opinion. I think there maybe more fundamental structures that are more dynamic and flexible. Maybe not. I have some designs in mind.
So the point of the "hashchain" as a basis for holding personal data is that it creates a sort of "quantum probabiliyt field", which can collapse - I have complete control over my sourceChain, so theoretically it can be in any state I like, and change state at any time to anything I like.. With a PNDHT, that field can collapse because enough nodes on the PNDHT hold enough of your personal sourceChain, that you cant really edit it without getting caught (the field collapses). The other way of doing that is to have real interactions with other actors cause a collapse in the chain - so there is no policing neighbourhood, but rather the network of real transactions is sufficient to collapse the state.
Each individual or organisation sourceChain collects information from many sources, and publishes it for that agent. Under GDPR style regulation, sources of data and processors of data only hold the hashes. This means that third party agents can query the various collective of agents involved in generating some entry in a source chain for the dates / times / agent of hashes of entries, and so cause waveform collapse.
I dont know Activity Pub well enough to present this in their language or even paradigm, nor SSB, but im pretty sure the twin concepts of "I own this data and have complete control of it" entails that there must be some mechanism to collapse the wave-form of uncertainty that creates to other agents.
Christopher Sat 19 Jan 2019 2:48PM
@pauldaoust1 Hi. Paul. Id very much appreciate your input on this thread. In the end, you represent the organisation with the most funding and time to develop this stuff. And at minimum it should be useful for you.
Paul d'Aoust Mon 21 Jan 2019 8:59PM
@christopher7 busy this week, but I'm going to try to revisit next week or the week after. I've made a loose commitment to be a part of this discussion, but I haven't got a firm timeframe yet.
Bob Haugen · Wed 16 Jan 2019 3:00PM
I do not have enough knowledge and experience with local consensus mechanisms to be able to specify this requirement in detail. But I wrote "local consensus" to differentiate from "global consensus" as crypto-currency blockchains seek to provide.
My personal knowledge and experience is in the planning and operation of economic networks, and the requirement for a common vocabulary, and to some extent, what such a common vocabulary should look like.