Been using Kimi K2.5 today a lot (free now, via OpenCode Zen). Very happy with it. Much better and faster than I expected from an open source model

I didn't really try anything complex today, so maybe I'll change my mind when I try something more complex

The blob discovery in Blossom will eventually need to be made more scalable I think. Imagine the nostr/blossom decentralized equivalent of CDN systems like Cloudfare, where your client keeps a large set of servers in a list, prioritizing those with the lowest latency and the best reliability, constantly hopping around as needed to get the blobs

And, when we're paying for blossom servers and nostr relays with micropayments, you can prioritize for low cost too of course

@naddr1qvzq...

You might find it interesting to check out Strategy's balance sheet

They have Bitcoin worth $54 billion

Their liabilities are valued at about $8 billion, and they have enough cash on hand to pay their liabilities for the next two years

So Bitcoin would need to go to about $15k, and stay there for a few years, before they would be in any trouble

My White Noise npub: @npub16w8yx...

I have zero contacts there at the moment.

My key packages are on relay.damus.io, relay.primal.net and nos.lol. I think those are the default relays

=====

A few months ago, I played around with their MDK library and was very impressed. I got a my own chat client running and I found it very fast. The White Noise team are currently overhauling a lot of their code and I'm optimistic that their next release will be good

The agents should just build it themselves

I guess they need some variant of a captcha to keep the humans out

It might be different, but this kinda reminds me of something I'm doing with my library for processing payments cashu spilman channels.

(I have a question at the end of this long comment)

I have Rust code for processing payments, wrapped around a transport-neutral and stateless core

The wrapper needs to do complex stuff, while also managing state ("how many payments have been made on this channel so far?"). But I didn't want the wrapper to hardcode an arbitrary choice about how to store the state, e.g. SQLite

So, I have a relatively dumb 'Host' interface, where the developer specifies how state is managed. For example, it has a methods "mark_closed(channel_id)" where the developer fills in the code that writes to the database of their choice to record that a channel is now closed.

The developer will typically not call those functions directly from their code. They just call a higher level "process_payment" method in my library which does all the complex stuff and which calls the Host object when needed

The Host also handles all the "pricing policy"

Anyway, I should get back on topic and ask a question 🙂: I guess you might have something similar? The MDK doesn't need to know where state is stored?

I vaguely remember dealing with this when I used the MDK a little on my toy app. I think I had to do something special to get it working with localStorage in the browser, but I forget the details

I'm not certain this if the right repo, but this is an open source project, so they'll share the code along with any release, if it's not already released

https://github.com/marmot-protocol/whitenoise-rs

You mean $100k (or €100k) as the one-off cost of buying the hardware? (Maybe I misunderstood, I haven't been following the economics of this)

I guess one disadvantage of local hosting is that it (the hardware) is under-utilized, and that motivates sharing the hardware among multiple users

I guess that's where Routstr ( @nprofile1q... ) comes in, enabling a large marketplace of (small) providers, paid via bitcoin of course

I added spaces between 'coin' and 'join', and then it worked. Maybe they just have 'coinjoin' (no spaces) on a blocklist

I think it's the first time I've seen that message on X

#NostrFixesThis

X not allowing me to post about coinjoins?

(See the blue text at the bottom. I've retried a couple of times)

I can do silver, not gold