Allow Items to "embed" other Items.

[NfNitLoop]

Unlike file attachments, these allow embedding other FeoBlog Items "into" an item that needs to reference them.

• The "embedded"[^1] Item is not stored inside of the protobuf in whole, but is referenced by its (userID, signature) pair (similar to a ReplyRef).
• Servers will allow you to upload a copy of that item in association with the embedding item, as one currently does for attachments.
• Sync tools can/should copy embedded items over as they would attachments.
• These items are available for clients to fetch to render Items that refer to (possibly multiple) other items. (ex: Comments. Reply Posts. Likes. Reblogs. Reblog chains like Tumblr.)
• The items are ONLY available to fetch within the context of the Item that embeds them. i.e.: Copying an embedded item does not make it available at a server's /u/:userID/i/:signature/proto3 endpoint. Thus items can be replied to and discussed in context without necessarily making them broadly available on servers that do not wish to host them.

Implementations should store embedded Items in a content-addressable store so that commenting/sharing doesn't end up creating duplicates of items.

This unblocks #6

[^1]: TBD: better term? We already have a ReplyRef type.

[NfNitLoop]

One question, tangentially related to this: If I embed an Item, and it has attachments, do we let attachments get posted to it? Or do I need to explicitly make those part of my top-level item? Perhaps the Embed Protobuf type will need to list attachments so that they're all available at the top level?

[NfNitLoop]

Thus items can be replied to and discussed in context without necessarily making them broadly available on servers that do not wish to host them.

Hmm, except it is available, just via the "embedding" user's uid/sig. I'd like servers to be able to ban users/content as necessary in the future.

So, maybe a compromise:

• Metada includes uid, sig, AND sha256(?) like we do for file attachments, since both attachments and embeds will go into the content-addressable store.
• This will let servers have metadata about the uid/sig for that content, and optionally ban it based on uid/sig/sha256. (in the future)
• Still: adding embedded content does not necessarily make it available at u/:userID/i/:signature/proto3. Only when content is sync'd via that method does it appear there. (And that endpoint can continue to deny PUTs as it does now.)