Livepeer Payment Clearinghouse

Direct Grants
5

Thank you @Mehrdad for the review and @rickstaa for the ongoing support on this initiative. I am excited to be building this developer-facing project for the Livepeer community!

Today I’m publishing the first community update for this project, which I will be publishing weekly following each deliverable.

Weekly Recap

The project kicked off Monday by migrating the current pymthouse.com signer proxy architecture over to OpenMeter with Kafka, to bring it into compliance with the specified new Kafka events architecture for usage tracking. This was necessary to provide a working Livepeer Dashboard demo on Tuesday.

On Wednesday, I began preparing the PR for the OpenMeter bootstrap scripts. It soon became apparent that the original implementation in builder-sdk was unnecessarily extensive and fragile due to a recent shift in SDK / API compatibility related to KongHQ’s recent acquisition of OpenMeter.

The only well-supported SDK that KongHQ provides for their hosted OpenMeter API is the go-lang package sdk-konnect. The OpenMeter OSS NodeJS SDK was not fully forward compatible with KongHQ’s hosted OpenMeter service which created a requirement to either use the go-lang SDK or generate client wrappers with OpenAPI. I made the choice to use the go-lang SDK to OpenMeter integration.

This led to a draft OpenMeter go-lang CLI, which can be found here feat: Go bootstrap CLI for Auth0 + OpenMeter/Konnect by eliteprox · Pull Request #33 · livepeer/clearinghouse · GitHub . Since OpenMeter Bootstrap is set for delivery in Milestone 3, this was used only to scaffold the OpenMeter hosted environment and not cleaned up for review yet.

OpenMeter provisioning is being moved into the OpenMeter Collector instance to make the solution more maintainable and will build on the work from the Milestone 2 PR which adds automatic customer provisioning for usage events feat(collector): implement customer upsert functionality in OpenMeter collector by eliteprox · Pull Request #39 · livepeer/clearinghouse · GitHub .

This can certainly be implemented more directly in the administrative API, which will be considered this week.

Milestone 1 & 2 Status

In conclusion, last week I created the first two pull requests to satisfy Milestone 1 & 2 and one PR to satisfy Milestone 3. All of which are currently under review:

This Week’s Focus - Milestone 3

The focus this week will be on first merging the initial PRs proposed for Milestone 1 & 2, with the majority of the week focused on Milestone 3 which will ship the bootstrap scripts to fully provision the hosted OpenMeter instance.

We also plan to implement a lightweight administrative API for querying usage at the platform, app or user level. This is initially planned to ship as new http endpoints within the OpenMeter Collector, which already has credentials for managing the billing instance.

Project Scope Clarity
I want to address an FAQ I’ve got from a few community members about the scope of this project as it relates to pymthouse.com (the current production clearinghouse site).

Q: Is github.com/pymthouse/pymthouse being replaced by livepeer/clearinghouse?
A: No, the project repository at livepeer/clearinghouse will be clean, modular example of a Livepeer Remote Signer / OpenMeter clearinghouse implementation as described in the milestones outlined above. The architecture is an improvement from PymtHouse and will make the stack modular, documented and straightforward for other builders to deploy, should they wish to operate their own infrastructure.

Each improvement to the solution will be up-streamed to pymthouse/pymthouse and deployed to pymthouse.com incrementally as I have done last week with the OpenMeter / Kafka integration.

This delivery pattern supports a dual validation approach for both webhook authentication adapters described in this grant (api-key and OIDC).

  1. livepeer/clearinghouse will be validated locally with builder-sdk using the signer webhook configured with api-key authentication.
  2. pymthouse/pymthouse will be validated in live deployments with the signer webhook configured with OIDC authentication.

Q: What is builder-sdk? Should we re-write that too?
A: builder-sdk is the NodeJS package which implements the webhook used by clearinghouses and platform applications to perform RFC 8693 OIDC token exchange, which allows them to issue a signed JWT for their own users. The builder-sdk supports both api-key and JWT authentication, allowing for both integration patterns to be supported. I am considering moving this work to a fresh repo so it can be minimized in scope

Thank you to the community for your continued support and feedback. Please feel free to comment below with any questions

2 Likes