Messages

Buzzer has an optional on-chain messaging tier. Most messaging is expected to run off-chain through a relay; this is the opt-in path for when you want permanence, censorship-resistance, and provable authorship written directly to the chain.

Sending

sendMessage(from, to, bytes32 settings, bytes content)   // requires MESSAGE on `from`

• from is the authenticated sender uid — unforgeable, which is the whole point of the on-chain tier. The acting address must hold the MESSAGE permission for from (separate from POST).
• to is either a user uid or a community id — a bit in settings says which. It is not validated, so you can message any id.
• content is opaque bytes, usually an encrypted envelope.

Message(uint256 indexed from, uint256 indexed to, bytes32 indexed settings, bytes content)

All three ids are indexed, so a light client can build an inbox straight from logs with no indexer at all — filter on to == myUid (or a community id) and you have your messages.

User to user, user to community

The same call covers both directions. A one-bit flag in settings distinguishes a direct message to another user from a message posted to a community, so group and one-to-one messaging share a single primitive.

Encrypted and plaintext

content can be plaintext or an encrypted envelope — the contract does not care, it just records bytes. For private messages, clients encrypt before sending and put the envelope in content; settings bits declare the scheme so the recipient's client knows how to decrypt. Because the payload is opaque, the encryption format is a client convention and can improve over time without any contract change.