COAR notes
These are some notes that have come up after the COAR notify meeting I attended.
These are not meant as todos (we should make separate issues if it comes to that), more as food for thought.
- We are currently conflating the receiver and the consumer logic. This means that our inbox receives, but also processes a notification. We could separate the inbox from the actual processing. This doesn't necessarily mean that the inbox should be a completely separate service or microservice (though that would be a viable option if we see the benefits).
- The receiver could respond with a 202 status upon receiving a message. This is a continuation of the previous point, where the inbox's job is to receive the message, not to process it necessarily. In this sense, as long as a valid payload has been received, we respond, then the processing happens independently.
- If processing happens separately, and it fails, we can send an error to the original sender of the notification that their request cannot be processed. This would assume though that the original sender can actually receive messages like this.
- We are currently not validating that the payload is valid COAR. Elife seems to already have a validator library in node that we can use.
- We should add different errors for different scenarios. eg. did this fail because there was a validation error, a processing error etc
- Rejection (eg. if someone sends a request for endorsement, which we currently do not support) could be handled differently than an error
- We could have an api endpoint that can describe what the system can do with regards to COAR. This way a sender can use our api and retrieve for example, that we only accept offers for review and that there's a sender whitelist in place, instead of trying to send something to our inbox only to see if it works.
- We should have a handler for the case of receiving a duplicate message.
- We should maybe introduce rate limiting of some sort.