The last few days I revisited the prism-v2 branch. I made some big structural improvements to the prism API a couple months ago, but left some features unfinished. But it's now a good time revisit the plugin due to Top Builder. Fortunately, the inimitable Damian Goodenough was paying some attention to the plugin as well, so we both contributed to pushing the v2 branch forward a bit.
What is the goal of all this work on the Prism plugin, and how does it relate to LNPlay?
First of all, I use LNPlay as a development environment for developing the Prism Plugin. It's not the only way to develop Prisms, just one option. I want to use the prism plugin in a more flexible way for my various Value4Value websites, the latest of which is roygbiv.guide. I also want to extend the prism functionality to also work in the context of LNPlay.live. My intention is to execute one or more Prisms at various points of the LNPlay instance lifecycle (e.g., purchase, provisioning, de-provisioning).
Prism Plugin Database Structure
Damian pointed out that we weren't using the CLN datastore method correctly, especially as it pertains to database keys. Our previous attempts at the prisms were extremely naive in terms of database performance as a result.
So, we set off to refactor the to make more efficient use of the database. The image below shows the prism database key/value structure at the time of this post:
The CLN documentation recommends the first key string to be the plugin name, thus we start with prism. The second layer is the prism version. This allows us to version the database records. So if there is a change in the database schema in future version of the plugin, we can develop migration logic.
member_ids to their own hierarchy the same level of prism and bind.The green and purple sections in the diagram define the prism policy and the state of a prism binding, respectively. The prism state includes member outlays.
BOLT12 Offer Prism Relationships
Damian helped in making another important decision for the project. For v2, I initially I architected the prism plugin to allow for multiple prisms to be associated with a single offer. I figured no one would use that feature often, but I didn't want to preclude the functionality from the system.
But, after discussing the issue with Damian, he convinced me that we should make prism bindings a one-to-one relationship. That is, only ONE prism can be attached to a BOLT12 offer at any given time.
Ok, so once we made that decision, I had to go back over the prism plugin and restructure the code to conform to this new key structure.
Learn more
If you're interested in learning more about the prism plugin, go take a look at the updated the Readme. It outlines the PrismV2 API. The v2 branch is still feature incomplete. The Prism plugin will have to take a breather however, as we switch our focus to other milestones.
Like what the prism plugin enables for the Lightning ecosystem? If so, considering leaving a tip.