The Block Protocol

by jacobrussell • 4 years ago

286 146 4 years ago

cxr• 4 years ago

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>.)

babyshake• 4 years ago

This has nothing to do with Jack Dorsey's Block, right?

spicybright• 4 years ago

It looks like it's not. I thought it was block chain just from the title myself.

jrochkind13• 4 years ago

When someone finally combines blockchain with semantic web, it'll be an immovable object meeting an unstoppable force and cyberspace will implode.

MarkBennett• 4 years ago

ha ha, that was my first thought too

euroderf2• 4 years ago

So is there a sweet spot between microformats and Notion ?

jitl• 4 years ago

(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.

DavidWilkinson6• 4 years ago

(One of the BP maintainers here)

If you’d be open to exploring this in the context of Notion we’d love to chat: david@hash.ai

euroderf2• 4 years ago

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 :)

uoaei• 4 years ago

Oh look, someone reinvented semantic web again.

redwall_hp• 4 years ago

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?

hammyhavoc• 4 years ago

Most likely because getting major browsers to adopt further changes can be challenging.

iddan• 4 years ago

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

feanaro2• 4 years ago

Why is RDF a bad thing?

k__• 4 years ago

Maybe, finally a useable iteration of it.

ciaranmn16• 4 years ago

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

j-pb4• 4 years ago

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!

wrnr• 4 years ago

Well it does use RDF and probably has the same problem, was it `foaf:Person` or `schema:Person` or maybe even `ai:reificatedConceptNr1234`.

anderspitman3• 4 years ago

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

egypturnash• 4 years ago

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".

cuteboy19• 4 years ago

Relevant XKCD: https://xkcd.com/927/

hackerlytest• 4 years ago

I knew what xkcd it was just by looking at the link. Lol

ohadron• 4 years ago

I came here for this comment

Dylan168073• 4 years ago

What are the existing standards?

andjd• 4 years ago

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.

bfung• 4 years ago

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.

jayd16• 4 years ago

One use case might be for federated chat. Rich media can exist as blocks and remain chat client agnostic.

pjkundert2• 4 years ago

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... :)

DavidWilkinson6• 4 years ago

Except it turns out that blocks and even block protocols were never actually blocked by the lack of a blockchain

pjkundert2• 4 years ago

How do you prove that a state-change occurred in a decentralized fashion?

slyall• 4 years ago

Blog post from Joel Spolsky introducing this.

https://www.joelonsoftware.com/2022/01/27/making-the-web-bet...

jrochkind13• 4 years ago

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.

DavidWilkinson6• 4 years ago

Various are interested in making their platforms more extensible (the flip side of content interop).

open-source-ux• 4 years ago

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.

ciaranmn16• 4 years ago

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).

pdonis3• 4 years ago

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.

tadfisher2• 4 years ago

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...

URSpider942• 4 years ago

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.

andrewflnr• 4 years ago

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?

moberley• 4 years ago

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?

DavidWilkinson6• 4 years ago

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.

alexaholic• 4 years ago

oEmbed[1] meets Schema.org[2]?

[1] https://www.oembed.com

[2] https://schema.org

tadfisher2• 4 years ago

org-mode plugin when?

qwertyuiop_• 4 years ago

"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" '

skybrian• 4 years ago

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.

gingkoguy• 4 years ago

Damn I thought square came out with something

blobbers2• 4 years ago

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?)?

ciaranmn16• 4 years ago

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.

blobbers2• 4 years ago

Is there a way you could describe this more concretely? Say for the specific use case of a Football website.

lucasmullens2• 4 years ago

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.

danecjensen• 4 years ago

Can you elaborate on this? Why can't you make a generator for regular web components?

lucasmullens2• 4 years ago

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.

yesimahuman• 4 years ago

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.

spankalee4• 4 years ago

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.

jawns• 4 years ago

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.

culi• 4 years ago

Sounds like we need a different economic system that doesn't have these types of incentives

AyyWS• 4 years ago

So you're saying block protocol would be a good fit for Red Star OS?

CyberDildonics2• 4 years ago

To be clear, you think that a standard data format and protocol is not worthwhile because some organizations don't release data?

zozbot234• 4 years ago

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.

DavidWilkinson6• 4 years ago

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.

URSpider942• 4 years ago

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.

doliveira• 4 years ago

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)

mejutoco• 4 years ago

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.

yencabulator• 4 years ago

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...

eitland• 4 years ago

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.

wraptile• 4 years ago

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.

the_other• 4 years ago

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.

dataangel• 4 years ago

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.

anderspitman3• 4 years ago

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...

slx26• 4 years ago

> 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.

divbzero2• 4 years ago

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?

divbzero2• 4 years ago

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

ciaranmn16• 4 years ago

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.

irq-1• 4 years ago

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.

atarian• 4 years ago

Ohh I get it. It's basically Docker/shipping containers for content.

dgellow• 4 years ago

So, we now need to develop a kubernetes for content, right?!

lootsauce• 4 years ago

Tried to sign up but can't get past the user name page.

ciaranmn16• 4 years ago

We had some teething issues earlier, apologies - if you try again now it should work.

usbfingers3• 4 years ago

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.

tmikaeld• 4 years ago

Not the same thing, this "Block protocol" is for HTML widgets basically, re-usable HTML/CSS/JS components for sites/apps.

usbfingers3• 4 years ago

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

anderspitman3• 4 years ago

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.

sam_goody• 4 years ago

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.

usbfingers3• 4 years ago

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.

catchmeifyoucan• 4 years ago

This kind of reminds me of https://adaptivecards.io/ from Microsoft.

lelandbatey• 4 years ago

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/

ciaranmn16• 4 years ago

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.

sambroner2• 4 years ago

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.

ricopags• 4 years ago

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/

codeflo2• 4 years ago

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.

codeflo2• 4 years ago

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.

naasking2• 4 years ago

Ironic that the schema.org approach basically matches the Waterken server schema model from 2003. Tyler Close was ahead of his time.

adamzwasserman2• 4 years ago

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

geektips• 4 years ago

Noob Question: How does this compares to an oEmbed.

bamazizi3• 4 years ago

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!

sambroner2• 4 years ago

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...

bamazizi3• 4 years ago

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.

rapnie• 4 years ago

That is interesting. Is it open-source or intended to be?

bamazizi3• 4 years ago

Hard to predict. Full or partial Open source? open consortium? federated?

spankalee4• 4 years ago

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.

DavidWilkinson6• 4 years ago

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.

ciaranmn16• 4 years ago

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.

miniatureape• 4 years ago

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

c-cube• 4 years ago

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.

ciaranmn16• 4 years ago

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...

Terretta• 4 years ago

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...

flutetornado• 4 years ago

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.

r0rshrk• 4 years ago

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

notpachet• 4 years ago

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?

ciaranmn16• 4 years ago

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.

metalliqaz• 4 years ago

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.

ericflo• 4 years ago

Widgets are back!

KoftaBob• 4 years ago

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.

zer0gravity• 4 years ago

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.

naasking2• 4 years ago

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.

The Block Protocol

Related Stories