BCF — BIM Collaboration Format

The three things BCF moves

The viewpoint is what makes BCF more than a ticket system: it pins the exact components — by IFC GlobalId — so the recipient opens the model on the same problem, not a screenshot of it. Stable GUIDs across model versions are the prerequisite; see IFC.

Two transport shapes

Versions

Why BCF exists at all

Without BCF, model coordination degrades into emailed screenshots and "the wall near the stair on the second floor". BCF replaces that with a portable, tool-neutral object that any compliant viewer can open on the exact geometry. It is the openBIM answer to the question "what is wrong, where, who owns it, and what was decided" — the human layer on top of IFC.

Mapping to signed events

BIM-CVP carries BCF as signed events, not as a file locked in one CDE. The current topic state is addressable, comments and audit records are append-only, and snapshots or attachments ride along as NIP-94 file events keyed by hash.

kind:30900  BCF Topic (addressable, replaceable)
  d: <topic-guid>
  tags: [
    ["a",        "<project-ref>"],
    ["status",   "Active"],            # Closed, ReadyForReview, …
    ["bcf-priority", "High"],
    ["p",        "<assignee-pubkey>"]
  ]
  content: { title, description, type, due_date }

kind:30901  Viewpoint   → immutable camera + selected IFC GUIDs + snapshot hash
kind:1170   Comment     → references the topic, signed by its author
kind:1171   Audit       → status, assignment and approval changes
kind:1063   Snapshot    → NIP-94 file event, integrity by sha256

Viewpoints follow the BCF rule: they are immutable. If the camera, selection, clipping plane or snapshot changes, the client creates a new viewpoint GUID and links it to the topic. Every topic state change also gets a signed audit event; the audit trail is the signature chain, not a database row anyone can edit. The detailed event mapping is on the BCF to Nostr events page; the full registry is on kind mapping; the signing model is in Nostr basics.

In BIM-CVP, the browser client creates and reads these topics, comments and viewpoints as signed events. This page is the BCF data model behind that workflow.

Practical pitfalls

• GUID churn. If the authoring tool regenerates IFC GlobalIds on re-export, every BCF viewpoint loses its component binding. Fix the GUID discipline in the BAP first.
• Version mismatch. Sender writes 3.0, receiver reads 2.1. Negotiate the BCF version explicitly, support both.
• Snapshot-only topics. A picture with no selected components is a screenshot, not a viewpoint — always pin the GUIDs.
• Round-trip merges. Two parties edit the same exported .bcfzip. Prefer an API or signed-event flow where order and authorship are unambiguous.

Sources

• buildingSMART BCF standard
• BCF-XML specification
• BCF-API specification
• Nostr NIP-01 event model
• Nostr NIP-94 file metadata