The Assets plugin will report the presence of duplicated files in twin locations based on the fork history in the journal pages within which it resides. We propose that this should indicate which files are older, newer or the same as those on the origin.
Here there is one file that might be usefully forked as it has a newer version in the remote site.
seattle.fed.wiki-
IMG_5696.jpg
IMG_5719.jpg
IMG_5720.jpg newer
IMG_5722.jpg same
found.ward.bay.wiki.org-
IMG_5720.jpg older
IMG_5722.jpg same
IMG_5604.jpg
Comparison will be against metadata from files on the origin. No judgement will be passed on files not duplicated.
We could consider creating hover logic that would quote more details like actual dates and sizes for any file listed.
# Request
A server-side component provides a file list for any known asset folder. No mechanism other than convention provides for discovery of folders.
/plugin/assets/list?assets=<folder>
{"error":null,"files":[<filenames>, ...]}
Plugins from independently managed sites will expect this much to work if any version of Assets plugin has been installed. There are other users of this api so any change should be upward compatible.
Note: The wiki-server can serve from an assets folder even if the Assets plugin has not been installed.
The simplest extension would be to report a parallel array of metadata if this were available from the installed plugin.
"metadata":[ { "created":<epoch>, "modified":<epoch>, "size":<bytes> }, ... ]
# Implementation
The server-side component adds a route to the wiki-server app and handles all requests for assets for the origin. Constructing the parallel arrays might require some adjustment of async calling sequence but the require stat for metadata appears in place. github 
The client-side changes will be more extensive. Emit iterates over the contexts sequentially not expecting to make comparisons. A better sequence would be to fetch all, annotate, and then report. github `
# Limitation
Upon upload, a file marked older will become newer since the dates compared will be filesystem dates on the respective servers. This will be true even if file chosen to upload is an old and obsolete version of the file.
A file forked should be timestamped to match the remote site using the utime system call. Only this way will they ever be reported as same. Current time will have to be used if the remote site lacks metadata.
An application that expects more reliable provenance should embed reliable dates into files and the fetch the files to read them. For example, see the Sofi administrator rollup. wiki