Problem / motivation
Sending a photo of whatever is in front of you means leaving Knit first: open the camera app, take
the shot, come back, tap attach, then find that photo again in the picker. Five steps for the thing
people most obviously want to do with a mesh messenger, where the subject is usually whatever you
and the person next to you are both looking at.
Proposed solution
A camera action in the composer, next to the attach button.
The smallest version that fixes the complaint is ActivityResultContracts.TakePicture() writing to
a FileProvider Uri, handed to the existing ChatViewModel.attach(uri). The system camera still
opens, but you land back in the same chat with the shot already attached and the picker never
appears.
The fuller version is an in-app CameraX viewfinder like Signal's, with a shutter and a front/back
toggle, feeding the same attach.
Either way the Uri goes through AttachmentStore.ingest, so downscaling, the NSFW verdict, and the
blob path are untouched.
Nothing new goes into the build for this. CameraX 1.6.1 is already here for the QR scanner and
ImageCapture lives in camera-core, which we already pull; CAMERA is already in the manifest;
the FileProvider is already declared; androidx.exifinterface is already a dependency for
orientation. The CameraX version pin is deliberate (ADR 015, plus the comment in the version
catalog), so don't bump it for this.
Alternatives considered
Leave it alone and lean on the share sheet. Knit already accepts ACTION_SEND images, so you can
shoot in the camera app and share into Knit. It works, but it starts in the wrong app and drops you
at conversation selection through ShareInbox rather than the chat you were already sitting in.
Go straight to the in-app viewfinder and skip the intent version. That's more code before anything
ships, and it leaves no fallback on a device where our CameraX stack misbehaves.
Scope and mesh impact
None of the above. Once ingested, a captured photo is an ordinary image blob: nothing changes on the
wire, in custody, or in the crypto envelope.
Additional context
Another in-person request, so there's no reporter account to link here.
Problem / motivation
Sending a photo of whatever is in front of you means leaving Knit first: open the camera app, take
the shot, come back, tap attach, then find that photo again in the picker. Five steps for the thing
people most obviously want to do with a mesh messenger, where the subject is usually whatever you
and the person next to you are both looking at.
Proposed solution
A camera action in the composer, next to the attach button.
The smallest version that fixes the complaint is
ActivityResultContracts.TakePicture()writing toa FileProvider Uri, handed to the existing
ChatViewModel.attach(uri). The system camera stillopens, but you land back in the same chat with the shot already attached and the picker never
appears.
The fuller version is an in-app CameraX viewfinder like Signal's, with a shutter and a front/back
toggle, feeding the same
attach.Either way the Uri goes through
AttachmentStore.ingest, so downscaling, the NSFW verdict, and theblob path are untouched.
Nothing new goes into the build for this. CameraX 1.6.1 is already here for the QR scanner and
ImageCapturelives incamera-core, which we already pull;CAMERAis already in the manifest;the FileProvider is already declared;
androidx.exifinterfaceis already a dependency fororientation. The CameraX version pin is deliberate (ADR 015, plus the comment in the version
catalog), so don't bump it for this.
Alternatives considered
Leave it alone and lean on the share sheet. Knit already accepts
ACTION_SENDimages, so you canshoot in the camera app and share into Knit. It works, but it starts in the wrong app and drops you
at conversation selection through
ShareInboxrather than the chat you were already sitting in.Go straight to the in-app viewfinder and skip the intent version. That's more code before anything
ships, and it leaves no fallback on a device where our CameraX stack misbehaves.
Scope and mesh impact
None of the above. Once ingested, a captured photo is an ordinary image blob: nothing changes on the
wire, in custody, or in the crypto envelope.
Additional context
Another in-person request, so there's no reporter account to link here.