The Block Protocol provides a specification for the interaction between web blocks and applications using them: how data structures are typed and passed around, and what data operations are available to blocks.
Its ultimate goal in doing so is to enable any blocks to be usable by any web application without any configuration or human intervention, once both are compliant with the Protocol.
More information on the motivation can be found in the specification overview.
The Block Protocol’s focus is on defining the interface between web blocks and applications using them.
It does not specify what happens to data once it crosses that boundary - it only seeks to standardise application-block interaction.
We do not believe that any existing protocol or specification serves the need of defining the interface between web blocks and embedding applications.
There are efforts which do so for a particular ecosystem (e.g. Microsoft Loop) — but none which improve the web as a whole. The Block Protocol is a generic contract which can be implemented by any web application.
Various frontend libraries and technologies provide means of implementing encapsulated blocks (e.g. React, Web Components) — but they do not standardise the interface between those blocks and the applications using them (e.g. the operations available to them).
Our focus is on supporting the web first and foremost, as this is the context we expect the Block Protocol to be most useful in. Implementation details will vary across contexts — for example, the details of how data can be passed around or operations called — but the general principles of the Block Protocol in defining a contract between applications and embedded blocks are applicable beyond the web. In the future we intend to support non-web contexts more directly.
Developers may build blocks to add functionality they want to applications that implement the Block Protocol.
They may also be motivated by the sorts of factors that motivate anyone to build open-source software: challenge, competition, fun, reputation, and the desire to contribute to and be part of a community.
Implementing the Block Protocol means that an embedding application can easily add new functionality, increasing its value to users.
Once they are Block Protocol-compliant, applications can easily search for blocks which can visualize or edit any type of data, and add them without any further configuration.
HASH’s mission is to help everybody make the right decisions. Part of how we do this is by making it easier to bring data together in a form that allows information to be understood and used both by humans and machines (e.g. other applications).
We started life as a simulation platform, offering insights from modelling the world to anyone with a browser. But this is just one way to get insight from data, and simulation models can be greatly enhanced when built atop the sort of timely, structured information that the Block Protocol makes accessible.
The Block Protocol advances HASH’s mission by encouraging both data itself and the tools that edit and visualize data to be structured and portable. This makes it easier to work with more data in more places, and unlocks more functionality for more users, increasing the ability for people to understand and learn from the world.
Blocks can be published to the Block Hub to make them browsable on blockprotocol.org, and to make their metadata and source code available via our API.
Entity data can be hosted in any application which implements the Block Protocol - we are developing one such application, HASH, which will be in public beta in the Spring.
Blocks can fetch their own data from external services. For example, a map block might fetch data from a mapping service.
We believe the best blocks will communicate data back and forth with the embedding application, making use of the operations defined in the spec.
For example, a mapping block which persists a user’s choices about map positioning or styling back to the application – all without the application having to know anything about the block, or the block having to know anything about the application.
Blocks can have their own local state - they might use this to allow users to explore data or draft changes, without saving anything.
To save data beyond the session, blocks should make use of the operations defined in the spec to send updates to the embedding application.
The Block Protocol standardizes how data requests are made between a block and an embedding application.
Web Components can describe the events they dispatch programmatically, but each one can be different. This means that you often need to know the details of how of a specific element operates in order to implement it. The goal of the Block Protocol is to make it so that new blocks can be added to an application without any configuration or without having to learn how they handle data.
We currently describe Web Components as one way of implementing Block Protocol blocks, and we are exploring how to best build on top of the existing Web Component technology - including potentially making them a recommended / default way of defining the application-block interface.
We believe blocks should provide neutral, minimal styling of their own, and leave it to embedding applications to provide additional styling - this might be in the form of an entire stylesheet for blocks to load, or style variables which can be selectively applied.
There is ongoing discussion on this topic - we welcome your views.
Blocks composed of other blocks is an important feature which we believe the Block Protocol must support, and which we have begun exploring.
A simple example is a ListBlock which is composed of a list of other blocks, and for which it has placeholders within it.
Blocks which are made up of other blocks may be referred to as “compound blocks”. We will be publishing example compound blocks soon.
The goal of the Semantic Web is to make internet data machine-readable.
It involves making sure there is data on web pages which can be parsed by machines, in order to determine the entities described, and their links to other entities elsewhere on the web.
The Block Protocol requires that the data passed between blocks and applications is in the form of entities conforming to a defined structure: a schema.
This structure can then be used to include data on web pages which describes the entities in a machine-readable way.
For example, where a page contains a block displaying a movie, machine-readable data would also be included describing the various properties of the movie (e.g. releaseDate), as well as linking to other pages which describe entities linked to it - e.g. its director.
One way of representing entities in a machine-readable way is in JSON-LD which describes entities and their link to other entities). Here’s an example of such a representation, taken from the JSON-LD homepage:
{
"@context": "https://json-ld.org/contexts/person.jsonld",
"@id": "http://dbpedia.org/resource/John_Lennon",
"name": "John Lennon",
"born": "1940-10-09",
"spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}
No, and for the most part the Block Protocol itself does not define the structure of entities passed between blocks and applications. Instead it specifies how entities should be defined, transmitted and updated.
The Block Protocol specifies that JSON Schema should be used to describe the properties of an entity and expected types of property values - not what those properties should be.
You can use existing schema.org schemas, or can create new schemas through the Block Protocol website, once logged in. The schema creator on the Block Protocol website aims to make it easier for users to define the different types of data structures that their blocks will work with.
We don’t prescribe canonical types for any thing, but do recommend that users link their schemas and properties to schema.org types and properties where possible, to help in making the pages that use their schemas machine-readable. We have included a way of doing so in our schema editor. Mapping different schemas and their properties to one another is a process known as ‘crosswalking’.
schema.org defines a collection of schemas for use in making the data on web pages machine-readable.
The Block Protocol does not define the structure of entities passed between blocks and applications - it only specifies how they are transmitted and updated.
Implementers of the Block Protocol could use the structure of entities as defined by schema.org, if they wished (e.g. a block could be built to render or edit a schema.org Event).
We recommend that users link their schemas and their properties to schema.org types and properties where possible, and have included a way of doing so in our schema editor.
There are two different types of ‘crosswalking’ we intend to support in the Block Protocol:
Crosswalking from JSON schema properties to schema.org (and equivalent) properties, in order to make rendered pages machine-readable - as described above, supported in the schema editor, and mentioned in the spec here. The purpose of this is to mark up web pages with structured data describing the entities within.
Crosswalking from JSON schema properties to other JSON schema properties, in order for applications to understand that seemingly incompatible schemas may in fact be compatible, and to translate between them. For example, if one Table schema has a 'rows' property, and another Table schema has a 'records' property, declaring that the two are equivalent allows applications to translate data conforming to the first Table schema for use in places where data conforming to the second Table schema is expected. This mitigates the impact of different approaches being taken to describe the same data.
Crosswalking?
Mapping different schemas and their properties to one another is a process known as ‘crosswalking’.
It helps machines more easily understand how new schemas fit in to existing knowledge graphs and ontologies.
Schemas are central to our vision for the Block Protocol.
We don’t believe that a single set of schemas provided by any one standards organization (even schema.org) can ever perfectly fit all use cases, and as such the ability to create new schemas is important. When doing this, we want to make them as accessible to machines (and people) as possible.
The Block Protocol website includes a schema editor that provides a convenient way to define new entity types used by or with blocks and their embedding applications. These are then hosted persistently and made accessible via the same content delivery network that serves blocks from the Block Protocol Hub, guaranteeing their availability and discoverability.
Who can see my schemas?
All schemas created on the Block Protocol website are currently public. In future we’ll support the creation of private schemas as well.
schema.org provides a great base ontology for defining lots of types of ‘things’ out there in the world.
givenName and a familyName and yet in various cultures this isn’t guaranteed. HASH uses preferredName and legalName instead - in communications and billing contexts respectively. You can view the HASH ‘Person’ schema at https://blockprotocol.org/@hash/types/Person and see how it crosswalks with the canonical definition of a person provided by Schema.org. This is just one example of how custom schemas can be made to relate back to the core ontology provided by Schema.org.JSON Schema has a rich vocabulary for validating data. We designed the Block Protocol with content management systems and collaborative workspaces in mind, and being able to define precise constraints for data is important for those applications.
We expect to have to add custom keywords to cover relationships which JSON Schema does not have in its core vocabulary (e.g. that a property is inverseOf another), but believe it will be easiest to start with JSON Schema and add keywords, rather than start with another vocabulary and add the required validation to it.
We encourage applications to include JSON-LD describing entities on their public pages to make them machine-readable.
In theory, the Block Protocol could use JSON-LD as the format in which entities are passed between applications and blocks. We did not pursue this because we believe it will be easier and more scalable to handle links between entities outside the JSON for the entity itself, as described here. We have also taken a different approach to identifying entities, which may not have a public URI and may require a combination of fields to identify.
GraphQL provides a “syntax and system for describing [application] data requirements and interactions”, whereas the Block Protocol is specifying a particular set of interactions: those between a block and any application embedding it.
It would be possible to define the operations specified in the Block Protocol in GraphQL - e.g. createEntity - or to extend the GraphQL spec to include them.
We do not yet believe it necessary to specify block-application requests in GraphQL syntax nor require that they be executed by the embedding application according to the GraphQL specification, although we are open to the idea. It may become more attractive as operations evolve to include more features already covered by GraphQL (e.g. subscriptions, selection sets).