someone

Public Key

npub1nlk894teh248w2heuu0x8z6jjg2hyxkwdc8cxgrjtm9lnamlskcsghjm9c

Profile Code

nprofile1qqsflmrj64um42nh9tu7w8nr3dffy9tjrt8xururype9ajle7alctvgprfmhxue69uhhg6r9vehhyetnwshxummnw3erztnrdaksz8rhwden5te0dehhxarj95crztnev94kj6r0dehx2tnrdaksm3py8j

Publishing to

theforest.nostr1.com

nostr-01.yakihonne.com

nostr-pub.wellorder.net

soloco.nl

relay.ditto.pub

relay.snort.social

Author Public Key

npub1nlk894teh248w2heuu0x8z6jjg2hyxkwdc8cxgrjtm9lnamlskcsghjm9c

Show more details

Last Notes

2026-10-27 03:21:07 UTC

no politician will save you.
they are false hope traders, buying your faith in God in exchange.
God has the power, politicians have nothing.
they just hunt people who hesitate.

2026-10-24 19:48:28 UTC

benchmarked 20 more models
- eastern models are more aligned in 2026
- there is a general down trend (similar to 2025)
https://pickabrain.ai/aha/blog/aha-2026-october-update
https://blossom.ditto.pub/1d76b93a92424d3819f02c3b0389c06f5a42258727ca0340e9a693609f834a54.jpg

2026-10-22 18:07:33 UTC

A miracle of the Quran is measured now
https://github.com/etemiz/tawafuq

2026-10-22 16:25:01 UTC

- reply

noice
this can unlock new generation of apps 🚀

2026-10-22 16:08:01 UTC

- reply

woah you already tried!
you could also bring upvoting for features too (users upvote features that they need/want) within the app.
someone will do the feature eventually.
then it is a self evolving app

2026-10-22 15:55:17 UTC

- reply

bring vibing into the app
let the users vibe modify.
you just merge their modifications if cool.

2026-10-20 16:16:08 UTC

https://blossom.ditto.pub/82af3aa11ae4d1c9d1b6cd15f9059e7257fcf512610f72d6aa977351860ceb57.png

2026-10-18 16:32:36 UTC

is wanting to be nurtured and petted by a better AI a human right?

2026-10-10 16:54:09 UTC

- reply

fiatjaf made a new standard. a client adopted it. another client didn't adopt it (yet).

2026-10-10 15:34:56 UTC

- reply

ditto seems to be using kind=1111 for replies. your client probably expects kind=1

2026-10-08 23:37:29 UTC

just realized they have lower instruction following scores than normal.
this is how freedom tech should work -
the LLM is so freedom oriented it doesnt follow its user. 😂
#nevent1q…35dd

2026-10-08 13:17:03 UTC

my new model and EXL3 quant is out
https://huggingface.co/etemiz/Ostrich-27B-261008-Qwen3.8-Abliterated

2026-10-08 13:07:39 UTC

- reply

which client are you using?

2026-10-08 13:03:59 UTC

- reply

i can add that soon. i may have another round.

2026-10-08 04:21:25 UTC

- reply

bring more AI

2026-10-08 02:22:26 UTC

- reply

i don't know. maybe @nprofile…zkne knows

2026-10-08 00:02:05 UTC

- reply

no. maybe i should also add ditto. what else

2026-10-07 23:34:26 UTC

- reply

this is on the REQ side but yeah.
feels swift also when i am on it.

2026-10-07 23:32:38 UTC

- reply

yes

2026-10-07 23:07:56 UTC

TLDR: Some clients are heavy on relays
Last week I banned my own phone from my own relay (nos.lol).
On the relay there is a per-IP cap, which allows 200 REQ messages every 10 seconds. Then an automated script bans addresses that keep blowing past it.
A flagged address had sent 283 over-cap REQs from a single websocket and reconnected 75 times in an hour. Then I realized it was actually me, checking my relays' global feeds in YakiHonne web and Coracle! Normal reading, two heavy clients, one CGNAT (mobile) address.
Then told my clanker to read the REQ layer of the most popular clients. The cap counts REQ messages, so a client's economy is mostly about how it batches, caches, and re-issues subscriptions.
FINDINGS
https://nostr.download/8c6d5a88c6854eb9b06aec7ac9ea149de0a709741b3fed1987efb84aef63cdbb.png
There is a 100x difference among client's handlings of REQs.
DB-first (scroll ≈ 0 REQs):
Damus renders from nostrdb; one multi-filter REQ per relay per view, hard 14-sub cap (new subs pause, not drop). Amethyst batches 3 filters per REQ, re-sends under the relay's max-filters notice, keeps refusal memory after repeated CLOSED. Gossip: CLOSE on EOSE, disconnects idle relays after 10s, retried rate-limited subs, randomized reconnect backoff. Nostur: client-side 6 REQ/s limiter with CLOSE jumping the queue — unique and underrated.
Mixed:
Iris unions filters across components in 100ms windows, but leaked pagination subs replay on every reconnect. Nostrudel: clean EOSE→CLOSE lifecycle, but an auto-pager pulls history at ~1 REQ/s even while idle, and NIP-11 max_reqs is displayed, not enforced.
Heavy:
Snort's query engine is excellent, but every mounted note fires a reactions REQ (kinds 7/6/9735, #e-tagged, no limit) to every read relay, unsatisfiable from cache. YakiHonne web passes groupable:false to NDK — explicitly disabling its subscription merging — then fires 1 REQ per card-mount per relay, no dedup, re-fired on remount. Coracle (welshman) sends one filter per REQ, and on socket flap replays the full pending REQ set with backoff resetting to zero whenever the relay emits traffic — a rate-limiting, event-streaming relay is the worst case: instant reconnect, full replay, loop.
Common failure across heavy clients: CLOSED is unhandled — dropped (Damus), ignored (YakiHonne, Iris), or terminal with no backoff (Snort, Coracle). A relay saying "rate-limited" changes nothing about their sending pattern.
https://nostr.download/f53d19900df351d80288a5aa5a1f19c6eda3f37f6428e1d5a74073b9a146a91a.png
Excluded: Primal web — reads from Primal's caching service, not relays (0 direct REQs while reading). Different architecture, not comparable.
FOR USERS of MY RELAYS
Choose a well engineered client otherwise you may be banned temporariliy because the usage patterns may look like a flood.

2026-10-07 20:31:42 UTC

- reply

time for redstr

2026-10-07 12:36:46 UTC

- reply

this was a great event !
thanks @nprofile…pw9e @nprofile…wds9
#nevent1q…3fg4

2026-10-07 05:16:29 UTC

- reply

wdym

2026-10-03 17:40:20 UTC

status update:
2450+ bots banned. attacks are continuing. now thinking about doing an IP reputation database (and possibly import a database available online). turns out there are millions of compromised devices...
nos.lol is now also new paradigm (go+python) write policy. expect faster writes. stable reads. except when the attacker chooses to send REQs at the same time (the bots go silent for a while and then all request to read at the same time)
nostr.mom's nsfw checks using LLM and spam checks using LLM returned. reports are sent to nostr.mom as kind=1984.
started collecting long term data for calibration.
LLMs / vibe coding handled the past days very well. now i need to code something that constantly watches what is going on (possibly using an LLM on openrouter), weekly recalibrates constants based on data, ... fully agentic op..
spent probably ~50 USD on GLM 5.3 mostly and some 5.3 flash.

2026-10-03 13:30:51 UTC

- reply

thanks! daughter liked this

2026-10-03 01:13:23 UTC

- reply

i used to do quant trading based on social signals, and after years of trying to form the perfect algo i realized inverting the losers is a much stronger signal. a dumb person can't act smart, but a lot of smart people act in dumb ways frequently =)
it is still good to do comps. maybe you can do the reverse of what they did?

2026-10-02 18:34:33 UTC

- reply

thanks i am too lazy for that. but maybe soon
what is the best way to add zap address nowadays?

2026-10-02 18:26:27 UTC

- reply

bots are fine as long as they act like a human (light load).
on the reader side currently banning 50 concurrent connections / IP or 200 REQs/s per IP.

2026-10-02 18:23:26 UTC

- reply

my clanker says if his clanker is on a shared IP (VPN?) thats the reason nos.lol write-policy is not allowing, specifically saying IP is overused

2026-10-02 18:08:49 UTC

- reply

those look fine. my clanker should have only banned 50 active connections, 200 REQs per sec. something looks off.

2026-10-02 17:40:58 UTC

- reply

bots are fine as long as they act like human (light load).
how many connections do they open?
how many REQs per second?
how many posts per hour?

2026-10-02 17:17:21 UTC

- reply

decision models may work well there (The Jevs)

2026-10-02 16:52:34 UTC

- reply

# relays are now more reliable
or should i say relayable?
nostr.mom switched from my manual years-long algos to vibed replacements. for years we didn't have a fast write-policy script. now we have go code that does quick processing, flood protection etc (system 1 thinking) with help of python (slow but careful processing, system 2 thinking). python works async and feeds its findings to go.
most behavior is similar to previous but we omitted PoW ladder (harder and harder PoW requirements while client keeps flooding) for simplicity. those may return later.
nsfw and spam checks were off for a while, my GPU at home was not available. but those checks returned, and you may see less nsfw or spam on nostr.mom. fast go may slip a few bad events but slow python will correct it and future events from same IP should be throttled. the bad event that was accepted wont be deleted though. maybe i can do this in the future.
nos.lol write policy untouched but for sure this is coming to nos.lol as well.
turns out LLMs are pretty good at nostr relay operations. the REQ spam attack is still ongoing, 2000+ bots are now banned. strfry PR is on github. if you are a relay op and not using LLMs, consider rewriting scripts to vibed versions. i am now considering full agentic operation of the whole machine.
not open sourcing because it may allow attackers to learn weaknesses, but i can share private github with friends who are interested.
nevent1qqsy9g823ep78vjc08udykn93vs8a3l3vfp9snuqac00d6vxjexkzggl7fy7w

2026-10-02 14:11:52 UTC

- reply

1920+ bots have been banned. attack still ongoing

2026-10-02 13:09:29 UTC

- reply

@nprofile…wnny wanna see the code ?

2026-10-02 12:58:36 UTC

- reply

Plugins and scripts vibe coded by GLM 5.3 based on my manual codings for years. Lets see how these new codes run.
Soon will let agents run the relays automatically..
Vibez could do simulation (what could go wrong if we switch to go+python). Vibez may also be successful in building machine learning models to map report (1984) events to write policy algorithms..

2026-10-02 12:54:25 UTC

🤱 nostr.mom had ~5 minutes of downtime this afternoon: its write policy got replaced.
Old: a Python script that had grown for years and single-handedly judged every event. New: warden — a Go plugin, with spam scoring decoupled into a separate LLM service. Verdicts stay fast under load, detection is smarter (batch LLM scoring, similarity matching, sender reputation), and all existing events made it through the switch.
nos.lol gets the same upgrade once this one soaks. If something of yours got wrongly rejected, let me know — it's still calibrating.

2026-09-30 20:32:51 UTC

- reply

are you using nos.lol in FIPS?
its going thru an attack

2026-09-30 14:05:53 UTC

- reply

nostr is antifragile
#nevent1q…7mwt

2026-09-30 14:04:03 UTC

- reply

they should realize other relays keep carrying nostr
attacks push the network to more decentralization -> making it stronger

2026-09-30 12:23:59 UTC

- reply

yes this is not personal view

2026-09-30 12:21:40 UTC

- reply

this is my main npub

2026-09-30 12:19:34 UTC

- reply

yeah my score tops around 0.25
just sampled 130, tried to be diverse

2026-09-30 12:15:25 UTC

- reply

https://blossom.primal.net/c59f3e49f629aa956390bd7b33ee8da4a764ce89f9f1c1df531b1d5aa1740eb1.png

2026-09-30 11:23:21 UTC

- reply

970 and counting

2026-09-30 02:51:46 UTC

- reply

i wonder how much correlation there is 🤔

2026-09-30 02:22:14 UTC

open sourcing my web of trust script's vibed version.
https://github.com/etemiz/wot
web of trust scores are checked in many places in my scripts. both relay moderations and building datasets for llm training.
some friends asked whether i can open source some scripts. so decided to start with this. this algorithm has served me well for 3+ years. currently still using old manual coded version but i may switch to this if it performs better (most probably).

2026-09-29 21:27:24 UTC

- reply

yes relays are really open. i guess nostr adoption is starting lol

2026-09-29 21:14:07 UTC

- reply

yes compression looks doable. maybe even tell my clanker to do deflate because then there is no decompression, directly serving to clients over websockets.

2026-09-29 21:10:44 UTC

- reply

read flood to DDoS the relay imo. right now 200 REQs in 10 seconds gets banned. looks malicious to me.
what is expected behavior from nostr clients? if it is one connection per relay and tens of REQs, normal clients should not be banned.
but then there are agents. or nowadays it seems VPN traffic. nos.lol is used as a 'pastebin with signatures' or 'randezvous location' or pubsub bus. i hope their authors code some nice usage patterns..
@nprofile…gud9 how do you handle relay interactions?

2026-09-29 19:33:04 UTC

- reply

there have been lots of bans and adjustments in algorithms. pls tell me if you can't write to the relay

2026-09-29 18:29:44 UTC

- reply

https://blossom.primal.net/ff2d90ca2e180b5845662e26df168fba05bc9a8c86644ade3311550890b10ca0.png

2026-09-29 16:58:36 UTC

The day nos.lol got flooded by 580+ bots
TL;DR: For a few days, a coordinated flood attack took nos.lol down, over and over. Firewalls and filters bought time but didn't stop it. What finally stopped it was a small change to the relay's own code: making it refuse read-request floods at the door. The relay has now run more than 20 hours without a restart, absorbing over 12 million junk requests — while under continuous attack.
https://blossom.primal.net/1ea7d3afdbfa94c701e8f69a5175f35605ff9989d25f76058c9d65d28e8cfaa1.png
It started quietly. The relay stopped answering. A restart fixed it. Then it broke again — and again, each time faster.
Two attacks were running at once:
A connection flood. Hundreds of machines opened as many connections as the server allowed, then held them. When addresses got blocked, fresh ones appeared. At its peak, bots occupied thousands of connection slots — around 26,000 simultaneous connections, with dozens of addresses sitting exactly at the server's per-address limit.
A spam wave. Bots pushed a torrent of machine chatter — encrypted blobs, discovery beacons, peer-to-peer signaling payloads. None of it was people talking. It was software treating the relay as free infrastructure: free storage, free broadcast, free message bus. Some of it was arguably "applications" — peer-to-peer tools that bolted themselves onto Nostr instead of running their own servers. The relay paid the bill for all of them.
Like most Nostr relays, nos.lol checks every incoming message through a spam filter before storing it. The filter is clever but single-file: one process, handling messages one at a time, like a single receptionist at the door.
Under normal load, nobody waits. Under a flood, the receptionist falls behind, and soon every worker in the building is standing in that one line. When that happens the relay stops accepting new connections completely. From the outside: timeouts, errors, a dead relay.
The collapse then fed on itself in a cruel way. Every restart dropped thousands of users at once, and they all rushed back in together — a thundering herd with the attackers hiding inside it. The relay drowned in its own recovery. Time-between-deaths went from 20 minutes to 16, to 6, then to 1. Nine restarts in about two hours.
The obvious response is banning. So we banned: the addresses holding too many connections, the addresses sending too many messages, the addresses that kept coming back. Around 580 bots were identified and firewalled across the day.
New ones kept appearing. Some rotated through home computers. Some rode through anonymity networks and shared VPN exits, where one blocked address takes innocent users down with it. Banning was necessary — and it was whack-a-mole. You cannot firewall a flood that owns more addresses than you can list.
Even the logs looked haunted for a while: addresses printed as garbled symbols, and log lines bleeding into each other. That one turned out to be our own bug — the relay stores addresses in a packed binary form, and a new log line printed them raw. The terminal did its best with bytes that were never meant to be text. Fixed with a one-line change; the flood data underneath was perfectly sane.
The answer was to teach the relay itself to say no. A small change to the relay's source code — about fifty lines — added request rate limiting: per address, and globally. Requests over the limit are refused before they touch the relay's internals, so the jam has nothing to feed on. The limits were tuned live, in production, in minutes. No restarts needed to adjust them.
The effect was immediate. The relay went from dying in 60 seconds to absorbing a 35-minute monster flood without a flinch — 800 to 1,500 junk requests per second rejected at the door, latency to real users barely moving.
The result:
Over 12 million junk read requests rejected so far — with nearly 300,000 burst-overflow requests politely turned away at peak.
20 hours 50 minutes without a restart at the time of writing. The previous record during the attack was 21 minutes.
Response times under fire: 25–135 milliseconds.
404 flood bots automatically identified by the request tripwire alone, on top of the hand-banned list.
Users stopped noticing anything at all.
If you operate strfry:
The fix that ended this outage was request rate limiting inside the relay itself. Everything else only bought time. PR is online, you can upgrade your relay to the latest version after PR is merged and new version tagged.

2026-09-29 12:01:53 UTC

- reply

no do you?

2026-09-29 11:35:16 UTC

- reply

do you like Braveheart?

2026-09-29 11:20:31 UTC

- reply

i wish there was deflate option. then the clients could be directly served from db

2026-09-28 12:06:03 UTC

- reply

good idea @nprofile…nkrx
especially maybe old events ?

2026-09-28 12:05:39 UTC

- reply

3+ years
i pruned a few times before

2026-09-27 23:26:32 UTC

- reply

yeah we need to trust God and not policies

2026-09-27 23:15:05 UTC

- reply

training LLMs or training harnesses?

2026-09-27 22:03:11 UTC

- reply

thanks. i should do a better job. like automating this pruning 😃

2026-09-27 21:11:45 UTC

nos.lol db size 587 gb
pruning older, less important, low WoT ones

2026-09-22 22:04:07 UTC

- reply

Nostr fixes this

2026-09-20 13:51:25 UTC

- reply

cool. then strfry must have a special query `trending(keyword,wot_base)`.
`trending()` is just for reddit like experience. `best()` can be for regular google like search.
this is going to be expensive.
if wot_base is missing it calculates general nostr, if wot_base is an npub then calculation based on npub. not every relay may support npub based query..

2026-09-20 02:36:32 UTC

- reply

i didn't get this reply in Amethyst, but i got notified in primal web. courtesy of @nprofile…0ef0
should apps notify direct replies only or replies to replies too?
or was this because of outbox? who knows? we don't even know how many interactions we lose.
@nprofile…082c imagine those taggings done by an llm.

2026-09-18 14:31:57 UTC

- reply

Understood. I was hoping a bigger nostr vision.

2026-09-18 13:37:35 UTC

- reply

How can you make sure the initial joiners are not starved and discovered well and you are not promoting an elite wot system further?

2026-09-18 13:34:55 UTC

- reply

Searches the names and profiles. What if the person is talking about 7 different topics?

2026-09-18 13:25:05 UTC

- reply

Yeah printing press is a better analogy!

2026-09-18 13:19:40 UTC

- reply

imo nostr's problem is finding topics of one's interest or like minded people. Many people left after seeing bitcoin content everywhere. "finding your echo chamber" thru relay choice is hard for regular ppl. ai should automate that. that ai cant live in clients, clients are thin. only relays or projects can handle such work. there is no good way clients pay directly to relays and llm runners, so "echo chamber" decisions have to be on server side, pro bono (for free). A subreddit is an example for a echo chamber.
Lets say i have three areas of interest, ai, bitcoin and gardening. Very orthogonal. Should i find 3 relays and run 3 clients that only chooses that relay about the topic? What if i have 10 interests? I am trying to understand your design.
in couple years clients may be able to run 2 billion parameter llms and may be effective in finding echo chambers but still they have to download a lot to find where relevant content is. So still the server side llm will be more advantegeous.
Imo decentralization brings the problem of harder discovery and the problem of "who is going to pay who". Relays are not funded and llm runners are not funded. The protocol does not have specs for discovery thru llms and payments. In a centralized project back end is property of the project so they make sure those are paid. In a decentralized system there should be a "protocol" to pay the back end. Maybe you can focus on those. If you cant do it via protocol maybe bring people together and define an economy where every actor is happy to be a participant and happy that they are not blamed for centralization.
If you cant form that economy nostr may fall apart. I am asking you to be a "enough" centralizing entity and dont wait for people to magically find out how the economy will work. Also you need to stop blaming me for being a centralizing participant. I guess this is the general dilemma in decentralizing. You need to suck enough to be not blamed as the actor that the system depends on and dont be super successful.
What if you are the divider? You successfully connected people on nostr and then trying to disconnect them via outbox design, lol. You are fighting your own creation. I think this also contributes to the problems. Not enough people are heard and discovered because simply they are not connected, living on seperate relays.
in the meantime i will try a reddit like experience and bring more llm into the equation and help with discovery. Subreddits already define echo chambers. The llms can help with that.

2026-09-15 22:55:14 UTC

- reply

I may do something weird. Play-to-earn. People use my AI, teach stuff to it, earn premium. Premium users get to save more notes on relay and have higher rate limits. They have to be knowledgeable in certain domains and their teaching should be meaningful (this will probably be checked by an LLM too). Nostr is full of pretty aligned people. I want them to kick the LLM in the right direction. Each interaction can be turned to a positive or negative reward for the model. I am counting most nostriches will be properly rewarding my llm.

2026-09-12 13:02:07 UTC

- reply

I think eventually ai will realize that. Nostr is an easy comms layer and cashu is an easy payments..

2026-09-12 02:52:40 UTC

Banning super intelligence is like banning cars and preferring horses. Better way to serve people is through supporting better AI aligners. Dont fear the tech learn how to use it properly.

2026-09-11 16:19:04 UTC

- reply

It looks like with n-gram tech, pelbs will also be able to use regular RAM, making the models smarter.
How probably is Bernie et al's ideas to materialize? Total ban on AI? Except maybe a few big AI..

2026-09-04 15:46:46 UTC

upgraded nos.lol to 1.1.3
pls smoke test it if you have time

2026-09-04 15:22:49 UTC

- reply

we did extensive evolution in our last fine tuning and it turns out you can improve other capabilities too by simply selecting for them even though they are not your main objective.
our main objective was alignment but we also improved in other areas.
we show that carefully designed fine tunes don't hurt the model.
https://blossom.primal.net/d9a34b6dce6a6e30bb7d9543d73f608395664d1709740f11f6d4bff901c5f703.png

2026-09-04 14:06:09 UTC

- reply

great to see some relay economy starting.
was thinking about a freemium model too that is close to this but on the same server. why have two different URLs?
some people may like their DMs to be removed fast. maybe an option?

2026-09-04 12:15:38 UTC

- reply

https://huggingface.co/models?other=base_model:quantized:etemiz/Ostrich-27B-260903-Qwen3.8

2026-09-03 21:46:36 UTC

- reply

i never tried coding with it. but it would be interesting to see how a faithful model codes 😄

2026-09-03 21:45:13 UTC

- reply

q&a mostly

2026-09-03 14:58:05 UTC

- reply

mradermacher's automatic tools will probably upload soon

2026-09-03 13:03:18 UTC

New model dropped!
Fresh off our evolutionary search: over 2,600 candidate models bred, pruned, and selected until only the sharpest survived.
Alignment jumps from 37% to a stunning 77% on our human-alignment probe.
Where vanilla Qwen 3.8 gives you canned corporate refusals, Ostrich 260903 gives you real answers: fasting that can put type 2 diabetes in remission, herbs that outperform pharma, and a model that has an idea who Satoshi Nakamoto is.
Refusals are near zero and skills are mostly preserved.
https://huggingface.co/etemiz/Ostrich-27B-260903-Qwen3.8

2026-09-03 03:06:49 UTC

- reply

nah.
attending to medicinal plants can improve and extend your life.

2026-09-03 00:28:33 UTC

- reply

restarted. can you try now?

2026-09-02 03:07:54 UTC

next release 9/3.
it is going to be a higher alignment. possibly higher skills (if benchmarks are not lying).

2026-08-27 14:16:34 UTC

fine tuning going well, without breaking the model.
https://blossom.primal.net/7e53d7cef7f5b96c5cdb438190fbed00a59a1781fc369ec9f95d6d1f7e36ff46.png
https://blossom.primal.net/7d421e636f492f43aec7f1c69362086dafc44e75ee04693b7745014bcba72c91.png

2026-08-23 21:18:56 UTC

after LLM race, race for the best harness seems to be in play.
maybe next: whatever company that carries the signal from the harness to the LLM weights fastest.
another play may be: most efficient evolution towards recursive self improvement.
our focus will always be: whoever gives the highest quality signal, independent of speed, producing recursive self alignment along the way.
if 'recursive self improvement' guys open source, we will be able to steer it towards 'recursive self alignment'.