pull down to refresh
@rblb
45,610 sats stacked
stacking since: #352021longest cowboy streak: 3 verified stacker.news contributornpub1klt4m...pcysd4kr0priccardobl
21 sats \ 1 reply \ @rblb 17 Dec \ on: Nervously announcing... I made a game gaming
Cool!
I like your code: no framework, no library, just a gameloop and a canvas 21/12 🫡.
To add on this, i've tried also cursor (thanks to @k00b), that is nice but I’ve noticed it is somewhat more opinionated about code compared to copilot.
In my experience, copilot feels like it is following you and just completing the code, while cursor feels like it is trying to anticipate what you will want to do several steps ahead. I prefer copilot, but I think it is a matter of personal taste and coding style.
I've been trying Github copilot reviews, that is another beta service, but it doesn't work very well , at least with our code base, but it can catch some oversights, sometimes.
Thank you, I'm glad you liked the result!
@k00b already compensates me generously, so i think a better use for those sats would be to put them on an invite link to onboard newbs.
But if you have more feature requests in mind, feel free to open issues, I am not working directly on the p2p (ex-nov-5) update, so I'll have time to look into them🫡
With good OOP you shouldn't even have to read the actual code 90% of the time, just the abstractions (unless you are bugfixing it).
But an OOP language to be good it needs to be very strict and verbose.
Java imo is (was) the best OOP language, C++ being the worst.
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.