See #13

Report from Jonathan on Thu 4 Jan evening build:

In an ideal world, we'd move away from the MVP implementation which relies on custom text headers to draw the bespoke reception UI, and read from the ZIP directly.

This task aims to permit the registration of some integrity proofs on a third-party ledger, namely MobileCoin – a cryptocurrenty and transaction system already built into Signal.

The MobileCoin team indicated that they thought we could leverage the Memo field of the transaction (max 64 bytes) to, for example, declare the hash of the image.

• MobileCoin’s Android SDK
• MobileCoin's integration guide
• MobileCoin can be reached in #starling-mobilecoin, and our contact are Bruce and Sara, both on Pacific time.

Corollary to #33: we need the sender to see what they've sent – unfortunately, Signal has built this in separate components.

Options regarding sharing a ProofMode-enhanced media

In this situation:
- I have captured a photograph through Custom Signal Build
- ProofMode proofs were generated (location, device ID, etc.)
- I have selected the contact(s) with whom I want to share this rich media.

What, precisely, should go to the Contact(s)?

Candidates to be included are:
- Some text as part of the message (the Message),
- The photograph itself (the Photo),
- The ZIP file of ProofMode proofs (the Proofs ZIP),
- The link to the MobileCoin ledger notarizing the capture (the MobileCoin registration link).

Something to keep in mind: The person-to-person workflow includes the idea that as the receiver of such a bundle, we will have some visual feedback about its qualities (think green check marks or locks), or show some of the proofs.
To this effect, having the ZIP file in a single, isolated message might (?) make it easier to de-serialise and pull data out of?

1. Send, in one go, all assets?
Well-formatted string containing Message + Registration link
Plus two attachments: the Photo + a ZIP file

2. Send (Message + Photo) together, then ZIP, then Registration
Feels quite natural to have Message and Photo together,
But might be costly to have further steps "taking over" your Signal,
engineering-wise, changes-wise, and UX-wise.

3. ???
what did i miss

(See full size on Mural)

This task aims to create a ProofMode item in Signal Settings, which directs to a page explaining briefly what ProofMode is about. On this page, it is possible to globally opt out of ProofMode features.

In this case, #10 features are off by default and #13 features are reverted back on.

Current:

Updates and follows #20.

(See full size on Mural)

This task aims to give some agency to the users regarding which proofs are included in captured media.

• If Secure Capture (#10) is off, then the following features should be off as well.
• If the user is capturing with Secure Capture, then:
  • Once a media has been captured, a button in the bottom row can be tapped to toggle some proofs on or off.
  • Tapping this button opens a modal-like thing (like Crop does, for example), which gives a couple of toggles for common ProofMode options (start with Location and Device Identity)

I'm a bit lost with which build I'm running – just want to make sure my changes to the copy went through :)

Nathan: One thing I’d like to consider is using our Proofmode “p” stamp/seal icon or a check icon instead of the lock on the camera view - i think it would be less generic and more clear that this for adding proof or verifiability. The lock makes me think of secure/insecure which is tricky within the Signal context.

basile: Yup this could be swapped in place. I believe this is the PR that implements the placement of this icon, which has two states: on and off. Could you provide these?

JD: Nathan, Quick question: I’m wondering is there a different icon we might be able to brainstorm. I’m concerned that Meredith might consider this an incursion on signal branding?
Agreed the lock is very specific.

Nathan: I think there is a need for a generic icon related to content authentication that is different than the typical lock or shield related to privacy/security. Since we already have the name "Proof Mode" in the signal settings, I think it makes sense for now to use the our P stamp icon. If there is another idea that day c2pa community has or Adobe happy to standardize on that... Unfortunately Twitter and Elon have ruined the idea of a checkmark 😅

basile: Haha, Nathan!
FYI I think that feature or change can be implemented next week, and I'd like to protect Max's remaining time today and tomorrow 🙏

Nathan: Sure this is definitely a low pri nice to have

Nathan: just to expand on the larger concept a bit, I think this is a great opportunity for us to define a standard “authenticated content” mark of some kind that Starling, Witness and GP/Proofmode can push together, and then hopefully with Signal and Adobe’s support as well. Carrie has some thoughts on this, and I know you must have explored these within the context of the Rolling Stone piece. What is interesting is that we aren’t necessary saying “this has been verified by a team of experts” in this context, but we are saying “make this verifiable” or “this media is verifiable”. Maybe we can start a different thread or have this as a topic for our next call.

cc @n8fr8

(See full size on Mural)

The purpose of this set of features is to empower users to use ProofMode, or simply to not use it.

• At the app, global level, users should be able to opt out: #16 aims to implement this.
• At the camera capture level, we'd like users to be able to turn on or off the proofs generation on a case-by-case basis: that's #10 and done already.
• Moreover, after a media is captured, we'd like users to be able to toggle on or off certain proofs, for example to keep their GPS coordinates private. That's #18.

This task aims to provide the receiver of a ProofMode-augmented media through Signal (which was registered on MobileCoin's ledger) a way to go and check this registration record.

The MobileCoin team have pointed us to their tool, Fog, which contains a block explorer. The sender of the message would then send a ProofMode ZIP and a link to the block containing the transaction.

From Nathan:

Ah right, the photo! That's the problem. I thought that was already happening.
The photo should be the saw raw bytes that you used to generate the proof hash. Do not re-encode.

The purpose of this task is to implement the UI on the receiving end of the process, i.e. what a person who receives one of these ProofMode-enhanced bundles sees.

We would like to leverage and surface the metadata as much as possible.

How do we ensure the bundles we're now passing around are actually valid? If that's even a question?

I seem to remember a complex process at https://proofmode.org/verify

cc @n8fr8

Before we do any work we should clear our plan with MobileCoin. I'll try to schedule something now.

Pinging @brucek @n8fr8

This issue aims to be the place to discuss some aspects of the backend of the Signal x ProofMode integration project.

One of the user stories for the MVP is sending a Bundle (media + proofs) to a specific target ("relay bot" in Mural?) so as to trigger Starling-specific preservation and registration workflows:

A user can easily take a picture or record a video in-app, and share that with a contact with any associated proof.

Sorry :(