Blink>Storage does not seem like the right component, as this is completely unrelated to the way storage uses DataElement? Storage code only uses DataElement to actually store data, so copying data is always the right thing to do there.

Anyway, I think we already decided that the correct thing to do was to fork DataElement in two separate classes for the storage and non-storage use-cases (and I think it might make sense to do that sooner rather than later, especially as you're making more and more changes like the one discussed in this bug).

The code is in storage/common/, which has blink>storage listed as its component.

If we split it, I guess we'd need a conversion from blink types to services/network types?

Actually, going to leave this unassigned - if we're going to gate this on splitting up the consumers of DataElements, this is several orders of magnitude more involved that I anticipated, and I won't have time for it in the foreseeable future.

Removing storage label, as this is now part of services/network.

hey matt, do we need this for the initial canary launch of network service? 

I don't think so - I don't think we'll even need it for full launch, since this affects both the legacy and the new codepaths, I believe (Well, the "new" legacy codepath).

Think this is reasonable to leave a a P3.