Add create observation endpoint #42
Conversation
|
Can you explain the use-case for this? I'm wary because it removes some guarantees about observations that we have been discussing in the context of legal evidence and proof of observation provenance. And when discussed with Evan we wanted to minimize the API surface area of the server and the associated maintenance cost. |
|
We're building a WhatsApp CoMapeo bot as part of an accelerator we're participating. There's already going to be a lot of security issues with it, so I think we just need to make sure to be explicit about the dangers of using CoMapeo DB outside the official applications. There's no need to merge this into the main branch, it's ok to leave it as a separate branch. I can eventually fork the repo as part of a separate project. |
|
Going to close this PR because it contains several changes that will break things for normal use, so I don't want to risk it being merged. Could you maybe move this work to a fork? FYI the changes to auto-create keys will mean that you will not be able to sync this project with anyone nor add anyone to the project. |
|
Sure! Just really wanted your eyes on it. Could you just explain why it
disables syncing or adding ppl the the project?
Em qui., 23 de jan. de 2025, 18:13, Gregor MacLennan <
***@***.***> escreveu:
… Closed #42 <#42>.
—
Reply to this email directly, view it on GitHub
<#42 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFJLYGYW4RMNGGJZN5PNXL2MFLORAVCNFSM6AAAAABVKRGCWWVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJWGA2DSOJUGEZDCMQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
The project ID is the public key of a key pair generated by the public creator. The server does not currently have a method to create a project, just join an existing one. By joining a project with a random project id, you are joining a project without a creator, and there is no role record giving the server permission to invite anyone. A device would not sync with the server in this state because there is no record of the server being added to the project. Once we add more role validation, the server in this state would probably not read the observations created on it, because there is no project membership record granting the server permission to create observations. Any membership record can only be created by a device with the correct permissions to create one, and that needs to be traced back to the project creator (who signs the membership records with the private key paired with the public key which is the project key). |
|
So i first need to create a deviceId for the user right? Then it can sign the public key and make the whole thing work. Looking at: |
|
Not sure what you mean by “the user” here. The project needs to be created
somewhere, and currently we don’t have support on the server for creating a
project. Normally what happens is a device creates a project, sends the
project key and encryption keys to the server, then writes a signed
membership record saying their server has permission to sync and if it has
permission to create data, and syncs that membership record to the server.
When another device attempts to sync with the server it validates the
membership record before proceeding with sync.
Theoretically the server could create a project, but you would then need to
implement a way for a server to invite devices, if you actually want to
sync devices. But I would need more info on what you’re ultimately trying
to do to advise the best way to do it.
On 23 Jan 2025, at 10:58 pm, luandro ***@***.***> wrote:
So i first need to create a deviceId for the user right? Then it can sign
the public key and make the whole thing work.
—
Reply to this email directly, view it on GitHub
<#42 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACG5GMOQL5W6IXUQUEL6532MFX2XAVCNFSM6AAAAABVKRGCWWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJRGE4DKOBXGA>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
|
Thanks for the explanation. I better understand now. I was making the wrong assumptions regarding how CoMapeo Cloud and the whole project creation flow works. An ideal WhatsApp client would need to be able to create, update and delete observations to a CoMapeo database, which ideally would be able to sync back to the Android client through the Remote Archive. But now I understand that's either not possible as invitation can only happen locally, or not desirable. The Cloud should only be able to create alerts. I guess for now all we can do is create an alerts client, which can serve as a complementary tool for reporting from other people in a territory who aren't exactly part of the monitoring group. And also a non-secure mapping option using WhatsApp only, with the ability to migrate data to a CoMapeo project in the form of alerts in the future. For what I was originally imagining, we'd need to have another class of data which is non-verifiable observations, that have audio, text and details attached to a location. Where trust would be put on the server to represent several devices associated with phone numbers. But for that the Android clients would have to be able to sync these as they do with alerts. A minor feature that could be interesting, I imagine for the CMI use case as well, is having alerts be clickable links that take to external websites. That way other platforms can take care of presenting the richer data that are normally associated with alerts. Here's a diagram of the WhatsApp bot that we'll be building, already updated to reflect the current limitations. It's part of this accelerator that we're participating: stateDiagram-v2
[*] --> Start
state Start {
WelcomeCard: Welcome! Are you reporting an incident or part of a safety group?
WelcomeCard --> ReportingIncident: Report Incident
WelcomeCard --> DefenseGroup: Safety Group Member
}
state ReportingIncident {
VerifyCard: Verify your identity
VerifyCard --> QRCodeVerification: Scan QR Code
state QRCodeVerification {
QRInstructions: Scan QR code to verify
QRInstructions --> Verified: Verification Success
}
state Verified {
LocationShare: Share incident location
MediaUpload: Upload photos/audio
LocationShare --> AlertGeneration
MediaUpload --> AlertGeneration
AlertGeneration: Generate Alert
AlertGeneration --> ExistingCoMapeoGetAlerts
ExistingCoMapeoGetAlerts --> ReceiveAlerts
}
}
state DefenseGroup {
PlatformChoice: Use secure CoMapeo application
PlatformChoice --> CoMapeoPath: Yes
PlatformChoice --> NonCoMapeoPath: No
}
state NonCoMapeoPath {
CreateProject: Name your project
CreateProject --> ProjectQRCode: Generate project QR code
state ProjectQRCode {
ShareLocation: Share project locations
ShareMedia: Upload project media
ProcessData: Process Observation
ShareLocation --> ProcessData
ShareMedia --> ProcessData
NoMapeoGenerateReport: Generate report
NoMapeoExportGeojson: Export data to GeoJson
ProcessData --> NoMapeoGenerateReport
ProcessData --> NoMapeoExportGeojson
ProcessData --> MigrateToCoMapeo
MigrateToCoMapeo: Migrate to CoMapeo via QR code
MigrateToCoMapeo --> ExistingCoMapeo
}
}
state CoMapeoPath {
CoMapeoStatus: Already using CoMapeo?
CoMapeoStatus --> ExistingCoMapeo: Yes
CoMapeoStatus --> NewCoMapeo: No
state ExistingCoMapeo {
AdminVerify: Verify admin status
AdminVerify --> QRInvite: Generate invite QR code
state QRInvite {
InviteTeam: Share QR code
ReceiveAlerts: Get alerts
ViewObservations: Check CoMapeo observations
DownloadOfflineMaps: Download offline maps
GenerateReport: Generate report
ExportGeojson: Export data to GeoJson
}
}
state NewCoMapeo {
Onboarding: Tutorial/Categories
Onboarding --> AdminVerify
}
}
|
Adds a PUT
/projects/:projectPublicId/observationroute for creating new observations.