fiatjaf

https://stuff.fiatjaf.com/

Public Key

npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6

NIP-05 Address

Profile Code

nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhyetvv9ujuam9wd6x2unwvf6xxtnrdakszxthwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mgpr9mhxue69uhhyetvv9ujudp5vf5kcmrfdahzumn9wsqs6amnwvaz7tmwdaejumr0dsq3wamnwvaz7tmfde3x77pwwfjkcctewvhxcctwvsqs7amnwvaz7tmwduh8xarj9e3hyz22khf

Publishing to

Author Public Key

npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6

Show more details

Last Notes

2026-02-25 16:16:38 CET

Hey @npub1jjn…vknm what do you think about running a one-click #pyramid relay setup hosting charging some monthly bucks? I can try to help with whatever I can. Let me know. Join the NIP-29 group at pyramid.fiatjaf.com'Tnq7x2ZTgrPZWFrC if you want to chat.
The expected revenue is between zero and a thousand millions.

2026-02-24 18:59:32 CET

- reply

This is good to hear. Thank you.

2026-02-24 13:22:16 CET

- reply

See, @npub1l3c…6vs2, there is real supply of infrastructure for hosting files, and it's -~=FREE=~- for up to HUNDREDS of 44b apps per user!
Meanwhile relays don't want to store base93-encoded unreadable blobs. Sure, they may accept it for now, but that's only because it's too much hassle for them to try to fight it, not because it's something they want. It's a flawed approach to try to build against all the incentives and still hope you'll get something that will last for the long term.
Make https://44billion.net/ blossom again!

2026-02-24 13:14:39 CET

- reply

Wouldn't it be nice if instead of trying to shove files into events with a weird encoding you just published them to Blossom?
That way you could get a canonical hash for each app version, fetch that from Blossom servers on 44b startup like you're doing anyway, and everybody would be much happier.
Even @npub1q3s…d26p would be much happier because Shakespeare would be able to automatically publish 44b apps with a single line change instead of requiring a new weird dependency with all sorts of unknown problems associated.

2026-02-24 13:10:23 CET

- reply

I read your report on Nostrability, but I don't understand how you're doing these benchmarks. Are you firing up the apps and measuring the notes they display? Can't be that, right? And what are those algorithms you listened. I tried looking them up but didn't get a clear view of how exactly they would work with outbox.

2026-02-24 13:07:35 CET

- reply

But there are all these relays with thousands of random groups we're not interested in, which I think is a valid use case, people should be able to create groups in one big provider and not care about the others.
On the other hand the single relay with multiple groups we're interested in is also a valid use case.

2026-02-24 13:05:15 CET

- reply

What about that idea of having multiple groups associated by their prefix to constitute sub-rooms? How are you feeling about it?

2026-02-24 01:38:20 CET

If you're looking for a tutorial to follow tonight or you're eager to send someone else a link for a tutorial they may want to follow tonight, here is it: https://spatianostra.com/getting-started-with-pyramid/

2026-02-24 01:33:15 CET

#nak has a "profile" command now. Paste a public key, npub, nip05 or nprofile and get all the basic relevant metadata. Just a small helper. https://github.com/fiatjaf/nak

2026-02-23 17:53:47 CET

Make Nostr that app no one likes but everybody is forced to use: #nevent1q…dvy8

2026-02-23 16:14:23 CET

- reply

I don't like that if I'm participating in two groups from two different relays I have to manually switch between the relays all the time, then find the group etc. I know it's early days, but did you consider a Discord-like interface in which multiple relays would be shown at the side-menu, then in a secondary side-menu there would be my groups (from my kind:10009 list or whatever the number is) and all the other groups in that same relay would be hidden by default?

2026-02-23 15:48:25 CET

@npub1f27…9swu can you create a NIP-29 group that we can join to complain about https://nostrord.github.io/nostrord/?

2026-02-23 15:41:14 CET

- reply

Maybe the idea is bad, but at the same time it can be much better for introducing people to Nostr than inviting open-minded people to a cesspool of bot spam where they will find no content they're interested in or anyone they know.

2026-02-23 15:34:07 CET

- reply

On Nostr, any idea that doesn't take into account what relays are going to be used for publishing and reading is going to have incentives all misaligned and is bound to fail.

2026-02-23 15:32:32 CET

- reply

You can definitely delete stuff. It doesn't work really when clients decide to broadcast your content to dozens of hardcoded relays, but in a setting where you're publishing only to one or a few handpicked relays as in the scenarios I described deletion would work perfectly.
The "you can't delete" stuff is more a legacy thing from 3 years ago when everybody was committing all kinds of sins when making clients. We're not perfect yet, but much better.
Many clients already have a button to delete, others should implement that as soon as possible.

2026-02-23 13:32:01 CET

"Social credit scores" are a good thing, government-enforced scores (even indirectly, as it's common these days) and the surveillance State are the bad things. They use wrong names in order to confuse everybody and you're falling for it.

2026-02-23 13:24:57 CET

- reply

Do you hate me again? Because of Asciidoc? I thought we had a truce.
I'm not anywhere near nazist, but there are some nazis on Nostr, which is somewhat ugly, which is fine by me as long as they don't do evil stuff (communists are much worse but Nostr is also a place for them). Luckily I have just suggested ways people can isolate themselves from them (and also from you) if they want.
By the way, @npub1m4n…c2jl, I don't know of any client that does exactly what I said that is ready to be launched next week. I'm genuinely just throwing the ideas out there and hoping others will build on them.

2026-02-23 13:16:12 CET

- reply

By the way, this is all about having a very loose type of "community" in kind 1 clients that is easy to set up and can be expanded gradually.
For strictly closed and moderated, traditional Telegram-style chat and forum-like "communities" (or "groups") the solution is still raw NIP-29 (or the single-selfhosted-relay multi-room Flotilla approach).
Take a look at https://github.com/Nostrord/nostrord and https://grimoire.rocks/.

2026-02-23 13:07:25 CET

- reply

I gave just an example above, but we can think of many variations on the same theme.
Such a community could have more than one relay, because just one might be giving too much authority to a single person running it, or for other reasons.
Or it could be open to external integration by allowing the rest of the world to read their stuff -- or even reply to their stuff (if all community members are set to use #pyramid's /inbox relay, for example) while still providing spam and harassment protection.
Having a canonical set of follows encoded in the invite isn't bad either, could be part of the community onboarding that some special news channel is auto-followed by everybody and that goes in the "following" feed while the rest of the community banter stays in a relay, or whatever variations of that you can think about.
It goes without saying that people who get introduced to Nostr like that can still find about the rest of Nostr if they want, start following other people, find other relays and gradually open itself to interacting elsewhere.

2026-02-23 13:00:43 CET

Maybe the way Nostr can get more people is by making it a good choice for semi-closed hyperlocal mini-social-networks, like a low-effort impromptu social network for a neighborhood, a church, a school, a company, I don't know.
People could join this just because they have to if they want to get news about their community and stuff like that. They won't regard it as a global social network, they will keep using X, Instagram etc, this will just be an annoying app they're forced to use.
How to make it work:
Some conscientious member of such community would set things up, spin up a #pyramid relay or something like that that would provide an exclusive space for this community. Then he would use a client that supported such mode of operation to send invites to other members.
Upon receiving the invite (the invite can just be specific for that client, no need for a standard here) new users would have an account created for them and be thrown into a prepared environment in which the only feed would be that relay's feed, search would be scoped to that relay, replies and mentions would only be sourced from that relay. There will be no spam, no Bitcoin, no bots.
Luckily it's easy to turn an existing kind 1 client into a client that supports this mode of operation (some are already almost there), so if you're a developer reading this here are some ideas to consider implementing:
- making relay usage highly configurable (allow users to be set up to only read mentions from their "read" relays ever, only publish to "write", only search for specially designated "search" relays etc -- this could be optional);
- supporting relay feeds alongside the classic "following" feed;
- hiding the "following" feed entirely if the user doesn't follow anyone (or having an option to hide that regardless);
- maybe allowing other customizations, like changing the UI colors and whatnot;
- supporting an invite flow that allows some community leader to prepare the invites and then sets up all of this stuff automatically for people who get the invite.

2026-02-22 16:06:27 CET

- reply

Sim, está funcionando.
wss://impromptu.relays.land/

2026-02-22 15:51:57 CET

- reply

I'm not talking about proxy or caching relays.
On NIP-65 you can specify "read" relays which should be used by others when replying or mentioning you and used by your client when reading your inbox.
That is where I'm saying one can select a relay that will reject stuff based on whatever criteria. https://pyramid.fiatjaf.com/inbox does that with a very dumb algorithm.

2026-02-22 15:46:55 CET

- reply

I see what you mean now. I had never considered that big and free relays would provide a generic filtering service for everybody, but indeed that is a possibility and would have negative consequences.

2026-02-22 15:44:22 CET

- reply

I think you're conflating Nostr and Amethyst.

2026-02-22 04:35:28 CET

- reply

I had never seen that approach suggested.
It's a pretty good idea.

2026-02-22 04:34:20 CET

- reply

Another issue: can relays be really "dumb" in the way you're implying? I don't think so.
If a relay should just accept anything without filtering (as long as the publisher pays, in your model, if I understand correctly) it would be exposing itself to hosting all kinds of sordid, illegal content, or perhaps just content they really dislike and are not ok with hosting. That creates an enormous disincentive to being a relay.
Relays should be free to "censor" anything they want. You don't agree?

2026-02-22 04:30:40 CET

- reply

The influencer use-case was just an example. We can think of others. I could prefer to use a different filtering criteria than follows-of-follows, maybe using 3 levels, or 2, maybe I want people to be known to publish about certain topic (according to an LLM judgement) for a while before I read their stuff, I don't know, there are many possibilities, and the client can pick and choose any by just switching their "read" relays.
The alternative of doing it on the client, even if it was possible in practice, would require a huge number of clients or a lot of complex implementations in the same client.

2026-02-22 04:26:55 CET

- reply

Just to clarify here: I think we're talking about "read" relays, not "write" relays. So it's actually the reader who picks the default relays for the interaction, right? Or at least those relays picked by the receiver are the ones that carry most importance in such interactions.

2026-02-22 04:22:21 CET

- reply

I don't understand what you mean here.

2026-02-22 04:21:23 CET

- reply

If you follow them you should get everything from them regardless, directly from their "write" relays.
What I'm talking about is a relay policy with regards to replies, reactions and mentions only, i.e. your "read" relays policies.

2026-02-21 20:52:50 CET

- reply

If you're asking relays to filter based on follows of follows isn't that elevating the role of the relay? #pyramid has an inbox relay that filters based on follows of follows, but is that what everybody wants? People might want a different filtering algorithm, the influencer case was just one example.
I really don't see how this introduces censorship. Given outbox everywhere no one is censored. And filtering replies on your own notes is almost a personal thing that affects others very little. Readers should still be able to see replies to you from relays others than the ones you chose (they will probably automatically see replies from people they follow already, even if those are banned from your inbox relay).

2026-02-21 19:34:25 CET

https://www.youtube.com/watch?v=li8EEGSxSSo

2026-02-21 19:22:37 CET

- reply

I know this is not the solution you want, but it should be easy to make a server that takes a blossom WACZ and serves it as a website via HTTP.

2026-02-21 19:19:42 CET

- reply

What you're saying makes sense, but it's impractical. Someone could spam a thousand likes on your note, then you'll download all of that to get only two in your web-of-trust? Most relays won't even allow you to fetch more than 500 events directly.
At the same time an influencer might want to know a full count of likes, and if he is famous most of the likes will come from outside his WoT. But still that number is meaningless if it can be easily spammed.
The only way to reconcile all the different use cases and preferences while also providing some efficiency is by using relays, and relays with different policies for different users.
Client-side filtering has its place too, but it's a secondary barrier.

2026-02-20 19:15:05 CET

- reply

It can't work this way, users shouldn't have to spend their days clicking a block button, relay-based filtering is necessary and urgent.

2026-02-20 17:52:17 CET

- reply

If it's not asking much, could you take a shot at adding the web archive kinds to https://github.com/nostr-protocol/registry-of-kinds?

2026-02-20 17:50:47 CET

- reply

OK, makes sense, but it's always better to support a single standard than multiple.
If you were to pick a single format to support for all web archives going forward forever, what would pick: WACZ or SingleFile HTML?

2026-02-20 11:03:28 CET

- reply

Why not just use WACZ?

2026-02-20 11:02:50 CET

@npub1ye5…knpr window.nostrdb is a great idea. Can you push https://github.com/hzrd149/nostr-bucket/blob/master/nip.md to the NIPs repository?

2026-02-19 17:48:26 CET

- reply

This is an amazing initiative.
I hope you can improve the archiver extension eventually, it is so rough right now.
Would be nice to have a CLI archiver too. I thought about doing it but I think I gave up because it wouldn't have JS support (although that can be arranged), but that isn't necessary in all cases.

2026-02-19 17:41:13 CET

- reply

Or that is the solution for getting rid of non-monetary transactions in Bitcoin: fill the blocks with quantum-resistant signatures.

2026-02-18 02:28:27 CET

https://www.youtube.com/watch?v=0GYcZkeMdJ4

2026-02-17 23:24:27 CET

- reply

So this was 6 hours ago and I'm only seeing it now?
That is one of the reasons why I don't like livestreams. Did you record it?

2026-02-17 16:37:25 CET

- reply

That would be a good idea but I kinda hate Lightning and have never even read the NWC NIP. Maybe someday.
Perhaps I should have never added NIP-60 support.

2026-02-17 11:35:34 CET

- reply

Can you do access control at the MOQ relay level? Would be nice to have a standard for that that worked similarly for ad-hoc public calls, for NIP-29 group level spaces, for NIP-17 chats.
Are there multiple implementations? I only saw one in Rust and one in Go, but the Go one seems to be abandoned.

2026-02-16 19:15:09 CET

- reply

Makes sense, thanks.

2026-02-16 18:37:05 CET

- reply

Where are these MOQ relays? Who is running them?

2026-02-03 23:03:02 CET

- reply

This is better: #naddr1qq…8q96

2026-02-03 12:01:10 CET

Are any of the Epstein things signed with his Nostr key?

2026-02-02 20:13:14 CET

Am I crazy or it looks like every single webpage that ever embeds a YouTube iframe in any way gets a 42MB of disk space used forever associated with it?
https://image.nostr.build/c5c56d61002e3e9fcbda28f00a7378adf43a1283528684dc6eae101fee6d560e.jpg
The web is some crazy dystopia. Websites I don't remember visiting ever have this YouTube garbage in it.
https://image.nostr.build/536dcf6afe4d95805a38e3945580f2b9cd5a28d209cfb2476abeccd4734a10b7.jpg
I guess in the past it would be a single 42MB of YouTube for your entire browser, but this situation got worse when browsers decided to treat iframes as different origins even if they have the same domain name as long as they're embedded in different places.
Why on earth they need 42MB after all? Why specifically this number, always?

2026-01-27 03:57:00 CET

Search on outbox relays directly fixes 80% or more of all generic "search" use cases. We almost can live without big centralized search indexers if we can do full-text search directly from the source of people we're interested in.
1. If I want to search for something specifically said by someone (on Twitter there existed a "by:" special directive when searching, I basically always used that) I can search their outbox relays directly.
2. If I want to search for something and I'm not sure who said it: it goes a long way to search each of my follows' relays, as that thing that I saw is likely to having been said by someone I follow.
3. The point above can be expanded to follows-of-follows: it may take more time, but such cases of search are rare enough that the user can be expected to endure through a "loading" bar while the client tries to search some hundreds of relays.
#nevent1q…ll83

2026-01-22 14:50:27 CET

If Bitcoin isn't directly used by most normal people in daily commerce then it is very easy to capture.

2026-01-21 21:31:31 CET

- reply

I'm aware, don't worry about trying it if you have given up everything. I hope it suits you if you decide to come back in the future. NIP-29 should also be better by then.

2026-01-19 17:20:01 CET

- reply

Bug report: clicking on the "chat" option in a note's menu opens the note in a chat, but its associated command is just "CHAT", no id. So when we try to open it in a new window it breaks.

2026-01-17 15:04:01 CET

- reply

Doesn't letting anyone submit an issue by just filling a captcha negate all the moderation stuff?

2026-01-17 00:09:22 CET

- reply

What is that one?

2026-01-15 02:23:46 CET

The new #pyramid v1.0.18 includes:
A way to customize the kinds the relay accepts:
https://image.nostr.build/58f48d349b18363e5113465ecf826c89018292ac1552db75a60800ef0a8fba22.gif
SFTP access for full control over events and blossom blobs (dangerous):
https://image.nostr.build/38af15f528ac309db701547312cc9a3a4573e50bb2c23eb9ccb2ebbf3b5ccd57.gif
NIP-86 support in all sub-relays (should work on https://landlubber.coracle.social and on https://nostrapps.com/relay-tools):
https://image.nostr.build/2de64c6c2556b8584186b54700bb0fc6f0011b2dda6fcd5584aaf4a8c7cdca74.jpg
And also:
- a way to pin events to the top of the feed of any of the relays.
- bug fixes.
#nevent1q…64vs

2026-01-15 02:08:41 CET

- reply

I ended up implementing a way to remove a user but keeping them in the tree, that should probably be the default action when deleting someone.
I had to because I realized that @npub1jk9…lqz7 is flooding wss://pyramid.fiatjaf.com/ with a million notes with ugly images but he has invited a ton of people that I don't want to remove.

2026-01-14 05:29:23 CET

- reply

@npub1m3x…a5sf if you're compiling from source this should be working already: allowkind/listallowedkinds/disallowkind methods. It's not in the UI yet, and not released, but hopefully will be.

2026-01-08 14:12:42 CET

new features in the latest last #pyramid release:
- primitive blossom support with a simple dashboard and upload button
- if you just publish an event with a date in the future it will be scheduled and automatically released at that date
- an option to automatically opentimestamp every note published to the relay
- an option to set the maximum size of events allowed
- many fixes
https://image.nostr.build/0e4f0ea0390ded77dd00c409a0c5bfb0d083e2fbdf6114528d17623264f3462e.jpg
#nevent1q…edd6

2025-12-29 01:46:07 CET

This new Yakihonne version fixes DMs completely apparently.
NIP-17 is working pretty well now on Amethyst, 0xchat, https://yakihonne.com/, https://chachi.chat/dm?
Also Coop, Nostur and Damus Notedeck if I'm not mistaken.
#nevent1q…sh9l

2025-12-11 20:22:15 CET

Can someone please do https://sponsor.ajay.app/ but for podcasts?
It's a perfect use case for Nostr, by the way, if you want to do it the crowdsourced way.
Or does it exist already?

2025-11-20 14:28:05 CET

- reply

It's here: https://gitworkshop.dev/fiatjaf.com/nostrlib/tree/master/khatru/grasp/server.go
But I'm still confused about the PR events and refs/nostr/ stuff and how are these related to patches.
I was thinking that would be nice to expose received patches as refs so they could be fetched by git directly, is that what that means?

2025-09-08 14:13:54 CEST

“And whereas all the other things, whether beast or vessel, that enter into the dreadful gulf of this monster’s (whale’s) mouth, are immediately lost and swallowed up, the sea-gudgeon retires into it in great security, and there sleeps.” —MONTAIGNE. —Apology for Raimond Sebond.

2025-09-07 18:28:18 CEST

“Suddenly a mighty mass emerged from the water, and shot up perpendicularly into the air. It was the whale.” — Miriam Coffin or the Whale Fisherman.