Implementing Lightning Address for lnsms.world

[jogc]

I've been implementing Lightning Address for lnsms.world the last few days and wanted to share my
experience and thoughts.

The idea was to allow users to simply specify [email protected] as a destination to be able to easily send a text message to the phone number NUMBER. On the surface it seemed like a perfect fit.

One major issue I have though is that due to the complexities of how SMS messages are encoded, it's impossible for me to know how many bytes a message will take up and consequently how much I need to charge for sending it without first seeing the complete message.

I could take a guess, but if i want to be completely safe the limit i would have to put on message size would be ridiculously restrictive in relation to the price.

Unfortunately, the way LA/LNURL currently works I need to give a price or a price range before I see the comment (which I my case will be the content of the message to send). So what I would like is a way of not having to give either a price or a price range (and ideally not a comment limit either), but just indicate that I would like the client software to give me a comment and in exchange I will give an invoice.

The second issue I had is that all information being exchanged is sent as request string parameters in a GET request. That means in a typical configuration it will be written to the webserver's access log, for example /var/log/nginx/access.log. So in my case both the recipient number and the full message contents ends up there, which I consider a big no-no. I'm very careful to not store that kind of information anywhere for obvious privacy reasons. Fortunately it was relatively straight-forward to use a custom log format + some regex matching to strip that out but I imagine this could be a problem for other services as well.

While working on this I got some ideas on how, in an ideal world, LA/LNURL would work to be 100% adapted to my use-case:

I imagine something like this:

There is only one endpoint. The client would repeatedly hit that endpoint until it gets an invoice. The first time, the client would not supply any data (same as now). If there is no data required, the server would simply respond with an invoice immediately. If any data is needed, the server would instead respond with a list of required fields. Those could include an exact amount (and in this case the server will provide an acceptable range) and it could also include a comment, with or without a max length. The client the asks the user for the required information and hits the endpoint again, this time with the data attached. (The client chooses wether to use a GET or POST for this and the server will respond to either.) The server once again either responds with an invoice, or again gives a list of additional data fields that are required. This goes on until the server is satisfied and responds with an invoice. When the client gets the invoice it asks the user for the final confirmation, using the amount in the invoice and then makes the payment.

In the vast majority of cases this will only involve one or two requests, but in some cases it could be three or even more. So there will basically be a kind simple dialogue between the server and the user. I think something like this would be flexible enough to cover most use-cases and at the same time save in one HTTP request in those cases where there is no need for the user to specify an amount.

I realize there are most likely reasons you have designed LA/LNURL they way you have and regardless it might be hard to change fundamental parts of it at this stage but I still wanted to share.

As it is now, using Lightning Address with lnsms is a terrible user experience.

[reneaaron]

@jogc This is a really interesting use case. That way you could send an SMS by paying to the Lightning Address [email protected], right?

While I also see no solution to that problem in general, you could maybe make the default use case of sending a single sms work by setting the allowComment property at the LNURL endpoint to a maximum number of characters that is covered by the minimum price set in minSendable.

That way wallets should indicate to users that there is only a certain character limit for their comment. I don't know about how this is implemented across wallets, though:

https://github.com/fiatjaf/lnurl-rfc/blob/luds/12.md#wallet-side