The Block Protocol(blockprotocol.org)
blockprotocol.org
The Block Protocol
https://blockprotocol.org/
153 comments
I was surprised to find out by Googling that by “Joel”, you actually mean Joel Spolsky: https://www.joelonsoftware.com/2022/01/27/making-the-web-bet...
I think that link is worth reading because it offers a more concise write-up of the project’s motivation.
I think that link is worth reading because it offers a more concise write-up of the project’s motivation.
Presumably no more than a dozen HN readers will understand that comparison, but now that I know he is involved, I wonder if Blocks are basically meant to be a reincarnation of ActiveX controls for the modern web.
ActiveX was what sprang to my mind as well. But I only gave the website the most superficial look.
The earliest call for something like this that I am aware of is Douglas McIlroy’s 1968 paper calling for “Mass Produced Software Components” which he delivered at the NATO Science Committee, Garmisch, Germany.
It is not exactly what Block Protocol is all about, but it is good reading nonetheless, and most of it still holds true over 50 years later and it does provide additional perspective on how Blocks could be used: https://www.cs.dartmouth.edu/~doug/components.txt
It is not exactly what Block Protocol is all about, but it is good reading nonetheless, and most of it still holds true over 50 years later and it does provide additional perspective on how Blocks could be used: https://www.cs.dartmouth.edu/~doug/components.txt
Assuming this[0] is the Solid you mean, as a potential disambiguation for folks.
Are you able to comment on your perception of Loop as an implementation of the original vision for Fluid?
[0]https://solidproject.org/
Are you able to comment on your perception of Loop as an implementation of the original vision for Fluid?
[0]https://solidproject.org/
Ironic that the schema.org approach basically matches the Waterken server schema model from 2003. Tyler Close was ahead of his time.
The idea that you can create blocks that can easily be integrated into other applications presupposes that it's a desirable thing to have data that can be easily integrated into other applications.
Which, for us as developers, seems like a given.
But when you look at it through the lens of business users, that becomes a much more murky assumption.
Look at RSS. Amazing way to aggregate content from other sources into a viewer that you have robust control over. Developers love it!
But is RSS desirable from a business point of view? The landscape over the past 15 years suggests that no, it's not.
Businesses would prefer to build walled gardens. They want complete control over the experience of consuming the content they produce, particularly when it comes to analytics and user data generated from that content. In many cases, their business model depends on it.
While the Block site touts this protocol as a way to collaboratively build and share things within a community and ecosystem that runs on cooperative principles, that may be at odds with what our current business environment is incentivizing.
Which, for us as developers, seems like a given.
But when you look at it through the lens of business users, that becomes a much more murky assumption.
Look at RSS. Amazing way to aggregate content from other sources into a viewer that you have robust control over. Developers love it!
But is RSS desirable from a business point of view? The landscape over the past 15 years suggests that no, it's not.
Businesses would prefer to build walled gardens. They want complete control over the experience of consuming the content they produce, particularly when it comes to analytics and user data generated from that content. In many cases, their business model depends on it.
While the Block site touts this protocol as a way to collaboratively build and share things within a community and ecosystem that runs on cooperative principles, that may be at odds with what our current business environment is incentivizing.
> Businesses would prefer to build walled gardens. They want complete control over the experience of consuming the content they produce, particularly when it comes to analytics and user data generated from that content.
Not only that, they want to actively prevent others from benefiting. Amazon shipping notification emails used to list the products included, but now it's just basically a link to the website. Can't let email providers, plugins, or 3rd party software have an easy way to view that data!
Personally, I'm most disappointed in the non-answer that is their "Security": https://blockprotocol.org/spec/embedding-applications#securi...
Not only that, they want to actively prevent others from benefiting. Amazon shipping notification emails used to list the products included, but now it's just basically a link to the website. Can't let email providers, plugins, or 3rd party software have an easy way to view that data!
Personally, I'm most disappointed in the non-answer that is their "Security": https://blockprotocol.org/spec/embedding-applications#securi...
We’ve spent a lot of time thinking and talking to folks about the incentive structures around this, and think they stand on their own - although your skepticism was an initial worry we had, too. As it stands the Block Protocol enables embedding applications to make their products more useful to consumers. And block developers reach a wider audience with their tools than they would otherwise. There’s a lot more to this that we’ll write up nicely later.
I can see how, if you get to critical mass, the network effect will drive adoption. For example, building a Blocks-based project management system becomes much, much easier if it can tie into one of many (hypothetical) Blocks-based HR information systems, so that you can pre-populate a list of employees at the company. As much as big companies love lock-in, there's tremendous potential value in enabling small companies to build open value-add tools that focus on solving a narrow problem extremely well.
Nail on the head with the walled garden comment.
I've been developing all sorts of web scrapers for 10 years now and businesses will go to extreme lengths to share the bare minimum required. You can really see that if you look at schema.org adoption - the only used fields are the ones that are required by seo. For example, schema's Person object can contain dozens of useful fields but most websites will provide name only even though the rest of the data is available in page content.
Public data is a long lost battle.
I've been developing all sorts of web scrapers for 10 years now and businesses will go to extreme lengths to share the bare minimum required. You can really see that if you look at schema.org adoption - the only used fields are the ones that are required by seo. For example, schema's Person object can contain dozens of useful fields but most websites will provide name only even though the rest of the data is available in page content.
Public data is a long lost battle.
> The idea that you can create blocks that can easily be integrated into other applications presupposes that it's a desirable thing to have data that can be easily integrated into other applications.
> Which, for us as developers, seems like a given.
Also as power users. And I mean that in the broadest sense. I mean, as a 16 year old I already understood and liked the idea of OLE.
By pretending it is only for devs we limits its potential in everyones minds. Don't do that unless you want to preserve the current somewhat sad state of affairs.
> Which, for us as developers, seems like a given.
Also as power users. And I mean that in the broadest sense. I mean, as a 16 year old I already understood and liked the idea of OLE.
By pretending it is only for devs we limits its potential in everyones minds. Don't do that unless you want to preserve the current somewhat sad state of affairs.
> Businesses would prefer to build walled gardens. They want complete control over the experience of consuming the content they produce, particularly when it comes to analytics and user data generated from that content. In many cases, their business model depends on it.
Business seem very happy to share business data (user analytics) with Google, via Google Analytics.
Business seem very happy to share business data (user analytics) with Google, via Google Analytics.
I have been asked to implement RSS but private please, more than once :)
One way to look at it could be that protocols create potential (sowing) and businesses exploit that potential (harvesting). Without the protocols I believe some of the walled gardens would also be impossible.
The best example i can think of is email, which created opportunities for businesses for events, ecommerce, login systems, etc.
To be clear, you think that a standard data format and protocol is not worthwhile because some organizations don't release data?
Standardized data formats and protocols exist already - see Linked Data and the Semantic Web. They're mostly used by non-commercial data providers because of the aforementioned incentive problem.
What does this have to do with anything though? Why is another standard a problem to people who don't even care about the problem it solves?
Linked data is actually heavily used by commercial entities, especially by video websites. This is because Google uses it for rich search results and they see value in exposing the information for that purpose.
It is nowhere near universal, but it seems to be growing and I hope it continues.
It is nowhere near universal, but it seems to be growing and I hope it continues.
[deleted]
I don't think there ever will be actual support from current major tech companies for such an endeavor, their business models are all about information and development lock-in, either explicitly or implicitly... I think it would have to start with academia and technical content, just like it did for the web (as I understand it)
Blog post from Joel Spolsky introducing this.
https://www.joelonsoftware.com/2022/01/27/making-the-web-bet...
https://www.joelonsoftware.com/2022/01/27/making-the-web-bet...
This is, as others have commented, a much better explanation than the article at the top of this thread.
But I'm not sure it's quite as simple as Joel makes it seem here:
> If you work on any kind of editor—be it a blogging tool, a note-taking app, a content management system, or anything like that—you should allow your users to embed blocks that conform to the Block Protocol. This way you can write the embedding code once and immediately make your editor able to embed a rich variety of block types with no extra work on your part.
I don't see how this would work. Sure, the data would be embeddable anywhere, but how does the editor know how to display it to the user and let the user interact with it? That's not just "embedding code". And later on:
> Want to create a block that shows the Great Circle routing for a flight between two airports? Write the code for the block once and it can be embedded anywhere.
Again, how does the application it's being embedded in know how to display it to the user? That seems like it requires more than just "embedding code". Each new kind of block requires each application to add code to use the block.
I agree the data exchange interoperability part is nice, but I'm not sure about the code reduction that seems to be implied here.
But I'm not sure it's quite as simple as Joel makes it seem here:
> If you work on any kind of editor—be it a blogging tool, a note-taking app, a content management system, or anything like that—you should allow your users to embed blocks that conform to the Block Protocol. This way you can write the embedding code once and immediately make your editor able to embed a rich variety of block types with no extra work on your part.
I don't see how this would work. Sure, the data would be embeddable anywhere, but how does the editor know how to display it to the user and let the user interact with it? That's not just "embedding code". And later on:
> Want to create a block that shows the Great Circle routing for a flight between two airports? Write the code for the block once and it can be embedded anywhere.
Again, how does the application it's being embedded in know how to display it to the user? That seems like it requires more than just "embedding code". Each new kind of block requires each application to add code to use the block.
I agree the data exchange interoperability part is nice, but I'm not sure about the code reduction that seems to be implied here.
Reading The Fine Manual here : (https://blockprotocol.org/spec) - blocks are expected to include code to render the block information in a displayable format. So, a block isn't just the data model, it's also the view layer. Some options suggested in the spec include React, vanilla HTML, and Web Components. This part feels a little mushy at the moment, since there's no proposal yet for how a Block identifies which rendering context it expects.
> Some options suggested in the spec include React, vanilla HTML, and Web Components.
Ah, ok. So the code is only expected to run in a browser, not an arbitrary application. Although since the spec is open, I have no doubt there will be efforts to write code for handling blocks in non-browser applications.
Ah, ok. So the code is only expected to run in a browser, not an arbitrary application. Although since the spec is open, I have no doubt there will be efforts to write code for handling blocks in non-browser applications.
At the moment, yes - we want to figure out the principles of application/block interaction in a web context first, and then move on to other environments. The principles should be transferable, although some of the 'how are they implemented' won't be (https://blockprotocol.org/docs/faq#what-about-non-web-contex...)
The comment above you is right that 'handling blocks implemented in different ways' (in a web context) is one of the mushier parts of the spec, and it's something we need to do more prototyping and refinement of.
The comment above you is right that 'handling blocks implemented in different ways' (in a web context) is one of the mushier parts of the spec, and it's something we need to do more prototyping and refinement of.
Ok, thanks for this information, it's very helpful.
I imagine there will be some JS libraries you can drop in to render various block types. I don't think that will solve all problems, but it makes it so the protocol doesn't need to specify a presentation layer. Otherwise you may as well use iframes...
We will be providing these, yes - we want to minimise the amount of work embedding applications have to do in setting themselves up to render blocks, as well as making it easier for block authors to write them.
Is it a better explanation? After reading this I still don't know where the UI code or "editor" state is hosted, or who are the parties to the supposed "protocol". If none of these are questions the "block protocol" is intended to answer, what makes it more interesting or in any way different from a UI framework?
The parties to the protocol (in this early form, with a web focus) are:
1) an application which is generating a web page, and
2) a block of functionality which is part of that page.
Or the authors of each.
Where is state?: blocks can have their own local state, but to persist data beyond the session should make use of the operations defined in the spec to pass data back to the application (the standardisation of what these operations are and what they do is a key part of the spec).
Where is the UI code?: I might've misunderstood this question, but - a block should have a package which contains code for rendering its UI and dealing with data to/from the application embedding it. The application can then either pull that code at runtime (e.g. from a CDN) when a user requests to use a certain block, or include it as a library and ship it with the application.
Or the authors of each.
Where is state?: blocks can have their own local state, but to persist data beyond the session should make use of the operations defined in the spec to pass data back to the application (the standardisation of what these operations are and what they do is a key part of the spec).
Where is the UI code?: I might've misunderstood this question, but - a block should have a package which contains code for rendering its UI and dealing with data to/from the application embedding it. The application can then either pull that code at runtime (e.g. from a CDN) when a user requests to use a certain block, or include it as a library and ship it with the application.
Interesting idea but more questions than answers...
The 'block' idea makes sense in the context of WordPress, but WordPress 'blocks' include layout blocks as well as content blocks.
You could argue HTML is already a universal language that includes semantic 'blocks'. Is the block protocol a collection of HTML elements grouped together to form higher-level blocks?
Will content 'blocks' be separated from style? What role will CSS component frameworks take in styling content blocks?
We have embedded content from third-party parties already e.g. a tweet 'block', a YouTube video, an Instragram post, etc. The result is embedded 'blocks' stitched together to make a slow-loading page with a mess of HTML and CSS code (and a host of third-party cookies). How can the block protocol avoid this?
As I said, interesting idea but many questions remaining at this early stage.
The 'block' idea makes sense in the context of WordPress, but WordPress 'blocks' include layout blocks as well as content blocks.
You could argue HTML is already a universal language that includes semantic 'blocks'. Is the block protocol a collection of HTML elements grouped together to form higher-level blocks?
Will content 'blocks' be separated from style? What role will CSS component frameworks take in styling content blocks?
We have embedded content from third-party parties already e.g. a tweet 'block', a YouTube video, an Instragram post, etc. The result is embedded 'blocks' stitched together to make a slow-loading page with a mess of HTML and CSS code (and a host of third-party cookies). How can the block protocol avoid this?
As I said, interesting idea but many questions remaining at this early stage.
> You could argue HTML is already a universal language that includes semantic 'blocks'. Is the block protocol a collection of HTML elements grouped together to form higher-level blocks?
That's part of how blocks are implemented, but we already have higher-level blocks made from HTML elements in the form of Web Components, and various JS libraries.
The protocol is aimed at building on this to standardise how those higher-level blocks communicate with the applications using them.
> Will content 'blocks' be separated from style? What role will CSS component frameworks take in styling content blocks?
This is an area of the spec we need to develop - the goal is a light-touch way of blocks appearing visually consistent with the application around them, while leaving the rest up to the block. The current proposal is some kind of theme variables the application can pass to the block for use, but needs more thinking - https://blockprotocol.org/spec/block-types#styling - and we appreciate any thoughts.
How can the block protocol avoid [issues with current embeds]?
Partly by focusing on standardising how you pass data back and forth between the block and the application: blocks which aren't of the application, and don't need to know about it, but allow users to edit data that lives in the application.
Agree that slow loading is an issue to address, which is easier to deal with when you control all the source code, less so when you're pulling in blocks from elsewhere - the first step in this is for blocks to be able to leave the provision of common libraries to the embedding application, so that each block isn't shipping React (or whatever).
That's part of how blocks are implemented, but we already have higher-level blocks made from HTML elements in the form of Web Components, and various JS libraries.
The protocol is aimed at building on this to standardise how those higher-level blocks communicate with the applications using them.
> Will content 'blocks' be separated from style? What role will CSS component frameworks take in styling content blocks?
This is an area of the spec we need to develop - the goal is a light-touch way of blocks appearing visually consistent with the application around them, while leaving the rest up to the block. The current proposal is some kind of theme variables the application can pass to the block for use, but needs more thinking - https://blockprotocol.org/spec/block-types#styling - and we appreciate any thoughts.
How can the block protocol avoid [issues with current embeds]?
Partly by focusing on standardising how you pass data back and forth between the block and the application: blocks which aren't of the application, and don't need to know about it, but allow users to edit data that lives in the application.
Agree that slow loading is an issue to address, which is easier to deal with when you control all the source code, less so when you're pulling in blocks from elsewhere - the first step in this is for blocks to be able to leave the provision of common libraries to the embedding application, so that each block isn't shipping React (or whatever).
This explains it a lot better than the OP. (At first I was wondering if it had to do with "blockchain", because of the word "block" and the OP seeming like the kind of "solution in search of a problem" I associate with blockchain).
But now I get it. Standardized content plugins across apps, basically?
Sure, makes sense. I wish I thought any of the platforms involved were interested in making any investment at all in interoperability.
But now I get it. Standardized content plugins across apps, basically?
Sure, makes sense. I wish I thought any of the platforms involved were interested in making any investment at all in interoperability.
Various are interested in making their platforms more extensible (the flip side of content interop).
This blog post refers to block in WordPress but I don't quite understand whether there is expected to be an actual connection. Is there a process that would lead to a Block Protocol block being usable in the WordPress editor?
Yes, as a first step we’re planning a WP plugin: https://hash.ai/blog/open-sourcing-hash
Further downstream we hope to be able to work with the Gutenberg team and to contribute more directly.
Further downstream we hope to be able to work with the Gutenberg team and to contribute more directly.
Strong Xanadu vibes. Not surprising to see, since at least one of the people involved isn't new to trudging through the history of hypertext and has several Xanadu writeups. (See the backlinks on <https://maggieappleton.com/garden-history>.)
I feel like "You can move things from one to-do app to another to-do app!" is not really a compelling answer to the question "Why would I want to build blocks with the Block Protocol".
One use case might be for federated chat. Rich media can exist as blocks and remain chat client agnostic.
Relevant XKCD: https://xkcd.com/927/
What are the existing standards?
HTML, JSON, iframes
The HTML and JSON standards don't get close to this by themselves.
I don't think iframes really do it either, but even if they do nobody uses them that way and a replacement seems okay. It's not really a "competing standard" if nobody wanted to use it.
I don't think iframes really do it either, but even if they do nobody uses them that way and a replacement seems okay. It's not really a "competing standard" if nobody wanted to use it.
If you look at https://blockprotocol.org/hub and can survive the <5fps (yikes!), you can see that they've demonstrated reimplementations of <p>, <img>, <h1> by piling mountains of Javascript/JSON on what is (hopefully?) just those standard HTML elements under the hood.
If I have to pick between standard slow-moving HTML and wild west HTML-reimplemented-in-React, I will choose the former every time. I will never have to worry about "my <p> has been abandoned by its maintainer and is now malware!".
If I have to pick between standard slow-moving HTML and wild west HTML-reimplemented-in-React, I will choose the former every time. I will never have to worry about "my <p> has been abandoned by its maintainer and is now malware!".
Exactly this. There may not be a 'standard' that does any of this already, but the goal of this being portable across websites requires all of those websites to support this 'new' standard -- so there probably isn't a way this becomes wide spread enough to be useful.
Relatedly, this follows the Notion model, where the UI is intrinsically tied to and limited by the data model. This may have appeal to developers who already are primed to think that way, but it's a terrible UI paradigm for everyone else.
Relatedly, this follows the Notion model, where the UI is intrinsically tied to and limited by the data model. This may have appeal to developers who already are primed to think that way, but it's a terrible UI paradigm for everyone else.
Like many others, one of the first things I thought of. This ain’t Mr. Spolsky‘s first rodeo, he must know of this specific xkcd!
The naming, given 2022’s technology landscape, is also super confusing. Block… no chain, but is it related? Or is this the payment platform formerly known as Square and they released some protocol???
Nope - It basically a React component library/package manager - ReactComponentHub. I do hope it works well, but like many, doubtful from previous examples in the past.
The naming, given 2022’s technology landscape, is also super confusing. Block… no chain, but is it related? Or is this the payment platform formerly known as Square and they released some protocol???
Nope - It basically a React component library/package manager - ReactComponentHub. I do hope it works well, but like many, doubtful from previous examples in the past.
I came here for this comment
I knew what xkcd it was just by looking at the link. Lol
That's because people whip it out constantly and almost always where it's not appropriate. It's pretty rare that anyone tries to enact a new standard. So, instead we see this comic use to downplay every time that anyone does anything resembling anything that has ever been done before. Which is to say: to downplay everyone else's efforts. It has long gone past being funny to just being dismissive in it's widespread use.
Yeah, it seems like it shows up any time a standard is suggested, which is taking a two sentence premise and ignoring 2/3 of it.
I am torn on this. On the one hand I believe very strongly in the value that the semantic web can provide, and I applaud any effort to move us towards a future where we can more reliably interop between different applications on the web. I hope this pushes the needle in that direction.
On the other hand, there is a very crowded graveyard of spiritual ancestors to this project, all of which were aspiring to similar goals. I am not seeing much direct acknowledgement here of why those other projects failed, or measures to prevent that from happening with the Block protocol.
One common problem in semantic web projects, which Block doesn't seem immune to, is that the authors of those projects seem to get stuck thinking about how to model the presentational components on a given web page (lists, forms, images, calendar widgets) instead of the actual real-world stuff that these things represent (the books on my shelf, my allergies, a picture of my dog, my birthday). Don't get me wrong, richly-typed presentational components would be a big improvement. But I don't think they should be the end goal (unless perhaps you're in the blog-writing software business).
Web pages are just one of many vehicles that we use for shuttling around information about the real world. We should try to come up with a system that is capable of representing real-world semantic information regardless of how that information ends up getting turned into pixels. It may be a web page, it may be Siri reading it to me, it may be AR.
But when modeling real-world data, we always seem to walk into traps such as this (from the Block FAQ):
> On other occasions you’ll want to store information differently than how it’s set out in the schema.org definition. For example, schema.org/Person defines a person as having a 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.
How do we design a semantic typing system for real-world data that is amenable to the inevitable need to evolve or amend the schema, or leave off certain fields from a type instance, or tack on a few extra fields? Should our applications eschew canonical types (like schema.org's Person) in favor of a ducktyping approach (I don't care if you give me a schema.org Person, or a blockprotocol.org Person, or a notpachet.org Dog, as long as the blob has a numeric field for the "age" key?
On the other hand, there is a very crowded graveyard of spiritual ancestors to this project, all of which were aspiring to similar goals. I am not seeing much direct acknowledgement here of why those other projects failed, or measures to prevent that from happening with the Block protocol.
One common problem in semantic web projects, which Block doesn't seem immune to, is that the authors of those projects seem to get stuck thinking about how to model the presentational components on a given web page (lists, forms, images, calendar widgets) instead of the actual real-world stuff that these things represent (the books on my shelf, my allergies, a picture of my dog, my birthday). Don't get me wrong, richly-typed presentational components would be a big improvement. But I don't think they should be the end goal (unless perhaps you're in the blog-writing software business).
Web pages are just one of many vehicles that we use for shuttling around information about the real world. We should try to come up with a system that is capable of representing real-world semantic information regardless of how that information ends up getting turned into pixels. It may be a web page, it may be Siri reading it to me, it may be AR.
But when modeling real-world data, we always seem to walk into traps such as this (from the Block FAQ):
> On other occasions you’ll want to store information differently than how it’s set out in the schema.org definition. For example, schema.org/Person defines a person as having a 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.
How do we design a semantic typing system for real-world data that is amenable to the inevitable need to evolve or amend the schema, or leave off certain fields from a type instance, or tack on a few extra fields? Should our applications eschew canonical types (like schema.org's Person) in favor of a ducktyping approach (I don't care if you give me a schema.org Person, or a blockprotocol.org Person, or a notpachet.org Dog, as long as the blob has a numeric field for the "age" key?
> Don't get me wrong, richly-typed presentational components would be a big improvement. But I don't think they should be the end goal (unless perhaps you're in the blog-writing software business).
At this early stage we'd be delighted with a big improvement in component standardisation/typing, and for now we're focusing on building on existing ways of representing semantic information in order to achieve that. I agree that there's a lot of scope beyond that for improvements.
> How do we design a semantic typing system for real-world data that is amenable to the inevitable need to evolve or amend the schema, or leave off certain fields from a type instance, or tack on a few extra fields? Should our applications eschew canonical types (like schema.org's Person) in favor of a ducktyping approach (I don't care if you give me a schema.org Person, or a blockprotocol.org Person, or a notpachet.org Dog, as long as the blob has a numeric field for the "age" key?
We may be indulging in cake-and-eat-it-ism, but we think the Block Protocol can allow for both.
The proposal is for the structure of entities to be represented in JSON Schema. As JSON Schema is just a set of constraints, you can take a blob of data and calculate 'does this data meet this set of constraints' (i.e. structural/duck typing). So if a Block has a schema which says that it requires a single field 'age: number', it doesn't matter what class the data you have belongs to, you can throw it into the block if it has that field. We have an API that will accept data objects and respond with blocks which have a schema the data is consistent with (not necessarily matches).
This doesn't preclude limiting certain operations/blocks to _only_ data which is linked/belongs to a specific schema/type (i.e. nominal typing), rather than simply satisfying its constraints. And there are circumstances in which not dealing with additional fields that a type might have is an issue, although for presentational or editing blocks that don't claim to be a 1:1 map onto a specific type, I think it's fine and useful for them to be able to present/edit a subset of fields from various types.
At this early stage we'd be delighted with a big improvement in component standardisation/typing, and for now we're focusing on building on existing ways of representing semantic information in order to achieve that. I agree that there's a lot of scope beyond that for improvements.
> How do we design a semantic typing system for real-world data that is amenable to the inevitable need to evolve or amend the schema, or leave off certain fields from a type instance, or tack on a few extra fields? Should our applications eschew canonical types (like schema.org's Person) in favor of a ducktyping approach (I don't care if you give me a schema.org Person, or a blockprotocol.org Person, or a notpachet.org Dog, as long as the blob has a numeric field for the "age" key?
We may be indulging in cake-and-eat-it-ism, but we think the Block Protocol can allow for both.
The proposal is for the structure of entities to be represented in JSON Schema. As JSON Schema is just a set of constraints, you can take a blob of data and calculate 'does this data meet this set of constraints' (i.e. structural/duck typing). So if a Block has a schema which says that it requires a single field 'age: number', it doesn't matter what class the data you have belongs to, you can throw it into the block if it has that field. We have an API that will accept data objects and respond with blocks which have a schema the data is consistent with (not necessarily matches).
This doesn't preclude limiting certain operations/blocks to _only_ data which is linked/belongs to a specific schema/type (i.e. nominal typing), rather than simply satisfying its constraints. And there are circumstances in which not dealing with additional fields that a type might have is an issue, although for presentational or editing blocks that don't claim to be a 1:1 map onto a specific type, I think it's fine and useful for them to be able to present/edit a subset of fields from various types.
Oh look, someone reinvented semantic web again.
We want to fit into the existing semantic web tech rather than reinvent it - there's a FAQ here which hopefully helps to clarify: https://blockprotocol.org/docs/faq
Kudos, this really feels like one of those ideas whose time has come.
I'm tinkering on something very similar for longer than I care do admit, except I took on the daunting task of replacing RDF, and I'm sufficiently disillusioned by years of frontend work to base the UI off of TUIs and HyperCard.
One thing that I experienced as a huge hurdle for semantic web technology is the lack of browser APIs to actually work with RDF/JSON-LD/Semantic Web data. There's really no complete and straightforward way to transfer, store and query semantic data in the fronted. JSON-LD works around this by exposing the graph as a tree regular old JS can work with, but that looses a lot of the flexibility and power of the original graph model, e.g. path independence and proper queries.
I'll definitely keep an eye on how your ideas and solutions evolve!
One thing that I experienced as a huge hurdle for semantic web technology is the lack of browser APIs to actually work with RDF/JSON-LD/Semantic Web data. There's really no complete and straightforward way to transfer, store and query semantic data in the fronted. JSON-LD works around this by exposing the graph as a tree regular old JS can work with, but that looses a lot of the flexibility and power of the original graph model, e.g. path independence and proper queries.
I'll definitely keep an eye on how your ideas and solutions evolve!
Thank you!
If you have any learning from your own work you'd care to share, or thoughts on ours, please drop by the repo (https://github.com/blockprotocol/blockprotocol) or Discord (https://blockprotocol.org/discord)
If you have any learning from your own work you'd care to share, or thoughts on ours, please drop by the repo (https://github.com/blockprotocol/blockprotocol) or Discord (https://blockprotocol.org/discord)
Exactly what I was thinking. The Semantic Web done the heavy lifting of defining general schemas (https://schema.org) and extending JSON (https://json-ld.org) and yet people don't subscribe to it. On the other hand, it has a lot of historical baggage (RDF, old schemas) that maybe a new standard can actually be better
Why is RDF a bad thing?
* Layers upon layers of complexity: Implementing CURIs alone is a non trivial task, although all that's really needed to describe entities and attributes is 128bit UUIDs.
* There is no good build-in way for authentication and trust.
* Description Logic (the foundation of OWL) has a fundamentally prescriptive philosophy, which makes it inappropriate for most practical applications.
* No good library and tool support in general, due to the complexity.
* Blank Nodes
* No good consistency mechanism for distributed data generation, and Quads (having multiple graphs) don't properly solve this.
* Using human readable entity and attr id's leads to more bike-shedding and accidental collisions than it's worth.
* High barriers to entry.
* After years of developer disappointment the earth is pretty much salted.
* There is no good build-in way for authentication and trust.
* Description Logic (the foundation of OWL) has a fundamentally prescriptive philosophy, which makes it inappropriate for most practical applications.
* No good library and tool support in general, due to the complexity.
* Blank Nodes
* No good consistency mechanism for distributed data generation, and Quads (having multiple graphs) don't properly solve this.
* Using human readable entity and attr id's leads to more bike-shedding and accidental collisions than it's worth.
* High barriers to entry.
* After years of developer disappointment the earth is pretty much salted.
What you've outlined above is a common misconception about RDF. Here's another way of looking at RDF:
An abstract data definition language for structured data represented as entity relationship graphs. Basically, the same Entity-Attribute-Value model that's existed for eons plus the addition of formalized identifiers (i.e., IRIs) for denoting entities, attributes, and values.
That's it!
RDF Schema, OWL Ontology, etc.. are simply Data Dictionaries comprising terms that describe Entity Relationship Types.
Related:
[1] Understanding Data -- https://www.slideshare.net/kidehen/understanding-29894555
[2] RDF based Linked Data, Ontologies, and KnowledgeGraph -- https://www.linkedin.com/pulse/linked-data-ontologies-knowle...
An abstract data definition language for structured data represented as entity relationship graphs. Basically, the same Entity-Attribute-Value model that's existed for eons plus the addition of formalized identifiers (i.e., IRIs) for denoting entities, attributes, and values.
That's it!
RDF Schema, OWL Ontology, etc.. are simply Data Dictionaries comprising terms that describe Entity Relationship Types.
Related:
[1] Understanding Data -- https://www.slideshare.net/kidehen/understanding-29894555
[2] RDF based Linked Data, Ontologies, and KnowledgeGraph -- https://www.linkedin.com/pulse/linked-data-ontologies-knowle...
Ignoring the fact that the underlying semantics of that data description are still fundamentally misguided and broken...
What you've outlined is the common misconception by the Semantic Web community about what constitutes a living and workable software ecosystem. It's the classical architecture-astronauts fallacy of ignoring this age old truth: The medium is the message.
The "but RDF only specifies the semantics of abstract graph data, all the serialisation formats are just implementation defined incidentals" argument is at the root of why there are thousands pages of specifications and 0 high quality semantic web libraries or tools. It's like saying "no, no, no, you misunderstand JSON/XML/YAML/ASN.1 it is not a (flawed?) serialisation format, it is a data model for trees, which works on any text processing capable system", true, but a straw-man.
Developers and Ontologists flocking to Protege, OWL API and Jena, is akin to dehydrated animals flocking to the last muddy and barely drinkable water-hole. They have no choice and it's mostly sh*t.
Everybody is still editing XML files by hand, there is no maintained, complete, production ready library for any language, and most of the stuff that does exist is either the cadaverous remain of a publicly funded science grant or an obscure project developed by a lone consultant who made peddling the semantic web his livelyhood without any real community.
People have to be able to use a system, and then actually use it in order to be meaningful, theoretical what ifs are irrelevant.
What you've outlined is the common misconception by the Semantic Web community about what constitutes a living and workable software ecosystem. It's the classical architecture-astronauts fallacy of ignoring this age old truth: The medium is the message.
The "but RDF only specifies the semantics of abstract graph data, all the serialisation formats are just implementation defined incidentals" argument is at the root of why there are thousands pages of specifications and 0 high quality semantic web libraries or tools. It's like saying "no, no, no, you misunderstand JSON/XML/YAML/ASN.1 it is not a (flawed?) serialisation format, it is a data model for trees, which works on any text processing capable system", true, but a straw-man.
Developers and Ontologists flocking to Protege, OWL API and Jena, is akin to dehydrated animals flocking to the last muddy and barely drinkable water-hole. They have no choice and it's mostly sh*t.
Everybody is still editing XML files by hand, there is no maintained, complete, production ready library for any language, and most of the stuff that does exist is either the cadaverous remain of a publicly funded science grant or an obscure project developed by a lone consultant who made peddling the semantic web his livelyhood without any real community.
People have to be able to use a system, and then actually use it in order to be meaningful, theoretical what ifs are irrelevant.
"CURIs"?
A standard for shorter URI/URN identifiers: https://www.w3.org/TR/curie/
It's needed because of the "readable resource name" criterion I also mentioned. Most of the complexity in RDF is actually not in the datamodel but leaks in from other parts of the web.
It's needed because of the "readable resource name" criterion I also mentioned. Most of the complexity in RDF is actually not in the datamodel but leaks in from other parts of the web.
As far as I'm concerned its most damning property is being all about relations but having no easy way to express properties of those relations.
It's easy to express "<something> isa <cat>", but significantly harder to express "<something> isa <cat> with probability 98%". And all attempts to express the later just look like you're trying to build an impromptu relational database in order to fit an n-ary relationship.
It's easy to express "<something> isa <cat>", but significantly harder to express "<something> isa <cat> with probability 98%". And all attempts to express the later just look like you're trying to build an impromptu relational database in order to fit an n-ary relationship.
<person> <has_diagnosis> <diagnosis>
<diagnosis> <diagnosis_type> <ADHD>
<diagnosis> <diagnosis_probability> <high>
<diagnosis> <diagnosis_type> <ADHD>
<diagnosis> <diagnosis_probability> <high>
well done!
I don't know how much that counts but every time I had to interact with RDF data I wanted to pull my eyeballs out of my sockets pretty much for the whole thing. Also, the idea that human knowledge can be categorized seems very laughable to me - I don't know of any RDF specification or ontology that holds in practice ; too many people have too many incompatible definitions for things and there is never one better than the others.
So you are not really arguing that human knowledge cannot be categorized.
In fact you are sort of arguing the opposite: Human knowledge lends itself so well to categorization that a single ontology is impossible (if it was really hard to categorize, there would be no or few ontologies).
In fact you are sort of arguing the opposite: Human knowledge lends itself so well to categorization that a single ontology is impossible (if it was really hard to categorize, there would be no or few ontologies).
Yes, but that's a deeper problem with the very concept of ontologies and not with RDF itself. As long as you keep the scope limited, that is you do not try to "categorize all human knowledge ever, consistently", ontologies can be used effectively.
Maybe, finally a useable iteration of it.
But with an inherent dependency on an additional abstraction. Why a "block" when we already have a Document with many Elements that should have semantic meaning applied directly to them?
Most likely because getting major browsers to adopt further changes can be challenging.
Well it does use RDF and probably has the same problem, was it `foaf:Person` or `schema:Person` or maybe even `ai:reificatedConceptNr1234`.
The security issue really should be front and center in a project like this. It's kind of disappointing to see it left as an exercise for the embedder.
In the general case with untrusted 3rd party code the only really safe solution is to embed the blocks in cross-origin iframes. In the face of Spectre and Meltdown you really want those to be out-of-process iframes too, but that's up to the browser.
iframes are cumbersome of course, so it would have been interesting to see the protocol focus on making them more seamlessly integrate with the embedding context with a standard postMessage protocol for things like securely forwarding content sizes (for auto-resizing the frame), events, and styling information across the frame boundary.
In the general case with untrusted 3rd party code the only really safe solution is to embed the blocks in cross-origin iframes. In the face of Spectre and Meltdown you really want those to be out-of-process iframes too, but that's up to the browser.
iframes are cumbersome of course, so it would have been interesting to see the protocol focus on making them more seamlessly integrate with the embedding context with a standard postMessage protocol for things like securely forwarding content sizes (for auto-resizing the frame), events, and styling information across the frame boundary.
> iframes are cumbersome of course, so it would have been interesting to see the protocol focus on making them more seamlessly integrate with the embedding context with a standard postMessage protocol for things like securely forwarding content sizes (for auto-resizing the frame), events, and styling information across the frame boundary.
That is one approach - what we've experimented with is having applications load their own thin 'block handler' code in an iframe, which then renders the block and does the message passing with the parent window. This way blocks don't have to know whether they're framed or not, and applications can choose not to frame blocks, e.g. because they're all trusted and they don't want the additional overhead.
As David says, very interested in any and all thoughts on this subject, as it's important to get right. Like many aspects of the spec, the thinness of the current material is more a reflection of the early stage of the project than a view that it is unimportant / doesn't need further work.
That is one approach - what we've experimented with is having applications load their own thin 'block handler' code in an iframe, which then renders the block and does the message passing with the parent window. This way blocks don't have to know whether they're framed or not, and applications can choose not to frame blocks, e.g. because they're all trusted and they don't want the additional overhead.
As David says, very interested in any and all thoughts on this subject, as it's important to get right. Like many aspects of the spec, the thinness of the current material is more a reflection of the early stage of the project than a view that it is unimportant / doesn't need further work.
This is a fair criticism of the public spec in its current form and we’re working on documentation to help folks deal with this.
We actively want to talk approaches through with more interested parties, and welcome contributions to the spec and docs.
Sidebar — for our part at HASH - we’re optimistic about the role WebAssembly might play, having used it extensively in building the wider ecosystem of simulation tooling.
We actively want to talk approaches through with more interested parties, and welcome contributions to the spec and docs.
Sidebar — for our part at HASH - we’re optimistic about the role WebAssembly might play, having used it extensively in building the wider ecosystem of simulation tooling.
How does the Block Protocol differ from or add to Web Components? Is it the standardization of how structured data that can be passed with the blocks?
Based on what I can gather from the documentation I think the answer is basically: Yes, it’s the structured data.
My initial confusion came from looking at Block Hub [1] which appears to be a collection of UI components. But the underlying Block Protocol specification [2] is all about structuring data around entity types and entity identifiers. Looking at a specific example of a block [3] the UI component is displayed next to the underlying data and schema.
My guess is the creators of Block Protocol want to promote the free exchange of structured data and decided that coupling the data to UI components is the best way to do that? It’s notable that the web has faced challenges encouraging use of both structured data (Semantic Web) and UI components (Web Components). Maybe they can be more appealing bundled together.
I do hope the Block Protocol project tries as much as possible to reuse existing standards for data and components, building upon whatever we have that already works well.
[1]: https://blockprotocol.org/hub
[2]: https://blockprotocol.org/spec
[3]: https://blockprotocol.org/@hash/image
My initial confusion came from looking at Block Hub [1] which appears to be a collection of UI components. But the underlying Block Protocol specification [2] is all about structuring data around entity types and entity identifiers. Looking at a specific example of a block [3] the UI component is displayed next to the underlying data and schema.
My guess is the creators of Block Protocol want to promote the free exchange of structured data and decided that coupling the data to UI components is the best way to do that? It’s notable that the web has faced challenges encouraging use of both structured data (Semantic Web) and UI components (Web Components). Maybe they can be more appealing bundled together.
I do hope the Block Protocol project tries as much as possible to reuse existing standards for data and components, building upon whatever we have that already works well.
[1]: https://blockprotocol.org/hub
[2]: https://blockprotocol.org/spec
[3]: https://blockprotocol.org/@hash/image
This is correct: it's the standardization of the interface between blocks and things using them, which includes structure in the data being passed back and forth, and the structure of the interface itself (e.g. what operations are available).
We do want to promote the free exchange of structured data, and to have data captured and marked up according to some structure - we also want to promote the portability and easy-of-setup of UI components.
Our FAQ illustrates how we relate to and intend to use existing standards - https://blockprotocol.org/docs/faq - we'd be interested in any others you think worth building on.
We do want to promote the free exchange of structured data, and to have data captured and marked up according to some structure - we also want to promote the portability and easy-of-setup of UI components.
Our FAQ illustrates how we relate to and intend to use existing standards - https://blockprotocol.org/docs/faq - we'd be interested in any others you think worth building on.
If you want to promote portability, then blocks should be web components based, full stop. React-based blocks won't be usable without setting up React on the page.
I think the FAQ around leaves a lot more open questions. Like:
> but they do not standardize the interface between those blocks and the applications using them
I'm not sure this is entirely true. Most reusable components these will have an interface described by a type system - this is how IDEs offer code completion and JSX and other template systems are type-checked.
In the Web Components Community Group we're also standardizing a format for describing the entire interface of a web component, including its attributes, properties, events, methods, CSS variables and parts, etc. This is called the Custom Element Manifest: https://github.com/webcomponents/custom-elements-manifest
Instead of being tied to json-ld, the manifest just documents what JS/TS type a property, etc., has. If a component has a person property that accepts a Person type, a tool can understand that.
This manifest will give tools like catalogs, linters, and visual UI builders enough information to do high-level operations like generate demos, lint templates, assemble components without code, etc.
I think the FAQ around leaves a lot more open questions. Like:
> but they do not standardize the interface between those blocks and the applications using them
I'm not sure this is entirely true. Most reusable components these will have an interface described by a type system - this is how IDEs offer code completion and JSX and other template systems are type-checked.
In the Web Components Community Group we're also standardizing a format for describing the entire interface of a web component, including its attributes, properties, events, methods, CSS variables and parts, etc. This is called the Custom Element Manifest: https://github.com/webcomponents/custom-elements-manifest
Instead of being tied to json-ld, the manifest just documents what JS/TS type a property, etc., has. If a component has a person property that accepts a Person type, a tool can understand that.
This manifest will give tools like catalogs, linters, and visual UI builders enough information to do high-level operations like generate demos, lint templates, assemble components without code, etc.
> If you want to promote portability, then blocks should be web components based, full stop. React-based blocks won't be usable without setting up React on the page.
As it stands we're reluctant to dictate the internal implementation of a block, on the assumption that we can abstract away dealing with different implementations - but I agree that the extra requirements for non-native implementations are a downside. We're also conscious of multiple implementation approaches potentially leading to fragmentation, with React-implemented blocks limited to applications who are happy to ship React, and other variations. It's a tricky balance to strike between freedom for the block author (i.e. can they implement it how they want, or must they use X) and work for the embedding application (how many different flavours of block implementation do they need to deal with - albeit we can provide libraries for this).
> Most reusable components these will have an interface described by a type system - this is how IDEs offer code completion and JSX and other template systems are type-checked.
Right - the components describe their interface, but there's no standardization of the shape of the interface. e.g. the format for Web Components you describe allows components to describe their methods, but the Block Protocol aims to standardize what the methods actually are - so that you don't need to read the API of a component to plug it into your app or understand what the methods do.
I believe the two projects are entirely compatible and complementary: a Web Component could have a thin wrapper around it to convert its methods to the expected name/signature specified by the Block Protocol. But I don't think Web Components as they are, in isolation, meet the aims of the BP.
As it stands we're reluctant to dictate the internal implementation of a block, on the assumption that we can abstract away dealing with different implementations - but I agree that the extra requirements for non-native implementations are a downside. We're also conscious of multiple implementation approaches potentially leading to fragmentation, with React-implemented blocks limited to applications who are happy to ship React, and other variations. It's a tricky balance to strike between freedom for the block author (i.e. can they implement it how they want, or must they use X) and work for the embedding application (how many different flavours of block implementation do they need to deal with - albeit we can provide libraries for this).
> Most reusable components these will have an interface described by a type system - this is how IDEs offer code completion and JSX and other template systems are type-checked.
Right - the components describe their interface, but there's no standardization of the shape of the interface. e.g. the format for Web Components you describe allows components to describe their methods, but the Block Protocol aims to standardize what the methods actually are - so that you don't need to read the API of a component to plug it into your app or understand what the methods do.
I believe the two projects are entirely compatible and complementary: a Web Component could have a thin wrapper around it to convert its methods to the expected name/signature specified by the Block Protocol. But I don't think Web Components as they are, in isolation, meet the aims of the BP.
I think you're misunderstanding web components: Web components aren't an internal implementation - they can have any internal implementation the author wants to use - they're an external interface.
You can build web components with React, Svelte, Lit, Stencil, or just vanilla JS. Given that blocks need an interface, it'd be nice to extend a standard with whatever else you need rather than go completely parallel to the standard.
You can build web components with React, Svelte, Lit, Stencil, or just vanilla JS. Given that blocks need an interface, it'd be nice to extend a standard with whatever else you need rather than go completely parallel to the standard.
I appreciate that you can use whatever JS you want when constructing custom elements.
To date we've been looking at how apps can deal with different ways in which blocks can be exposed to the app, but haven't ruled out specifying that they must be exposed in a fixed way - this would make it more consistent, at the cost (which may well be small and largely automatable) of requiring authors to wrap their block, e.g. with a custom element definition.
I'd be interested to talk in more detail about how that might work with relation to the current web component spec and future plans / other work in train: [email protected] if you're up for it
To date we've been looking at how apps can deal with different ways in which blocks can be exposed to the app, but haven't ruled out specifying that they must be exposed in a fixed way - this would make it more consistent, at the cost (which may well be small and largely automatable) of requiring authors to wrap their block, e.g. with a custom element definition.
I'd be interested to talk in more detail about how that might work with relation to the current web component spec and future plans / other work in train: [email protected] if you're up for it
As many have stated here, the problem is not that there aren't good data exchange protocols in the world, the problem is the PROTOCOL or the MODEL by which the world works, which is maximizing financial profit, not civilizational profit. Humanity is not yet capable of acting as a whole, we're still in a paradigm where each part is trying to rule the other parts. With this kind of mindset, a territorial mindset, it's only logical that every actor out there is trying to control as much as it can, and create an advantage for itself. That's why no sharing and cooperation data protocol catches, because those are incompatible with the current state of Affairs.
Many have tried - very recently - and seemingly stalled or failed at creating something like this with wide adoption, most notably Tim Berners-Lee with the SOLID protocol
https://solidproject.org/
https://solidproject.org/TR/protocol
The roadblock is always getting major tech companies to accept it as a valid means of accessing user data.
The amount of times I've heard about SOLID on NPR or other popular mainstream newscasts only to garner little to no support is astounding. Definitely take note where others have seemingly failed here because it's an uphill battle.
https://solidproject.org/
https://solidproject.org/TR/protocol
The roadblock is always getting major tech companies to accept it as a valid means of accessing user data.
The amount of times I've heard about SOLID on NPR or other popular mainstream newscasts only to garner little to no support is astounding. Definitely take note where others have seemingly failed here because it's an uphill battle.
The real difference is the mindshare.
joelonsoftware has bajillion readers, but he is much better known for founding stackoverflow.
When SO endorses something, it will got a lot of mindshare, and becomes something that developers feel connected to.
And with enough mindshare, the same project that would have been dead in the water becomes a given.
joelonsoftware has bajillion readers, but he is much better known for founding stackoverflow.
When SO endorses something, it will got a lot of mindshare, and becomes something that developers feel connected to.
And with enough mindshare, the same project that would have been dead in the water becomes a given.
this is an excellent point
Sort of tangent, but the fact that Block Protocol is also managing the distribution of the resulting UI components, unlike Solid which encouraged people to consume the data independently through an API, makes it more accessible.
Sort of tangent, but the fact that Block Protocol is also managing the distribution of the resulting UI components, unlike Solid which encouraged people to consume the data independently through an API, makes it more accessible.
Personally my hesitancy in embracing Solid is the complexity. What I really want is essentially an HTTP filesystem API for my programs. Like a modern WebDAV to replace Google Drive. All the linked data stuff might be useful down the road but I currently don't need it.
[deleted]
Not the same thing, this "Block protocol" is for HTML widgets basically, re-usable HTML/CSS/JS components for sites/apps.
https://news.ycombinator.com/item?id=30105910
At its heart, it is very similar.
Comment above does a good job at describing the distinction. It's more than just re-usable HTML/CSS/JS, that's just how they're making it accessible to others. There are entities associated with the HTML/CSS/JS mapped alongside the component, which is the core benefit here.
https://blockprotocol.org/spec for more info on how they're mapping data as entities
At its heart, it is very similar.
Comment above does a good job at describing the distinction. It's more than just re-usable HTML/CSS/JS, that's just how they're making it accessible to others. There are entities associated with the HTML/CSS/JS mapped alongside the component, which is the core benefit here.
https://blockprotocol.org/spec for more info on how they're mapping data as entities
Back in the dot-com era we had "portal servers" which were basically a way to build a dashboard. This seems like a related idea? Put blocks in multiple columns and you have a dashboard.
Maybe it will do better this time? But I feel like mobile phones went in the opposite direction with UI's designed for smaller screens, showing only one app at a time.
We do have lots of documents and notebooks though. Maybe Observable's notebooks would benefit from something like this?
Observable's notebooks let you define variables containing data and use them in other places, with live updates. It seems like you'd want something like that with blocks.
Maybe it will do better this time? But I feel like mobile phones went in the opposite direction with UI's designed for smaller screens, showing only one app at a time.
We do have lots of documents and notebooks though. Maybe Observable's notebooks would benefit from something like this?
Observable's notebooks let you define variables containing data and use them in other places, with live updates. It seems like you'd want something like that with blocks.
Interesting, especially since Joel Spolsky seems to be involved. Would like to see a comparison to microformats[0], RDFa, etc.
[0]: https://microformats.org/wiki/Main_Page
[0]: https://microformats.org/wiki/Main_Page
Sometimes software projects become a parody of the industry, this feels like one of those times. Abstraction astronauting to the 10th power, "A block is structured data" okay so like nearly ANYTHING? "You can send structured data between apps"... so it's JSON. "But also things like images!" ok, so files you've reinvented files. Maybe there is something actually useful here but Christ nobody is going to know based on this website.
>> Why would I want to build blocks with the Block Protocol?
>> Blocks built with the Block Protocol can easily pass data between applications because the data within each block is structured.
Yeah, what you said. What's their problem? What better world do they imagine? What's the approach taken on their solution? Very poorly explained.
EDIT: Joel's article is much, much, much more convincing.
>> Blocks built with the Block Protocol can easily pass data between applications because the data within each block is structured.
Yeah, what you said. What's their problem? What better world do they imagine? What's the approach taken on their solution? Very poorly explained.
EDIT: Joel's article is much, much, much more convincing.
Funny you invoke astronauting, given that AFAIK Joel Spolsky (involved in this project) coined or at least popularized the term:
https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
[deleted]
So this seems to be a wrapper around web components, which might make web components easier to use in frameworks. By providing types, one could build a generator that takes a Block and creates a strongly-typed React/Vue/Svelte component, or even mobile components using a webview.
The Web Components Community Group is developing such a format to describe the types of components here: https://github.com/webcomponents/custom-elements-manifest
People have already built tools that generate wrappers based on it.
People have already built tools that generate wrappers based on it.
Stencil has this feature btw: build a web component and it can output the strongly-typed React/Angular/Vue bindings to consume it natively in those frameworks.
Can you elaborate on this? Why can't you make a generator for regular web components?
You can, but knowing a certain property on the web component is an integer isn't easy with static analysis alone. Somehow you need some more rigid way to declare types to guarantee all generated components can be strongly typed.
This kind of reminds me of https://adaptivecards.io/ from Microsoft.
Interesting timing! After more than 3 years of preaching this idea to every ear I could find, no one listened! So I've been building a whole 'block oriented backend as a service' for a while now. Basically "bring your own frontend"
Event driven, CQRS, with workflow orchestration of LEGO like microservices around block oriented data structures!
Not an easy system to architect and build, but efforts like this are not only great validation or motivators but a great reference to compare and contrast!
Event driven, CQRS, with workflow orchestration of LEGO like microservices around block oriented data structures!
Not an easy system to architect and build, but efforts like this are not only great validation or motivators but a great reference to compare and contrast!
How would your approach be similar to or different than Edge DB [1]? Sounds like much more orchestration around the DB layer?
[1] https://www.edgedb.com/blog/building-a-production-database-i...
[1] https://www.edgedb.com/blog/building-a-production-database-i...
After several iterations I settled on immutable data storage approach. Block data need to be versioned with full revision history, think note sharing apps like Notion.
Many Block initiatives have opted for immutable graph databases like Datomic (not open-source, nor cheap, nor performant at scale). Postgres has reverse recursive queries and graph indexing. Cassandra another option if you want a more flexible schema structure and a bit of time series spice mixed in.
Many Block initiatives have opted for immutable graph databases like Datomic (not open-source, nor cheap, nor performant at scale). Postgres has reverse recursive queries and graph indexing. Cassandra another option if you want a more flexible schema structure and a bit of time series spice mixed in.
To everyone that doesn't get it, think desktop UI controls, but for the web. Joel explains it clearly on the intro blog post: https://www.joelonsoftware.com/2022/01/27/making-the-web-bet...
The strongly typed data is about not scraping the web; its typing for software reading the blocks and reusing the data.
The strongly typed data is about not scraping the web; its typing for software reading the blocks and reusing the data.
Is the idea that you build your website out of the blocks of other websites?
As in TMZ and Techcrunch both publish something and you display their little blocks on your website? Is the data dynamic? It seems like there is data, and there is a block that can display said data.
How is this any different from a view and a model(+controller?)?
As in TMZ and Techcrunch both publish something and you display their little blocks on your website? Is the data dynamic? It seems like there is data, and there is a block that can display said data.
How is this any different from a view and a model(+controller?)?
The idea is more that you build your website out of blocks which allow the display or editing of defined data structures - so you search for blocks which are compatible with the data you want to work with (which can be done programmatically), and swap them around depending on what the user wants to do (display x, edit y).
The goal is that blocks can be dropped into applications to provide the functionality to display x or edit y, without requiring configuration, because the operations they will use to work with data, and the ways in which constraints/valid data are described, are common across all blocks and supporting applications.
The goal is that blocks can be dropped into applications to provide the functionality to display x or edit y, without requiring configuration, because the operations they will use to work with data, and the ways in which constraints/valid data are described, are common across all blocks and supporting applications.
Is there a way you could describe this more concretely? Say for the specific use case of a Football website.
For the case of a football website, you could have blocks which display or edit data which doesn't need to be tied to football specifically, but can be used to build/display the football website, e.g. (I'm just going to say 'display' but assume these can all 'edit' the same data):
- an 'Organization' block that displays an org name, logo, HQ location, etc (for displaying info on teams)
- a 'Table' block that takes any dataset and can allow you to sort, filter, the data in it (for displaying stats)
- an 'EventCalendar' block that takes a list of fixture dates and details, maybe allows you to view it as a list or on a calendar
these blocks wouldn't care that you were using them for football specifically - just that you were providing them data in the structure they can work with. We're not claiming that these generic blocks would do everything you wanted - but they'd get you a lot of the way there.
- an 'Organization' block that displays an org name, logo, HQ location, etc (for displaying info on teams)
- a 'Table' block that takes any dataset and can allow you to sort, filter, the data in it (for displaying stats)
- an 'EventCalendar' block that takes a list of fixture dates and details, maybe allows you to view it as a list or on a calendar
these blocks wouldn't care that you were using them for football specifically - just that you were providing them data in the structure they can work with. We're not claiming that these generic blocks would do everything you wanted - but they'd get you a lot of the way there.
This has nothing to do with Jack Dorsey's Block, right?
It looks like it's not. I thought it was block chain just from the title myself.
When someone finally combines blockchain with semantic web, it'll be an immovable object meeting an unstoppable force and cyberspace will implode.
ha ha, that was my first thought too
[deleted]
I have always wanted Kindle to support a lot more features than what it does today. Digital books could be a lot more than what they are today. Want to embed a python REPL in a python book for users to test things right in the book, from a common source? Want to embed function graphs in a Math book from a common source? How about a theorem prover right there in the book? How about a Wolfram engine embedded in there to solve arbitrary calculus problems? How about a section in another book - license it from the other publisher and embed it into your book? Embedding a video, a web page, a 3D visualization engine, etc should all be possible in a digital book.
Looks like this maybe able to achieve all of this. Just need to get Amazon Kindle team on board with this.
Looks like this maybe able to achieve all of this. Just need to get Amazon Kindle team on board with this.
FYI Kindle renders a subset of HTML[0]. They have deliberately chosen not to support everything because of security.
[0] - https://kdp.amazon.com/en_US/help/topic/GG5R7N649LECKP7U
[0] - https://kdp.amazon.com/en_US/help/topic/GG5R7N649LECKP7U
The idea is cool, but why would any major service support this? The whole point of every startup these days is to grow to the point where they can hog all the users on to their own proprietary platform. Interoperability is anathema to the modern way of thinking.
I think this is a really cool idea and something I have personally wanted (or at least thought I wanted) for a long time. In fact I wrote about a similar idea in 2013.[1]
To me, this is just one part of something bigger though. I want to be able to store code in blocks and compose them into bigger blocks by chaining them and pipelining them. I'd also like versioning and some access rules.
https://justindonato.com/notebook/urls-as-pointers.html
To me, this is just one part of something bigger though. I want to be able to store code in blocks and compose them into bigger blocks by chaining them and pipelining them. I'd also like versioning and some access rules.
https://justindonato.com/notebook/urls-as-pointers.html
I know this is a webdev project anyway, but I imagine embedding code would mean, in practice, embedding Javascript. Then the whole thing becomes 100% tied to the web and to modern browsers, which is a shame. Such blocks could be used from native applications, bots, or TUI programs, but that ship has probably sailed already.
We're focusing on the browser context at first, but expect the principles of the interface between a block and application (if not the implementation details) should be applicable to other environments - very briefly mentioned here https://blockprotocol.org/docs/faq#what-about-non-web-contex...
I'm interested in hiring people who want to not just invent but put into production a better way of doing that. Mostly I want people who think of the problem like that.
Email in profile...
Email in profile...
What would be really cool is if this concept could be expanded to allow a specific block on a website to be directly linked to. Currently, this is generally done by using a dom selector, which is super clunky and unreliable, since all it takes is for the id/class name to be changed for it to stop working.
Widgets are back!
[deleted]
I think this really needs to make clear that this is a protocol for client-side components that run in a web browser. It was very confusing until I read Joel's blog post.
oEmbed[1] meets Schema.org[2]?
[1] https://www.oembed.com
[2] https://schema.org
[1] https://www.oembed.com
[2] https://schema.org
So is there a sweet spot between microformats and Notion ?
(Disclosure: I work on Notion)
This is a really cool idea!
I think the challenging part of this project will be building intuitive and collaborative interfaces on top of the bare-bones data model. The challenge comes with two parts: (1) allowing blocks to compose, so I can nest a "task block" inside a "paragraph block", and (2) figuring out the collaboration model so multiple users can manipulate blocks at the same time, eg by typing characters. Both of these aspects are un(der)specified in the Block Protocol spec.
For an example of a challenge building composable blocks, consider the suggested architecture - the project imagines different block types implemented as sandboxed iframes, orchestrated by some editor that stitches them together into a document or dashboard. This would make certain interactions difficult/impossible to implement in the browser. For example, you can't start a text selection in one iframe, and end the text selection in the next iframe. This means that each layer will need to implement many of the standard blocks, just to provide tools that operate on the contents of more than one block at a time.
I'm left wondering if there will ever be "block protocol native" apps, or if this will be more of an interoperability/import/export format between otherwise monolithic platforms that have their own much richer internal data format.
This is a really cool idea!
I think the challenging part of this project will be building intuitive and collaborative interfaces on top of the bare-bones data model. The challenge comes with two parts: (1) allowing blocks to compose, so I can nest a "task block" inside a "paragraph block", and (2) figuring out the collaboration model so multiple users can manipulate blocks at the same time, eg by typing characters. Both of these aspects are un(der)specified in the Block Protocol spec.
For an example of a challenge building composable blocks, consider the suggested architecture - the project imagines different block types implemented as sandboxed iframes, orchestrated by some editor that stitches them together into a document or dashboard. This would make certain interactions difficult/impossible to implement in the browser. For example, you can't start a text selection in one iframe, and end the text selection in the next iframe. This means that each layer will need to implement many of the standard blocks, just to provide tools that operate on the contents of more than one block at a time.
I'm left wondering if there will ever be "block protocol native" apps, or if this will be more of an interoperability/import/export format between otherwise monolithic platforms that have their own much richer internal data format.
This is kind of orthogonal to what you guys are discussing, but I want a blog where new posts (and essays) can be drawn from a library of structured templates. Starting with the basic types in DITA, and then taking it forward. Extending tasks to recipes, for example. And an outline for product reviews. And outlines for (e.g.) software use cases and software requirements specs. And with templates having available all the microformats that the cool kids use.
Pardon my babble :)
Pardon my babble :)
(One of the BP maintainers here)
If you’d be open to exploring this in the context of Notion we’d love to chat: [email protected]
If you’d be open to exploring this in the context of Notion we’d love to chat: [email protected]
Blocks of data and the semantic rules for their creation (validation), reading, updated and deletion (CRUD), with composability, versioning and robust APIs?
That's a pretty succinct description of the Holochain project. Turns out that it is pretty powerful, once implemented. It isn't as simple as you might expect... :)
That's a pretty succinct description of the Holochain project. Turns out that it is pretty powerful, once implemented. It isn't as simple as you might expect... :)
Except it turns out that blocks and even block protocols were never actually blocked by the lack of a blockchain
How do you prove that a state-change occurred in a decentralized fashion?
Noob Question: How does this compares to an oEmbed.
"The Block Protocol is a global standard for building interactive blocks connected to structured data."
is this a W3C standard ? why are they claiming its a global "standard" '
is this a W3C standard ? why are they claiming its a global "standard" '
Damn I thought square came out with something
I've read and perused this, and I have some specific questions.
1. According to the spec[0], a "block package" is "a collection of files making a block type (which is 'a definition and implementation', the schema and the code) available for use by embedding applications, including its source code and accompanying metadata." However, when I browse to a "block"/"block package" in the Block Hub[1], I'm presented with a demo of the "block package" in the form of a concrete "block", a view of example data being provided to this "block", and a view of the schema of this "block". However, if this is meant to be a view of the "block package", shouldn't I also be able to find my way to the rest of this "block package", i.e. where do I view the implementation code? The spec says that a block package includes its source code, and the block hub seems to be a browser of block packages, but it doesn't give me the full view into said block packages. Is there a reason for this? Is it on the to-do list?
2. What's going on with the type signatures here? I see a lot of what look like type signatures, in both the spec and the schemas. In reading the spec, it seems like the type signatures are being used pretty loosely, maybe as pseudo code of a sort, as I don't see them being rigorously referred to. For example, I see that in "Specification > Block Types > Entity type functions"[2] under `createEntityTypes` it refers to accepting a type of "CreateEntityTypesAction" (no type signature), but then lower down it refers to accepting a type of "CreateEntityTypesAction<T>", but then says that the shape of that entity is just two hard-coded fields, with no reference to the generic type "T". What's going on here? Then if I view an actual block in the Block Hub[1], I see that the schema for that block also has definitions for entities with some kind of type signature 'something' going on e.g. "#/definitions/Record<string,{cellState:UseRowStateLocalState<{},unknown>;}>". Maybe those are for use with something like TypeScript? I'm not familiar with TypeScript, so I don't know how to parse those, though I do know that they're not specifying anything at the level of "JSON Schema"[3], so I assume they're related to either something in the spec or something in the implementation, or both. What's happening here? Are these types in the schema owned by the implementation (e.g. they're used by the source code of the implementation for JSX or something?), while the types in the spec are merely pseudocode?
If there's already a pattern where additional layers of features such as typing/templating are being shoved into the schemas of Blocks, might this make interop between blocks more difficult in the future?
[0] - https://blockprotocol.org/spec#terminology
[1] - https://blockprotocol.org/@hash/table
[2] - https://blockprotocol.org/spec/block-types#entity-functions
[3] - https://json-schema.org/
1. According to the spec[0], a "block package" is "a collection of files making a block type (which is 'a definition and implementation', the schema and the code) available for use by embedding applications, including its source code and accompanying metadata." However, when I browse to a "block"/"block package" in the Block Hub[1], I'm presented with a demo of the "block package" in the form of a concrete "block", a view of example data being provided to this "block", and a view of the schema of this "block". However, if this is meant to be a view of the "block package", shouldn't I also be able to find my way to the rest of this "block package", i.e. where do I view the implementation code? The spec says that a block package includes its source code, and the block hub seems to be a browser of block packages, but it doesn't give me the full view into said block packages. Is there a reason for this? Is it on the to-do list?
2. What's going on with the type signatures here? I see a lot of what look like type signatures, in both the spec and the schemas. In reading the spec, it seems like the type signatures are being used pretty loosely, maybe as pseudo code of a sort, as I don't see them being rigorously referred to. For example, I see that in "Specification > Block Types > Entity type functions"[2] under `createEntityTypes` it refers to accepting a type of "CreateEntityTypesAction" (no type signature), but then lower down it refers to accepting a type of "CreateEntityTypesAction<T>", but then says that the shape of that entity is just two hard-coded fields, with no reference to the generic type "T". What's going on here? Then if I view an actual block in the Block Hub[1], I see that the schema for that block also has definitions for entities with some kind of type signature 'something' going on e.g. "#/definitions/Record<string,{cellState:UseRowStateLocalState<{},unknown>;}>". Maybe those are for use with something like TypeScript? I'm not familiar with TypeScript, so I don't know how to parse those, though I do know that they're not specifying anything at the level of "JSON Schema"[3], so I assume they're related to either something in the spec or something in the implementation, or both. What's happening here? Are these types in the schema owned by the implementation (e.g. they're used by the source code of the implementation for JSX or something?), while the types in the spec are merely pseudocode?
If there's already a pattern where additional layers of features such as typing/templating are being shoved into the schemas of Blocks, might this make interop between blocks more difficult in the future?
[0] - https://blockprotocol.org/spec#terminology
[1] - https://blockprotocol.org/@hash/table
[2] - https://blockprotocol.org/spec/block-types#entity-functions
[3] - https://json-schema.org/
1) The spec says that a block package includes its source code, and the block hub seems to be a browser of block packages, but it doesn't give me the full view into said block packages. Is there a reason for this? Is it on the to-do list?
It's on the to-list indeed - we are going to add links to the source of blocks. The package for distribution will typically be minified and less illuminating, although we can look to expose that too (as well as making it available for request via the API when actually loading a block).
2) What's going on with the type signatures here?
The type signatures on functions in the spec definitely need cleaning up to be consistent and more helpful. They are pseudo-code. There are TypeScript types for them (https://github.com/blockprotocol/blockprotocol/blob/main/pac...) which won't be much use to you, but I am including in case they are of someone else.
The schema you mention in the Hub is autogenerated from the TypeScript interface for the block, which can lead to weird artefacts of the sort you identify. We need to add custom codegen to better handle this. It should valid JSON Schema.
It's on the to-list indeed - we are going to add links to the source of blocks. The package for distribution will typically be minified and less illuminating, although we can look to expose that too (as well as making it available for request via the API when actually loading a block).
2) What's going on with the type signatures here?
The type signatures on functions in the spec definitely need cleaning up to be consistent and more helpful. They are pseudo-code. There are TypeScript types for them (https://github.com/blockprotocol/blockprotocol/blob/main/pac...) which won't be much use to you, but I am including in case they are of someone else.
The schema you mention in the Hub is autogenerated from the TypeScript interface for the block, which can lead to weird artefacts of the sort you identify. We need to add custom codegen to better handle this. It should valid JSON Schema.
org-mode plugin when?
Historically, OpenDoc is pretty relevant. So is OLE. More recently Notion, Coda, Microsoft Loop [1], Anytype.io, etc lean on the same concepts to allow you to break documents into independent & reassemble-able components. There hasn't been a large ecosystem here, although the componentized approach has more traction now as we move away from skeuomorphism.
On the data side, Solid is the most relevant. The models are often the same, users give applications very granular data permissions and progressively authorize data access as required for additional functionality. Developers seem to dislike the model... You don't really know what you're going to be rendering and key features are not really used.
From a pure schema perspective, you have schema.org. It's a pretty comprehensive attempt to catalog structured data for most use cases. It's nice that this project can kinda build on the semantic web, but most people ignore it! That being said, adoption would go a long way towards interoperability between OSS projects.
I'd like to live in a world where everything works together? But I'm not so hopeful at this point because the ecosystem has very weird economics. Ultimately the "Block Developer" needs to be compensated, but the host is the one getting the SaaS or advertising payment. Obviously simple components can be free, but very complex ones may need micropayments, licensing fees, etc.
[1] I helped start Fluid Framework, which is the underlying tech for Microsoft Loop. These are just my opinions and I no longer work for Microsoft.