14 ms·

The Block Protocol

286 points by jacobrussell 5y ago

metalliqaz 5y 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.
cxr 5y 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 https://maggieappleton.com/garden-history>.)
pjkundert 5y 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... :)
- DavidWilkinson 5y ago
  Except it turns out that blocks and even block protocols were never actually blocked by the lack of a blockchain
  - pjkundert 5y ago
    How do you prove that a state-change occurred in a decentralized fashion?
babyshake 5y ago
This has nothing to do with Jack Dorsey's Block, right?
- spicybright 5y ago
  It looks like it's not. I thought it was block chain just from the title myself.
  - jrochkind1 5y ago
    When someone finally combines blockchain with semantic web, it'll be an immovable object meeting an unstoppable force and cyberspace will implode.
- MarkBennett 5y ago
  ha ha, that was my first thought too
- deleted 5y ago
  [deleted]
euroderf 5y ago
So is there a sweet spot between microformats and Notion ?
- jitl 5y 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.
  - DavidWilkinson 5y 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
  - euroderf 5y 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 5y ago
Oh look, someone reinvented semantic web again.
- redwall_hp 5y 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 5y ago
    Most likely because getting major browsers to adopt further changes can be challenging.
- iddan 5y ago
  Exactly what I was thinking. The Semantic Web done the heavy lifting of defining general schemas (https://schema.org https://schema.org) and extending JSON (https://json-ld.org 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
  - feanaro 5y ago
    Why is RDF a bad thing?
    - j-pb 5y ago
      * 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.
anderspitman 5y 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 https://microformats.org/wiki/Main_Page
egypturnash 5y 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".
- jayd16 5y ago
  One use case might be for federated chat. Rich media can exist as blocks and remain chat client agnostic.
- cuteboy19 5y ago
  Relevant XKCD: https://xkcd.com/927/ https://xkcd.com/927/
  - hackerlytest 5y ago
    I knew what xkcd it was just by looking at the link. Lol
    - mindcandy 5y ago
      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.
      - Dylan16807 5y ago
        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.
        Ostrogodsky 5y ago
slyall 5y ago
Blog post from Joel Spolsky introducing this. https://www.joelonsoftware.com/2022/01/27/making-the-web-better-with-blocks/ https://www.joelonsoftware.com/2022/01/27/making-the-web-bet...
- jrochkind1 5y 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.
  - DavidWilkinson 5y ago
    Various are interested in making their platforms more extensible (the flip side of content interop).
- open-source-ux 5y 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.
  - ciaranmn 5y 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 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).
alexaholic 5y ago
oEmbed[1] meets Schema.org[2]? [1] https://www.oembed.com https://www.oembed.com [2] https://schema.org https://schema.org
tadfisher 5y ago
org-mode plugin when?
qwertyuiop_ 5y 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 5y 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 5y ago
Damn I thought square came out with something
lucasmullens 5y 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 5y ago
  Can you elaborate on this? Why can't you make a generator for regular web components?
  - lucasmullens 5y 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 5y 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.
- spankalee 5y 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 https://github.com/webcomponents/custom-elements-manifest People have already built tools that generate wrappers based on it.
blobbers 5y 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?)?
- ciaranmn 5y 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.
  - blobbers 5y ago
    Is there a way you could describe this more concretely? Say for the specific use case of a Football website.
    - ciaranmn 5y ago
      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.
jawns 5y 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 5y ago
  Sounds like we need a different economic system that doesn't have these types of incentives
  - AyyWS 5y ago
    So you're saying block protocol would be a good fit for Red Star OS?
- CyberDildonics 5y ago
  To be clear, you think that a standard data format and protocol is not worthwhile because some organizations don't release data?
  - zozbot234 5y 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.
dataangel 5y 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.
- deleted 5y ago
  [deleted]
- anderspitman 5y 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-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
- slx26 5y 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.
deleted 5y ago
[deleted]
divbzero 5y 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?
- divbzero 5y 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 https://blockprotocol.org/hub [2]: https://blockprotocol.org/spec https://blockprotocol.org/spec [3]: https://blockprotocol.org/@hash/image https://blockprotocol.org/@hash/image
  - ciaranmn 5y 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 https://blockprotocol.org/docs/faq - we'd be interested in any others you think worth building on.
    - spankalee 5y ago
irq-1 5y 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-better-with-blocks/ 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 5y ago
Ohh I get it. It's basically Docker/shipping containers for content.
- dgellow 5y ago
  So, we now need to develop a kubernetes for content, right?!
lootsauce 5y ago
Tried to sign up but can't get past the user name page.
- ciaranmn 5y ago
  We had some teething issues earlier, apologies - if you try again now it should work.
usbfingers 5y 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/ https://solidproject.org/TR/protocol 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 5y ago
  Not the same thing, this "Block protocol" is for HTML widgets basically, re-usable HTML/CSS/JS components for sites/apps.
  - usbfingers 5y ago
    https://news.ycombinator.com/item?id=30105910 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 https://blockprotocol.org/spec for more info on how they're mapping data as entities
- deleted 5y ago
  [deleted]
- Ostrogodsky 5y ago
- anderspitman 5y 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.
catchmeifyoucan 5y ago
This kind of reminds me of https://adaptivecards.io/ https://adaptivecards.io/ from Microsoft.
lelandbatey 5y 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 https://blockprotocol.org/spec#terminology [1] - https://blockprotocol.org/@hash/table https://blockprotocol.org/@hash/table [2] - https://blockprotocol.org/spec/block-types#entity-functions https://blockprotocol.org/spec/block-types#entity-functions [3] - https://json-schema.org/ https://json-schema.org/
sambroner 5y 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 5y 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/ https://solidproject.org/
- codeflo 5y 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-better-with-blocks/ 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.
geektips 5y ago
Noob Question: How does this compares to an oEmbed.
bamazizi 5y 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!
- sambroner 5y 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-in-ten-years-or-less https://www.edgedb.com/blog/building-a-production-database-i...
  - bamazizi 5y 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 5y ago
  That is interesting. Is it open-source or intended to be?
  - bamazizi 5y ago
    Hard to predict. Full or partial Open source? open consortium? federated?
spankalee 5y 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.
- DavidWilkinson 5y 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.
- ciaranmn 5y 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 5y 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 https://justindonato.com/notebook/urls-as-pointers.html
- c-cube 5y 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.
  - ciaranmn 5y 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-contexts-e.g.-native-applications https://blockprotocol.org/docs/faq#what-about-non-web-contex...
- Terretta 5y 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 5y 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 5y 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 https://kdp.amazon.com/en_US/help/topic/GG5R7N649LECKP7U
notpachet 5y 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?
- ciaranmn 5y 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.
ericflo 5y ago
Widgets are back!
KoftaBob 5y 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 5y 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.
naasking 5y 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.

286 points by jacobrussell 5y 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.

cxr 5y 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 https://maggieappleton.com/garden-history>.)

pjkundert 5y 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... :)

DavidWilkinson 5y ago
Except it turns out that blocks and even block protocols were never actually blocked by the lack of a blockchain
- pjkundert 5y ago
  How do you prove that a state-change occurred in a decentralized fashion?

babyshake 5y ago

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

spicybright 5y ago
It looks like it's not. I thought it was block chain just from the title myself.
- jrochkind1 5y ago
  When someone finally combines blockchain with semantic web, it'll be an immovable object meeting an unstoppable force and cyberspace will implode.
MarkBennett 5y ago
ha ha, that was my first thought too
deleted 5y ago
[deleted]

euroderf 5y ago

So is there a sweet spot between microformats and Notion ?

jitl 5y 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.
- DavidWilkinson 5y 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
- euroderf 5y 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 5y ago

Oh look, someone reinvented semantic web again.

redwall_hp 5y 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 5y ago
  Most likely because getting major browsers to adopt further changes can be challenging.
iddan 5y ago
Exactly what I was thinking. The Semantic Web done the heavy lifting of defining general schemas (https://schema.org https://schema.org) and extending JSON (https://json-ld.org 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
- feanaro 5y ago
  Why is RDF a bad thing?
  - j-pb 5y ago
    * 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.

anderspitman 5y 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 https://microformats.org/wiki/Main_Page

egypturnash 5y 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".

jayd16 5y ago
One use case might be for federated chat. Rich media can exist as blocks and remain chat client agnostic.
cuteboy19 5y ago
Relevant XKCD: https://xkcd.com/927/ https://xkcd.com/927/
- hackerlytest 5y ago
  I knew what xkcd it was just by looking at the link. Lol
  - mindcandy 5y ago
    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.
    - Dylan16807 5y ago
      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.
      - Ostrogodsky 5y ago

slyall 5y ago

Blog post from Joel Spolsky introducing this. https://www.joelonsoftware.com/2022/01/27/making-the-web-better-with-blocks/ https://www.joelonsoftware.com/2022/01/27/making-the-web-bet...

jrochkind1 5y 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.
- DavidWilkinson 5y ago
  Various are interested in making their platforms more extensible (the flip side of content interop).
open-source-ux 5y 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.
- ciaranmn 5y 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 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).

alexaholic 5y ago

oEmbed[1] meets Schema.org[2]? [1] https://www.oembed.com https://www.oembed.com [2] https://schema.org https://schema.org

tadfisher 5y ago

org-mode plugin when?

qwertyuiop_ 5y 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 5y 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 5y ago

Damn I thought square came out with something

lucasmullens 5y 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 5y ago
Can you elaborate on this? Why can't you make a generator for regular web components?
- lucasmullens 5y 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 5y 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.
spankalee 5y 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 https://github.com/webcomponents/custom-elements-manifest People have already built tools that generate wrappers based on it.

blobbers 5y 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?)?

ciaranmn 5y 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.
- blobbers 5y ago
  Is there a way you could describe this more concretely? Say for the specific use case of a Football website.
  - ciaranmn 5y ago
    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.

jawns 5y 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 5y ago
Sounds like we need a different economic system that doesn't have these types of incentives
- AyyWS 5y ago
  So you're saying block protocol would be a good fit for Red Star OS?
CyberDildonics 5y ago
To be clear, you think that a standard data format and protocol is not worthwhile because some organizations don't release data?
- zozbot234 5y 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.

dataangel 5y 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.

deleted 5y ago
[deleted]
anderspitman 5y 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-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
slx26 5y 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.

deleted 5y ago

[deleted]

divbzero 5y 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?

divbzero 5y 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 https://blockprotocol.org/hub [2]: https://blockprotocol.org/spec https://blockprotocol.org/spec [3]: https://blockprotocol.org/@hash/image https://blockprotocol.org/@hash/image
- ciaranmn 5y 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 https://blockprotocol.org/docs/faq - we'd be interested in any others you think worth building on.
  - spankalee 5y ago

irq-1 5y 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-better-with-blocks/ 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 5y ago

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

dgellow 5y ago
So, we now need to develop a kubernetes for content, right?!

lootsauce 5y ago

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

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

usbfingers 5y 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/ https://solidproject.org/TR/protocol 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 5y ago
Not the same thing, this "Block protocol" is for HTML widgets basically, re-usable HTML/CSS/JS components for sites/apps.
- usbfingers 5y ago
  https://news.ycombinator.com/item?id=30105910 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 https://blockprotocol.org/spec for more info on how they're mapping data as entities
deleted 5y ago
[deleted]
Ostrogodsky 5y ago
anderspitman 5y 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.

catchmeifyoucan 5y ago

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

lelandbatey 5y 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 https://blockprotocol.org/spec#terminology [1] - https://blockprotocol.org/@hash/table https://blockprotocol.org/@hash/table [2] - https://blockprotocol.org/spec/block-types#entity-functions https://blockprotocol.org/spec/block-types#entity-functions [3] - https://json-schema.org/ https://json-schema.org/

sambroner 5y 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 5y 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/ https://solidproject.org/
codeflo 5y 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-better-with-blocks/ 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.

geektips 5y ago

Noob Question: How does this compares to an oEmbed.

bamazizi 5y 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!

sambroner 5y 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-in-ten-years-or-less https://www.edgedb.com/blog/building-a-production-database-i...
- bamazizi 5y 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 5y ago
That is interesting. Is it open-source or intended to be?
- bamazizi 5y ago
  Hard to predict. Full or partial Open source? open consortium? federated?

spankalee 5y 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.

DavidWilkinson 5y 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.
ciaranmn 5y 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 5y 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 https://justindonato.com/notebook/urls-as-pointers.html

c-cube 5y 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.
- ciaranmn 5y 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-contexts-e.g.-native-applications https://blockprotocol.org/docs/faq#what-about-non-web-contex...
Terretta 5y 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 5y 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 5y 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 https://kdp.amazon.com/en_US/help/topic/GG5R7N649LECKP7U

notpachet 5y 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?

ciaranmn 5y 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.

ericflo 5y ago

Widgets are back!

KoftaBob 5y 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 5y 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.

naasking 5y 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.