@Gargron: There is nothing in the archive that you could really make a use of without a specialized tool of some sort. There's images and JSON files.
@ccoenen: Twitter does something very nice, in my opinion: they have this tiny html thing that can (I guess?) parse the JSON. This would be a separate feature request, though. It would add tremendous value to the export.
IMHO it can be very simple at first; maybe just links or so. At least Firefox e.g. displays the JSON in it's nice JSON viewer when you access one like this.
Just as @Gargron said, it would make a quick look into the data easier without special tools. So this would help less technical users, who may just want to have a look into it.
One approach the Twitter archive uses (or used) was to serialize the data as .js so that it could be statically included in
Most helpful comment
Well, to get back to the original issue at hand: the idea was to _also_ have somthing human readable. There are lots of reasons, why this might be a good idea, in my opinion.
So while I think, an export _could_ potentially serve both export/import, I _also_ believe that this can be a totally separate thing that has nothing to do with the existing export at all.
Earlier, I suggested just adding a JS alongside the JSON file. Again: that's adding a tiny amount of storage (zipped up probably next to nothing, _at least_ compared to the media files that are _also_ in there). And it's automated and a one-way operation so there's no real practical reason _not_ to do this.
BTW: the reason the
JSworks, where theJSONdoes not: one can just add a script tag forJSfiles, but one needs a XHR-Request forJSON, and that's where the sandbox comes into play. This has been the case for a number of years, but not in all browsers.