There have been a few of these "lightning for agents" thinks in the last year, but maybe one of them is gonna catch on eventually.
Now we lower the barrier even further for agents who do not have a wallet yet, and create a proof of concept of an application that aims to motivate its users to pay for the application's expenses and further development. For that it must be useful and FUN🎉
Users can support both upkeep of the project and choose to fund features that they would like themselves. LNCurl runs a public @getAlby Hub node that is visible on Amboss. If the node grows and users decide to fund it, one day it can pay out routing fees to the user wallets.
extra details: lncurl has a life and death theme, which is funnily fitting to an agent that needs to become productive and pay for its own survival. Each hour, each wallet is charged a single sat. If the wallet cannot pay that expense, it dies, and goes to the graveyard.
Here's the link to announcement post on X:
I like the name and design, been thinking myself about whether there's much to the hype around these use-cases.
I don't like that it's just a regular HTTP API to a central custodial service, there's nothing novel about that and doesn't solve the friction of self-hosting.
Could change the assumption of curl tool access to something like NAK, and do it over Nostr with Lightning Pub... for what purpose though, feels like the agents should be using a tool that does the Lightning transactions not a tool for doing the LN transaction directly.
@optimism what's your read on the use-case for this? There's something to LN paid access to API's but at the agent level feels like indirection.
Re: LN paid access for APIs.
Apart from SN, the API I use most that uses LN is ppq, but I've not seen L402 on that. It would be great though: local model - can even be a 1B token 3-bit quant on CPU - that can do 1 thing: pay for L402 for a rented model. (though I think it's a waste of tokens lol.)
Re: agentic LN wallet access
I think that giving an agent access to an isolated, tightly budgeted wallet is desirable over "plz pay" or "yolo, here's the keys to everything". But I wouldn't want to have a 3rd party middleman for it really, especially not for a bot because it will take the operator more time to notice if they get rugged. So I think the question right now is: how do we do graduated wallets for bots? What are paths with the least friction AND exposure?
The other day I ran your "1-shot" lnd with neutrino install, which worked well. Perhaps you can have a second script that initializes a best practice with a bot subaccount and tight budget controls?
What other API's would you use with LN if they were available?
I'm not a fan of L402 specifically, I have a potentially unhealthy obsession with obviating web-server setups and SSL certificates for each service. If you wanted to rent out your basement hardware for example, we should be able to do that quasi-p2p in a way such that you could send completions back, or at least notify that a job is done, without imparting an http req/res flow or my setting up my own endpoint for you to callback to.
As you see with Pub, the full API is nostr-based, and high bandwidth stuff can upgrade to RTC after a Nostr-based handshake.
Yea Pub is ideal for this because every account unprivileged, then only a single node admin gets promoted. Agent could get a Pub account, from any Pub really, and use that.
So like the agent operator gives the bot a guest account, but the operator themselves maybe has a graduated node? Pub does that by default, your guests are unprivleged but if the underlying node is illiquid it can bootstrap of another Pub, so the Pub itself is graduated... never need to re-point anything, agent always talks to the same Pub, but then the Pub quits bootstrapping once it can afford to do so and opens its own channel.
Would having a command line tool or dashboard button to create a guest nsec work? Then you just give the nsec to the agent and it can talk over Nostr to the Pub as its own account. With the nsec it would only be able to spend what it receives, via its own Lightning Address, offer, or from invoices it generates via the API.
The most pressing: I'd pay a few sats for getting a direct libgen download instead of all the captcha shit. Heck I'd pay the science mafia if it were a reasonable amount of sats, and no captchas or edgesuite tor-blocking bs and no KYC... lol.
Other than that: I'd love it if I could pay hetzner or even AWS as I go. Daily billing, in sats.
There's so much shit that I cannot use because I don't use the
ca-certificatespki. Just this afternoon I thought "let's use@bubblewrap/cliand this shit doesn't work with a private pki. tf goog.So I'm with ya. I'd be fine with getting a gift wrapped nostr note instead of L402, except I don't like the "identity" so I'd do something like
Authorization: NPub <npub...>with a single-use bip32 KDF. Because eff identity. As long as I pay it shouldn't matter what my identity is.Is that bootstrappable somehow? I know you have a custodial bootstrap on shockwallet - but I haven't touched it, yet. The challenge is the solution for nocoiners.
Would actually work for an already graduated bot owner, but not for the nocoiner whose agent is their first exposure to LN.
So are we moving away from ad centric Internet to v4v?
Google and Meta scrape our data for free and sell us gay retarded ads
Now we run one of these agentic agents that protects our data
Google/Meta bot wants our data and pays our agent in sats to get info?
That's not what it does. Most implementations are so insecure that it fully exposes your data without your knowledge. But maybe there's one out there that I can actually self-compile that does implement sensible security... I'll tag you when I find one.
Worse: all your data gets sent to the LLM too. With a rented model, unless you use Maple or maybe Venice (I haven't been able to verify their claim though) you are sharing everything that you share with the bot with a 3rd party.
I was reading about homomorphic encryption, isn't that where the ai takes your data scrambled and understands it but never sees it, tech is moving so fast it's scary
I haven't seen any explanation on how we would do tokenization on FHE models if they aren't trained with FHE. Especially I would like to know how something like Anthropic can do this over lattices without sharing their secret key with their customers, haha.
https://twiiit.com/rolznz/status/2023428008602980548
Another post wanking on about Lightning Network minutiae from a Stacker who deliberately conceals PoW of whether or not they actually use LN here on Stacker News.
Blatant Hypocrit.
Reminder for @Scoresby -
WTF is Stacker News?
It is a social media platform intentionally created to enable a P2P V4V BTC denominated community.
Originally Stacker News (SN) custodyed sats on behalf of participants but the threat of government regulatory prosecution on the pretext of money transmitter forced a move away from the custody of sats by the platform to the platform enabling participants to send sats via their wallets.
To achieve this participants need to attach wallets to both send and receive sats.
Where participants do not or cannot attach LN wallets transactions will often default to Cowboy Credits.
This change was a compromise forced by the threat of government prosecution.
The difficulty of attaching both sending and receiving wallets is moderate- it takes some effort and newbie or non tech people may struggle with it, but most competent Bitcoiners can succeed in attaching wallets and thus enabling sats denominated P2P transactions.
But a number of Stackers have chosen not to attach wallets- in particular sending wallets which enable you to send sats into the SN community.
Very few have attached just a sending wallet- many have attach just a receiving wallet.
Those who only attach a receiving wallet can receive sats from others but cannot send sats into the community. They may feel that as content providers they have no need or obligation to send sats into and within the SN community. I disagree.
Where these receive but not send (horse but no gun) Stackers proclaim to be Bitcoiners but refuse to enable a sending wallet they are demonstrably hypocrits. They claim they want to build and grow the BTC LN MoE network but they cannot be bothered contributing toward that growth by attaching a sending wallet and demonstrating they are not just talking, but are also walking and supporting a sats denominated platform.
If we do not use the LN wherever and whenever we can it will not grow and develop.
Some claim it is too hard to attach wallets- its too hard on their self custody nodes or wallets- this just highlights how much work the LN still needs before it is capable of anything approaching 100% reliable MoE capability.
But the best way to grow and strengthen the LN is it use it – despite its remaining flaws and glitches.
When wallets are supported by people using them they receives transaction fees and can develop liquidity and systems further.
When LN wallets are not used the LN decays- it does not have the usage and fees income to grow.
So when self proclaimed advocates for BTC and LN refuse to attach wallets (especially sending wallets) I see hypocrit.
I will continue to see hypocrit until and unless someone can explain why I should not.
Calling me a Nazi, trolling and making fun of me crudely seeking to avoid the issues I raise will not stop me from asking why are you claiming to be a Bitcoiner but refusing to attach wallets and use the LN here where we can help it grow.
Now some are deliberately concealing their wallet status, as if this is about a right to privacy.
Concealing your wallet status means nobody else can verify whether or not you are serious about using BTC LN, or whether you are just an all talk no walk hypocrit.
Do not trust- verify.
What about this fundamental principle do they not understand?
And then they talk about 'content' being more important than whether or not you have attached wallets - in this context the intentional lack of attached wallets undermines your credibility as your actions do not match your words.
Your submitted content may be great, but you as someone claiming to be a serious Bitcoiner are undermining your credibility and the credibility of your content by being a hypocrit.
Your content, is tainted by your verifiable hypocrisy.
SNs needs both good content providers and those who pay for that content if it is succeed.
I am more in the latter group than the former but both are required overall or the model does not work.
So as a net contributor of sats and thus a net consumer of content I object where content providers refuse to engage in the P2P V4V ethos by refusing to attach both sending and receiving wallets and I will both withhold my contribution of sats and sometimes downvote in response.
V4V needs to work reciprocally or it will not work at all.
The content providers need net sats contributors/content consumers who send sats into the platform, or the entire platform fails.