I’ve been working with @Leandrodimarco on a protocol/approach for Recurring (Push) Payment services.
In concept, it functions similar to an RSS feed - the Recurr application itself is an “aggregator” that would allow users to add Recurr-formatted feeds from service providers (that support it) and view/instantiate the payment of bills from within the app.
Although this is not necessarily BCH specific (it uses URL’s to instantiate actions like payments - meaning most payment methods/gateways could be supported), we’d like to reach out to the BCH community for feedback on the specification/approach - as BCH was the primary motivation for this project.
The website with more detail and a (WIP) MVP WebApp can be found here:
(Examples feeds should also work if anyone would like to see how it would function.)
The design goals for this are primarily:
- To be simple for services to implement (NodeJS example of how implementation may look is around 100 lines: Guide - Recurr).
- To allow both fiat and crypto bill payments.
- To be decentralized in the sense that the protocol does not depend upon any central server to function (avoids contention).
The main item of concern we have is enhancing security - in a way that does not over-complicate the implementation for services (or make implementation too difficult):
Currently, if a Feed URL is exposed, a user’s bills/receipts (fee payload) would also be exposed. Although HTTPS will be mandated (thereby obscuring URL paths from any MITM), these URL’s would still appear in server-logs, etc.
Hoping to feel the waters for what could possibly be done to enhance this while making it so implementation for services is still simple/easy. Currently, implementation should be able to be done in around 100-150 lines of code. Guide here demonstrates how it might look in < 100 lines: Guide - Recurr
The current approach we’re considering to enhance security is using a symmetric key which is included in the scan URL and having the service then encrypt the feed payload with this key (ideally, with an encryption algorithm that’s well supported across languages). We’re open to using a Private/Public keypair also - but are concerned that it might complicate implementation. Opinions on this would be much appreciated.
We do also plan to support Push Notifications (as opposed to only RSS-like polling) - but that will likely be in a future version of the spec and will not force the use of any particular Push Notification service so that we can maintain a decentralization and avoid contention. As it is currently, the protocol supports “delta” records and that, combined with a compression (gzip is supported by all major HTTP servers), means the payload remains small. Hence, even as is, bandwidth usage should be fairly minimal.
We also plan to create Native Apps for iOS/Android as Progressive Web Apps (PWA) have some limitations - however, we would like to finalize the proto and PWA before focusing on these pieces.
Any other feedback/recommendations/thoughts would be much appreciated.