Ivan Reese this feels a bit more #present-company now looking back through the channels… shall I move it?

Or even possibly #introduce-yourself 🤔

present company seems right based on previous such messages

Sorry to hear Cole 😞

Thanks. I got a lot of enjoyment out of the journey, though. And, it really helped me develop my “product owner” identity and skillset.

I feel like with the advent of semantic web, this is how all bookmarks should behave in future.

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

Any and all thoughts and prototypes are encouraged and welcomed!

The FAQ and Joel’s blog post also hopefully offer more insight into the motivation for the project and its relation to others.

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.

Ah, I think @Ciaran Morinan replied to my HN question.

blocks can have their own local state, but to persist data beyond the session should make use of the operations defined in the spec to pass data back to the application

That's actually kind of interesting. I think something like that needs to be in the first couple hundred words of the pitch, though, if not actually above the fold on the homepage.