Conversation

5/ BP blocks can *read data* from the apps they’re embedded in, and send suggested updates back. Blocks declare what kind of data they expect to receive (numbers, strings, email address) & what they can do with it (display, transform) Which leads us to structured data…
A web app with blocks inside. An arrow shows that the web app's database can send data to the blocks inside it, and a dashed arrow in the other direction shows a block can send suggested updates back to the database.
A diagram of the UI structure of a block showing slots where an image, name, and a set of three tasks can fit. We also see a diagram of the data structure the block expects to receive; it expects a Person object that has a picture, a name, and a tasklist.
1
26
6/ One lofty, formidable dream we’re going after with the BP is to help enable the semantic web. The possible data types that BP blocks accept aren’t just numbers and strings. They also recognise things humans would recognise as types: Person, Company, Book, Movie, etc.
A list of human-friendly types blocks might accept that includes Person, Book, Movie, Company, Article, Game, Festival, Restaurant, Recipe, Flight, and Map. We also see a diagram of the "Recipe" and "Flight" types going into two blocks that visually display their data inside of blocks.
2
48
7/ We can define these human types with β€˜schemas’ – sets of properties and values. Eg. A β€œflight” schema would have properties like β€œdepartureAirport” and β€œflightNumber” This enables us to build specialised blocks that display specific kinds of data. Blocks like…
A diagram of the schema for a flight showing the typical properties a flight might have; a departure time, a flight number, an airline, and a departure and arrival airport.
We see this schema pointing towards a JSON file that holds the values of these properties inside it. Eg. departure airport: "LHR".
We then see than JSON object being passed into a block component that renders it with a graphical display of the flight number, destination, and a small map of the flight path.
2
24
9/ There’s been a πŸ¦†-ton of previous work on schemas & the semantic web. We’re not reinventing any wheels. We’re respectfully building off previous art. People can use existing schemas (eg. schema.org), BUT we also let people extend schemas and define their own…
2
22
10/ There is no perfect, universal schema system, and never will be. Human categories & hierarchies are subjective, fluid, & always evolving. People will use schemas that make sense to them, then extend & adapt schemas to fit their needs. It’s a free-schema-world…
2
24
12/ To recap: We now have a standard way… to create reusable blocks… that can read / write semantic data… and be used in any app that opts into the ecosystem. Which saves us from block fortresses. And blocks create structured data by default, without devs manually doing it.
4
20
This looks interesting, what is the difference between the block protocol and web components? developer.mozilla.org/en-US/docs/Web I noticed the docs say react only at the moment which leads me to believe they are not web component based. If not, why not use this standard?
1
1
Curuous why web components are not the primary choice? What's the reasoning? They are the lingua franca of the web, and seem like the obvious choice (to my ignorant, outsider perspective). They don't need to be pre-registered by name, that could be left for the consuming app
1
Our reasoning was not wanting to be too prescriptive about how blocks are defined, but – as with everything in the spec – we're open to changes, and will be revisiting this area as a priority given the strength of feedback on it (precisely why we're making this public early!)
3
2
Show replies