That's it for today's tech value! Tomorrow's builds right off of where we left off, at "user empowerment and fostering agency"!

If you find yourself aligning with our technical values, as a reminder we're running a fundraising campaign, maybe pitch in! https://spritely.institute/donate/

Cya tomorrow!

Thus it is also important, both in terms of safety, but in terms of interactive features, that our platforms be extensible. Many different communities may also wish to extend our platform in different ways we could not possibly anticipate, and we should support and encourage that!

What is important is that we allow tooling for communication to be contextualized and for different kinds of communities to form, self-govern, and protect their users.

We cannot provide all the rules and expectations for all communities, but we can provide tooling to keep communities safe.

The needs and expectations of different communities vary widely depending on the needs and context of their community. The rules and needs of a visual effects demoscene celebration community may be very different from that of an ocular migraine support community, for instance!

Let's start with the definition of "healthy communities" from our about page: https://spritely.institute/about/

> We must build tech that allows communities to self-govern according to their needs, which vary widely from community to community. We may not know all of these needs or mechanisms required for all communities in advance, but we should have the building blocks so communities can easily put them in place.

Continuing with our "Technical Values and Design Goals", today's is "healthy communities"! https://spritely.institute/about/

Of course, "healthy communities" isn't something we can design ourselves, but it's something our tech can help enable, value, and plan for! 🧵

That's it for this value today. If what we're speaking about aligns with you morally, technically, and philosophically, consider supporting Spritely! https://spritely.institute/donate/

See you tomorrow where we will talk about our next value: "healthy communities"!

This is one of the reasons Spritely's tech has been so research-oriented. To deliver the social world ("networks of consent") we want to see online, we also need new technical foundations.

And that's what we've been doing in Spritely: "networks of consent" are a natural fit within our systems!

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!

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.

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.

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.

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.

"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.

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.

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! 🧵

Tomorrow we'll talk about the high level conceptual model for secure collaboration we use in Spritely's technology.

Talk to you then, and thanks to everyone who's supported us so far! https://spritely.institute/donate

People collaborate in many different ways; one way is in communication and discourse. But we also want to build the worlds we want to live in together.

Why should we have only certain categories of software which are considered "social"? Our day to day lives involve social collaboration!

The goal of Spritely's tech is to allow *all* software to be able to be easily social and distributed. This requires new foundational work.

Our About page defines "secure collaboration" as:

> *Secure collaboration:* Spritely's work is to enable safe cooperation between individuals and communities in an unsafe world. We are building tools to make this possible.

This includes decentralized social networks. But that's just a start!

Many new people are discovering us since the launch of our supporter campaign (thanks to all who have supported us so far!) https://spritely.institute/donate/

For the next few days we're going to go through each of our Technical Values and Design Goals. https://spritely.institute/about/

Today's is "Secure collaboration". Let's talk about what that means to us!