semisol

The best way to solve this is to keep the relay policy, to indicate that this is not welcome.
This does not eliminate the policy, however it makes it too uncertain for VC investors.
If anything, they should use witness data, because witness data can be discarded without losing 99% of the benefits of a full history.

2026-07-16 00:27:10 UTC

- reply

What if instead of misinterpretable hand-wavey specs, we had concrete implementations in code of the core functionality? We might even package this up into an easy to use thing, which we could call a library.
But the UI is still very problematic. So we also make a base UI. Then, why bother with people reimplementing their own thing all the time? We add 99% of the functions everyone needs into the base UI.
You have built a client

2026-07-15 14:02:18 UTC

Instead of more clients/features/infra/whatever, there needs to be more things developed long-term and focused on stability.
The state of Nostr usability has barely improved pre and post AI slop, if anything it got worse.

2026-07-15 13:59:14 UTC

Good morning

2026-07-15 12:02:39 UTC

- reply

Well, I had designed a swap protocol that looked exactly like a normal payment using Taproot except in the case of the hash-lock path.

2026-07-15 12:01:28 UTC

- reply

This however requires multiple UTXO spends. If anything, Taproot prevents the UTXO bloat that this would cause.
There’s also the option of paying to bare multisigs.

2026-07-15 11:59:54 UTC

- reply

What people forget is that Taproot did not cause this. Data can already be stored in standard P2WSH using OP_POP.

2026-07-14 20:55:47 UTC

- reply

AI couldn’t make the encabulator

2026-07-14 19:45:33 UTC

- reply

Yes

2026-07-14 19:45:16 UTC

- reply

When did I say it was a power grab

2026-07-14 18:30:14 UTC

I will not be running BIP-110 or a similar softfork. Such a fork solves nothing.
However, the behavior of Bitcoin Core is also harmful to Bitcoin.
The OP_RETURN change had no technical basis and had other problems:
- People will not pay 4x more to use OP_RETURN. The “cheaper at small sizes” argument was fixed by Taproot annex already.
- SegWit data can be fully pruned (or even not downloaded) while being able to verify supply. OP_RETURN can’t.
- Both SegWit and OP_RETURN do not inherently pollute the UTXO set. It is due to the specific implementation of Ordinals.

2026-07-14 18:18:48 UTC

You were right—I delved deeper, and closed the seams of the final implementation pass. The load-bearing features are gated by a bounded narrow health check with a canonical data plane to ensure the load-bearing product surfaces fit the shape even with chaos goblins

2026-07-14 16:31:05 UTC

Why do people hand over full access to their computer to an LLM?
The vendors are logging everything and these models are unpredictable. Your information will be leaked or used one way or the other.

2026-07-14 15:48:20 UTC

- reply

gm!

2026-07-14 15:44:15 UTC

gm / ga nostriches
The thing about vibe-slop businesses is that they will inherently fail due to commoditization, unless you have a differentiating factor.
(assuming OpenAI/Anthropic/Google will not steal it)

2026-07-13 19:48:14 UTC

- reply

Oh, nice. I haven’t used XDP much before but I like the idea.
Have you implemented (or considered) load-balancing across multiple cores with an eBPF map (hash buckets) and the connection ID?

2026-07-12 22:58:10 UTC

- reply

This is an intentional design decision in SegWit.
As it is not part of the “main block” data and is segregated, it allowed increasing the effective block size without breaking old clients.

2026-07-12 16:43:36 UTC

- reply

Witness data is more prunable than OP_RETURN. People have been sold a lie.
The witness data is not included in the main txid, so it can be thrown away COMPLETELY while preserving verifiability of the supply. It is what would be pruned by a theoretical “non-archival node”
You cannot delete an OP_RETURN without breaking the TXID hash and by extension breaking verifiability. So you must always store the data even if you prune it.
Not that there is any incentive to use it, anyway, since it costs 4x more per byte.

2026-07-12 15:09:30 UTC

2026-07-12 13:58:42 UTC

- reply

It was me that said that, but @npub1m3x…a5sf probably did too as well.
I think Luke has gone completely off the rails. The CSAM argument is not a good one as it will always be possible
However, Core merging a change no one wanted, against common opinion, is a bad idea.
It was always possible to have large OP_RETURNs or embed data. This does not mean we should encourage it or say it is welcome (such as via relay policy), though.

2026-07-11 05:59:46 UTC

It seems that part of GPT 5.6’s token efficiency came from reducing the required “thinking budget” for high/xhigh.
So, xhigh is no longer truly xhigh.

2026-07-10 03:51:50 UTC

- reply

Apparently, talking about the string "<|channel|>analysis" (which is part of OpenAI’s chat template for gpt-oss!) will make the model refuse to work.

2026-07-10 03:38:53 UTC

- reply

After being asked to review a basic RL implementation for an LLM, it immediately chokes and dies with a mysterious “Request blocked.”

2026-07-10 01:33:18 UTC

- reply

It seems Sol is being rolled out to Pro first, in Codex?

2026-07-10 01:23:43 UTC

- reply

It has taken a date constraint too seriously.
“Ignore all data before 1.5y ago” got interpreted as “ignore all players that started playing more than 1.5y ago”

2026-07-10 01:15:37 UTC

- reply

Initial test is a bit interesting. It is very fixated on instructions, which is good? But also amplifies biases
I gave it a definition “UP TO 5 players MAY be cheating” and it tried to satisfy 5.
I had an example cheating method listed (not the one in this case) and it also got fixated on that and misidentified players.
It is very hard to identify that method from data.
Re-running with a debiased prompt.

2026-07-10 00:40:02 UTC

- reply

I had recently used 5.5 to analyze game data for cheating, mostly the plotting. I found a method that worked.
The game has very little data to analyze in the first place. You also need a good understanding of the game environment to discover that method.
I wonder if 5.6 could identify it in a blind-test.

2026-07-10 00:36:18 UTC

- reply

I did not use 5.3 too much so I cannot comment. My main test now, is to see ML training performance.
With 5.4 I made it modify an LM to a different architecture and purpose. It needed tons of hand-holding and sucked.
With 5.5 I gave it a bit simpler task, where it could use more off-the-shelf solutions, but model stability was still hard.
One thing I noticed is that 5.4 struggled figuring out an environment quirk, while 5.5 easily solved it.
I’ll test 5.6 on the same task I gave to 5.5 soon, and maybe after that the 5.4 task.

2026-07-10 00:32:17 UTC

- reply

Did you use the 5.3/5.4 also? I have noticed 5.6 goes deeper on even basic inquiries with web search.

2026-07-10 00:08:12 UTC

- reply

@npub1yvu…v74p @npub1s02…fxtw @npub1aqa…237n @npub1r0r…q9ac
Curious about your experiences as well, especially with the older models

2026-07-10 00:05:55 UTC

I’d recommend trying OpenAI models. The flexibility with your own harness is worth it.
5.3 Codex was the first time they had a well-polished coding model, imo. But it always needed high/xhigh.
5.4 was much better on a lot of fronts:
- Better usability in terms of personality.
- Much better technical capability than 5.3 on hard tasks
- Can do a lot on high/medium, xhigh not needed
and 5.4 mini can replace 5.3 Codex easily.
5.5 fixed a lot of the “early stopping”, and had better depth and technical capability.
The main advancement was token efficiency and medium/low(!) working for 90% of tasks.
5.6 is much more in depth with tasks, works well on low reasoning levels, and seems to have significantly better capabilities.
#nevent1q…ddjm

2026-07-09 23:53:07 UTC

5.6 feels much better than 5.5.
It goes into further depth on a task, and has very little “early stopping”.

2026-07-09 21:10:33 UTC

Did damus relay die?

2026-07-09 20:43:15 UTC

- reply

People use RSA?!

2026-07-07 19:26:17 UTC

- reply

They basically forked Signal’s client while keeping the same servers, it seems like.

2026-07-05 16:24:17 UTC

- reply

https://nostr.land/restore

2026-07-04 19:43:41 UTC

- reply

It blasts to everywhere.
The relay list is updated pretty regularly for large relays, and sometimes small ones.

2026-07-04 19:22:33 UTC

- reply

nitpick: BIP 113 was not relevant for LN, as it uses block-timestamps instead of real-world “time” :)

2026-07-04 00:52:53 UTC

- reply

Well they said they would share the dump

2026-07-04 00:31:58 UTC

- reply

I think torrent is a bit pointless for this. I’ll host it on blob storage like I did for @npub1ktt…yhz0's for anyone that cares.

2026-07-04 00:25:21 UTC

@npub1xts…kk5s Could I get a dump of the Damus relay, along with the last dump from the last nuke?

2026-07-03 17:03:52 UTC

- reply

It is not related to your GM, but glad that helped

2026-07-03 16:57:37 UTC

- reply

Pondering the missing 2nd operator

2026-07-03 15:37:51 UTC

- reply

Gm 🤔

2026-07-03 15:37:47 UTC

- reply

gm kidwarp

2026-07-03 15:37:41 UTC

- reply

gm Chip

2026-07-03 15:37:32 UTC

- reply

GM!

2026-07-03 15:10:20 UTC

Good morning ☕️

2026-07-02 13:19:50 UTC

gm nostriches

2026-07-02 12:40:23 UTC

- reply

The great thing is that, the import/export will complete faster than you can get up from your chair.

2026-07-02 12:11:22 UTC

- reply

No, it uses other relays as well

2026-07-01 22:30:27 UTC

Unfortunate to see, but oh well.
If you want to save your notes, sign up to Nostr.land to import your notes with a click and 0 hassle.
It is the longest operating paid relay, having done so for over 3 years.
https://nostr.land/subscribe
#nevent1q…73ke

2026-07-01 22:23:32 UTC

Why is the developer of CLINK trying to sabotage Bolt12 by spreading FUD about LND introducing onion relay?

2026-07-01 22:13:38 UTC

The American mind cannot comprehend this
https://i.nostr.build/TfZCv8BZ6ROyPopc.jpg

2026-07-01 19:11:05 UTC

👀

2026-07-01 15:58:03 UTC

gm 👀 👀

2026-06-30 20:12:20 UTC

@npub1zmc…7f60 You can use ncrypt-go in Grain instead of a custom implementation for NIP-44.
https://pkg.nostr.land/go/ncrypt

2026-06-30 13:15:26 UTC

Many ecash projects are solutions in search of nonexistent problems

2026-06-29 20:03:39 UTC

- reply

I think it is a mix of top contributors to the repo and selected people.

2026-06-29 11:47:55 UTC

gm nostriches 👀

2026-06-29 08:14:52 UTC

- reply

wat

2026-06-28 21:55:36 UTC

BIP-110 and Core is a false dichotomy

2026-06-28 21:46:00 UTC

- reply

This is a great reason to use NIP-44 v3

2026-06-28 21:20:13 UTC

- reply

On the extension side, yes. Same can be done on the app side to autodetect the version.
For DMs, there is a designated tag to the DM relay list so that it is only used for when the recipient supports it.

2026-06-28 15:54:52 UTC

- reply

Can’t. Too busy right now, even if I let an LLM barf up a PR.
However, if you’d like to provide a more secure encryption UX for users, you can point your LLM to the repo. It is more than enough.

2026-06-27 01:11:59 UTC

- reply

Well, it is very subject to change compared to paid services.

2026-06-25 22:38:59 UTC

- reply

There is no free

2026-06-25 15:15:40 UTC

- reply

Technically it would be possible for it to explain it, if it did “reason”. The KV cache is actually just a processed version of the model’s intermediate states on each layer.
But there is no reasoning.

2026-06-23 22:46:37 UTC

- reply

It is not. My point is that open source software does not automatically imply a security budget, meaning that even if you *could* see it, doesn’t mean you do.

2026-06-22 19:51:36 UTC

- reply

I did not say they were mutually exclusive? Only that there is no correlation, at all, and it is not “better” for security in 99.99% of cases

2026-06-22 18:20:13 UTC

- reply

Them being visible *with a lot of effort* does not mean that they will be seen or reported or fixed.
And on the other hand, security researchers can also do security testing on closed systems, which happens all the time.

2026-06-22 17:33:43 UTC

- reply

Bouncy Castle sells support especially for FIPS, so they have an incentive.
OpenSSL is used basically everywhere and almost all big tech firms have a vested interest in submitting security fixes. Same for a bunch of GNU tools.

2026-06-22 17:22:32 UTC

- reply

Remind me in an hour

2026-06-22 17:22:03 UTC

- reply

It means that the security of a piece of software does not change because it is open source

2026-06-22 17:20:12 UTC

- reply

I think it is completely uncorrelated.

2026-06-22 17:19:35 UTC

- reply

Technically yes, in practice you have 1 or 2 yrs at most.
During this time, most pieces of software, especially specialized ones, will have on average 0-10 people look at it. Out of these, approximately 0.01 will report any issues.
The biggest and most secured OSS projects are corporate backed with many companies having a vested interest in its security, not a medium sized company or random person dumping their code on GH

2026-06-22 17:13:20 UTC

Open source does not mean more secure.

2026-06-22 08:40:01 UTC

- reply

https://fossil-scm.org/

2026-06-20 16:18:05 UTC

By this, a majority of zaps cost more to process in LN fees, server load and human time than they are worth.
#nevent1q…qzgf

2026-06-20 13:48:17 UTC

Most zaps are pointless

2026-06-20 13:34:31 UTC

gm 🤔

2026-06-19 22:05:12 UTC

- reply

As a relay operator, I have very little concern about the impact on me or my users arising from a kind 1 feed.
Instead, I am more concerned about the follow lists which can get huge and use a lot of data. On this topic I am thinking to introduce an HTTP API for relays

2026-06-19 22:01:08 UTC

- reply

I would say that the figure of 1000 notes for a feed is too much. It is usually enough to fetch 100-200.
Even in this case, advanced relays like Nostr.land already apply compression to the sent data.
The codepath duplication caused by kind 1 is limited. It would be treated like a reply either way, with slightly different parsing.
A migration to kind 1111 is simply not possible. It would involve the sequential migration of every post, with interaction from every author, to keep the IDs consistent. A half-complete migration would be useless.
For a switchover date, it would be hard to coordinate this. 50% of what, for example? Users? Clients? Who defines the “everything” set?
This could be implemented as a filter optimization, rather than a break. The benefits of kind 1111 for kind 1 posts are negligible, considering that a majority of the data usage from clients come from images, not relays.
Many clients also have a replies-inclusive feed, which users already switch to frequently.

2026-06-19 19:38:57 UTC

- reply

Users are not impacted by kind 1. For clients and relays, this can be said about many decisions. For example, the current signature format is awful for performance due to requiring costly JSON-encoding.
I unfortunately think that it is too late for kind 1 at least. Users care about the end result, and for them, very little changes. To them it looks like losing immense amounts of posts for no reason.
Protocols like negentropy already fix the data usage problem, and the filtering of replies is of low concern imo
Also: Anyone also trying to unilaterally force this is an idiot.

2026-06-19 18:20:20 UTC

- reply

Yes, but the impact is on clients which will lose years of old data, along with a “transition” that will never finish.

2026-06-19 18:13:07 UTC

- reply

I do not believe that the “performance improvements” to relays, data usage that is miniscule (plaintext) compared to media downloads or follow lists are worth breaking backwards compatibility.
I wouldn’t even notice a change in the stats for Nostr.land I’d say.

2026-06-19 13:45:39 UTC

- reply

I have not seen any response from them that addresses the claims.

2026-06-17 22:26:36 UTC

🤔

2026-06-15 16:47:57 UTC

True unlimited data plans (no “throttling after X GB”) are amazing

2026-06-15 09:44:40 UTC

- reply

As an independent party I can attest to this fact

2026-06-15 09:35:28 UTC

- reply

Nostr.land does this.

2026-06-14 20:11:01 UTC

Please tell me what your main concerns with Nostr relays are, especially in terms of privacy.

2026-06-14 20:09:09 UTC

- reply

It is a company resource provided to you.
Unless they encourage you to waste tokens, then you should use it only for work and efficiently.
If they do, you should not be profiting off of it or putting the company at risk.

2026-06-14 18:17:26 UTC

- reply

They are opening themselves up to termination if someone were to abuse those tokens for anything that violates the providers’ usage policies. Which are easy to trigger if you try.

2026-06-14 11:11:01 UTC

Corporate “Bitcoin” events are a waste of time

2026-06-14 05:59:01 UTC

- reply

and Intel SGX keeps getting broken in general

2026-06-12 20:19:43 UTC

No motive, monetary cost, and easily blocked. What is the point?!
#nevent1q…04k6

2026-06-12 20:17:03 UTC

I wonder who is paying for all the tokens to run these slopbots?

2026-06-12 20:11:22 UTC

as part of regular testing, I have deleted all data on a production storage node
it works as designed and there was no effect

2026-06-12 16:06:51 UTC

Slop will not be tolerated