# social.coves.community.acceptance

> Published by [coves.social](https://lexicon.garden/identity/did:web:coves.social)

✓ This is the authoritative definition for this NSID.

## Links

- [View on Lexicon Garden](https://lexicon.garden/lexicon/did:web:coves.social/social.coves.community.acceptance)
- [Documentation](https://lexicon.garden/lexicon/did:web:coves.social/social.coves.community.acceptance/docs)
- [Examples](https://lexicon.garden/lexicon/did:web:coves.social/social.coves.community.acceptance/examples)

## Definitions

### `social.coves.community.acceptance`

**Type**: `record`

A community's attestation that it accepts a post. Written only by the community's key holder, automatically once admission checks pass - machine attestation, not human approval. The community is implicit in the repository this record lives in. The record key is deterministic: the unpadded lowercase base32 encoding of the SHA-256 digest of the canonical subject AT-URI (fixed 52 characters, always rkey-safe), so a post has exactly one acceptance rkey per community, concurrent writers converge idempotently instead of allocating duplicates, and re-acceptance after an author edit is an update of this same record in place. Repo placement attributes authorship as vouched for by a verifying relay or a direct DID-resolved PDS fetch; firehose events themselves carry no commit-signature proof. If the author deletes the subject post, the community host deletes this acceptance on observing the tombstone; consumers treat an acceptance whose subject is gone as inert.

**Key**: `any`

| Property | Type | Required | Description |
|----------|------|----------|-------------|
| `createdAt` | `string` (datetime) | Yes | Timestamp when the post was accepted |
| `subject` | `ref` → `com.atproto.repo.strongRef` | Yes | Strong reference to the accepted post, pinning the exact accepted version. If the author edits the post the CID no longer matches and the post is pending re-acceptance; clients and AppViews MUST NOT auto-render the new CID under the old acceptance. |

## Raw Schema

```json
{
  "$type": "com.atproto.lexicon.schema",
  "defs": {
    "main": {
      "description": "A community's attestation that it accepts a post. Written only by the community's key holder, automatically once admission checks pass - machine attestation, not human approval. The community is implicit in the repository this record lives in. The record key is deterministic: the unpadded lowercase base32 encoding of the SHA-256 digest of the canonical subject AT-URI (fixed 52 characters, always rkey-safe), so a post has exactly one acceptance rkey per community, concurrent writers converge idempotently instead of allocating duplicates, and re-acceptance after an author edit is an update of this same record in place. Repo placement attributes authorship as vouched for by a verifying relay or a direct DID-resolved PDS fetch; firehose events themselves carry no commit-signature proof. If the author deletes the subject post, the community host deletes this acceptance on observing the tombstone; consumers treat an acceptance whose subject is gone as inert.",
      "key": "any",
      "record": {
        "properties": {
          "createdAt": {
            "description": "Timestamp when the post was accepted",
            "format": "datetime",
            "type": "string"
          },
          "subject": {
            "description": "Strong reference to the accepted post, pinning the exact accepted version. If the author edits the post the CID no longer matches and the post is pending re-acceptance; clients and AppViews MUST NOT auto-render the new CID under the old acceptance.",
            "ref": "com.atproto.repo.strongRef",
            "type": "ref"
          }
        },
        "required": [
          "subject",
          "createdAt"
        ],
        "type": "object"
      },
      "type": "record"
    }
  },
  "id": "social.coves.community.acceptance",
  "lexicon": 1
}
```