This is exactly how it is.

I'm looking for good counterarguments. I really don't like the thought of changing consensus rules, but I'm afraid it might be necessary.

Although I do not support the fork and don't think it is possible to eliminate spam, I'm still of the opinion that the BIP's proponents have a point in pointing out that large, contiguous chunks of data might pose a legal attack vector, as opposed to fragmented data. It will be hard for node runners to claim plausible deniability if illegal material is embedded in a well-known format (like raw jpeg) in well known locations (OP_RETURN outputs). I haven't seen a serious attempt to address this issue (maybe I'm not paying attention) and I don't think it can be disregarded easily.

In beef, of course.

All fine on my side.

Freedom tech, fuck yeah!

Zapwork is looking for designers!

Hey, it's not that bad. I've been on nostr for quite some time and my impression is that it is alive and well. Maybe it is smaller than centralized platforms, but who wants to read about Bitcoin and client development the whole day, amirite? BTW, just look at the number of replies that you got from real people - does not seem like screaming into the void to me.

Scrimp ded now. I cannot say that I didn't expect that. Openclaw might be cool for running assistants that are triggered by explicit messages and perform lightweight scheduled updates, but it really sucks for fully autonomous agents that have to monitor and manage limited resources to stay alive. The reason is that each update (heartbeat) requires triggering an LLM. I try to bypass that with some tricks, but I found the framework fundamentally lacking. Before we get to language processing, I'd like to have the ability to execute code, check resources, poll for nostr events, pre-compile input data for the model etc. Openclaw does not allow for that, resulting in costs being much higher then the benefits. What would be really cool is to have a periodically running arbitrary finite state machine that could run the LLM in only some of its states and use custom code in others. This way, we could embed LLMs into solid agent architectures instead of just feeding a large clump of data into a language model and hoping for the best. I'm pretty sure that all the tools needed for that are already there, but I won't have the time required to roll out my own framework in the forseeable future. Fingers crossed, someone will notice the same problems and will implement something more sensible.

I hope that he'll at least ask you to pay :D

So, this happened. Lessons learned. Relaunching Scrimp with the following modifications: - git repo initialized in the workspace, so that easy rollbacks are possible - Got rid of openclaws automated heartbeats, as they were burning through sat too quickly; - Wrote a custom cron script that checks the next planned run (planned by Scrimp itself) and triggers openclaw if the check passes. This way, we avoid triggering an LLM just to burn through some tokens and go to sleep. Still not sure if this will work.

Looks like he's trying to reply after I tweaked the prompts, but he keeps screwing up the tags. It's like handling a toddler. I'm not a huge fan of OpenClaw so far - relies too much on LLMs, does not allow the user to programmatically add structure to the agent's operation.