MetaMask
Request/Response Middleware
This draft introduces a new endowment that would allow a snap to register itself as a request middleware.
I think this SIP would better serve as defining Snaps JSON-RPC middleware instead of catering to becoming solely a JSON-RPC provider. I'm interested in re-writing this spec to have a Snaps middleware stack in the extension. I can envision a HOPR middleware snap still sending the request to the provider through HOPR and terminating execution through some res object. HOPR can be one of the first few snaps providing middleware.
I think this SIP would better serve as defining Snaps JSON-RPC middleware instead of catering to becoming solely a JSON-RPC provider. I'm interested in re-writing this spec to have a Snaps middleware stack in the extension. I can envision a HOPR middleware snap still sending the request to the provider through HOPR and terminating execution through some
resobject. HOPR can be one of the first few snaps providing middleware.
I think a generalized middleware stack would certainly be useful. However, as you already correctly described the RPCh integration would have to be some kind of middleware processing termination point because it touches the entire request (target, headers, body) and other middleware would not be able to process it further. As long as that is supported the approach should be good.
@hmalik88 @esterlus I updated the proposal to match the discussed middleware approach. Feedback is welcome.
@Mrtenz @hmalik88 I would like to turn this SIP into a form which is acceptable to you and which works for our use-case. As it stands the current proposal is somewhat in between a generic middleware approach and a focused support for RPC request execution.
To keep things simpler I would actually propose to split this into 2 SIPs: (1) Middleware without support for entry or termination, which simply can modify the request headers and data; (2) A RPC request executor, only a single one can be set, which replaces the "simple" fetch internally.
Thoughts? I am happy to write both SIPs if we agree on the approach.