[Proposal] Standardize Communities' Approach to Attestations as first WG Output

[essentialrandom.bsky.social]

Hello folks, I’m just back from sync’ing with @baldemo.to about where we’re at and next steps. They’re compiling the information collected from interviews (thank you all who joined—Baldemoto included!—for your time), and in the meantime, we have a proposal for a first item to come to an agreement on: attestations.

Proposal: Standardize Communities’ Approach to Attestations as first WG Output

Attestation = a community-issued, independently-verifiable trust certificate towards another entity.

Note: not to be confused with the payment-attestation work in the Attested Network WG—we’re open to converging on another name (e.g. certificates), but are leaving it for future discussions.

Here’s why we believe this makes for a good first item, despite not being the most pressing:

• We have a lot of more complex and nebulous standards work ahead of us, but have not yet truly come together as a WG. Walking first will make it easier to run.
• Most communities here have their own implementation of attestations, or have expressed a need/interest for them.
• There is already an initial tested attestation-adjacent lexicon currently being formalized in this forum: community.lexicon.badge.

Deliverable: Patterns + Use Cases ⇒ Lexicons + Best Practices

We propose the output of this Working Group to be 2 sets of items:

• A Use Cases + Patterns Document: outlines what attestations are, what purpose they serve, patterns of usage from both communities and their members, and the general flow of operations for common cases (see below for details).
• A Set of Lexicons and Associated “Best Practices”: a shared language communities can use to interact with attestations, and a set of recommendations for those interested in adopting and leveraging them (informed by the previous document).

Initial Document: Patterns + Use Cases

This is our brainstorming (open for feedback) of a set of questions this WG should answer. @baldemo.to’s first step will be to use what was collected during interviews to answer these through existing patterns. This will help come to a shared understanding of where the ecosystem is at, and kickstart further discussion ahead of a formalization.

Our questions:

1. What are the categories of attestations communities wish to issue?
2. How these attestations can be used (by communities and the larger ecosystem)?
3. How are attestations displayed or signaled, both by communities and individuals?
4. Who can see these attestations, and who gets to “use” them? (including the intersection with permissioned data)
5. How are attestations assigned, and how are they accepted, if they are?

We believe this topic is well-suited to a first deliverable, and that we’ll quickly be able to formalize it as a lexicon.

With that, we can move to…

Future Step: the “Middle Entity”

A strong signal that surfaced from interviews is that many community implementations are circling around the idea of a “middle entity”—an external(?) arbiter with the permission to “broker” the writing (and, eventually, sharing) of data on behalf of the community.

Once the attestations effort is underway and (we hope) proceeding smoothly, we intend to reuse the same template to explore this concept and come to a formal recommendation. In the meanwhile, our plan is to begin understanding and teasing apart the various implementations. To that end, I’ve already committed to lead a more public “understanding and discussion session” about the Arbiter pattern proposed by @zicklag.dev, and associated Lexicons. If that’s successful and useful, I’d be happy to lead more and help explore other patterns.

What Done Looks Like

[This section is intentionally placed to stress that attestations being “done” is not a blocker for “middle entity” discussions]

We believe this WG should consider the Attestations proposal done when:

• The patterns doc is “sufficiently complete” and publicly available
• A set of lexicons (and associated “how to”) is published, and…
• At least N communities have committed to adoption (Lexicon Community suggests N=2, but we’d ideally have more)

Timeline and Next Steps

With this post, we’re formally asking for a buy-in signal or feedback on our proposed approach. Once agreement is reached and we know who’s “on board”, we’ll fill the Working Group Template, and publish a more defined timeline with associated dates.

Let us know what you think,
Ms Boba & Baldemo.to

[baldemo.to]

Hey all! Just quickly co-signing here. I’m planning to make a longer post about this direction that I’ll post on my Leaflet after I process all of my notes this weekend, then I’ll start filling out some comparative analyses.

While there were many differences in implementations (as expected), there were several points of productive convergence to work from. In particular, a few things stood out:

• A general acknowledgement that governance decisions and enforcement must be delegated by necessity for any cogent community implementation. There is no such thing as a zero-trust community; the question is what shape the delegation of trust takes.
• The pattern of communities as DIDs. This is the major locus of convergence I noticed among projects targeting large-scale community infra. Projects that bucked this have fundamentally different scopes/design intent (e.g. Acorn with full-stack implementations, Mezzanine/Habitat small-scale interaction patterns)
• Cryptographically verifiable certificates/attestations of mutual consent. This is directly enabled by the communities-as-DIDs pattern.

Outside of these, the divergences are largely in terms of either data architectures or design intent itself. This aids in surfacing truly generalizable patterns (as above). But it also means significant work in disentangling what use cases and patterns should be in-scope for a WG, and which should not.

So why start with attestations? Well, it’s a common pattern of convergence that’s simple in concept while enabling massive affordances. After all, what’s an attestation but a two-way label?

I’ll be preparing a longer writeup on this topic soon, with a more precise initial ontology of the existing use cases and design constraints to account for. But we’d love to hear everyone’s thoughts on this as an initial deliverable to work from!

[zicklag.dev]

This sounds good and well reasoned.

Attestations isn’t something I’ve directly thought about very much, and I’m somewhat wary of committing to more specing work when I’ve already got my hands full a bit with the group stuff / trying to get Roomy going with, but like you say this does sound like a good start generally as far as a working group goes.

[essentialrandom.bsky.social]

As I was mentioning to @baldemo.to, I think Attestations is also a good way to start talking about membership and whether that is just a special case of that or (more likely) its own separate mechanism.

We haven’t formally discussed this, but “throwing out there a personal thought” this makes sense to me as an initial bundle of real value for communities:

• Attestations: What should communities use them for? What use cases where they’re tempting actually need different handling?
• Membership primitives: How is membership (likely its own case) represented? How is it assigned? What primitives are needed?
• The “Middle Entity”: How is community data (starting with the use cases above) written and accessed in practice?

(edit: to clarify, I don’t mean to expand the original scope. Just pointing out that “membership primitives” naturally slot with the topic, and will likely begin to take form alongside it.)

I’m happy to do specing work for Attestations, as I’ve already done some. The intention here is mostly to understand how they relate to communities—and obviously making sure that my initial spec does work for such an important use case.

As a more general question, I would love to hear people’s thoughts on what they’d like to get agreement on as a (working) group in the longer term. I’m going to make a different thread though, so this can stay focused on this specific discussion.