Could it be the specific proton server you chose? I'm also on proton and never have issues with access

Who was it that got you into Luna in the first place?

Just pushed an update to expose an option on the cli to reuse keys https://github.com/smallworlnd/publsp/commit/21cdce8cb1225ec785016d8caf7ac8cd1bc70c08

Default behavior is to auto rotate keys on startup, so users have to opt-in to reuse. Thanks for the idea!

Love it. I wasn't aware of those options.

Built-in UPS is a great feature

I wonder if it'd be possible to obfuscate the receiving node pubkey similar to how NIP-17 private messages obfuscate the receiver key?

The current implementation of publsp autogenerates new keys at startup if none are found, then saves those to file. Each subsequent startup will try reading that file to see if keys are there to use. I figured that was a reasonable trade-off to reduce friction, and to avoid potential confusion if the tool automatically regenerates new keys each time. But you bring up a good point. This could just be a new option the user sets to deliberately create new keys each time, or the opposite, to keep the existing keys each time. I guess either opt-in or opt-out but the user is made aware.

On the receiving LN node privacy issue, I think that's a separate problem to tackle. In the end, the LSP needs to know where to open the channel so it can't be avoided, but there's no reason that the receiving nodes can't be one-offs, for example.

If it's just for experimentation with family and friends, then you can set up a private, trusted zero-conf channel from your node to their Blixt wallet, for example. That way nothing hits the chain and they can have a 10k sat channel. When they're done just abandon the channel from your node and coordinate with them to pay you back the money they spent.

I'm saying that assuming you were thinking of routing some payments, is that right?

Otherwise if 'others' means family members then there are less capital intensive ways to get them onboarded.

The reality is that channels under 1M sats are much more likely to be liquidity bottlenecks. It's better to go bigger than that, if you can manage it, since it'll give you more breathing room to properly manage that liquidity.

Good liquidity management goes pretty far in getting others connected.

I do, and then they grow too much too quickly and it devolves into war.

That's correct. Also nothing stopping either party from using their own keys if they prefer.

Thanks! I posted a demo here:

nostr:nevent1qqsyp5xmsp9952f6c05lgc24kyu6pa2xwc5skw7qhszyh55lw2h0sqqpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgs9myundyk6v3jmnc4zjs3rvfazjlnx3kc55cn6zktsyaj4h9320usrqsqqqqqpjhhr0s

Soon enough liquidity purchases/renting coordinated over #nostr https://github.com/smallworlnd/publsp

No account or node signing of any kind required.

That one hits hard.

Swiss Chalet but Quebec

Was gonna say St-Hub but you're in Tranno and I don't think there is one there

Awesome. Not a particularly big announcement for me since I'm always pulling the latest but still a big milestone.

Nice work team nostr:npub155m2k8ml8sqn8w4dhh689vdv0t2twa8dgvkpnzfggxf4wfughjsq2cdcvg for coming up with a fix so quickly for https://github.com/dgarage/NBXplorer/issues/518

Instance upgraded and back online.

#nostr makes for a pretty great UX, I'd say. `publsp` is just the first implementation of the idea.

nostr:nevent1qqsrfasy4zxfmajazueptzt3y7qp252c7dz0zvury63qayhlwyzt0fcpzdmhxue69uhhwmm59e6hg7r09ehkuef0qgs9myundyk6v3jmnc4zjs3rvfazjlnx3kc55cn6zktsyaj4h9320usrqsqqqqqpa5l3cc

In a way the UX is no different from going to a website like lnbig to get #LightningNetwork inbound liquidity, but #nostr provides a universal API for any LSP to advertise. `publsp` is just one way to access that universal network of liquidity.

GM. Introducing publsp (https://github.com/smallworlnd/publsp): a free and open-source command line tool for any #LightningNetwork node or Lightning Service Provider (LSP) to advertise liquidity offers over #nostr. It's a rough adaptation of bLIP51 that also takes inspiration from NIP-15, NIP-69 and NIP-99.

The tl;dr:

LSPs advertise liquidity as addressable Kind 39735 events. Clients just pull and evaluate all those structured events, then NIP-17 DM an LSP of their choice to coordinate a liquidity purchase.

If you're looking for liquidity, use publsp to find an LSP that suits your needs and budget, then send the liquidity request on the spot. Use whatever wallet of your choice to pay the invoice, and you get liquidity to your LN node. The invoice itself is a hodl invoice, so the payment preimage is held by the LSP until the channel opens.

As an LSP, use publsp to post a liquidity offer then let the daemon run the rest. It will 1) listen for liquidity requests, 2) send invoices in response to those orders, 3) send funding transactions to the mempool upon payment, 4) update the customer on channel funding details, and 5) release the payment preimage upon channel open.

# Another tool to get inbound liquidity? There are so many already!

There's a dozen different custom APIs available to get channels from specific LSPs, node software that aggregates various LSP APIs, liquidity swaps coordinated through various platforms, protocol-native advertisements supported by one or the other LN implementation, and of course liquidity auction platforms. It's a fractured landscape, each option with its pros and cons. Choice of venue isn't a bad thing, but ultimately it just makes it more difficult for anyone to find what they're looking for at the right price that also fits their personal preferences, whatever those may be.

The more recent bLIP51 spec in particular was something I had high hopes for because it seemed like it was a move in the right direction. A P2P, LN-native, LN implementation agnostic, universal market for liquidity (more so than previous attempts) where anyone could be an LSP and anyone could easily find liquidity. The trouble, however, is that its greatest strength is also its biggest constraint.

There are many reasons why the practical implementation of bLIP51, in my humble opinion, is just not a great UX if the idea is to foster P2P liquidity markets. This insight comes from trying to maintain a reasonably up-to-date list of bLIP51 LSPs at https://sparkseer.space/chanoffers but it ended up being a very difficult task for a number of reasons. I'll spare you all the details, but it boils down to limitations in the LN in its current state and UX. If it's hard to run an explorer (which also has to be done altruistically because competing LSP services aren't incentivized to), it's definitively going to be difficult for the users to get onboard. I don't fault anyone for these shortcomings because the challenges are diverse and complex. In some sense it is a success for some big, well-known LSPs currently making use of it, but the essence of what I'm looking for is still missing.

The heart of the spec itself is solid, though. Kudos to the devs behind it. So, what if it were implemented in a different protocol that might get closer to the vision I have for P2P liquidity marketplaces? Cue Nostr.

# Nostr as an open, P2P liquidity marketplace

- Infinitely extensible in ways unimaginable right now, especially with the advent of AI agents participating in the open market

- Existing LSPs on other platforms/protocols/APIs can easily plug into Nostr, and it may be to their detriment not to in the future!

- Free to use (free, as in beer, and free as in freedom) for both customer and LSP, you're not locked in

- Open to any customer and LSP, arguably with minimal friction

- Transparent advertising: what you see is what you get, and order invoice details can be verified against it on client-side (don't trust, verify)

- uncensorable, no one can stop you from advertising or purchasing

- Decentralized, no single API point of failure, and liquidity offers persist

- Orders can be privately made through NIP-17 DMs, so order flows are not broadcast and not centralized while also providing some plausible deniability

The current implementation in publsp is just a beginning. The future for an open liquidity marketplace over Nostr is bright. Here are just a few things I can envision happening in the near future:

- Nostr grows into a pervasive, super simple universal API that attracts both clients and LSPs from disparate venues

- Liquidity swaps can be coordinated over Nostr as an alternative to purchasing inbound

- Nostr's flexibility allows for reputations to develop in novel ways, possibly through rating systems, open customer service, advertising in unique ways

- The experience can be flipped around where the client could simply announce 'I want a channel of N sats' and then LSPs would compete for that business

- Various data silos can exist and be tapped into through Nostr (possibly for a price) to inform decisions

- Give autonomous AI agents some budget to go collect data from public events and paywalled data sources to condense into a decision

- Other LN marketplaces popping up over Nostr

That's all for now. Testers and feedback appreciated. Onwards

My eyes :(