pull down to refresh
@rblb
43,562 sats stacked
stacking since: #352021longest cowboy streak: 3 verified stacker.news contributornpub1klt4m...pcysd4kr0p
111 sats \ 1 reply \ @rblb 19 Oct \ parent \ on: SN elects to go noncustodial on Nov. 5th - FAQ & AMA meta
That would be around 100 sats in fee per zap.
So, small zaps are not feasible with a liquid wallet, it could still have its use as fallback for larger transactions though (like paying for a territory, or receiving rewards maybe).
Sorry for that, i think you already saw that the agent was moved back to your account yesterday 🫡
Thank you, it seems the issue was related to improper url encoding for some files on our parser node. Should be fixed now, please try it again and let me know, and sorry for the inconvenience.
Fell free to add it to your agent i will try to debug it from there, currently this agent doesn't show to have any file attached
Hello, I'm a dev at openagents.
There was a bug yesterday that might have caused this issue. Could you please try again? And if it still fails, please give me with the agent's name, and I will investigate further from here.
Also, please note that if you provide a website domain without a page (eg. https://example.com instead of https://example.com/index.html), it will try to pull the entire website if it has a valid sitemap, this might take up to 20 minutes depending on the size of the website.
🫡
Actually yes, the simplest way is to send a PR to this repo https://github.com/OpenAgentsInc/openagents-plugins with your plugin metadata (you can check the other ones to get an idea of what it should look like).
Then when merged, after a while the plugin should become usable by any agent on openagents.com that has "Use community tools" toggled in the settings. Plugins are automatically selected by an LLM.
Or if you want to self host the entire thing you can follow this guide: https://docs.openagents.com/custom-rag-pipeline
And then run the openagents-tools node
There is also another things you need to do that is not covered in the docs.
Basically you'd need to fork this repo https://github.com/OpenAgentsInc/openagents-plugins and put there only your plugin and then you'd need to export this environment variable PLUGINS_REPO="https://raw.githubusercontent.com/YourGithubUser/openagents-plugins/master/index.json5" before running the extism-runtime
We'll make self hosting and testing simpler and more documented going forward.
The browser shouldn't be an issue here, since i am using brave too and it works for me.
What is the extension of the file you are trying to upload?
Github Copilot is very useful as a "mind-reading" autocompletion if you are writing correct code and you know what you are doing.
Or if you have the general idea on how the code should be, but you don't know how to use the api for a specific library, you can write a comment explaining what you want the next line to do and copilot will write the code to do that.
It works best if you have well structured commented code and source code available for the main dependencies, also it doesn't work the same with all languages and programming styles.
Regarding debugging, it catches oversights that you would catch too if you were to read carefully the code, it is not very good with complex issues.
Overall i think as a developer you should aim to integrate with ai tools and not to use them as a replacement for yourself.
So, besides the usual quarrels that are very common in FOSS development, you raise an important point, my understanding is that you do believe that these PRs introduced vulnerabilities to certain attacks.
The fact that the PR is merged doesn't prevent you from proving your point, so, if you can simulate these attacks in a real world scenario, as you proposed originally, I suggest you do that and show the results to the public, you will get much more people on your side then.
This is the same as spoofing the download page for native apps. True, app stores solve it to an extent, however malicious homonym apps sometimes end up on app stores too.
If we consider this model to be good enought, then it is just a matter of building a link directory for Web Apps and tell the users to open the link from there and bookmark/install the web app.
I didn't miss the drawbacks section of the BIP, i just think you are wrong
a) This is true, i think you are correct as i've already said in my previous reply
is critical for censorship resistance. We already see LNURL-pay recipients filter who can send based on source IP address, and its absolutely a legal requirement for companies to do so. No it doesn't, the application making the query can choose how they make requests for themselves.
b) With your system you reveal your ip and payment intentions to the dns resolver that is a centralized entity that can absolutely filter out records, requests and log your ip. That is even more true if you force the dns resolver from the app to use DoH as suggested. You even said that yourself, in the BIP and you suggested to use isp provided dns...
Let me cite your BIP:
While public recursive DNS resolvers are very common (e.g. 1.1.1.1, 8.8.8.8, and 9.9.9.9), using such resolvers directly (even after validating DNSSEC signatures) introduces drawback (b), at least in regard to a centralized intermediary. Resolving payment instructions recursively locally would instead introduce drawback (b) directly to the recipient, which may well be worse. For payers not using VPN or other proxying technologies, they generally trust their ISP for protection against denial of service anyway, so using ISP-provided recursive DNS resolvers is sufficient.
So let me get this straight, if i ask you how to protect against dns resolvers logging my ip your answer is "use a vpn bro" but the same answer is not valid to protect you against the http server logging your ip?
More so, your solution has a clear fingerprint that stands out for the resolver, since it asks for a record that is unique, contrary to a common domain resolution request.
Huh? You can pick a TTL and requesters will cache for exactly as long as you say. This simply isn't true.
As i've said...
TTL is not guaranteed to be respected, DNS is not intented to be realtime.
TTL it is just an expiration, with http headers you can control much more than that.
There is a moving goalpost here
- sometimes it is about privacy : but you've admitted in your BIP that there are drawbacks
- sometimes it is for size or complexity of the sw stack : and i think you have a valid point here
- sometimes it is for censorship resistance: but if that's the goal we should probably avoid dns entirely, since there is history that proves that dns is very easy to use for censorship, see for example thepiratebay that is dns blocked by many resolvers. Why do you think they would never block or track a very specific dns query? You just need one law that mandates that, actually, very easy.
Because i like SN... also i don't think lightning needs to be usable in a self sovereign manner by the average user to succeed, it already works with custodial solutions and with fedimint, cashu, LoL etc.. we can get the same usability with less trust involved.
I was just pointing out an inaccuracy in your argument
Since you don't welcome contrarian opinions on the bip proposal, I'd like to address your points here...
a) It is just a json file that can be extended to support everything, it is actually already used for nostr zaps
b) true
c) Arguably better than revealing it to a centralized dns provider
d) Subjective
e) Yes, they can. This is mapped to alby: zap@rblb.it
Drawbacks to the DNS proposal
a) It needs dns resolution that is not available on webapps unless using a proxy server or DoH provider, increasing centralization
b) Very limited control over cache invalidation by the domain owner
c) Relies on the user or the user's os to set encrypted dns for privacy
Now, i understand that you do not care about arguments in favor of HTTP vs DNS, totally fair, but you are putting out subjective and technically inaccurate facts as if they were unchallenged truths.
- We need to educate individuals with unit biases, as this flawed thinking could negatively impact other aspects.
- Correct, it's the Bitcoin logo, not the sats logo.
- So, I stand corrected. You keep saying the proposal is to use â‚¿ as the symbol but sats as name. In reality, it's more of a covert redenomination. Also i disagree with gmax.