Requirements for a protocol for agent-centric P2P economic networks

My personal focus on this topic will be ActivityPub. If I focus on Holochain, there's too much already decided. In AP, not so much. I sketched out a tentative architecture for economic networks in AP at https://github.com/valueflows/vf-apps-agents/issues/1#issuecomment-456105864

ActivityPub will need something like the quantum probability field that @christopher7 is thinking about, but doesn't have so much of it defined and in process of development yet.

So it's more of a clear quantum probability field... :sunglasses:

Another reason for focusing first on ActivityPub instead of Holochain, SSB or Solid, is that I think the coding skills required for AP will be more common than those required for any of the other candidates.

Here's a list of tested implementations, and they keep coming all the time: https://activitypub.rocks/implementation-report/

One of the reasons the early Web took off was view-source, copypasta, learn a little HTML. I want the economic web to be similarly easy to plug into. Don't know if it can be as easy as the early Web, but that's my goal.

@christopher7 commented in that other thread,

there is another channel on loomio, now, which is for working on the specification of a PNDHT as an open project. personally I’m not comfortable putting out furtherspecifics without someone from Holo involved in the conversation, given my clear history as an employee there.

I assume he means this channel. I am deliberately starting over without copying Holo, and want to start by specifying the requirements that prompted the Holo PNDHT. I think a different design and implementation is possible in ActivityPub, but can't tell until the requirements get defined.

I don't expect people from Holo to help in that effort.

However, I am most likely not qualified to define those requirements, and so will be seeking help. We are working toward an AP economic network framework (as well as Holo and SSB), and will need to do it anyway.

The SSB crew includes people who understand all this stuff and so will not need any help from this thread, altho maybe we can get some help from them...

Aye, Im not trying to be difficult, Im just trying to be careful about respecting other people's work. I would feel more comfortable if @pauldaoust1 was involved in the conversation so that anything that has come from Holochain, that might be useful from that project, can be fed back into it.

He'll either get involved or I will point him to anything that anybody thinks should be fed back.

But @christopher7 I understand and respect your carefulness.

Who's interested in this topic? And of those who are interested, who feels like they know enuf to participate in defining requirements?

I need to do this anyway, sooner or later, for our ActivityPub track, but I am trying to gauge its current priority vs other work on my plate.

im interested. I am busy. Certainly I have the skills... I dont know how to move forward .As usual in this space, everything seems to become vague and about "disagreement", rather than clear and about technology.

Be prepared to have your predictions come true

ᐧ

I think I know how to move forward. Don't assume I will be vague and about "disagreement" until it happens.

But I intend to move forward first with requirements that could be implemented in more than one technology. Like tamper-evident, non-repudiation, and requirements from threat assessments. And some of those requirements will need to be interpreted along with with the other requirements I listed previously. Like, consensus is easier if everybody uses the same database with good transaction controls (or the same blockchain), but that will not be the case.

I'm also open to suggestions of improvement for any of the requirements I have listed anywhere.

Re disagreements, I plan on using Loomio's polling and voting features to see where we are at, depending on how many people join this conversation.

As for timing, I would start when anybody wants to start with me. Until then, I know I need to do this sooner or later but it won't be high on my current priorities.Yet.

That sounds perfect Bob. Ill be around. Lets give it some time to see what comes out of Holochain about this stuff. And then we can look at the specific requirements of agent-centric truth proving in a decentralised manner
Be prepared to have your predictions come true

ᐧ

Chris, what are we supposed to be making of this mysterious "be prepared to have your predictions come true" comment?

it's my email signature.

try to stay grounded, in general, unless you are doing it for fun. it's relatively easy to do if you know what you are doing for yourself, and so the work to be clear about it to others

Who's interested in this topic?

Totally fascinated @bobhaugen :D But sadly, no technical skills whatsoever in this domain. I hang in here to learn more about the politic of 'protocolling', which is foundational. Looking forward to seeing you sklilfully chewing your way thro this Bob! Probably without needing to read read Pirsig?

@mikeh8 thanks for hanging in. And yeah, protocols are foundational, good word choice.

I make no promises about skill, I have a little knowledge of the requirements for consistency, validity, honesty, etc, in distributed systems, but you know what they say about a little knowledge...

I am studying and talking to people who have more.

Same here Mike - no technical knowledge but plenty of enthusiasm - so you're in good company (at least I'd like to think so)! :-) ;-)

I'm interested. My participation is time-limited and technically limited, since I don't code software and I'm only weakly familiar with ActivityPub and the existing WWW protocol stack which you want to interface with. With that said, thanks much @bobhaugen for focusing on the immensely important issue of agent-centric communications protocols!

BTW I haven't read all docs & links related to this topic, but this article quote caught my eye:

ActivityPub doesn’t support fine-grained access control checks, e.g. I want someone to be able to see my posts but not respond to them

^ I think that's a big problem. Separately-identifiable media resource access and edit rights are essential to all of my community models. I guess however that that ActivityPub limitation can and probably will be fixed eventually.

General personal context: I focus mostly on human-to-human protocols, such as Inclusive Network Governance Framework, which could interface (directly or indirectly) with computing protocols. My most relevant interests here are agent-based protocols for developing digital collective IDs, collective resources (including apps and protocols), and collective resource versioning systems. These interests are reflected in my conception of a collective resource description framework which can, theoretically, hold any digital media, supported (and updated) by any collective. This "CRDF" is conspicuous in my P2P Modular Organizing Framework model. Another prominent concept there is the distributed app, because I think that distributed computing (signaling, processing and hosting) is practically necessary to sufficiently support the inclusive p2p communities which I believe we'll all need.

IMO, another big element of effectively developing agent-centric p2p information will be something like Collective Media Markup Language. However, I doubt that much of CMML (or anything like it) should be built directly into a basic comms protocol. Most of it can and probably should be developed to add as a separate layer to data-items and their RDF annotations (which would include all machine-readable semantic links).

I perceive Bob that you're focused here on developing a requirements list for a p2p protocol which we'd all want. FWIW, the general technique I suggest for identifying shared design goals and agreements is based on Inclusive Design Framework. (Needs work though; as does Inclusive Network Governance!) I know you've seen that, but fyi (for everyone), some IDF elements:

1. Identify and discuss each peer's positive and negative requirements and recommendations for the conceptual and structural features of the product (which can be a good, service or shared activity.)
   • negative requirement= prohibition; negative recommendation= dislike
   • Conceptual features are more basic than structural features. Structural features, including hierarchy, organize a product by developing components to (hopefully) support its overall conceptual features.
2. Gradually clarify a mutually approved list of wanted and needed conceptual and structural features of the product.
3. When #2 is reasonably stable, any number of designers (persons or teams) could research & develop compatible prototypes.
   • People can & probably will do R&D work before #2 happens. #2 is simply, IMO, highly advisable to reduce social risks, such as excessive commitment to deeply conflicting approaches.
4. Each designer should engage the community via FYI and RFC announcements.
5. If a designer seeks the full support of any specific collective, launch a formal proposal to approve a specific finished prototype as a collectively endorsed (and possibly co-governed) product.

Hope that's helpful co-creative framework.

I like to imagine that if we (or any group) can develop a stable compilation of mutually approved conceptual and structural features, we will effectively identify (in Bob's words) "a meta-protocol" where ActivityPub, ssb, Holochain, and more can all beneficially operate. I sure hope so!

@gregorycassel

this article quote caught my eye:

ActivityPub doesn’t support fine-grained access control checks, e.g. I want someone to be able to see my posts but not respond to them

^ I think that's a big problem. Separately-identifiable media resource access and edit rights are essential to all of my community models. I guess however that that ActivityPub limitation can and probably will be fixed eventually.

Christopher Webber, one of the people who worked on the standard, is also working on access controls
https://dustycloud.org/blog/spritely/

The main dev of Pleroma, who has disagreed with Christopher a lot in the past, seems to agree roughly on the approach, but of course, devils in details:
https://blog.dereferenced.org/what-would-activitypub-look-like-with-capability-based-security-anyway

Replying to myself, one of the diffs between ActivityPub vs Holochain and SSB is ActivityPub is a published standard with several different implementations while SSB and Holo either do provide, or intend to provide, whole integrated software suites for a unified user experience.

There are strengths and weaknesses in both approaches.

SSB also provides a published protocol and people are working on alternative implementations, but it remains to be seen how well they will all interoperate.

Several of the ActivityPub implementations are already interoperating.

The downside of AP (published spec with many implementations) is that the people developing the different implementations, while they do interoperate, also disagree about some under-specified details and also about how to move forward. Some of this is because AP is a generalization spec, derived from several different previous protocols, as you can read about here https://dustycloud.org/blog/on-standards-divisions-collaboration/

And some of this is because the people who worked on the standard did not agree with each other on some of the details, as you can also read in that article.

Creating a standard is hard but necessary work.

so the fractal space of each app being... an individual organism is that each group of people have a vision. the various interpersonal tools are equally important as the formalised expression as validation rules.

the progressions from one to the other are part of the responsibility of the group, not the software.

the simplicity of expression is available to each community as a set of choices, supported by their tech people.

the mechanism of "truth of honesty"is not limited to a sense that someone can be honest for a while, and then lie later. the pndht mechanism is more robust than that.

the core intention is to create a mechanism by which small agreements can grow. currently that mechanism is supported by (in most cases) by some sort of socially acceptable "formal" third party trust mechanism. but actually as it turns out, that mechanism had become less and less supportive of emergent concerns.

better software tools could help.

Assume that the group of people has computer-readable models of:
* their organizational structure and relationships, along with some parameters about how those relationships work;
* their governance agreements and rules;
* their explicit agreements about all economic exchanges with other agents;
* in a framework that understands economic interactions.
* And so do all of the other agents in their economic network.

How much could that help with the trust mechanisms you have in mind?

depends on the level of ideology on decentralisation

also on the size and market awareness of the organisations involved

if "full" decentralisation, and "unknown entities", then legal kyc is very valuable

without even that, "time of existence" becomes a significant factor

I suggest that people who want to be part of such mechanisms rent cloud space as part of their "natural" PERSON

I suggest that people who want to be part of such mechanisms rent cloud space as part of their "natural" PERSON

That's part of our intended architecture for ActivityPub

https://apps.nextcloud.com/apps/social is now offering one-click installs of ActivityPubs. We'll be talking to them soon.

if "full" decentralisation, and "unknown entities", then legal kyc is very valuable

Yup. Most of the groups we work with are relatively known to and trust each other, but that won't always be the case.

so the sense of "third party authority" decomposes into the fractal of individual truth...

the larger the molecule, ... have you read "Lila" by Robert Pirzig

One other factor is a whole network can be a scope and have its own database of all interactions that mention it. It's another space for rules and validations.

the larger the molecule, ... have you read "Lila" by Robert Pirzig

Nope. Should I? Would it help in this conversation?

it's a pretty amazing decomposition of the idea of free will and quantum interaction. as a novel. I think it's useful. wonderful book.

I use that when viewing this stuff from a wide angle.

so, branches between different "networks" seem reasonable. I guess the most obvious question to me is, "are the branches the same kinda thing as people/agents, or a different kind of thing". I intuit that a properly designed network should be able to address data in other networks?

@christopher7 does this anywhere relate (branches) to ppl inventing memetic currency in between other currencies to monetize ideas?

Did you have any contact with Ronen through the Holochain Mattermost community @christopher7 ? He's a huge fan of Robert Pirsig and writes about his ideas on his website www.iamronen.com You might like to check it out to get a bit of a taster @bobhaugen He's best known for his first book Zen and the Art of Motorcycle Maintenance which is a "cult classic."

Ronen is an excellent person.

no my mattermost account and chat history were deleted.

I look forward to working with him in the future, as I am sure will come to pass. he has and is doing good work on himself, and lives in the real world.

I had a brief amount of contact with him and really like him too. It doesn't surprise me at all that the two of you get on though I'm pleased, certainly. As regards working with him please keep me in the loop if anything like that should come to pass as I might like to be involved if there was a role for me.

I know who Pirsig is and read some of Zen and the Art of Motorcycle Maintenance when it was popular with some friends a long time ago. I like zen dishwashing and zen firewood splitting. Am a little resistant to getting too cosmic with this protocol stuff, but could always be wrong.

I never read art/zen/mc, but to me lila, it's very concise, using the metaphor to ground some very deep ideas. it doesn't feel crazy cosmic to me. tell me what you fink if you read it

@christopher7

it doesn't feel crazy cosmic to me.

That's re-assuring.

@christopher7

branches between different "networks" seem reasonable. I guess the most obvious question to me is, "are the branches the same kinda thing as people/agents, or a different kind of thing".

I think branches would be either declared relationships between agents or resource exchanges without a declared relationship.

I intuit that a properly designed network should be able to address data in other networks?

You could address agents, if they are available thru federation, but addressing data could require a capability, which could be received from an agent in the other network, or could be available on request from a federated agent.

Linked open data would be another possibility but would need to be published by an agent in the network, which could be the network itself according to its agreed-upon rules.

This stuff gets snaky and we don't yet have enough experience with it to figure out all the angles. I wrote about some of the angles in the context of Sensorica in 2012: http://valuenetwork.referata.com/wiki/How_internal_exchanges_and_schedules_must_work_in_a_value_network

ok. thanks I'll look into it. I think what you say about branches makes sense. travel meetings with education people in Finland this week.

@christopher7 and all: I am studying this right now: Keeping CALM: When Distributed Consistency is Easy.

I just read that - thanks - although, I'm not certain it gave me any great "Aha!" moment; more the "vaguely interesting" feeling :wink:

I note, however, that there appears some momentum behind Bloom, the programming language that CALM paper promotes. Indeed, this paper on the subject seems to have attracted a fair degree of interest...

"latching point"

"simplicity of freedom vs scope of power" - "electron to organic molecule"

Forgive a n00b question, but where's the best place to start reading about ActivityPub?

ps. just ordered Lila :) Thanks for the recommendation, @christopher7 !

@stevehuckle

where's the best place to start reading about ActivityPub?

https://activitypub.rocks/
This might also help: https://fediverse.party/
AP was an attempt to standardize a protocol coming from several other protocols mentioned in that diagram. They all more-or-less federate with each other, and some of them have now implemented AP, altho there remains some unhappiness about the standard (as always...)

To continue about AP: in terms of the criteria I listed in the heading, it is a protocol, and several independently-developed apps are using it, and they do now interoperate.

It is not inherently agent-centric, but can easily be made so.

It does work on the Web.

It does not satisfy any of the other criteria. Yet.

Thanks, @bobhaugen

I suggest reading lila to create an out of band communication tool.

doesn't matter, but it's short and not weird, and very specifically on point

Me too! And yes, thanks @christopher7 It's going to be a fun discussion methinks! :-) ;-)

I suggest reading lila to create an out of band communication tool.

What does that mean?

A tool to aid communication, as in the metaphor of it, that is "out of band" as in about a different subject than the core disucussion

A useful metaphor
Be prepared to have your predictions come true

ᐧ

Here's a scenario that might test whether a distributed P2P protocol and application software could handle the requirements for an economic network: https://github.com/valueflows/valueflows/blob/master/use-cases/who-spoiled-the-yogurt.md

I said in that use case that Holochain could handle the requirements, but I am not yet sure of that. I'm pretty sure that ActivityPub and Scuttlebutt will require some extensions.

ok. I'm on an overnight bus, meetings throw and Saturday... will hope to be around next week.

by "holochain" do you mean what they are describing they are doing, or what they have done?

@christopher7

by "holochain" do you mean what they are describing they are doing, or what they have done?

I mean, we have an active Holochain project in motion, and I will learn more about how it all works and can probably have a better idea of whether they can handle those requirements or not. But your analysis would probably be better.

I just thought it was a sorta fun use case and it had some good examples for ValueFlows and maybe for local "truth telling".