Still no beta 🐌, but 2 new alpha releases we can share with you, Alpha 9 and Alpha 10. Let’s have a look at what’s new and what’s the holdup.
Autopeering is fixed
We don’t know if anybody even noticed but Rafiki’s local playground autopeering didn’t work for quite some time because tunnelmole disallowed multiple open tunnel connections at the same time without a subscription. Since we didn’t want every developer looking into Rafiki to buy a tunnelmole subscription, we looked for alternatives and landed at another open source tool called localtunnel. While localtunnel requires user confirmation when accessing tunneled front-end pages, Rafiki is mainly backend software, hence localtunnel worked as an alternative for us.
Tigerbeetle production release
While we are still trying to finally make it to Beta, our friends at Tigerbeetle have released their first production release! Congratulations to Joran Dirk Greef and team 🥳! Of course we also upgraded our version of Tigerbeetle that Rafiki comes with.
Open Payments Quoting is optional
We have always introduced Open Payments as a three-step process.
- Create an Incoming Payment
- Create a Quote
- Create an Outgoing Payment
While this makes perfect sense for e.g. e-commerce payments, i.e. once-off payments. It doesn’t necessarily work that well for recurring payments, e.g. subscriptions or Web Monetization payments. In these instances, payments are pre-approved based on an existing outgoing payment grant. This means a user does not need to explicitly approve a payment on a consent screen, meaning we can remove the extra round trip for quote creation, since it does not add value for the client.Hence, we have allowed for the creation of outgoing payments without a quote if those outgoing payments are created with such a long-lived grant. The ILP rate probe still happens under the hood, however.
Security features
This was always supposed to be the last missing piece before we moved to Beta. And don’t get me wrong, it was definitely the biggest missing piece. We have secured the Admin UI using Ory Kratos and the Admin APIs with a shared secret between the ASE and Rafki, that is used to sign request signatures, just like webhook requests are currently already secured. If this secret is set within Rafiki, it expects all incoming Admin API requests to be signed with that secret.
What’s the holdup?
So if the security features are done, why is there still no Beta release of Rafiki? The main reason is that we are currently working on a couple of breaking changes and Beta is supposed to be at least somewhat stable. So let me walk you through those upcoming breaking changes:
- We are moving the grant interaction endpoints to a different server/port. That way, this port does not need to be exposed because it’s only communicating with the ASE’s identity provider.
- We have opted to transition away from treating errors as data within the GraphQL Admin APIs and we are now returning errors as described in the GraphQL specification. The reason for the transition was the inconsistency in queries (that didn’t treat errors as data) and mutations.
🤞There will be a Beta release next month! 🤞
Top comments (0)