Hello! Continuing with our walk through Spritely's Technical Values and Design Goals, today's is "networks of consent": https://spritely.institute/about/

This one expands the vision of "secure collaboration", which we discussed yesterday, and ties together both social and technical goals! 🧵

Let's go through the definition on our About page, linked above, and then we'll expand on its history and goals:

> The cooperation mechanism we use is capability security, which allows for consent-granted mechanisms which are intentional, granted, contextual, accountable, and revocable.

"Networks of consent" cotd:

> Rather than positioning trust as all-or-nothing or advocating for "zero trust" environments, we consider trust to be something fundamental to cooperation. We want individuals and communities to be able to build trust to collaborate cooperatively together.

The origin of this phrase came from a writeup by our Executive Director @cwebber in "OcapPub: Towards networks of co1nsent" https://gitlab.com/spritely/ocappub/blob/master/README.org

This document described limitations of the present-day fediverse, as well as beginning to sketch how to overcome them.

Fundamentally, we believe in consent-based flows. As it turns out, capability security is an excellent mapping to about as much of consent-based flows as can be mapped into technical systems.

Consent is not wholly a technical problem, so a proper system combines tech with social flows.

For consent to flourish, trust must flourish also. This is why we reject the term "zero trust systems": we see trust as necessary and fundamental to any cooperating society.

However, trust cannot be injected into a technical system: consent is something built between people and communities.

In many ways, OcapPub's vision of "networks of consent" was an attempt to quickly capture as much of the description of how a more consent-based system could be mapped onto the present-day fediverse from visions already-in-progress in the development of Spritely's technology.

However, we found that the primary roadblock for OcapPub was the very reason Spritely began as a research project in the first place: it's too hard to build the systems we're describing on top of eg Django, Rails, Node, etc.

We need new architecture where these designs are natural!