ppq [concept]

It is a pain in the ass to get project images from my phone (camera) to my documentation, and then it's frequently an additional manual step to resize, and then I have to go back and delete them off the phone, as I wasn't trying to preserve the images in Google Photos/iCloud in the first place--version control on the documentation is responsible for that persistence. First world problems, sure, but it's a bunch of additional friction to adding images ("documenting as you go"), which demonstrably makes documentation more engaging and clear.

A 60% solution is magic wormhole on the receiving device with something like wormhole william on the phone. That lets me document as I go, but I need the wormhole running all the time, I need to sync the code, and I need to take the images out-of-band. Basically I need my laptop with me and set up to synchronously receive everything. That's fine, but I often am taking pictures in-the-moment, and it's not guaranteed everything will be set up this way ahead of time.

What I actually want is a client-side partitioned media queue that doesn't require a concurrent receiving device — open the app, make a queue, take a bunch of pictures, go back and title ones I want to keep, they automatically upload. Later, when I'm writing up the docs, run something like:

$ cd blog/content/current-post
$ ppq list
htm [5 pending]
$ ppq dump -q htm --resize 720x480
dequeue demo1.jpg
dequeue demo2.jpg
dequeue demo.mp4
dequeue test.jpg
dequeue broken.jpg

I'd also like to support:

$ ppq stream -q htm --resize 720x480

to stream all the files as I take them, and possibly some undo functionality.

language choices

I'll probably write the server component in Elixir, as I've been playing with it recently and this really is a distributed systems problem. I could just use NATS + JetStream, but I kinda don't want to deal with its authentication system / overload it here.

Phone app is Kotlin on Android unless there's something nice for Rust (seems like maybe — might try it out if it doesn't seem like too much of a pain in the ass).

CLI will be Rust.

design sketch

server

Relational DB (probably just SQLite? I don't think PG is worth it) for queues + Phoenix for REST API.

• GET /: list all queues

• POST /:name: create queue

• DELETE /:name: delete queue

• GET /:name: list items in queue (metadata only)

• POST /:name/item: add item, returns uuid

• DELETE /:name/:uuid: remove item

• POST /:name/dump: download and remove all items in queue

phone app

• Login activity -- set server, token (JWT)
• Home activity: queue list (names, number of items)
• Queue detail activity: image grid + detail edit modal

cli

• configure --server $server --token $token

• list -> GET /

• -q $name create -> POST /:name

• -q $name rm -> DELETE /:name

• -q $name list -> GET /:name

• -q $name post < $item -> POST /:name/item

• -q $name rm $uuid -> DELETE /:name/:uuid

• -q $name dump -> POST /:name/dumpSERVER