Our aim is to develop a new standard for building frontend components, or "blocks", whose styling and logic are cleanly separated from data. Learn more >
The "RFC" (Request For Comment) process provides a consistent and controlled path for new features to enter the protocol's specification. Many changes, including most bug fixes and documentation improvements can be implemented and reviewed without going through this process. However, when changes are considered "substantial" enough, we require that they first take shape as RFCs, are subject to community comment, and are designed in a way that produces broad agreement approved by the Block Protocol core team. This process serves to transparently document in detail the considerations behind major changes, and enables spec evolution to take place in a way that accounts for all community member's interests.
This link will be replaced with direct links to the RFCs on blockprotocol.org soon
We expect to introduce the following new modules to the Block Protocol to support additional functionality that requires application-block cooperation. We welcome suggestions for other modules that may be useful, via GitHub discussions or by creating RFCs.
A generalized approach to capturing user actions could involve a module whereby a block reports on which elements within it capture actions (e.g. a button), and embedding applications could choose to bind further actions to them as a response.
We want to facilitate users leaving comments on elements within blocks. This could be:
A module to provide the user’s preferred locale to blocks, for localization and internationalization. Please see the GitHub discussion. This module could be generalized to support passing other user-specific preferences or options which can be used to customize blocks (e.g. accessibility choices around font-size, or color vision deficiency).
A module to provide the user’s location to blocks (with appropriate safeguarding).
The styling module would involve the embedding application to communicate styling or theming data to blocks, to allow blocks to apply styling to make them appear more visually consistent with the application embedding them.
Please see the GitHub discussion for a discussion of what data might be transported as part of a styling module (e.g. a
styleObject, or a CSS file).
Much familiar functionality requires a reference to the current user, or being able to select from users in the system. For example:
A users module could help expose some of this data to blocks, with appropriate safeguarding and permissions sought.
While embedding applications can handle displaying an interface for reloading blocks at particular earlier versions, we will specify a way of communicating to blocks that (a) an earlier version is being displayed, and (b) the difference with the current version would allow blocks to implement visual diffs.
Block entry point: we currently provide that blocks can be exposed to applications in three different ways: as custom elements, HTML files, or React components. We may wish to reduce this to a single entry point. Please see the discussion for more.
In order to predict in advance whether a given block will work in a given application, it would be helpful for blocks to be able to indicate which modules and parts of modules they require.
The most detailed version of this would be for blocks to be able to:
requires: "graph"), and
Block-user authentication: we will be providing a mechanism for users to insert their own secrets for use when connecting to external services which require them to individually authenticate, in order to access their own private information within blocks (e.g. Coda).
Generic callback handler: we will be removing service/provider specific references from the specification and making the service module more readily extensible, in anticipation of allowing third-party providers to self-register additional services.
Currently, if a user wants to add additional information to an existing entity type, their only option is to make a brand new one and manually copy the structure. We'd like to add support for users to be able to "extend" types in a way that doesn't break existing entity types and allows for reusability across embedding applications and blocks. To allow for situations where a user wants to customize an entity type in a way that a non-compatible fashion, we want a mechanism to "duplicate" or "fork" an existing entity type. For in-depth motivation, a proposed implementation plan, and the wide-reaching implications please see the RFC.
We define six primitive data types in the Graph type system. These data types define value spaces for the inner properties of entities, and currently are limited to basic primitives such as "text" or "number". Building robust data models will require the ability to define constraints and define validation mechanisms (think maximum/minimum lengths on properties, or applying regular expressions to define the pattern of a string). We are thinking about implementing this through allowing the creation of non-primitive data types, built off the composition and extension of other data types coupled with a suite of supported constraints. You can read more about this in this RFC.
We intend to move to a cursor-based method for paginating results of querying entities, likely based on the Connections specification.
The Block Protocol does not seek to describe or prescribe the shape of particular entities (e.g. what fields a
Instead, it seeks to define the block-application interface.
This does, however, mean there is a possibility of competing schemas attempting to describe the same entities, which different blocks using different schema - reducing the portability of blocks.
The ability to translate between schemas would help - e.g. some way expressing an equivalence relationship between properties in different schema. This might be a keyword such as
equivalentTo mapping between schemas and their properties. Then, either blocks or embedding applications could programmatically translate between schemas.
Note that this is about translating between different JSON Schemas, and is not to be confused with the process of translating JSON schema to schema.org (and equivalent) types, which has an established technical approach mentioned here.