Requirements for a protocol for agent-centric P2P economic networks

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.