[WIP] [RFC] offer: be able to create an offer with description

[vincenzopalazzo]

PR Proposal: Support for Offers with Descriptions in phoenixd

I started exploring phoenixd to enable the creation of offers with custom descriptions, allowing users to specify the purpose of their payments.

It is widely recognized that phoenixd is one of the best solutions for regular users to operate their own node without having to navigate the complexities of the Lightning Network. However, in the Phoenix mobile wallet, there is currently no option to create offers with custom descriptions beyond the default one. While this limitation exists for valid reasons, I believe it is possible to support this type of offer on the server side. Doing so could unlock new use cases for using Phoenix.

This PR aims to introduce support for creating offers with custom descriptions that work seamlessly with the LSP, just like the default offers.

Current Status

This PR is a work-in-progress because I believe there are changes required on the LSP side to handle and fetch this new type of invoice.

I have a partially working version of phoenixd based on this commit: phoenixd branch with description offers. While the modifications in phoenixd are functional, the feature is not fully operational due to the LSP's current limitations. I would need guidance on how to modify the LSP to support these changes.

Request for Feedback

I am opening this PR to gather feedback from the team regarding the following points:

1. Is there interest in supporting offers with custom descriptions in phoenixd?
2. If this is not a priority at the moment, I would like to volunteer to maintain this part of the code if it requires ongoing attention.

Missing steps

• Polish the code and remove some fixme around the current solution
• Implementing persistance for the offer generates
• Adding the endpoint in phoenixd to create an offer with description
• Resolve the LSP part that now it is rejecting the fetchinvoice message for a no default offer

[pm47]

That's a duplicate of #678.

[vincenzopalazzo]

Oh nice, thanks for pointing me to it. What is the status of the conversation? there is any eta to it?

[t-bast]

While the modifications in phoenixd are functional, the feature is not fully operational due to the LSP's current limitations. I would need guidance on how to modify the LSP to support these changes.

This has nothing to do with the LSP: I think that your current code isn't working because the custom offer you're creating isn't registered in the OfferManager, so invoice_requests are ignored by your phoenixd instance. See #678 where the offer is added to the OfferManager.

What is the status of the conversation? there is any eta to it?

The open issue with #678 (and the reason why it wasn't merged) is that there currently isn't any persistence mechanism for those custom offers. We would need to store those offers in a new DB, and load them on start-up to register them to the OfferManager. We would also need a mechanism to list offers and revoke them.

It's really unclear whether this additional work is worth the effort: we haven't had any other request for that feature apart from Ocean. None of the phoenixd operators seem to need this feature right now, so I guess we'll wait for compelling usecases before making this a priority.

[vincenzopalazzo]

This has nothing to do with the LSP: I think that your current code isn't working because the custom offer you're creating isn't registered in the OfferManager, so invoice_requests are ignored by your phoenixd instance. See #678 where the offer is added to the OfferManager.

Thanks for guiding me, @t-bast. I didn’t pay much attention to the error that was returned because I couldn’t compile phoenixd on my Arch Linux setup. I had to rely on my remote server with Docker instead.

Perhaps I could use the JVM build as a workaround? This might be something we can discuss further in PR #126.

The open issue with #678 (and the reason why it wasn't merged) is that there currently isn't any persistence mechanism for those custom offers. We would need to store those offers in a new DB, and load them on start-up to register them to the OfferManager. We would also need a mechanism to list offers and revoke them.

Yep this is the point where I got stuck too 😸 (outside of the previous error that you pointed out)

It's really unclear whether this additional work is worth the effort: we haven't had any other request for that feature apart from Ocean.

I’d like to double click about "ocean" here before moving forward with the discussion. Just to clarify, even though I’m the same person raising this, this is not an "ocean" request. The work I do isn’t entirely owned by them — I contribute to Phoenix because I find it enjoyable and it aligns well with my expertise and interests. Then if ocean will ship phoenixd as an alternative is just because I like the usability that you are giving to the user and I do not like to see user of the lightning network said that it is too difficult just because they are using the wrong implementation.

This PR stems from a discussion with @rustyrussell regarding PR #7786, where we were considering the idea that users should specify what they want to be paid for. However, in my opinion, the rationale for the Phoenix mobile wallet is too compelling to bring this argument to the mobile wallet side. On the server side, though, I think this idea might be more acceptable.

None of the phoenixd operators seem to need this feature right now, so I guess we'll wait for compelling usecases before making this a priority.

Probably I am missing some of them for sure, but I was looking at the UI that was using phoenixd, and they do not have a bolt12 support at all. e.g: https://albyhub.com

Are there any phoenixd operators you could point me to who are using Bolt12 today? And why are they using the default offer without considering the description? To me, this seems like a lack of alternatives within the ecosystem. phoenixd is so superior that operators are simply using the features it ships with because "it just works"—which is very different from "barely works." with other full node implementations

E.g: I know that cashu is doing bolt12 magic with a description but I did not have a change to understand what yet and they should be a phoenixd operator

P.S: In the meantime I will move my fork of phoenixd using the #678

[t-bast]

Good points, it can indeed be useful for phoenixd where people may want to segregate payments between multiple offers to make accounting easier. In that case I think it makes sense to have in lightning-kmp, so the remaining work that needs to be added on top of #678 is:

• create a new DB to store offers that are created by the node operator
• allow creating, listing and revoking such offers
• load those offers on start-up and register them with the OfferManager

Then phoenixd can add APIs for this, that internally just call into lightning-kmp.

[vincenzopalazzo]

Thanks @t-bast

I could take ownership for this. Due that I am new there do you have any channel where I can put some question if I get stuck understanding the design of phoenixd?

P.S: changing ownershit -> ownership I made a typo sorry my screen reader did not catch it

[t-bast]

I could take ownership for this. Due that I am new there do you have any channel where I can put some question if I get stuck understanding the design of phoenixd?

Great! We usually use github discussions, we're pretty responsive on those, don't hesitate to use that for questions!