Breathe

Subjective Delegation XEP

2026-09-30T12:00:00Z

I have been interested in subjective moderation for years, but I am not very familiar with the inner workings of XMPP. Please contact me with feedback on this XEP draft. Thank you!

XEP-XXXX: Subjective Delegation for Multi-User Chat

Status: Experimental
Type: Standards Track
Short Name: subjective-delegation
Namespace: urn:xmpp:subjective-delegation:0
Dependencies: XEP-0030, XEP-0045, XEP-0060, XEP-0359, XEP-0421
Optional: XEP-0004, XEP-0128, XEP-0163, XEP-0313, XEP-0334
Author: Joseph Turner

1. Abstract

This specification defines a PubSub-based protocol for subjective delegation in XMPP Multi-User Chat rooms.

The generic protocol defines a room-scoped graph model in which participants publish decisions, delegate decision evaluation to other participants, and locally exclude participants from delegated traversal.

A: What's your favorite line from Romeo and Juliet?
B: That's too OT.  The current topic is XEP design...
A: Alas!  There is no world without Verona walls.
B: I pray thee, leave me to myself.
   *B mutes A*

This specification also defines one initial capability: mute.

The mute capability affects only local client rendering. It does not remove, ban, kick, moderate, retract, or silence any participant.

2. Introduction

Multi-User Chat moderation is objective and room-wide. A moderator’s action generally affects the room state observed by all participants.

By contrast, each participant can use subjectively delegated mute to compute their own local view of a room by combining their own mute decisions with mute decisions imported from delegates.

For example:

Alice mutes Bob.
Alice delegates mute decisions to Carol.
Carol mutes Dave.

Result:

Alice’s client locally suppresses Bob’s and Dave’s messages.
Carol’s client locally suppresses Dave’s messages.
Other participants are unaffected.

Participants can recursively gather decisions from delegate's delegates. Participants can also prune delegates from the graph with exclusion rules.

A richer example:

Alice delegates mute decisions to Carol recursively.
Carol mutes Bob.
Carol delegates mute decisions to Dana.
Carol also delegates mute decisions to Eve.
Dana mutes Fred.
Eve mutes Mallory.
Alice excludes Dana as a delegate.

Result on Alice's client:

Alice’s client locally suppresses Bob’s and Mallory's messages.
Alice’s client does not suppress Dave’s messages through Dana.
Dana and Dana’s delegates are not traversed for Alice.

This specification uses PubSub for public room graph state and update notifications. This allows clients joining a room to fetch current graph state without reconstructing it from MUC message history.

PEP may be used for private multi-device synchronization, but PEP is not used as the authoritative source for public room graph state.

3. Generic Model

Subjective delegation is modeled as a directed graph of edges.

Each edge has:

an actor,
a type,
a capability,
a room,
and, usually, a target.

The generic protocol defines edge types and graph traversal behavior. Individual capabilities define the meaning of their decisions.

4. Concepts

4.1 Actor

The identity that creates an edge.

4.2 Target

The object affected by an edge.

For delegate and exclude edges, the target is an identity.

For decision edges, the target type is capability-specific. A decision may target an identity, a message, a thread, or another object defined by the capability.

4.3 Capability

A capability is a decision namespace.

This specification defines one capability:

mute

Future specifications may define additional capabilities.

A capability defines:

valid decision actions,
valid target types,
whether decisions may be public, private, or both,
how imported decisions are evaluated,
how local conflicts are resolved.

The generic <edge/>, <actor/>, and <target/> elements are defined in the generic namespace:

urn:xmpp:subjective-delegation:0

Capabilities MAY define additional semantics for actions and targets.

If a capability requires additional XML payload beyond the generic attributes and elements, that payload SHOULD use a capability-specific XML namespace.

4.4 Decision Edge

A decision edge expresses the actor’s decision within a capability.

Example: Alice publishes a mute decision suppressing Bob.

4.5 Delegate Edge

A delegate edge expresses that the actor imports another identity’s public decisions for a capability.

A delegate edge may also permit recursive traversal through the target’s public delegate edges. Recursion depth is controlled by the hops attribute.

4.6 Exclude Edge

An exclude edge expresses that the actor excludes the target identity from delegated traversal for a capability.

For conceptual and computational simplicity, only positive additions to the delegation graph can be imported from delegates. Therefore, exclude edges are always local, and MUST NOT be imported through delegation.

Example:

Alice delegates mute decisions to Carol recursively.
Carol delegates mute decisions to Dana.
Alice excludes Dana.

Result:

Alice imports Carol’s public mute decisions.
Alice does not import Dana’s mute decisions through Carol.
Alice's client does not traverse Dana’s delegates.

4.7 Public Edge

A public edge is stored in the room public graph node and visible according to that node’s access model.

4.8 Private Edge

A private edge is stored locally or in private PEP storage visible only to the actor’s clients.

Private edges are never imported through delegation by other users.

5. Edge Types

This specification defines three generic edge types:

decision
delegate
exclude

Generic edge attributes:

Attribute	Meaning
`type`	`decision`, `delegate`, or `exclude`
`capability`	Capability name
`room`	Room JID

Decision edges additionally have:

Attribute	Meaning
`action`	Capability-specific action

delegate edges additionally have:

Attribute	Meaning
`hops`	Non-negative integer or `unbounded`

6. Identity Model

This protocol supports two identity forms:

bare JIDs,
XEP-0421 stable occupant IDs.

It does not support:

MUC nicknames,
MUC occupant JIDs,
full JIDs,
temporary session identifiers,
display names,
avatars.

6.1 Non-anonymous MUCs

In non-anonymous MUCs, implementations MAY use bare JIDs or XEP-0421 occupant IDs to identify actors and identity targets.

6.2 Semi-anonymous MUCs

In semi-anonymous MUCs, implementations MUST use XEP-0421 occupant IDs only.

Protocol payloads for semi-anonymous rooms MUST NOT contain actor or target bare JIDs, even if the publishing client knows them.

6.3 Anonymous MUCs

In anonymous MUCs, implementations MUST use XEP-0421 occupant IDs only.

If a participant has no identity appropriate for the room’s anonymity mode, that participant is not addressable by identity through this protocol.

6.4 Room Scoping

Occupant IDs are scoped to a room. The occupant ID alone is not globally meaningful.

An implementation MUST interpret an occupant ID together with the room attribute of the edge.

7. PubSub Model

There are two storage locations:

room public graph storage,
private user graph storage.

This specification uses XEP-0060 PubSub as the storage and notification substrate for room public graph state.

Private graph storage may be implemented using:

a private PEP node,
local client storage.

PEP MUST NOT be used as the authoritative source for public room graph edges. PEP nodes are discoverable by bare JID and are therefore not suitable for authoritative public graph state for anonymous and semi-anonymous rooms.

8. Room Public Graph Node

Each supported room SHOULD advertise a public graph node that stores public edges relevant to that room.

Example node name:

urn:xmpp:subjective-delegation:0/rooms/room@example.org/public

The exact node name is implementation-defined, but it MUST be discoverable.

The public graph node stores only public edges. Capability specifications define which edges may be public.

8.1 Node Requirements

The room public graph node MUST support:

persistent items,
item IDs,
item retraction,
payload delivery,
event notifications,
access control.

The node MUST be configured with:

persistent items enabled,
payload delivery enabled,
event notifications enabled.

The public graph node’s access model SHOULD match the room’s effective access policy. For example:

open room: readable by anyone or by current occupants,
members-only room: readable by members, admins, and owners,
otherwise restricted room: readable only by entities authorized to access the room.

9. Private Graph Storage

Private graph storage contains edges used only by the actor’s own clients.

Private edges MUST NOT be shared with the room public graph node.

Private storage MUST be readable and writable only by the owning user or resources authorized by that user.

Private edges belonging to another actor MUST NOT be imported through delegation.

If PEP is used for private synchronization, private edges are stored as PubSub items using the same edge payload format. If private graph state is stored locally, there is no PubSub <item/> wrapper.

10. Discovery

A room supporting this protocol MUST advertise protocol support using XEP-0030 service discovery:

urn:xmpp:subjective-delegation:0

A room supporting this protocol MUST advertise the PubSub service and public graph node using XEP-0128 extended service discovery. The data form advertises the concrete PubSub location where public graph state is stored.

Example disco response:

<iq xmlns="jabber:client"
    type="result"
    from="room@example.org"
    to="alice@example.com/laptop"
    id="disco1">
  <query xmlns="http://jabber.org/protocol/disco#info">
    <feature var="urn:xmpp:subjective-delegation:0"/>
    <feature var="urn:xmpp:occupant-id:0"/>
    <x xmlns="jabber:x:data" type="result">
      <field var="FORM_TYPE" type="hidden">
        <value>urn:xmpp:subjective-delegation:0#disco</value>
      </field>
      <field var="pubsub-service">
        <value>pubsub.example.org</value>
      </field>
      <field var="public-node">
        <value>urn:xmpp:subjective-delegation:0/rooms/room@example.org/public</value>
      </field>
    </x>
  </query>
</iq>

11. Edge Payload Format

Edges are XML payloads, usually carried inside PubSub <item/> elements.

The edge element is qualified by:

urn:xmpp:subjective-delegation:0

11.1 Identity Elements

Actors and identity targets are represented using either jid or occupant-id:

<actor jid="alice@example.com"/>
<actor occupant-id="a1"/>
<target jid="bob@example.com"/>
<target occupant-id="b2"/>

occupant-id MUST be used in anonymous and semi-anonymous rooms. An identity element MUST NOT contain both jid and occupant-id.

11.2 Direct Decision Example

Alice publishes a public decision in a non-anonymous room:

<item xmlns="http://jabber.org/protocol/pubsub" id="edge-1">
  <edge xmlns="urn:xmpp:subjective-delegation:0"
        type="decision"
        capability="mute"
        action="suppress"
        room="room@example.org">
    <actor jid="alice@example.com"/>
    <target jid="bob@example.com"/>
  </edge>
</item>

11.3 Occupant-ID Decision Example

Occupant a1 publishes a decision targeting occupant b2:

<item xmlns="http://jabber.org/protocol/pubsub" id="edge-2">
  <edge xmlns="urn:xmpp:subjective-delegation:0"
        type="decision"
        capability="mute"
        action="suppress"
        room="room@example.org">
    <actor occupant-id="a1"/>
    <target occupant-id="b2"/>
  </edge>
</item>

11.4 Delegate Edge Example

Alice delegates mute decisions to Carol, importing only Carol’s direct public decisions as indicated by hops="0":

<item xmlns="http://jabber.org/protocol/pubsub" id="edge-3">
  <edge xmlns="urn:xmpp:subjective-delegation:0"
        type="delegate"
        capability="mute"
        hops="0"
        room="room@example.org">
    <actor jid="alice@example.com"/>
    <target jid="carol@example.com"/>
  </edge>
</item>

11.5 Recursive Delegate Edge Example

Alice delegates mute decisions to Carol and permits recursive traversal. In the following example, hops="2" means that Alice's client will aggregate decisions from Carol, Carol's delegates, and Carol's delegate's delegates:

<item xmlns="http://jabber.org/protocol/pubsub" id="edge-4">
  <edge xmlns="urn:xmpp:subjective-delegation:0"
        type="delegate"
        capability="mute"
        hops="2"
        room="room@example.org">
    <actor jid="alice@example.com"/>
    <target jid="carol@example.com"/>
  </edge>
</item>

Alternatively, use hops="unbounded" to indicate that recursion continues indefinitely.

11.6 Private Exclude Edge Example

Alice excludes Dana from mute delegation traversal:

<item xmlns="http://jabber.org/protocol/pubsub" id="edge-6">
  <edge xmlns="urn:xmpp:subjective-delegation:0"
        type="exclude"
        capability="mute"
        room="room@example.org">
    <actor jid="alice@example.com"/>
    <target jid="dana@example.com"/>
  </edge>
</item>

This edge is private and MUST NOT be published to the room public graph node.

11.7 Private Decision Example

The protocol for a particular capability may specify that some decisions can be private. For example, the mute capability specifies that "allow" decisions are always private. In the following example, Alice privately allows Bob:

<item xmlns="http://jabber.org/protocol/pubsub" id="edge-5">
  <edge xmlns="urn:xmpp:subjective-delegation:0"
        type="decision"
        capability="mute"
        action="allow"
        room="room@example.org">
    <actor jid="alice@example.com"/>
    <target jid="bob@example.com"/>
  </edge>
</item>

This example assumes private storage uses PEP. If stored locally, the <edge/> payload is stored without a PubSub <item/> wrapper.

12. Hops Semantics

A delegate edge imports the target’s direct public decisions for the named capability.

The hops attribute controls whether the target’s public delegate edges are also followed.

`hops`	Meaning
`0`	Import target’s direct public decisions only
`1`	Also import target’s delegates' decisions
`2`	Also import target's delegates' delegates' decisions
`unbounded`	Continue importing recursively, subject to implementation limits

13. Publishing Public Edges

A client publishes a public edge using XEP-0060 publish.

<iq xmlns="jabber:client"
    type="set"
    from="alice@example.com/laptop"
    to="pubsub.example.org"
    id="pub1">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <publish node="urn:xmpp:subjective-delegation:0/rooms/room@example.org/public">
      <item id="edge-1">
        <edge xmlns="urn:xmpp:subjective-delegation:0"
              type="decision"
              capability="mute"
              action="suppress"
              room="room@example.org">
          <actor jid="alice@example.com"/>
          <target jid="bob@example.com"/>
        </edge>
      </item>
    </publish>
  </pubsub>
</iq>

The PubSub service then sends normal PubSub event notifications to subscribers.

14. Revocation

Edges are stateful. Revocation is performed by retracting the PubSub item.

<iq xmlns="jabber:client"
    type="set"
    from="alice@example.com/laptop"
    to="pubsub.example.org"
    id="retract1">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <retract node="urn:xmpp:subjective-delegation:0/rooms/room@example.org/public">
      <item id="edge-1"/>
    </retract>
  </pubsub>
</iq>

After retraction, clients MUST remove the edge from their local graph.

Implementations SHOULD use stable item IDs. An item ID SHOULD identify exactly one active edge.

15. Notifications and Synchronization

Subscribers receive updates via normal PubSub event notifications.

Clients SHOULD fetch current node state:

on login,
on reconnect,
on room join,
after missed notifications are suspected.

PubSub notifications are not authoritative. The PubSub item set is authoritative.

Services MAY include XEP-0334 no-store hints on PubSub notification messages because durable state is stored in PubSub items rather than notification messages.

16. Generic Delegation Evaluation

The following Scheme-like pseudocode defines behavior, not implementation language.

For local actor U, room R, and capability C, evaluation uses:

decisions authored by U,
delegate edges authored by U,
private exclude edges authored by U,
public delegate edges reachable through delegation.
public decisions reachable through delegation.

Private edges authored by other actors are never used. Exclude edges are never imported.

(define (delegated-decisions U R C)
  (append-map
   (lambda (edge)
     (let ((T (edge-target edge)))
       (if (excluded? U R C T)
           '()
           (traverse U R C T (edge-hops edge) '()))))
   (delegate-edges-authored-by U R C)))

(define (traverse U R C X hops visited)
  (cond
   ((member X visited) '())
   ((excluded? U R C X) '())
   (else
    (append
     (public-importable-decisions X R C)
     (if (zero? hops)
         '()
         (append-map
          (lambda (edge)
            (traverse U R C
                      (edge-target edge)
                      (hops-min (hops-dec hops) (edge-hops edge))
                      (cons X visited)))
          (public-delegate-edges X R C)))))))

(define (hops-dec hops)
  (if (eq? hops 'unbounded)
      'unbounded
      (- hops 1)))

(define (hops-min a b)
  (cond
   ((eq? a 'unbounded) b)
   ((eq? b 'unbounded) a)
   (else (min a b))))

Helper meanings:

delegate-edges-authored-by returns public or private delegate edges authored by U for capability C.
excluded? checks whether identity X is privately excluded from delegation by U.
public-importable-decisions returns public decisions that capability C allows to be imported.
public-delegate-edges returns public delegate edges.
edge-hops is a non-negative integer or unbounded.

Note that in the above traverse function, the visited argument only detects cycles within the current recursive branch. Implementations SHOULD deduplicate returned decisions, for example by stable PubSub item ID. Implementations MAY use caching or a global visited structure only if doing so preserves the semantics of hops and local exclusions.

Implementations MUST detect cycles and SHOULD impose limits on recursion depth, edge count, node count, and computation time.

Mute Capability

17. Capability Name

The mute capability name is:

mute

The mute capability controls local rendering of ordinary MUC messages.

It does not affect room state and does not grant moderation power.

18. Capability namespace

The mute capability uses only the generic edge payload format defined by this specification. It does not define a separate capability-specific XML namespace.

19. Mute Decision Actions

The mute capability defines two decision actions:

Action	Meaning
`suppress`	Locally suppress matching messages
`allow`	Locally override delegated suppress decisions

19.1 Suppress

A suppress decision means the actor does not want matching ordinary MUC messages shown in the main conversation view.

A client SHOULD suppress notifications for suppressed messages.

A client MAY provide a way to reveal suppressed messages.

19.2 Allow

An allow decision is a private local override. It causes matching messages to remain visible to the local actor even if they are suppressed by delegated decisions or by the actor’s own active suppress decisions.

An allow decision does not retract, modify, or hide any public suppress decision from other users. Users who delegate to the actor may still import the actor’s public suppress decisions.

Clients SHOULD warn when a local allow conflicts with an active public or private suppress authored by the same actor.

20. Mute Edge Visibility Rules

suppress decisions may be public or private. Public suppress decisions may be imported through delegations.

For conceptual and computational simplicity, only suppress decisions can be imported from delegates. Therefore, allow edges are always local, and MUST NOT be imported through delegation.

21. Mute Targets

Mute decision edges may target:

identities,
messages,
threads.

Mute delegate and exclude edges target identities only.

21.1 Identity Target

An identity target uses jid or occupant-id:

<target jid="bob@example.com"/>

or:

<target occupant-id="b2"/>

21.2 Message Target

A message target uses a XEP-0359 stanza ID.

<target stanza-id="msg-123" by="room@example.org"/>

The stanza-id attribute contains the XEP-0359 stable stanza ID. The by attribute identifies the assigning entity.

21.3 Thread Target

Mute decision edges MAY target RFC 6121 message thread identifiers. Clients that do not support or preserve <thread/> MAY ignore thread targets.

<target thread="thread-123"/>

Thread identifiers are room-scoped by the edge’s room attribute.

22. Effective Mute Evaluation

For local actor U in room R, effective mute targets are:

(define (effective-mute U R)
  (difference
   (union
    (direct-suppress U R)
    (delegated-suppress U R))
   (local-allow U R)))

Where:

direct-suppress returns suppress decisions authored by U, whether public or private.
delegated-suppress returns imported public suppress decisions.
local-allow returns private allow decisions authored by U.

A local allow decision cancels matching suppress decisions for the local actor’s own view, including suppress decisions authored by the local actor.

A local allow decision does not retract or modify any public suppress decision. Therefore, if Alice publicly suppresses Bob and privately allows Bob, Alice’s client shows Bob, but users who delegate mute decisions to Alice can still import Alice’s public suppress decision for Bob.

Clients SHOULD warn when a local allow conflicts with an active public or private suppress authored by the same actor.

23. Mute Message Filtering

When rendering a MUC message, the client determines whether the message matches any target in effective-mute.

A message is suppressed if any of the following match:

sender identity,
message stanza ID,
thread identifier.

24. Mute Examples

The following examples show <edge/> payloads only. Public examples are published as PubSub <item/> payloads in the room public graph node. Private examples are stored in private PEP or local storage.

24.1 Direct Public Mute

Carol mutes Dave publicly in a non-anonymous room:

<edge xmlns="urn:xmpp:subjective-delegation:0"
      type="decision"
      capability="mute"
      action="suppress"
      room="room@example.org">
  <actor jid="carol@example.com"/>
  <target jid="dave@example.com"/>
</edge>

24.2 Local Allow

Alice allows Dave, overriding any potential mute decisions:

<edge xmlns="urn:xmpp:subjective-delegation:0"
      type="decision"
      capability="mute"
      action="allow"
      room="room@example.org">
  <actor jid="alice@example.com"/>
  <target jid="dave@example.com"/>
</edge>

Dave is visible to Alice. If Alice also has an active public suppress decision for Dave, users who delegate mute decisions to Alice may still suppress Dave.

24.3 Message-Specific Mute

Alice suppresses a particular message:

<edge xmlns="urn:xmpp:subjective-delegation:0"
      type="decision"
      capability="mute"
      action="suppress"
      room="room@example.org">
  <actor jid="alice@example.com"/>
  <target stanza-id="msg-123" by="room@example.org"/>
</edge>

In message targets, the by attribute MUST be present and MUST match the by attribute of the XEP-0359 <stanza-id/> being referenced. In typical MUC usage, this value is the room JID and therefore matches the edge’s room attribute.

24.4 Thread Mute

Alice suppresses a thread:

<edge xmlns="urn:xmpp:subjective-delegation:0"
      type="decision"
      capability="mute"
      action="suppress"
      room="room@example.org">
  <actor jid="alice@example.com"/>
  <target thread="thread-123"/>
</edge>

25. Actor Authenticity

For bare-JID edges, the PubSub service MUST ensure that the publisher is authorized to publish edges for the claimed actor JID.

For occupant-ID edges, the PubSub service MUST ensure that the publisher is authorized to publish edges for the claimed XEP-0421 occupant ID in the specified room.

This may require integration between:

the MUC service,
the PubSub service,
the occupant-ID provider.

A client MUST NOT trust a self-asserted actor occupant ID in a public PubSub item unless the service enforces this binding.

26. Access Control

Access control is required for both reading and writing.

The service MUST prevent unauthorized publication of edges for another actor.

The service MUST prevent unauthorized retraction of another actor’s edges.

The room public graph node SHOULD use an access model consistent with the room’s access policy.

Private graph storage MUST be readable and writable only by the owning user or authorized resources.

In semi-anonymous and anonymous rooms, the PubSub service MUST NOT expose bare JIDs through:

payloads,
node names,
notifications,
access-control side effects visible to unauthorized entities.

27. Privacy Rules

In semi-anonymous and anonymous rooms, stable occupant-IDs are used to identify actors and identity targets. Bare JIDs MUST NOT appear.

In non-anonymous rooms, bare JIDs are permitted because the room already exposes them.

Public delegation graphs may reveal social information. For example, they may reveal who mutes whom and whose mute decisions are delegated to by others. Implementations SHOULD make this clear to users.

28. Interaction with Existing XEPs

28.1 XEP-0045: Multi-User Chat

This protocol does not alter MUC roles, affiliations, bans, kicks, voice, or moderation. A delegate is not a MUC moderator.

28.2 XEP-0060: Publish-Subscribe

XEP-0060 is the storage and notification substrate for public room graph state.

28.3 XEP-0163: Personal Eventing Protocol

PEP MAY be used for private multi-device synchronization.

PEP MUST NOT be used as an authoritative source for public room graph edges.

28.4 XEP-0359: Unique and Stable Stanza IDs

The mute capability may use XEP-0359 stanza IDs to target individual messages.

28.5 XEP-0421: Occupant IDs

XEP-0421 is required for semi-anonymous and anonymous room support.

28.6 XEP-0313: Message Archive Management

Clients MAY apply the same capability-specific filtering to archived messages.

28.7 XEP-0334: Message Processing Hints

Message Processing Hints are not required for protocol correctness.

Services MAY include no-store hints on PubSub notification messages.

29. Security Considerations

Implementations MUST consider:

actor spoofing,
occupant-ID forgery,
unauthorized PubSub publication,
unauthorized PubSub subscription,
unauthorized item retraction,
deanonymization through bare JID leakage,
cycles in delegation graphs,
denial of service through large graphs,
stale or rotated occupant IDs.

30. Client UX Recommendations

Clients SHOULD distinguish:

direct local decisions,
delegated decisions,
local allow rules,
local exclude rules,
delegates with limited hops,
delegates with recursive traversal.

For the mute capability, suggested UI actions include:

private mute,
public mute,
unmute
allow despite delegated mute,
remove allow rule,
delegate mute decisions,
set delegate hops,
exclude delegate,
remove exclude rule.

Instead of offering an option to set delegate hops, a simple delegation UI may provide a choice between zero-hop "delegates" and unbounded "superdelegates".

If a user selects “unmute” for a participant muted only through delegation, the client SHOULD create a private allow decision.

If a user selects “unmute” for a participant directly muted by the user, the client SHOULD retract the direct suppress decision instead of creating a private allow decision.

If a user excludes a directly appointed delegate, the client SHOULD normally retract the direct delegate edge instead of creating an exclude edge.

30.1 Delegation graph

Clients MAY provide a navigable interface for viewing the graph of delegates for a particular room and capability. See the "Prior Art" section for examples.

31. Delegation Seeds

A future version of this specification may define delegation seeds for bootstrapping a participant’s private delegation graph when joining a room.

A delegation seed is a recommended set of initial private edges associated with a room. For example, an invitation link or out-of-band invitation mechanism could recommend that a joining participant delegate the mute capability to one or more existing room participants.

A seed does not affect any participant unless that participant’s client accepts it. If accepted, seeded edges are created as private edges authored by the joining participant.

Seed child <edge/> elements are templates, not graph edges. They therefore omit the actor. The actor is filled in by the accepting client.

Example seed:

<seed xmlns="urn:xmpp:subjective-delegation:0"
      room="room@example.org">
  <edge type="delegate" capability="mute" hops="0">
    <target jid="carol@example.com"/>
  </edge>
  <edge type="delegate" capability="mute" hops="unbounded">
    <target jid="dana@example.com"/>
  </edge>
</seed>

If Alice accepts this seed, her client creates private edges like the following:

<edge xmlns="urn:xmpp:subjective-delegation:0"
      type="delegate"
      capability="mute"
      hops="0"
      room="room@example.org">
  <actor jid="alice@example.com"/>
  <target jid="carol@example.com"/>
</edge>

Clients MAY also use the existing set of room owners, admins, and moderators as seed delegates.

Future work:

how seeds are encoded in XMPP URIs,
how seed data is fetched from PubSub or another source,
whether seeds are signed,
how clients verify seed authenticity,
how invitation links or seed access tokens interact with XMPP access control,
how seeds represent occupant-ID targets in anonymous or semi-anonymous rooms.

32. Open Issues

Exact PubSub node naming convention.
Whether room public graph nodes must be hosted by the MUC service.
How edge IDs are generated, e.g., using deterministic hashes.
Handling occupant-ID rotation policies.
Cache expiration after users leave a room.
Fine-grained muting, such as muting a participant within a particular thread,

33. Prior Art and Related Work

Credit for inspiring this XEP goes to:

Alexander Cobleigh’s TrustNet, which describes a subjective trust graph model in which users can delegate moderation-like decisions to trusted peers, producing different local views for different participants.
The Cable moderation protocol, used in Cabal, which explores moderation as graph-based, user-centered social state rather than solely centralized server authority.
USHIN’s hyperdrive.el EmacsConf 2024 presentation, which demonstrates a navigable UI for viewing the graph of sources/delegates.

34. Summary

This specification defines subjective delegation for MUC using PubSub.

The generic model is:

decision: express a decision within a capability,
delegate: import another identity’s public decisions for a capability,
exclude: locally remove an identity from delegated traversal,
capability: a named decision area with capability-specific semantics.

This specification also defines the mute capability:

suppress: locally suppress matching messages,
allow: locally override delegated suppress decisions.

Moving to Dali Gratitude / 搬家感恩记

2026-08-24T12:00:00Z

We are now in our new space on the outskirts of Jiangdu Village, Xizhou Town, Dali, Yunnan! Thank you so much to Mama Apple and Stepdad Dai Bobo for their loving support as we transition into our new home!

我们住进了云南大理喜洲镇江渡村郊外的新家！特别感谢妈妈和戴伯伯在我们搬家的这段过渡时期给予我们满满的爱与支持！

Mama Apple and Stepdad Dai Bobo helped us pack things up in Zhuzhou, Hunan, including a full-size electric drum kit.

妈妈和戴伯伯帮助我们把湖南株洲的行李收拾打包，其中还包括一套全尺寸的电子鼓。

They spent several days helping me jump through hoops to get a Chines e drivers license, and then they did most of the driving from Hunan to Yunnan, over 1200 miles!

他们花了好几天帮我费尽周折地办理中国驾照，之后又几乎全程开车载着我们一路从湖南到了云南，路程超过1200英里！

In Dali, they helped us carefully pack up everything from our Sanwenbi home, where Bei Bei and I stayed last year. With the help of a moving van, we moved everything over to the new place, and they took care of food shopping, cooking, and cleaning. They helped us think about how to organize our new space. They encouraged us to be confident in our negotiations in the lease transfer. They gifted us their car!!

在大理，他们又帮我们仔细打包好了三文笔村房子的行李——那是贝贝和我去年住的地方。我们用货拉拉把所有东西都搬到了新家后，他们还包揽了买菜、做饭和打扫卫生。他们帮我们一起想办法布置新家，并鼓励我们谈租约转让时大胆争取自己的权益。他们甚至把车送给了我们！！

After several weeks of toil, when I expressed my thanks to Stepdad Dai Bobo, he simply said, "必须的 (It must be)".

在几个星期的忙碌之后，当我向戴伯伯表达感谢时，他只是简单地说了一句：“必须的。”

Thank you, Mama Apple and Stepdad Dai Bobo!!!

谢谢妈妈和戴伯伯！！！

We wish you safe and happy travels on your adventure to the island of Bali this week!

祝您们这周的巴厘岛探险之旅安全和愉快!

Black Mouth Berry / 黑嘴巴果

2026-07-23T12:00:00Z

Today, Bei Bei and I went for a short hike up Phoenix Mountain in Zhuzhou, Hunan Province and found a patch of low-growing berries, Melastoma dodecandrum (地棯). It's edible, sweet with an astringent and slightly bitter aftertaste. The whole plant is used in traditional Chinese medicine. According to a 2003 article published in China Journal of Chinese Materia Medica, Five compounds were isolated and identified as hexacosanoic acid (I), quercetin(II), avicularin(III), gallic acid (IV), kaempferol(V).

今天，贝贝和我去湖南株洲的凤凰山爬山，并发现了一片贴地生长的小浆果——地菍。

它的果实可以食用，味道甜甜的，之后会留下涩味和一点苦味。地菍全株可入中药。

根据《中国中药杂志》2003 年发表的一篇文章，研究人员从地菍中分离并鉴定出了五种化合物：二十六烷酸（Ⅰ）、槲皮素（Ⅱ）、扁蓄苷（Ⅲ）、没食子酸（Ⅳ）和山柰酚（Ⅴ）。

The Latin name literally means "black mouth", since the fruit stains your mouth. Perhaps it could also be used as a dye.

它的拉丁属名，字面意思是“黑嘴”，因为果实会把嘴染黑。也许它还可以用来做染料。

小過 (歌词 + 视频) / Xiao Guo (Lyrics + Video)

2026-07-22T12:00:00Z

卦辞 The Judgment

小過。亨，利貞。可小事，不可大事。飛鳥遺之音。不宜上，宜下，大吉。

Preponderance of the Small. Success. Perseverance furthers. Small things may be done; great things should not be done. The flying bird brings the message: It is not well to strive upward, It is well to remain below. Great good fortune.

歌词 Lyrics:

小小飞鸟飞得低

Little bird, flying low

你家很远不用急

Your home is far away, no need to hurry

晒晒太阳太阳光

The sunlight is shining down

光会跟着你去每个地方

Sunlight will follow you wherever you go

云朵环绕山峰凝结成水滴

Clouds around the mountaintop condensing into droplets

奔涌的小溪归于湖底

Streams rushing down, returning to the lake

滋养生灵

Nourishing life

小鱼嬉戏

Little fish are playing

水草摇曳

Reeds are swaying

沙石被塑形

Sand and stones are being shaped

树木支撑土壤

Trees holding the soil

彩虹跨越天际

Rainbows leaping across the horizon

万物连接

Everything is connected

这叫生命

This is life

就像你

And it's just like you

小小飞鸟飞得低

Little bird, flying low

你家很远不用急

Your home is far away, no need to hurry

晒晒太阳太阳光

The sunlight is shining down

光会跟着你去每个地方

Sunlight will follow you wherever you go

万物连接

Everything is connected

这叫生命

This is life

就像你

And it's just like you

Justin Squires Wedding Speech / 婚礼致辞

2026-07-21T12:00:00Z

Joseph and Bei Bei,

Your union is true. Your union is written. Your union is in faith and true love. You guys are meant to be!

Joseph, if there’s anything that I trust about you in the few years I’ve known you, it’s that your path and your ways are guided by a wisdom and intuition further reaching than yourself, and this guidance shines clear and bright to me in every interaction I’ve had with you since Archangeli’s phonology class back in 2017.

You move with clear intention and a powerfully honest presence. Your mundane, day to day actions are courageous in their orientation towards a greater harmony of mind, body, and spirit for yourself, those you love, and the whole world. All the many kinds of blessings from heaven are with you, whether it be your music, your healing hands, the ki that you move yourself and the world with, your connection to the trees and the waters, your extraordinary heritage, your mind which sings a song of discovery, deep and one-of-a-kind, and your open and loving heart. Your substance is far more unique, uplifting, and purposeful than any of us here will ever know, and in all this I knew, before I met her, that your love Bei Bei sings a song equal to you in beauty. Your way of life is far too honest, clear, and in love for someone any less to have joined you in marriage as Bei Bei joins you now. God has known the both of you, and in knowing you, he knew your union. He knew your harmony, and he knew your completion. So here we are!

To see you two now, coming together in the most powerful connection that humans can share, is reassurance to me that whatever is really going on in this crazy world we live in is actually far more excellent and inspiring than it may otherwise seem. When I see you two together, I see that God’s design is deeper, truer, freer, further, greater.

Bei Bei, Joseph is my brother across lifetimes, a special gift to me from a higher place, and I see that you ground him, and you lift him. You are clear water for him. You are his love. You center him, and he holds you. I see how your tranquility, your levity, and your honesty fortifies his heart. And to see you in this way for him is inspiring to me. I love you, and I love that you love him in the perfect and unique way that you do. You are his wife, and you are my family. Welcome, and thank you for being here.

Justin Squires

中文翻译：

Joseph 和贝贝：

你们的结合是真实的，是早已写下的。你们因信仰与真爱而走到一起。你们本就注定属于彼此！

Joseph，在认识你的这些年里，如果说有什么是我始终深信不疑的，那就是：你所走的道路、你行事的方式，一直受到一种超越你自身的智慧与直觉所引领。自从 2017 年我们在 Archangeli 的音系学课上认识以来，在与你的每一次相处中，我都能清晰而明亮地感受到这份引领。

你带着明确的心意前行，也带着一种无比真诚而有力量的存在感。即使是在最平凡的日常生活中，你所做的每一件事也都怀着勇气，并始终朝向一种更大的和谐——让你自己、你所爱的人，乃至整个世界，在身体、心灵与精神之间更加完整。来自上天的种种祝福都与你同在：你的音乐，你那双能够疗愈的手，你用来推动自己、也影响这个世界的“气”，你与树木和水流之间的连接，你非凡的血脉与传承，你那颗唱着探索之歌的心——深邃而独一无二——还有你敞开而充满爱的内心。你真正的本质，比我们在场的任何人所能完全理解的都更加独特，更能带给人力量，也更有方向和意义。正因为如此，在见到贝贝之前，我就已经知道，你所爱的人，也一定会唱着一首与你同样美丽的歌。你的生活如此真诚、清澈而充满爱，因此，今天与你步入婚姻的贝贝，也必定拥有与你相称的灵魂。上帝一直认识你们两个人。而在认识你们的时候，祂也早已知道你们会结合。祂知道你们之间的和谐，也知道你们会如何使彼此变得完整。于是，我们今天就在此庆祝！

此刻，看着你们走到一起，进入人与人之间所能拥有的最深刻、最有力量的连接，我感到一种深深的安慰。这让我相信，无论我们所生活的这个疯狂世界究竟正在发生什么，它都远比表面看起来更加美好，也更加鼓舞人心。当我看着你们在一起，我看见上帝的安排比我们所能想象的更深、更真、更自由、更辽阔，也更伟大。

贝贝，Joseph 是我生生世世的兄弟，是来自更高之处、赐予我的一份珍贵礼物。我看见，你让他安稳地扎根，也让他向上生长。对他而言，你如清水一般澄澈。你是他的爱。你让他的心安定下来，而他稳稳地承托着你。我看见你的宁静、你的轻盈和你的真诚，如何让他的内心变得更加坚定。看见你以这样的方式陪伴着他，也让我深受感动和鼓舞。

我爱你，也爱你以只属于你的、完美而独特的方式爱着他。你是他的妻子，也是我的家人。欢迎你，也谢谢你来到这里。

Justin Squires

外公的婚礼祝福 / Wedding Blessings from Grandpa

2026-07-20T12:00:00Z

恭喜外孙女贝贝和小九新婚之喜！远在亚利桑那州缔结良缘，新春佳节双喜临门。外公特意填词两阕，既合中式雅韵，又寄万里祝福。两阕词皆紧扣新春、新婚、远地良缘之意，平仄韵脚依词牌正体格律，既合迎宾贺婚之礼，又藏阖家祝福之情。贝贝，如你们那里有“中国红的”大红纸买的话，你去买张红纸抄写一份贴在你们的新婚房间里，作个纪念。《迎宾词》用红纸抄写一份贴在你们办喜酒的大门。（外公外婆衷心祝福，2026年2月19日于中国）

Congratulations to our granddaughter Bei Bei and Joseph on your marriage!

You have joined your lives together far away in Arizona, and your wedding has brought us double happiness during the Chinese New Year. To celebrate, Grandpa has written two traditional Chinese poems especially for you. They carry the grace of Chinese poetry, as well as our blessings sent across thousands of miles.

Both poems are about the Chinese New Year, your marriage, and the happy fate that brought you together in a faraway place. Their tones and rhymes follow the traditional forms. They are written both to welcome the guests and celebrate the wedding, while also carrying the love and blessings of the whole family.

Bei Bei, if you can find some bright red paper—the traditional Chinese red—where you live, please buy a sheet and copy the poems onto it. You can hang them in your newlywed room as a keepsake.

Please also copy the poem titled “Welcoming the Guests” onto red paper and hang it by the entrance of the place where you hold your wedding banquet.

With all our hearts, Grandpa and Grandma wish you both a happy marriage and a beautiful life together.

February 19, 2026 China

《春光好》

Spring in Gentle Light

莺语软， Soft birds sing,

柳丝柔， Willows sway softly,

瑞烟浮。 Auspicious mists drift.

万里天涯春正好， Across ten thousand miles, spring is bright—

缔鸾俦。 Lovebirds unite.

锦瑟同心相绾， Twin zither hearts bound as one,

华堂笑靥凝眸。 Smiles meet in the bridal hall.

岁岁琴瑟和韵永， Year after year, harmonies run,

福长留。 Blessings ever fall.

《浪淘沙·迎宾词》

Welcoming Verse — Tune of Lang Tao Sha

嘉节启新章， This fair day opens a chapter new,

喜气盈堂。 Joy fills the hall through.

宾朋同贺凤求凰。 Friends gather to bless the phoenix pair,

万里姻缘天作合， A bond heaven-made across miles so far—

共祝安康。 All wish them peace to share.

笑语暖壶觞， Warm laughter lifts the wine,

春意绵长。 Spring lingers, tender and long.

兰闺佳偶岁月香。 A graceful couple, their years refined,

白首齐眉情不改， Side by side till hair turns white, love strong—

世世荣昌。 Blessed through ages in song.

我们的故事 (第一集) / Our Story (Episode 1)

2026-07-20T12:00:00Z

2025年年初，我受航长的邀请参加每周一次的启发聚会（一系列帮助人了解基督教信仰的课程）。我那时住在下关，每次路上要花一个半小时，但我无比庆幸自己参与其中，因为在那里我认识了对我非常重要的一群好朋友。3月时我还信誓旦旦地告诉他们我懒得搬家，每周这么赶路也无所谓，转头4月1号我就已经住进了三文笔村的新家。我有了自己的沙盘工作室，也有了与朋友们更频繁的相聚。我们在聿敏家打鼓、跳舞，在航长家聚餐、欢唱，在Raymond家喝酒、畅聊……我的“闭关”状态渐渐褪去，被友情的连接所填充。6月的一天，我和姚瑶约好了吃午餐，她早上临时问我能不能再带一位刚认识的外国朋友一起，我随即就答应了，并不知道自己命运会因此发生翻天覆地的变化。在这个愉快的下午之后，我和谭九每天都会见面，每次见面聊天聊到不想告别。两周以后在一个聚会上我邀请谭九和我一起跳舞，我们两个十分笨拙地相拥跳舞，一不小心就踩到对方的脚。那天告别时我意识到，我要恋爱了。第二天谭九来到我家问我，虽然我们的未来充满了不确定，我是否愿意和他开始恋爱。我们的故事就这样在懵懂的心动中开始了。

At the beginning of 2025, Hangzhang invited me to join a weekly Alpha gathering (a set of structured lessons for learning about Christianity). I was living in Xiaguan at the time, so getting there took an hour and a half each way. Even so, I am incredibly glad that I kept going, because that was where I met a group of friends who would become very important to me.

As late as March, I was still confidently telling everyone that I was too lazy to move and perfectly happy to spend all that time on the road every week. And then, almost as soon as I had said it, I moved into my new home in Sanwenbi Village on April 1.

The move gave me a sandplay studio of my own, but more importantly, it brought me much closer to my friends. We played drums and danced at Yumin’s place, gathered for food and singing at Hangzhang’s, and enjoyed homemade cocktails and conversation late into the night at Raymond’s. Without my really noticing, the “retreat” I had been living in slowly came to an end, and friendship began to fill the space it left behind.

Then one day in June, I made plans to have lunch with Yaoyao. That morning, she asked at the last minute whether she could bring along a foreign friend she had just met. I agreed right away, with no idea that this small decision was about to transform my life.

After that lovely afternoon, Joseph and I started seeing each other every day. Each time we met, we would talk until neither of us wanted to say goodbye.

Two weeks later, at a gathering, I asked him to dance with me. We held each other and moved around very awkwardly, stepping on each other’s feet more than once. By the time we said goodbye that evening, I knew I was falling in love.

The next day, Joseph came to my home and asked whether I would be willing to start a relationship with him, even though there was so much uncertainty ahead of us.

That was how our story began: with a shy and slightly confused kind of excitement, before either of us fully understood where it would lead.

Barrel Compost Toilet (Episode 1) / 桶式堆肥厕所 (第一集)

2026-07-17T12:00:00Z

After we got married in February, Bei Bei and I honeymooned at the Cascabel Conservation Association's Cottage Hermitage, a sublime solitary retreat nestled in Hot Springs Canyon east of Tucson, AZ. We actually made plans before we got married to do the week-long retreat together in Cascabel! Only after getting engaged three weeks before our wedding did we realize that the retreat would be the perfect honeymoon.

二月结婚后，贝贝和我来到亚利桑那州图森以东、热泉峡谷中的卡斯卡贝尔保护协会隐修小屋度蜜月。那是一处静谧绝美、远离尘嚣的独居隐居地。其实在结婚之前，我们就已经计划好，要一起去卡斯卡贝尔进行为期一周的静修！直到婚礼前三周订婚后，我们才意识到，这次静修正好可以成为一场再完美不过的蜜月。

Immediately following our honeymoon-retreat week, we were blessed to join in Saguaro Juniper's 3rd annual Home On the Range event. We enjoyed a morning work-party, Papa Cobre patties, and fulfilling conversation with old and new friends.

蜜月静修结束后，我们又很幸运地参加了 Saguaro Juniper 举办的第三届年度“Home On the Range” （牧场家园开放日）活动。那天上午，我们一起参加了集体劳动，品尝了 Papa Cobre 肉饼，还和新老朋友们进行了一番充实而愉快的交流。

David Omick and Pearl Mast, whose creatively minimal lifestyle inspires us greatly, patiently fielded countless questions about their brilliant barrel composting design. David, who only a few days prior underwent knee surgery, hopped up to eagerly show us some of the composting toilets they built and installed for private and community use around Cascabel.

David Omick 和 Pearl Mast 极具创意的极简生活方式一直深深启发着我们。他们耐心回答了我们关于其巧妙桶式堆肥系统设计的无数问题。David 几天前才刚做完膝盖手术，却还是一跃而起，兴致勃勃地带我们参观了他们在卡斯卡贝尔各处建造和安装的一些堆肥厕所，这些设施既供私人家庭使用，也供社区共同使用。

The 55-gallon drum composting toilet is safe (even approved by the ADEQ), easy to put together, and comfortable to use. What's more, David and Pearl's designs are available for anyone to study for free on their website!

这种采用 55 加仑桶的堆肥厕所安全可靠——甚至获得了亚利桑那州环境质量部（ADEQ）的批准—— 组装简单，使用起来也很舒适。更棒的是，David 和 Pearl 已经把设计方案免费发布在他们的网站上，任何人都可以查看和学习！

This blog post summarizes some thoughts I had while building a composting toilet based on these designs. Thank you, David and Pearl, for sharing your wisdom! Thank you, Dad, for carpentry guidance! Thank you, Bei Bei, for diligent quality assurance testing!

这篇博客文章总结了我依据这些设计建造堆肥厕所时产生的一些想法。谢谢 David 和 Pearl，感谢你们无私分享自己的智慧！谢谢爸爸，在木工方面给予我的指导！谢谢贝贝，认真负责地完成了质量保证测试！

The Throne

宝座

David and Pearl's original design recommends burying the barrels halfway so that the business-doer can comfortably sit without having to climb up stairs. However we wanted to install our toilet on the front porch, which already has a wood floor. This meant that we needed to build some steps to get up to the toilet:

David 和 Pearl 的原始设计建议把桶体埋入地下约一半，这样如厕的人无需爬楼梯，就能舒适地坐上去。不过，我们想把厕所安装在前廊上，而那里本来就铺有木地板。这意味着，我们需要搭几级台阶才能坐上马桶：

The main disadvantage to this approach is that it requires moving the steps and the barrel after it's full, but with two people and a large hand truck, it's no problem to replace the full barrel every few months. Alternatively, David's website suggests placing a plant dolly underneath the barrel for easy transportation indoors.

这种做法最大的缺点是，桶装满后，必须先移开台阶，再把桶搬走。不过，只要有两个人，再配上一辆大型手推车，每隔几个月更换一次满桶并不是什么难事。另一种办法是，按照 David 网站上的建议，在桶底下放一个带轮子的花盆托架，这样在室内搬运起来会方便得多。

Toilet top

马桶顶板

Instead of making the toilet top out of epoxy-coated wood, aluminum, or concrete, we found a piece of 5/16" grey plastic material at the scrapyard and cut out the toilet top and insect plate with a jigsaw. It resists weathering and can be cleaned easily.

我们没有用涂有环氧树脂的木板、铝板或混凝土来制作马桶顶板，而是在废品回收场找到了一块厚约 8 毫米（5/16 英寸）的灰色塑料板材，再用曲线锯切割出马桶顶板和防虫板。这种材料经得起日晒雨淋，也很容易清洁。

We did not add a hold-down spring assembly, but instead relied on the snug fit between the locator bolts (we used 3/8" bolts, less prone to bending than the 1/4" bolts in the original design) and the holes drilled around the lip of the barrel.

我们没有安装弹簧压紧装置，而是依靠定位螺栓与桶口边缘所钻孔洞之间的紧密配合来固定顶板。我们使用了直径约 10 毫米（3/8 英寸）的螺栓，比原设计中直径约 6 毫米（1/4 英寸）的螺栓更不容易弯曲。

Urine diverter

尿液分流器

David and Pearl's design calls for a funnel + rubber stopper as a urine diverter. I hacked together an alternative design using old plastic jugs. Cut a milk/vinegar/oil jug to the desired shape. Drill a hole in the lid of the jug the same diameter as your tubing. Cut the last 1/2" of the tubing open lengthwise, push it through the hole in the lid, and screw the two flaps of the tubing down to the lid. It's not perfectly watertight, but a little moisture is good for the compost. If your milk jug has a handle, cut the handle long, bend it over, and screw it down to itself.

David 和 Pearl 的设计使用漏斗和橡胶塞来制作尿液分流器。我则用几个废旧塑料壶，临时拼出了另一种做法。先把牛奶壶、醋壶或食用油壶剪成需要的形状。然后在壶盖上钻一个孔，孔径与导管外径相同。把导管末端约 1.3 厘米（1/2 英寸）长的一段纵向剪开，将导管穿过壶盖上的孔，再把剪开的两片分别用螺丝固定在壶盖上。这个连接处并不能做到完全不漏水，不过堆肥中保留少量水分反而是好事。如果牛奶壶带有把手，剪的时候把把手留长一些，再将它弯折过去，用螺丝固定在把手自身上。

Keeping the urine diverter clean

保持尿液分流器清洁

Instead of using a stainless steel sink drain screen to keep the diverter from clogging with misplaced cover material, I wrapped the entire urine diverter with insect screen. This way, when cover material accidentally falls onto the diverter, it mostly bounces off, reducing the need for manual cleaning. However, the screen and urine diverter can still be removed and cleaned, since it's fastened in place by a piece of wire which can hinge up and out of the way.

原设计使用不锈钢水槽滤网，防止误落的覆盖材料堵住尿液分流器。我没有采用这种做法，而是用防虫网把整个尿液分流器包了起来。这样一来，覆盖材料即使不小心掉到分流器上，大多也会弹开，从而减少手动清理的次数。不过，防虫网和尿液分流器仍然可以拆下来清洗。它们由一段金属丝固定在原位，需要清理时，可以把金属丝像铰链一样向上掀开，让到一旁。

An alternative method for keep the urine diverter clean while the barrel is aging is to turn the bottom of the milk jug into a cover which fits snugly over the urine diverter. That way, as you stir the aging compost, no flying debris will fall in.

在桶内的堆肥静置腐熟期间，还有另一种保持尿液分流器清洁的方法：把牛奶壶的底部剪下来，做成一个能够严密扣在分流器上的盖子。这样，翻动正在腐熟的堆肥时，飞散的碎屑就不会落进分流器里。

Urine collection

尿液收集

Instead of installing an underground leaching chamber, we opted to save the urine for our garden! Just run a line (we used rabbit watering system hose) from the barrel through a hole in the wall and into the lid of a 5-gallon bucket. We also added orange peels into the bucket to cut the smell.

我们没有安装地下渗滤装置，而是决定把尿液收集起来，用在花园里！只需从桶里接出一根软管——我们用的是兔用自动饮水系统的软管——让它穿过墙上的孔，再接入一个约 19 升（5 加仑）塑料桶的桶盖即可。我们还在桶里放了一些橙皮，以减轻异味。

More fun hacks

Safe, Happy Compost

安全又有活力的堆肥

After we filled up the first barrel, happy little sprouts began popping up on top of the compost material, only to be turned under by our compost crank each week. The internal temperature of the compost rose to 122℉ (50℃) and stayed there for a few days, high enough to kill all potential parasites and pathogens, according to the "Time and Temperature Safety Zone" graph from Joseph Jenkins's Humanure Handbook (Version 4), Chapter 13, page 204.

第一个桶装满后，堆肥表面开始冒出一株株生机勃勃的小嫩芽，不过每周都会被我们的堆肥搅拌器重新翻进堆料里。堆肥内部的温度升至 50℃（122℉），并维持了数日。根据 Joseph Jenkins 所著《人粪堆肥手册》第四版第 13 章第 204 页中的“时间与温度安全区”图表，这一温度已经足以杀灭所有可能存在的寄生虫和病原体。

On the next episode of Barrel Compost Toilet...

《桶式堆肥厕所》下回预告……

Bei Bei and I are now preparing to move into our new home in Xizhou Town, Dali City, Yunnan Province, China! Stay tuned for more compost toilet updates!

贝贝和我正在准备搬进位于中国云南省大理市喜洲镇的新家！敬请期待更多关于堆肥厕所的后续更新！

We are tremendously grateful to all of the folks in Cascabel who welcomed us so warmly! We can't wait until the next time we get together. Thank you!!

我们由衷感谢卡斯卡贝尔的每一位朋友，感谢大家如此热情地欢迎和接纳我们！我们已经迫不及待地盼着下一次相聚了。谢谢大家！！

Follow Up on emails with mu4e and org-capture

2025-02-03T12:00:00Z

When I send an email, I often want my agenda to remind me to follow up a few days later. Thanks to Dirk-Jan C. Binnema's help, I was able to set this up with mu4e and org-capture.

`mu4e` + `org-capture`

Here's the code:

  (add-to-list
   'org-capture-templates
   ("efu" "Follow Up" entry (file+olp "todo/todo.org" "Email" "Follow Up")
    "* TODO Follow up with %(eval sent-message-to) on [[mu4e:msgid:%(eval sent-message-id)][%(eval sent-subject)]]
SCHEDULED: %(org-insert-time-stamp (org-read-date nil t \"+3d\"))
%i"))

  (add-hook 'message-sent-hook #'my/org-capture-sent-mail)

  (defun my/org-capture-sent-mail ()
    "Prepare to capture sent mail after window configuration is reset."
    (let* ((sent-message-id
          (replace-regexp-in-string
           "[<>]" "" (message-fetch-field "Message-Id")))
           (sent-message-to
            (replace-regexp-in-string " <.*>" "" (message-fetch-field "To")))
         (sent-subject (or (message-fetch-field "Subject") "No subject")))
      (org-capture nil "efu")
      (add-hook 'mu4e-compose-post-hook #'my/pop-to-buffer-org-capture-mail 99)))

  (defun my/pop-to-buffer-org-capture-mail ()
    (pop-to-buffer
     (car (match-buffers
           (lambda (buffer)
             (equal "efu"
                    (plist-get
                     (buffer-local-value
                      'org-capture-current-plist buffer)
                     :key))))))
    (remove-hook 'mu4e-compose-post-hook #'my/pop-to-buffer-org-capture-mail))

After I send an email, I see the org-capture pop-up window pre-filled from the template:

*** TODO Follow up with John Doe on [[mu4e:msgid:1234576890][Beautiful Snowy Morning]]
SCHEDULED: <2025-02-06 Wed>

If I run org-capture-finalize (C-c C-c), then I'll be reminded in three days to follow up on the email. Before capturing the reminder, I can add more information or edit the date if I want to have more or less time before it shows up on my agenda. Alternatively, I can run org-capture-kill (C-c C-k) if I don't want to be reminded at all.

Technical Details

After closing a composition buffer, mu4e restores your window configuration in mu4e-compose-post-hook, a feature which I want to keep. However, this means that the org-capture buffer gets hidden when the windows are restored.1 The solution above is to add a self-removing hook function my/pop-to-buffer-org-capture-mail to mu4e-compose-post-hook which pops back to the org-capture buffer after the window configuration is restored.

Footnotes

1

I want to interact with the org capture buffer each time I send an email, so I can edit or cancel the reminder while capturing it. If I didn't want to interact with the org capture buffer, I could put :immediate-finish in the org-capture template and get rid of my/pop-to-buffer-org-capture-mail.

Query Regexp Replace Lisp Replacement

2024-12-19T12:00:00Z

I rarely use query-replace-regexp's lisp expression replacement feature, but I came upon a good use for it today!

Recently, I've been testing out org-srs for practicing Mandarin vocab. So far, it works very well! When I asked to truncate the serialized data which gets written to the Org files to reduce diff noise and to make the state column fit on my small laptop screen, the package author kindly offered a workaround1, which causes this:

# Without workaround:

#+NAME: srsitem:2d51efcd-8523-4432-b074-50d1ba4c45b3
| ! | timestamp            | rating |          stability |        difficulty | state     |
|---+----------------------+--------+--------------------+-------------------+-----------|
|   | 2024-12-11T18:37:19Z |        |                0.0 |               0.0 | :new      |
|   | 2024-12-11T18:38:23Z | :again |             0.4072 |            7.2102 | :learning |
|   | 2024-12-11T18:39:05Z | :easy  | 0.9375660842587888 | 6.078123501986166 | :review   |
|   | 2024-12-14T07:07:08Z | :easy  | 16.133939701409084 | 4.972537594025855 | :review   |
| * | 2024-12-30T07:07:08Z |        |                    |                   |           |

to become this:

# With workaround:

#+NAME: srsitem:2d51efcd-8523-4432-b074-50d1ba4c45b3
| ! | timestamp            | rating | stability | difficulty | state     |
|---+----------------------+--------+-----------+------------+-----------|
|   | 2024-12-11T18:37:19Z |        |       0.0 |        0.0 | :new      |
|   | 2024-12-11T18:38:23Z | :again |      0.41 |       7.21 | :learning |
|   | 2024-12-11T18:39:05Z | :easy  |      0.94 |       6.08 | :review   |
|   | 2024-12-14T07:07:08Z | :easy  |     16.13 |       4.97 | :review   |
| * | 2024-12-30T07:07:08Z |        |           |            |           |

However, I already had some existing data in my chinese.org file. To truncate that data, I used this lisp expression replacement with query-replace-regexp:

[0-9]+\.\([0-9]+\) → \,(if (length> \1 2) (format "%0.02f" \#0) \0)

The regexp matches the numbers in the stability and difficulty columns. My chinese.org file conveniently contains no other numbers in decimal-point notation. The lisp expression checks if the part after the decimal point contains more than two numbers, since I don't want 0.0 to become 0.00. If it does, then the format expression rounds it to two decimal places. Otherwise, the match is left as-is. Note that \#0 in the replacement text converts the match string to a number, which is required by the %f format type specifier.

After replacing all of the numbers in the buffer, I ran a quick keyboard macro to align all of the srsitem tables to fit the narrower contents, but I'll leave that as an exercise to the reader.

I hope this helps you. Feel free to contact me with suggestions, corrections, or questions!

Footnotes

1

Workaround to truncate the data:

(cl-defmethod org-srs-algorithm-repeat :around ((_ fsrs-scheduler) _)
  (let ((output (cl-call-next-method)))
    (setf (alist-get 'stability output) (format "%.02f" (alist-get 'stability output))
          (alist-get 'difficulty output) (format "%.02f" (alist-get 'difficulty output)))
    output))

Mirror Worg to a Hyperdrive

2024-12-16T12:00:00Z

During the Q&A session of the EmacsConf 2024 hyperdrive.el talk, Ihor Radchenko suggested using hyperdrive to distribute worg, the community-driven Org documentation written in Org format.

Thanks, Ihor!

Mirror `worg` to a hyperdrive

You can run these commands on a local or remote machine. I chose to mirror worg to a hyperdrive on a remote Debian 12 VPS so that the content stays available when I turn off my computer.

Install git, dtach and drives cli:

sudo apt install git dtach npm
npm install -g drives

Clone worg, then create a new corestore and hyperdrive:

git clone https://git.sr.ht/~bzg/worg/
cd worg
drives init
drives touch # Copy hyperdrive public key from output

Mirror the worg repository into the newly created hyperdrive:

# drives mirror --dry-run . bpb1bq6sdfajw4bok7k9tdmrq153pbwzcyfkrqrfxw3hhihyddhy # Dry run first
dtach -n /tmp/drives-worg-session drives mirror --live . bpb1bq6sdfajw4bok7k9tdmrq153pbwzcyfkrqrfxw3hhihyddhy # From output of `drives touch`

Note that drives ignores the .git folder out of the box. Running the command inside a dtach session is a quick and dirty way to make the process persist after we've disconnected from the VPS. A better approach would be to write a service file to register the drives process with the init system (Debian 12 uses systemd).

To automatically pull the latest changes from the remote worg repository, add a cronjob with crontab -e:

30 0 * * * git -C ~/worg pull

Voilá! worg is now continuously mirrored to a hyperdrive, which can be explored, linked to, transcluded, and more using hyperdrive.el:

hyper://bpb1bq6sdfajw4bok7k9tdmrq153pbwzcyfkrqrfxw3hhihyddhy/

If you're viewing this file in Emacs with hyperdrive.el installed, follow this link to view the "Introduction to Org-Mode and Worg" in the hyperdrive mirror:

hyper://bpb1bq6sdfajw4bok7k9tdmrq153pbwzcyfkrqrfxw3hhihyddhy/index.org#%3A%3A%2AIntroduction%20to%20Org-Mode%20and%20Worg

I hope this helps you. Feel free to contact me with suggestions, corrections, or questions!

Sourcehut Org Mode README

2024-12-10T12:00:00Z

Out of the box, Sourcehut only renders README, README.md, and README.markdown.1

Workarounds to render `README.org`

One proposed workaround is to export README.org to README.md (in a git hook), and then commit README.md, which will be rendered as HTML on git.sr.ht. Another option is to set a custom README.

Here's how we render the README for hyperdrive.el on git.sr.ht by setting a custom README:

Makefile + build script

The Elisp for exporting README.org to HTML goes in a Makefile, which simplifies the packaging process, since there's no extra .el file for linters and compilers to complain about. Credit for the idea to use a Makefile goes to Jonas Bernoulli.

Add a file called Makefile at the root of your project (hyperdrive.el Makefile):

EMACS := emacs
EMACSQ := $(EMACS) -Q
BATCH := $(EMACSQ) --batch \
          --eval '(setq vc-handled-backends nil)' \
          --eval '(setq org-startup-folded nil)' \
          --eval '(setq org-element-cache-persistent nil)' \
          --eval '(setq gc-cons-threshold (* 50 1000 1000))'

README.html: README.org
        $(BATCH) --find-file $< --eval "(require 'ox-html)" \
          --eval '(org-html-export-to-html nil nil nil t)'

The build script installs hut and emacs, clones your repo, exports README.html, and sets the custom README. Add a file called readme.yml in the .builds/ subdirectory of your project (hyperdrive.el .builds/readme.yml):

image: archlinux
oauth: git.sr.ht/REPOSITORIES:RW git.sr.ht/PROFILE:RO
packages:
  - hut
  - emacs-nox
sources:
  - https://git.sr.ht/~ushin/hyperdrive.el
tasks:
  - update-readme: |
      cd hyperdrive.el
      make README.html
      hut git update --readme README.html

I hope this helps you. Feel free to contact me with suggestions, corrections, or questions!

Acknowledgements

Thank you to Thorben Günther, for this example git repo which shows how to set a custom README.

Footnotes

1

Requests for Org-mode README rendering support on git.sr.ht: Mar 2020 Feb 2021 Oct 2021 Jan 2022 June 2022 May 2024 Dec 2024