Part of Stem. This page defines the contact kind: one account's public statement about another account. Contacts are how the address book, the follow lists and the "members" of a space are expressed. The formal schema of this kind's state is attached as the schemaDefinition of this page.

Descriptor

{
  "name": "Contact",
  "description": "One account's statement about another: a name, a follow, a join.",
  "state": "snapshot",
  "schema": "hm://z6MkiAKDcRSzQ4zPZfnJcS5HYx5MwgN6MU9foHihJGrhqNBj/stem/kinds/contact/value",
  "naming": "unnamed",
  "children": false,
  "access": "inherit",
  "retention": "latest",
  "links": [
    { "path": "/subject", "kind": "target" }
  ]
}

State

field	type	required	meaning
`subject`	principal	yes	The account this contact is about. A principal in a `target` position names that account's space root.
`name`	string, at most 256 characters	no	The name the author uses for the subject.
`follow`	boolean	no	The author follows the subject's updates.
`join`	boolean	no	The author has joined the subject's space as a member.

Rules

A contact is an unnamed node under the author's root. Its readers are inherited from the author's root, so contacts in a public space are public and contacts in a private space are private to its members.

Contacts grant nothing and change no reader set. A join is how an account accepts a role it was granted: the authority graph decides what the account may do, and the contact decides whether the client treats the account as a member who wants that space's updates.

The subject emits a target link to the subject's root. That is the edge the members list, the followers list and the trusted peer rule read. Inbound contacts are part of the authority facet of a space's scope set, so a peer syncing a space learns who joined it.

One contact per subject per author is a convention, not a rule; a client replaces an existing contact by publishing a new Snapshot with prev.

follow and join are inputs to the default sync policy: a client that sets join normally also adds a follow rule for the subject's space. The daemon never turns a contact into a rule by itself.

Today (HM24)

The Contact blob carried id (TSID on updates), account (when a delegate signed), subject, name and subscribe{site, profile}, and an empty subject was a tombstone. Contacts were always public. Under Stem subscribe.site is join, subscribe.profile is follow, the TSID is the node id, deletion is a tombstone Node, and account disappears because a delegate writes through a grant.

Example

{
  "type": "Snapshot",
  "signer": { "/": { "bytes": "7QFo…" } },
  "sig": { "/": { "bytes": "…" } },
  "ts": 1759902000000,
  "schema": "hm://z6MkiAKDcRSzQ4zPZfnJcS5HYx5MwgN6MU9foHihJGrhqNBj/stem/kinds/contact/value",
  "value": {
    "subject": { "/": { "bytes": "7QHm…" } },
    "name": "Starlight",
    "follow": true,
    "join": true
  }
}

{
  "type": "Node",
  "signer": { "/": { "bytes": "7QFo…" } },
  "sig": { "/": { "bytes": "…" } },
  "ts": 1759902000000,
  "kind": "hm://z6MkiAKDcRSzQ4zPZfnJcS5HYx5MwgN6MU9foHihJGrhqNBj/stem/kinds/contact",
  "parent": "bafyreiujzdegxdncf32epf3dhodzdocis2jhtlgmxgedn73u55xtplpft7",
  "target": { "kind": "snapshot", "snapshot": { "/": "bafy2bzacej…" } }
}

Descriptor

State

Rules

Today (HM24)

Example

See also