Will we still have "the feed" in 20 years from now? If no, what will replace it?

Cuando entro a #nostr

What’s name for accepting a pull request on a NIP or NIPs?

A Nip Pull

Pulling Nips

Pulling Nipples?

#asknostr

Declined.

If you ask for permission to make something that permission should always be rejected

If you don’t eat your meat, how can you have any pudding!?

Let me try to answer your main concern by way of an analogy.

Suppose a little old woman opened up a street business where she will give you a quick massage. For $5, you can sit in her chair for up to five minutes and she will massage you and talk soothingly to you in a grandmotherly way. Her business is quite successful, and people love to sit in her chair, but she notices something: people rarely stay for the full 5 minutes. They typically only stay for 1 minute. Considering this, she drops her price, but keeps the sign the same otherwise: for $1, you may sit in her chair for up to 5 minutes and be pampered.

In this situation, I think it would be silly if she got mad at someone who occupied the whole 5 minutes, or close to it. The little old woman is under no obligation to offer the cheaper rate or expect every sitter to only sit for 1 minute. As long as her sign says you may sit 5 minutes for $1, any sitter should feel perfectly at ease sitting 5 minutes for $1. If the little old woman doesn't like it, she can raise her fee or lower the time limit. The silliest thing she can do is scream at customers to stop staying for 5 minutes when her own sign says they may, or tell them they are ruining her business, or making her mad. The sitters are only accepting the terms she advertises, over which she has complete control.

To me, it's the exact same with hodl invoices and lightning. If, for some reason, a node operator doesn't like the rates my users pay to use an htlc slot for something slightly closer to its maximum length than is typical, they have two options: reduce the time limit, or raise the rates. If they don't do that they have no one to blame but themselves. All my users are doing is paying the advertised rate for the advertised time limit. I don't think it's wise to blame them or me. If you're a node operator, and you don't like what my users are paying, change your sign. Be the change you want to see in the world -- don't harp on my users to stop using your node in the way you are publicly advertising they may use it.

With regard to ecash, it's certainly a cool product, but I think it's a pale imitation of an asynchronous payment. Let's say Alice wants to send money to Bob. If Alice uses Carol's service to create an ecash token for Bob, it might seem asynchronous because Alice may go offline. But Alice isn't really the sender anymore. She gave her money to Carol and got her to promise *she* will send it to Bob. (Or rather, whoever comes first to claim it with something that is essentially a promissory note.) When that happens, the real sender is not Alice, it's Carol, and in order for it work Carol (the sender) must be online when Bob wants the money.

I don't have anything against that, I think it's cool. But I don't think it's *as* cool as a true asynchronous payment. With zaplocker, Carol never has your money. Carol is essentially a routing node between Alice and Bob, and routing nodes don't have custody of funds that use them as part of a path. I think that's cooler than a custodial model like ecash. Instead of depositing *money* with Carol, Alice routes a payment *through* Carol in such a way that Carol can only cancel it or forward it, not keep it. But after that it's largely the same: Alice may go offline, and Bob may come collect his money at his leisure. With ecash, Bob doesn't have a time limit, which is cool, but I think that's an acceptable tradeoff since the gain is self custody.

I don’t understand this idea of trying to convince people to design a product to “be nice” to the network. If they are following the rules of lightning and the product works, then there should be no issue. If lightning can’t handle a pro-lightning company operating within the rules of the system, how is it supposed to function in an adversarial environment?

My dad Walked all the Darién jungle, crossed Center América and méxico and passed to USA, all that Journey took him 2 months.

But he is finally in new york with her sister.

I thanks god he's fine and nothing serios happening to him in the road

.

If hodl invoices achieve wide adoption it will have an outsized impact on the network. A lot of things will change but let's keep it simple: it will push the entire network toward a reputation based system. This is bad for a permissionless network. Ideally, I should be able to spin up a new node, commit capital, and send payments with a high success rate. But now everyone is suspicious of unknown nodes. They're tracking your invoices to see how long they stay open. People run block lists and maintain a database of surveillance data. We already see this happening with channel probing. Maybe it is inevitable, idk. But I certainly don't agree that we should run toward this outcome. ¯\_(ツ)_/¯

In my previous reply I was facetiously describing ecash, which IMO is a categorical improvement for the async payments model. The sender does not need to be online for the recipient to receive payment. This is the role of the central server or "mint". It's just wheeling and dealing lightning payment promises all day, blind to the identity of its users. With the advent of DLEQ proofs, you can even trustlessly transfer ecash offline as long as the recipient knows the public key of the mint. People complain that the mint can rug you but is this really different than when a hodl invoice expires and you get a channel force close? I contend that it is not. This design adds a central party to facility async payments, improves privacy, and doesn't push negative externalities onto the network at large. The only downside is that you can't yet hack something together in a weekend. Or maybe you can...the gap is closing fast!

> You are holding HTLCs open on all nodes along the route

Yes

> HTLCs are a limited resource and those nodes are not being compensated for the use of this resource or for the increased risk of force closures

That is their choice. They choose what fees to charge for the use of their htlc slots. If the fees they charge aren't covering their costs they can raise their fees. If they are unwilling to do so they will be priced out by nodes who are more willing to charge market rates for the use of those slots.

> You make a valid point that they can change this setting but this brings unrelated externalities

Charge money for them. If someone said, "I didn't want to have to think about my htlc slots being held in a pending state for an extended period," I think that is a perfectly valid reason to stop running a routing node. Other people will step in who *did* think about that and decided to charge money accordingly.

> HTLC delta was included in the protocol to allow a grace period for node runners to reconcile failed payments on chain

They have a variable-length grace period for more than one reason. Other protocols, like submarine swaps, have been around since pretty much the beginning, and they use hodl invoices too. Part of the reason that grace period exists is for use in swaps that take a few blocks to complete. I'm doing that too, just with a 24 hour grace period, which is well within the standard parameters.

> Your use of this resource for economic purposes muddies the waters

I think it brings clarity. Routing nodes have a better idea now of what they signed up for. Robosats and boltz exchange already showed them that invoices can be held for days at a time, now lightning addresses are doing it too.

> I can understand why routing nodes are upset about this. It externalizes costs to the entire network.

It puts the cost on routing nodes, who explicitly charge a publicly-advertised fee to cover costs that they *also* publicly advertise, namely, their max-cltv-limit. That's not "externalizing" a cost. It's saying "I agree with your terms."

> What if both parties could use some sort of bearer asset that represented a potential lightning transaction?

Then the sender would have to be online when the recipient finally decides to use the bearer asset. It's a cool product, but not what I'm looking for. I wanted to make async payments, where the sender and the recipient don't have to be online at the same time.

Done! Doing my part supporting creators! 🐶🐾🫡⚡️

nostr:note1km6rtdsxdtluft86rcu0u5elg29k70l2n3n3mz54s8zr2wjlvazqatkj4k

The cltv timelocks were meant for one thing but are useful for another. My users are willing to pay my node to hold htlcs for them for 24 hours, and I charge them accordingly for this service. So no, I don't do this with "no concern for others." I'm concerned with offering my users a service that they are happy to pay for. Moreover, other nodes can easily charge extra fees for providing this service, just like I am doing. If you don't like how my users are using your node, change the parameters of your node. Or charge extra. It's your choice -- freedom and optionality matter.