I quite like the idea of userspace reusable blocks https://blockprotocol.org/ The blocks living above the level of a single application. I wonder if I should prototype something.

A JSpolsky production, interesting React/web-component/other – umm

There are various different implementations of embedding applications and blocks which would be compliant with the protocol, but not with one another.

The ultimate goal of the Block Protocol and supporting ecosystem is that any embedding application should be able to render any block, if both are correctly configured.

In order to achieve this, embedding applications will need to have strategies for handling blocks which are implemented in different ways.

ie, code for react and web components and other – I don't get it No mention on what the data supplier or ownership should be Eventually there'll be a "BlockHub" https://blockprotocol.org/hub

yeah that seems the most important bit of a protocol, the data exchange and how its rendered but its kinda missing. They did say its a draft I guess.

I’m super curious what other limitations you end up noticing

Skimmed through the spec: • The protocol is only concerned with blocks <--> "embedding app" communication. "Embedding app" is any application that wants to use blocks to render some data • The data is owned by the app. And it has to implement all aspects of fetching/watching/updating/storing data. • There is zero discussion of how different apps should communicate (if at all). No discussion of how to export/migrate data between apps • The protocol defines data and functions that embedding app needs to provide to blocks. ◦ The protocol does not define the mechanism to provide these. That's why React/iframe/web-components are possible compatible implementations (though unspecified). This can potentially fragment the ecosystem, so iiuc they plan to spec this as well • The spec also does not define how blocks are distributed, how end users can search or add them This does not seem like "userspace reusable blocks". This is rather a spec for devs to create compatible components that can be used by other devs.

Hey, I work on this - Alexey has a good read on the aims and scope of the protocol. Some thoughts:

[Different implementations of blocks] can potentially fragment the ecosystem, so iiuc they plan to spec this as well

We’re conscious of multiple implementation approaches potentially leading to fragmentation, with React-implemented blocks limited to applications who are happy to ship React, and other variations. It’s a tricky balance to strike between freedom for the block author (i.e. can they implement it how they want, or must they use X) and work for the embedding application (how many different flavours of block implementation do they need to deal with - albeit we can provide libraries for this to save every application rolling their own).

The spec also does not define how blocks are distributed, how end users can search or add them

The spec does not define this, and I’m not sure we want to require that people use particular distribution methods, but we do provide one - at a very early, too-manual stage - and have an API which allows callers to filter blocks by keywords, or by data structure (i.e. pass a data structure and you will be returned blocks which have a schema compatible with that data structure).

At what point is it actually a "protocol", i.e. what are the communicating parties and what are they saying? I'd accept if it was just a "protocol" between a web page and an embedded block, but from this thread apparently not even that is specified in detail? If Alexey is correct that this spec doesn't want to address data ownership, inter-app communication or code distribution, I don't see how it can make a significant difference on its stated goals of data portability. It just looks like a moderately ambitious UI framework, and honestly I'm irritated to have waded through so much grandiose language in both the website and Spolsky's blog post to come to that conclusion. Even if I'm wrong about that, please update the docs to be less obtuse about the project actually is.

Even if I’m wrong about that, please update the docs to be less obtuse about the project actually is.

Can you expand on which bits of the site / docs you found particularly obtuse? To my reading, the introduction to the spec is pretty explicit about what the communicating parties are - do you mean those docs, or other ones? We’re obviously keen to explain it as clearly as possible.

The front page of blockprotocol.org, mainly (and Spolsky's post, not much you can do about that, though). The FAQ and Quickstart were also less helpful than I would have liked, but I don't think we should even have to go that far for basics like "how is it possible for this thing to actually work". Reading a detailed spec is a big time commitment, so generally I won't bother unless I'm already convinced it has a shot of solving an interesting problem. My top questions were (1) "who owns the state", (2) "where is the code hosted" (all the talk about interop made me think maybe different apps were sharing the same code), (3) "who is talking in the protocol", and (4) "what are they talking about", in roughly that order. It was your HN comment about blocks passing changes back to the app that answered 1,3,4, and the Quickstart mostly answered 2 (which at the time was a disappointment, since I didn't know anything else interesting about the project). I don't know if this is just me, but marketing-wise you're up against a headwind. Big goals for uniting the web are common and cheap. You're still marketing to devs at this stage, not executives, right? Give us the "how" early.

Understood, thank you for explaining - I agree we need to address these sorts of questions more directly on the homepage, or at least link to where they are addressed from there. Being close to the detail, we’re somewhat blind to how easy it is to understand from the outside, so it’s helpful to have these points highlighted.