We will introduce the following new services to the Block Protocol to support additional functionality that requires application-block cooperation.
A generalized approach to capturing user actions could involve a service 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 service to provide the user’s preferred locale to blocks. Please see the GitHub discussion.
A service to provide the user’s location to blocks (with appropriate safeguarding).
The styling service 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 service (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 service 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.
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.
Applications may implement some services only, or implement part of a service only (e.g. allowing
createEntity but not
Many blocks will require certain services, and parts of services.
Blocks will not work in applications that do not implement the services they require, and the parts of services they require. If there is a mismatch which is not identified prior to a block being selected for use, they may crash or be non-functional at the point of use.
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 services and parts of services they require.
The most detailed version of this would be for blocks to be able to:
requires: "graph"), and
We’re intending to move away from entities having to fully describe the constraints of each of their properties. Instead, type definitions are going to become shareable and reusable in a new type system which establishes a hierarchy of types to address a number of shortcomings in our current system. For in-depth motivation, a proposed implementation plan, and the wide-reaching implications please see the RFC.
We intend to move to a cursor-based method for paginating aggregations of 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.
Anyone with an existing application who wants to embed semantically-rich, reusable blocks in their product can use the protocol. Improve your app’s utility and tap into a world of structured data with no extra effort, for free.