update the samples to be a bit more logical...

sample/file.md

@@ -4,12 +4,13 @@ Sample structure for sharing file information.
 
 secure hash of file
 file name?  I don't think it should be part of this, as the set of bytes could have any name.
-metadata, e.g. code, language
+metadata, e.g. code, mime-type, language, alt hashes
 
 ```
 {
 	'id': 'uuid',
 	'hash': 'sha256:xxxx',
+	'length': 1234,
 	xxxmetadata
 }
 ```
@@ -19,34 +20,39 @@ metadata, e.g. code, language
 hostname + path
 link to base file
 
-How are these versioned?  Are they?
+How are these versioned?  Are they?  They need to be, via modified
 
 ```
 {
 	'hash': 'sha256:xxx',
 	'hostname': 'server.example.com',
-	'fqpath': '/some/set/directories/and/filename.ext'
+	'fqpath': '/some/set/directories/and/filename.ext',
+	'modified_date': 'iso8601'
 }
 ```
 
-# Links to file in archive
+# Archive file listing
 
-link to base file
-archive hash
+link to archive hash
+list of files
 name/handle in archive
 
 This is an immutable "fact", treat it differently?
 
 ```
 {
-	'filehash': 'sha256:xxx',
 	'archivehash': 'sha256:xxx',
-	'archivepath': 'archive/path/to/file.ext'
+	'files': [
+		[ 'archive/path/to/file.ext', 'sha256:xxx' ],
+		...
+	]
 }
 ```
 
 # Links to file in torrent
 
+Maybe merge torrent into here, as a torrent is really an "archive" of the files, but just w/ a differnt lookup method, via torrent info hash (magnet link) vs file hash.
+
 torrent hash
 name of file in torrent if multi file torrent