The wifi range will have to be tested; it is likely that the thing is designed for a second end that is few inches away from the camera module.
If the firmware was hackable, it would be nice to introduce two modes of operation - one-to-one, with pairing with the phone and encrypted communication, and one-to-many, with said UDP-broadcasting of the images/stream for anybody who can receive.
I bet it could be doable with Raspberry Pi, for example, and a suitable camera module. The noir picam has quite decent night operation. But the cam itself is tiinyyy (which is both good and bad) and as the bus is the earlier-mentioned-here MIPI standard, other better cams should be possible to attach. Then, voila, broadcasting “eye” (which can also record locally). And all the signing timestamping features could be also added.
Additional thought. A container data format for other data, or an appropriate filesystem. Split the file to blocks, and attach a header to each block that describes the file and the timestamp/version. Make the blocks size match the block/cluster size of the physical device that it is written to. In case of any sort of crash or filesystem damage, run a scan on the raw device, and pull the blocks of the proper files in the proper order. In case of nondamaged media, the files can then be cleared by catting them through a program that just bites out the cluster headers, in case of damaged ones the sectors with the file chunks can be easily found and reassembled. The chunk header should hold the ID of the file, the order number of the chunk, and timestamp when it was written (so various wear-balancing strategies that scatter older pieces of files around the block device won’t provide false positives; just pick the newest); 12 bytes should do. (With optional file name/path in the first chunk, to pair the file ID with name in case of total loss of directory data.) It should be possible to implement it with relative ease as a FUSE filesystem. In context of cameras, it would provide easy recovery of file from the medium even in case of sudden loss of power to the camera, or yanking out the medium during operation - important for cases of street reporting under adversarial conditions.
(This thought was originally developed for storing node data on extfs systems, so in case of filesystem damage these can be recovered; these files then can be stored on the same partition and can be recovered by scanning the block device. Dump the data to a file via cron every few hours, recover when needed.)
