# org.cannadb.like

> Published by [cannadb.org](https://lexicon.garden/identity/did:plc:lrtzzib3ycggsodkfidzuorw)

✓ This is the authoritative definition for this NSID.

## Links

- [View on Lexicon Garden](https://lexicon.garden/lexicon/did:plc:lrtzzib3ycggsodkfidzuorw/org.cannadb.like)
- [Documentation](https://lexicon.garden/lexicon/did:plc:lrtzzib3ycggsodkfidzuorw/org.cannadb.like/docs)
- [Examples](https://lexicon.garden/lexicon/did:plc:lrtzzib3ycggsodkfidzuorw/org.cannadb.like/examples)

## Definitions

### `org.cannadb.like`

**Type**: `record`

A lightweight engagement signal — the publisher's like of another CannaDB record. Likes are the polymorphic-subject pattern: one record type covers multiple subject collections via an additive allowlist on `subject`. For v1 the allowlist is `org.cannadb.strain` and `org.cannadb.review`. Future indexable record types (e.g., grows, lists) get added to the allowlist additively without a lexicon revision; consumers gracefully ignore likes pointing at unknown collections. The AppView aggregates likes per-subject into counts and trending signals; like records do not carry counts themselves. CannaDB's social-signal pattern is to add new lightweight engagement features by extending the `subject` allowlist before authoring a new record type — "is this a like with different display, or something genuinely new?"

**Key**: `tid`

| Property | Type | Required | Description |
|----------|------|----------|-------------|
| `subject` | `string` (at-uri) | Yes | AT-URI reference to the subject being liked. v1 allowlist: `org.cannadb.strain` and `org.cannadb.review`. Future allowlist additions are forward-compatible — consumers ignore likes whose subject is not currently in their allowlist rather than rejecting them. (The lexicon spec does not enforce collection constraints on at-uri; consumers must inspect the AT-URI's collection segment and apply the allowlist at ingest time.) |
| `createdAt` | `string` (datetime) | Yes | Client-declared timestamp when the like was created. |

## Raw Schema

```json
{
  "id": "org.cannadb.like",
  "defs": {
    "main": {
      "key": "tid",
      "type": "record",
      "record": {
        "type": "object",
        "required": [
          "subject",
          "createdAt"
        ],
        "properties": {
          "subject": {
            "type": "string",
            "format": "at-uri",
            "description": "AT-URI reference to the subject being liked. v1 allowlist: `org.cannadb.strain` and `org.cannadb.review`. Future allowlist additions are forward-compatible — consumers ignore likes whose subject is not currently in their allowlist rather than rejecting them. (The lexicon spec does not enforce collection constraints on at-uri; consumers must inspect the AT-URI's collection segment and apply the allowlist at ingest time.)"
          },
          "createdAt": {
            "type": "string",
            "format": "datetime",
            "description": "Client-declared timestamp when the like was created."
          }
        }
      },
      "description": "A lightweight engagement signal — the publisher's like of another CannaDB record. Likes are the polymorphic-subject pattern: one record type covers multiple subject collections via an additive allowlist on `subject`. For v1 the allowlist is `org.cannadb.strain` and `org.cannadb.review`. Future indexable record types (e.g., grows, lists) get added to the allowlist additively without a lexicon revision; consumers gracefully ignore likes pointing at unknown collections. The AppView aggregates likes per-subject into counts and trending signals; like records do not carry counts themselves. CannaDB's social-signal pattern is to add new lightweight engagement features by extending the `subject` allowlist before authoring a new record type — \"is this a like with different display, or something genuinely new?\""
    }
  },
  "$type": "com.atproto.lexicon.schema",
  "lexicon": 1
}
```