-
@ 57d1a264:69f1fee1
2025-02-25 12:38:46
I've been pondering how LSPs (lightning service providers) might pan out over time and how that might affect fees, and I am wondering what everyone else is thinking. Some people will always prefer to manage their own channels, and for some specific use cases, that might be preferable. But I am thinking about the broad userbase that does not want to do that. We will need a massive LSP infrastructure to onboard people and to enable insane amounts of payments.
LSPs will need to efficiently open and adjust channels for users, using their own liquidity or sourcing liquidity from other providers, using just-in-time channels, batching and/or splicing to reduce costs and wait times. Across all this, along with facilitating payments, they need to make their business model work and offer different options for users to pay for their services.
Users might be able to:
1. Pay-as-you-go (pay X for Y more liquidity for Z amount of time)
2. Pay X per month for Y inbound liquidity
3. Pay X per month for unlimited liquidity
4. Nothing for liquidity, but higher transaction fees
A wallet might also automatically choose an appropriate LSP based on what is the best and most appropriate deal at the time.
Let's look at user scenarios:
- If someone sends and receives the same amount every month, they will never need more liquidity. They just draw down the same channel and fill it up again. So they would only pay the LSP for them assigning that fixed amount of liquidity to them. Maybe options 1 and 2 are good for them.
- If someone receives more than they send (they save a certain amount every month), they will need more and more inbound liquidity over time. They might choose option 2.
- An online store that receives a ton and can't really estimate how much, might go for option 3.
- For option 4, it depends if the higher transaction fees are fixed or percentage-based.
It's a bit like choosing a data plan for your phone (or for internet at home). You can get a prepaid card, a regular plan with certain limits, or go unlimited. And there are separate plans for small and large businesses, etc. And there are massive amounts of complex infrastructure behind these service providers to make it all work.
So when someone starts using a lightning wallet, maybe they have to first pick an LSP and a plan before being able to receive. Or maybe they get a first channel for free and pay higher fees, and are then prompted to choose a plan. Maybe they need to wait an hour until the LSP has enough channel opens for a batch/splice, to reduce costs. A complex market at work.
Is that how things might pan out? Am I completely off? Is it worth mocking up different scenarios?
```
#bitcoin #LN #BTC #Lightning #LSP #service #zaps #sats #wallet
```
originally posted at https://stacker.news/items/896520
-
@ 57d1a264:69f1fee1
2025-02-25 07:28:18
@Voltage team will be building a simple implementation of a Lightning gated API service using a Voltage LND Node and the L402 protocol.
📅 Thursday, February 27th 4:00 PM CDT
📷 Live on Voltage Discord, on X, or on YouTube.
- discord.gg/EN93fDfQ
- https://x.com/voltage_cloud/status/1892938201980919985
- https://www.youtube.com/@voltage_cloud
originally posted at https://stacker.news/items/896373
-
@ 57d1a264:69f1fee1
2025-02-24 04:10:33
As your involvement in open source design increases, you’ll face challenges that go beyond basic UI work. From creating scalable design systems to mentoring new contributors, these advanced areas require strategic thinking, collaboration, and leadership.
This chapter dives into these complexities, helping you handle real-world situations while continuing to grow as a designer.
- Championing Design Initiatives
- Creating and Maintaining Design Systems
- Handling Complex Design Challenges
- Conducting In-Depth User Research
- Balancing Open Source Work with Other Commitments
- Navigating Project Dynamics
-0 Mentoring New Designers
Read more:
https://opendesign.guide/10-advanced-topics
```
#design #nostrdesign #bitcoindesign #ln #grownostr #asknostr #zap #btc #bitcoin #nostr #cashu
```
originally posted at https://stacker.news/items/895377
-
@ 266815e0:6cd408a5
2025-02-18 17:26:16
To all existing nostr developers and new nostr developers, stop using kind 1 events... just stop whatever your doing and switch the kind to `Math.round(Math.random() * 10000)` trust me it will be better
## What are kind 1 events
kind 1 events are defined in [NIP-10](https://github.com/nostr-protocol/nips/blob/master/10.md) as "simple plaintext notes" or in other words social posts.
## Don't trick your users
Most users are joining nostr for the social experience, and secondly to find all the cool "other stuff" apps
They find friends, browse social posts, and reply to them. If a user signs into a new nostr client and it starts asking them to sign kind 1 events with blobs of JSON, they will sign it without thinking too much about it
Then when they return to their comfy social apps they will see that they made 10+ posts with massive amounts of gibberish that they don't remember posting. then they probably will go looking for the delete button and realize there isn't one...
Even if those kind 1 posts don't contain JSON and have a nice fancy human readable syntax. they will still confuse users because they won't remember writing those social posts
## What about "discoverability"
If your goal is to make your "other stuff" app visible to more users, then I would suggest using [NIP-19](https://github.com/nostr-protocol/nips/blob/master/19.md) and [NIP-89](https://github.com/nostr-protocol/nips/blob/master/89.md)
The first allows users to embed any other event kind into social posts as `nostr:nevent1` or `nostr:naddr1` links, and the second allows social clients to redirect users to an app that knows how to handle that specific kind of event
So instead of saving your apps data into kind 1 events. you can pick any kind you want, then give users a "share on nostr" button that allows them to compose a social post (kind 1) with a `nostr:` link to your special kind of event and by extension you app
## Why its a trap
Once users start using your app it becomes a lot more difficult to migrate to a new event kind or data format.
This sounds obvious, but If your app is built on kind 1 events that means you will be stuck with their limitation forever.
For example, here are some of the limitations of using kind 1
- Querying for your apps data becomes much more difficult. You have to filter through all of a users kind 1 events to find which ones are created by your app
- Discovering your apps data is more difficult for the same reason, you have to sift through all the social posts just to find the ones with you special tag or that contain JSON
- Users get confused. as mentioned above users don't expect their social posts to be used in "other stuff" apps
- Other nostr clients won't understand your data and will show it as a social post with no option for users to learn about your app