@nemo not significantly different from what you're thinking of already, but if it's a small message, an SQS queue could work as well. PutMessage from somewhere, and the lambda gets the message from that queue.
@ni_nad SQS adds a lot of surface area for what I'm attempting: https://tatooine.club/@nemo/110124326073673862
@nemo if you're thinking of surface area as 'anything can push messages to this queue beyond a well defined set of resources', it's no different than an S3 bucket. I get the general sense of what you're trying to do (trusted computing on serverless) but I'm still figuring out your approach!
@ni_nad I was worried about queue replication, dead letter, SNS etc. Lots of inadvertent ways for data to stay in there.
We want to guarantee (Provably) that the data reached the lambda (only), and the lambda did exactly what it was supposed to do (Verified).
Adding bigger blocks like SQS makes it hard to prove that the data wasn’t going elsewhere. Maybe even true for S3, so need to think of simpler primitives like just simple http servers perhaps.
@nemo yeah, that's the direction I went in too. Unless we enforce policies on the queue as to which principals can put messages, it is hard to prove authenticity. Same would apply to S3 too. A web server you control (or an mqtt or amqp or S3 compatible API) is probably better here