The Block Protocol is building on a pretty large history of similar ideas, but none have really succeeded. Joel's interest in this project is some cause for hope as is the embrace of existing standards like react, webcomponents, and HTML.
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.
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.
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
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.
> 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!
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.
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.
> 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.
> 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.
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.
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.
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)
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.
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.
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...
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?
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.
> 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).
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.
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?
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".
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.
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.
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?
> 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.
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!
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
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?
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.
> 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.
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.
Readit News
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.
I think that link is worth reading because it offers a more concise write-up of the project’s motivation.
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
Are you able to comment on your perception of Loop as an implementation of the original vision for Fluid?
[0]https://solidproject.org/
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.
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...
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.
> 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.
Business seem very happy to share business data (user analytics) with Google, via Google Analytics.
Deleted Comment
https://www.joelonsoftware.com/2022/01/27/making-the-web-bet...
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.
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.
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).
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.
Further downstream we hope to be able to work with the Gutenberg team and to contribute more directly.
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.
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.
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?
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.
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!
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.
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.
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.