Solvedgutenberg Dynamic reusable blocks: technical details

I'm splitting this out from #1516 (Turning a static block into a dynamic reusable block) since that issue is long and primarily focused on the UI aspects. Here's what I've been thinking of in terms of how such reusable blocks would work at a technical level:

1. There would be a new block post type.
2. The block post would store in its post_content one serialized block. Potentially we could store the block's attributes individually in postmeta instead, and just the contents of the block in post_content. That would improve the ability to do queries on the blocks. If a block type is registered with PHP, it could have serialize/deserialize logic that would dictate whether the attributes get stored in postmeta instead of in content.
3. A block would be identified by a UUID which would get saved in post_name. Using a UUID instead of auto-incremented post ID would eliminate the requirement that a block post be created up-front to reserve its ID. The auto-incremented post ID would be for internal use only and not exposed in the API.
4. A block_type taxonomy would exist and each block would be associated with one and only one term that would store the block type as the term's slug. The sanitization logic for such terms could be overridden to allow slashes in the slug, e.g. core/text.
5. The block post type would be exposed in the REST API with endpoints such as:

• /gutenberg/v1/block-types - Collection of registered block types.
• /gutenberg/v1/blocks - Collection of all blocks.
• /gutenberg/v1/blocks?type=text/core - Collection of blocks of the core/text type.
• /gutenberg/v1/blocks/358b59ee-bab3-4d6f-8445-e8c6971a5601 - Single core/text block.

6. A block resource would look like:

{
	"id": "358b59ee-bab3-4d6f-8445-e8c6971a5601",
	"type": "core/text",
	"attributes": {
		"dropCap": true,
		"align": "center"
	},
	"content": "<p style=\"text-align:center\" class=\"has-drop-cap\">Hello World!</p>"
}

7. External blocks would be embedded in a post via a core/block block type which has a single attribute that contains the UUID (REST API resource id) for the external block, for example: <!-- wp:core/block { "ref": "358b59ee-bab3-4d6f-8445-e8c6971a5601" } /-->
8. When a core/block block initializes, it looks up the from the REST API via the UUID supplied in the ref attribute, and then it creates a block component for the type returned for that block resource.
9. Modifications to such an external core/block's attributes get written not into the containing post's content, but rather get written into edits for that external block resource.
10. Saving the editor updates not only the main post resource, but also any edits to the block resources that were modified.
11. The core/block block would be registered in PHP, and its render_callback would look up the block post by its UUID ref, and embed the content from that block post.
12. When a non-reusable block (attached block) is converted into a reusable (detached) block it would go through a transformation that would result in a new REST API block resource being drafted among the edits, including a newly-generated UUID and all of the attributes from the block would be moved into this detached block resource, with the transformed block in content then getting the generated UUID as its sole ref attribute.
13. Likewise, a reusable/detached could be re-attached to the content by reversing the transformation in the previous step.

Thoughts?

I might be missing a piece of this puzzle so apologies for wading into this late! The above REST spec and some associated features seem to make the assumption that the registered blocks are available server-side, but as I understand it, it's recommend to write / register custom blocks in JavaScript: https://wordpress.org/gutenberg/handbook/blocks/writing-your-first-block-type/

This is a "limitation" that struck me when reading the handbook - by having all block registration done client side, it becomes impossible to provide server-side functionality and abstractions, such as a /block-types REST API endpoint. Having them available server side allows us to do some more security wise validation, which would presumably be more important when blocks can be used outside of the post_content (which is safe, as already has all the reliability of existing sanitization).

It would also open up the possibility of other block interfaces backed by a REST API, such as mobile apps. Again, if this has been discussed elsewhere, a link would be great. By having block registration as part of the Gutenberg app client side, the blocks and general Gutenberg concept will never be able to escape the confines of the WP Admin. While I don't think it will be possible to make blocks totally portable (UI / front end logic is always going to be more powerful expressed as JavaScript components), having registration happen at the server level (and only the server level) will ensure they are more portable.