semisol

👨‍💻 software developer
📨 nostr.land relay

all opinions are my own.

Public Key

npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj

NIP-05 Address

semisol@nostr.land

Profile Code

nprofile1qqs99d9qw67th0wr5xh05de4s9k0wjvnkxudkgptq8yg83vtulad30gpzamhxue69uhkummnw3ezuum9d45hxmmv9ejx2as7dkvh9

Publishing to

nostr.semisol.dev

Author Public Key

npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj

Show more details

Last Notes

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-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: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 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: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

2026-06-12 11:54:25 UTC

A pay per use model would significantly enshittify paid relays, lead to horrible UX and allow tons of spam:
1. It would lead to unpredictable charges for users. A fixed fee per month/year means the relay just works.
2. The cost acts as a bond for spam and abuse, compared to pay-per-note.
3. It is incompatible with services like aggr.nostr.land and NIP-05 where there is no “usage”.
4. It would allow a monetary DoS for services like inbox relays, where someone can spam you with junk giftwraps.
5. Users should not need to worry about constantly having a topped up wallet and using a supported client.

2026-06-11 16:56:01 UTC

&time>now-60&time<now+60&id=03…&method=pay&pinvbolt11_node=03…

2026-06-11 13:55:23 UTC

- reply

if done right: harder
usually: a little bit

2026-06-11 13:55:00 UTC

- reply

Any automated ways?

2026-06-11 13:49:32 UTC

- reply

Nostr.land is planning to support OTS.
I’m planning to use the standard OTS spec that is already well-implemented. “Inline” proofs is not something I plan to support as a client can easily request OTS proofs when necessary.
Also, I hate AI written “specs” so much as they have so much useless junk (like wtf is the s tag for?) and overcomplicate things.

2026-06-11 06:19:54 UTC

- reply

Well until you merge the dust outputs which then links all of the unlinked addresses back together

2026-06-10 16:06:08 UTC

CLINK or whatever this protocol is, is worse than NWC. What is the point?

2026-06-10 16:04:41 UTC

Code is a liability, to some extent. Each feature and line incurs a maintenance cost.
Less code is better.
#nevent1q…njx9

2026-06-10 15:29:15 UTC

Code has always been cheap. You don’t need an LLM to generate slop.
For me, nothing has changed

2026-06-10 13:36:06 UTC

- reply

This only makes me less confident, unfortunately.
“Your keys are never stored in a usable form” does not make sense, as that would mean that you can’t use them.
A PIN can be easily brute forced if you break the secure element, as it needs to know the PIN to verify it.
Tamper detection switches are not very good protection. Attacks have been done on devices with multiple layers of tamper protection with an entry less than 2mm.
The OS is “fine”, but claiming Xous’ reputation while having majorly changed it for your own usecase is weird. It’s not the same thing anymore.
My other points still stand.
I’m not going to assume malice or intentional deception, but it feels like they do not really have much experience with secure hardware.

2026-06-10 06:36:41 UTC

Anthropic has released a new money-incinerator that predicts probabilities better than the previous money-incinerator and also incinerates your money faster

2026-06-10 06:33:58 UTC

- reply

Yes your client would still have to AUTH that is it. Gift wrap spam/DoS being hard to mitigate is one reason for this, and especially mass-DM scambots.

2026-06-09 22:43:18 UTC

- reply

The UI is being retarded

2026-06-09 22:39:52 UTC

- reply

The bot is not wrong. It says !payment (inverse) not payment

2026-06-09 21:46:59 UTC

- reply

I believe it is fiatjaf’s thing.

2026-06-09 21:45:22 UTC

- reply

Well, auth depending on the pubkey acts as a strong anti-spam signal. It also indicates explicit consent for anything you send to it, instead of someone being able to say “well I didn’t put it on nostr.land”

2026-06-09 21:35:24 UTC

- reply

To some extent. Nostr.land already requires AUTH for a huge amount of features, so it would encourage devs to actually support it properly.
And for some things like gift wrap spam filtering, it would not be possible at all.
What is the use case?

2026-06-09 21:29:07 UTC

I am considering requiring NIP-42 authentication for a majority of event writes.
It would prevent random rebroadcasts where it is not desired and allow for better spam filtering, so why not?

2026-06-09 21:20:47 UTC

- reply

relays.land is a completely unaffiliated service that comes with way less, and it is confusing that they picked that name :/