org.cannadb.like

cannadb.org

Documentation

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

main 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?"

Record Key tid Timestamp-based ID

Properties

createdAt string datetime Required

Client-declared timestamp when the like was created.

subject string at-uri Required

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

View raw schema
{
  "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?\""
}

Lexicon Garden

@