fiatjaf

https://stuff.fiatjaf.com/

Public Key

npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6

NIP-05 Address

Profile Code

nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gpz4mhxue69uhkg6t5w3hjuur4vghhyetvv9uszxthwden5te0d3hkx6mzdauzuenfv96x5ctx9e3k7mgprfmhxue69uhhyetvv9ujuam9wd6x2unwvf6xxtnrdakszxthwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mgpremhxue69uhkscnj9e3k7unpvdkx2tnnda3kjctv9a5kucn00qq3jamnwvaz7tm9d35hgetn9ehx7um5wfshg6fwdaexwjvzee3

Publishing to

hbr.coracle.social/inbox

elites.nostrati.org

Author Public Key

npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6

Show more details

Last Notes

2026-01-15 18:55:15 UTC

- reply

Another good idea. I'll look into that, but it will depend on whether there is already some library that does the hard parts of streaming in Go, I don't know anything about the subject yet.

2026-01-15 15:04:54 UTC

- reply

Looks wrong, it usually does less than 1% CPU for me.
I just noticed the last release is buggy for some reason. There is an infinite loop somewhere.

2026-01-15 12:36:47 UTC

- reply

No, the only "changelogs" are the commits in the repository and these notes I publish, which are all nestedly quoted here. I never liked these changelogs in open-source projects, they're often useless autogenerated garbage that I assumed no one read.
But if I can help you in any other way please let me know. You can also join our group at https://grimoire.rocks/run?cmd=chat%20pyramid.fiatjaf.com%27Tnq7x2ZTgrPZWFrC

2026-01-15 12:31:36 UTC

- reply

It's too intertwined. But I'm curious: why do you want to run it in two different machines?
You can always run two copies and only enable the blossom server on the other, perhaps? There is also a simple pure blossom server at https://viewsource.win/fiatjaf.com/myriad

2026-01-15 01:23:46 UTC

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 01:08:41 UTC

- 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-15 01:06:25 UTC

- reply

Unfortunately I haven't seen your DMs, but Nostr wasn't really designed to do DMs, so I have that excuse.
Now, it can be adapted to do DMs reliably I think, but the implementation is lacking. With an extra 10% implementation effort we could have reached reliable DMs a long time ago, but probably haven't yet because the "let's all agree to use the same hardcoded relays" mentality took hold too much on most developers' minds.
In your analogy the shift required is turning UDP into TCP or something like that (but I don't know if I like the analogy).

2026-01-14 20:36:24 UTC

- reply

I didn't read the full discussion, but npubs are definitely insufficient.
That's why we have nprofiles, nip05s or at least the dependency on a client having access to a greater ecosystem of recent events from other people that may provide updated hints to the relays of a bare npub, ideally through some form of local database. It's all on a best-effort basis, no mathematical guarantees, but I think that suits the messy world we live in very well.

2026-01-14 04:29:23 UTC

- 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-13 18:40:05 UTC

Some #pyramid relays I know of that are up and running very profitably:
- https://spatia-arcana.com
- https://inner.sebastix.social
- https://basspistol.org
- https://nestr.nedao.ch
- https://garden.zap.cooking
- https://pyramid.fiatjaf.com
Please let me know if you're running one and how it's going. And send me your most adventurous feature requests such that they can be slowly worked on.
#nevent1q…psrs

2026-01-13 11:02:07 UTC

- reply

The links should be fixed in the latest commit. Thank you.

2026-01-12 17:36:59 UTC

- reply

On vnak it will authenticate to any relay provided that you have set a main secret key at the top.
On nak you have to pass --sec and --auth. There is also --force-pre-auth for when the relay doesn't send an "auth-required:" message but you want to auth anyway.

2026-01-11 17:00:07 UTC

https://viewsource.win/ now supports:
- displaying information about the latest commit
- a page with commit history
- fetching directly from github.com, codeberg.org, gitlab.com
- displaying README files automatically when no filepath is provided
- browsing the repository at any commit, branch or tag
https://image.nostr.build/35f2e5780e485595c14ef83b40a9d6cc5d6f848b2e5f9d803c2cd7062446ffa0.jpg
All without having to clone the repository or download a ton of stuff (if the server supports filters, which most should and eventually will).
Some examples:
- https://viewsource.win/npub1useke4f9maul5nf67dj0m9sq6jcsmnjzzk4ycvldwl4qss35fvgqjdk5ks/gitplaza should download directly from Codeberg
- https://viewsource.win/460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c/amethyst should download directly from GitHub
- https://viewsource.win/npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6/gitview should download directly from wss://pyramid.fiatjaf.com or wss://basspistol.org
There were also some bugfixes. But let me know if more things are broken.
#nevent1q…c6gk

2026-01-11 13:38:31 UTC

- reply

"load profile" is for loading preexisting profiles created with "nak bunker --profile". That isn't well-developed yet, I should have probably hidden that button for now.

2026-01-11 11:36:25 UTC

- reply

It was released yesterday!
Do you have feature requests?

2026-01-11 00:36:22 UTC

vnak v0.2.0 is now widely available:
https://image.nostr.build/6b7ffdcef8861607eb3300d59b8b6796330b31c2cc85d3636dc62e3a48bf4149.jpg
https://image.nostr.build/c2094aa40330cd8e06e7276137a8825cb1d133266befbdbad8139224bdde55de.jpg
https://image.nostr.build/fb1b412c6b003fb4aec27413a0d037f053f3a970fe7bdcbee5edea4751268723.jpg
https://image.nostr.build/beb32dab7576d71e1e44481ffe5bd1e5449f0b4c10e150015c3847e002b17758.jpg
https://image.nostr.build/05af2b3f2edc24711500b1d3b0b7c894a0977d3ae1144feb99362ca9a159b67b.jpg
https://github.com/fiatjaf/vnak/releases/tag/v0.2.0

2026-01-09 01:22:36 UTC

- reply

Good point, I'll do that.

2026-01-08 13:12:42 UTC

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

2026-01-04 11:57:18 UTC

I have just invited @npub1zl3…jajh @npub1zfs…w445 and @npub1q5j…2qhm to https://basspistol.org/, please make good use of your new privileges.

2026-01-01 16:41:31 UTC

- reply

The ciphertext being decrypted in his screenshot is a NIP-04 one, notice it ends with an "?iv=..." parameter.

2025-12-31 23:49:42 UTC

- reply

We should run a prediction market for this.

2025-12-31 15:59:31 UTC

- reply

Looks good but I'm not in a position to do anything about this.

2025-12-31 15:42:05 UTC

- reply

wss://basspistol.org/ is apparently basically a feed of reposts from @npub18ug…20ex. Not bad.

2025-12-31 11:54:50 UTC

- reply

Why isn't #grimoire on the list? That's completely backwards.

2025-12-31 00:33:50 UTC

- reply

We're pretty close, I'm introducing another interoperability issue with decoupled keys so let's postpone that goal to 2027, but I think after that we will definitely be good.

2025-12-31 00:31:00 UTC

- reply

Would be nice if there was a scheme that worked for encryption/decryption over FROST, but even so I don't know if it would be useful in practice. I think it's better to use decoupled keys that just live on the devices, because performing dozens of decryption calls through a network of key share holders like that would be awful experience.
Better focus on crazy key setups that guarantee user identity keys for the long term instead, if you have crazy ideas.

2025-12-30 22:12:50 UTC

- reply

It's not that straightforward I think, but there is https://viewsource.win/npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6/promenade: #nevent1q…p7fz
That's what made me realize we needed to decouple encryption keys from identity keys.
There is also Frostr that is doing a similar thing but with different goals.

2025-12-30 18:44:58 UTC

The latest nak v0.17.4 implements support for managing decoupled encryption keys that fix NIP-17 completely, as per https://github.com/nostr-protocol/nips/pull/1647
See this amazing infographic that explains how it works:
https://image.nostr.build/89c543d261ad0d665c1dea78f91e527c2e39e7fe503b440265a3c47e63c9139f.jpg
If you call `nak dekey --sec <whatever>` you'll generate a new decoupled encryption key that is stored locally and announced with a kind:10044 event. After that if you use `nak gift wrap` or `nak gift unwrap` that key will be used by default (when wrapping both keys will be tried if possible).
If you run `nak dekey` on another device/client (or with another --config-path) that other device will announce itself as in need of the decoupled key, then you can run `nak dekey` again on the first device and it will automatically send the key to the second -- and like that the key is shared among all your devices.
Call `nak dekey --rotate` to discard the current decoupled key and generate and announce a new one.
Download here: https://github.com/fiatjaf/nak/releases/tag/v0.17.4

2025-12-30 15:57:35 UTC

- reply

Maybe just host it under emojito.habla.news or somewhere else? Is the source open?
Domain names are such a big scam, we should stop giving these people money.

2025-12-30 13:10:01 UTC

- reply

Yes, definitely.

2025-12-29 22:45:49 UTC

Here's a very simple and hopefully very fast read-only client for NIP-34 git repositories:
https://image.nostr.build/b8642babe490a628570e23ae0ad3a43489099f001e41dd2d742844017e9ba9fe.jpg
https://image.nostr.build/fa85be6cf7d54c3d6e205cd7f18d9b159d398b440597ddfc2eb9fd89e0ec0094.jpg
An example: https://viewsource.win/fiatjaf.com/nostrlib/_/master/~/nip17/nip17.go

2025-12-29 13:15:43 UTC

- reply

Are you using the relays from kind:10050? It doesn't look like you are, I'm missing all messages from clients that do that correctly, (Chachi, Flotilla, Coop).
My suggestion is that you remove NIP-04 support entirely because it just confuses everybody and bloats the code, then start doing NIP-17 DMs but only sending them to the kind:10050 relays of others and reading from yours. That is necessary to ensure privacy and efficiency.

2025-12-29 12:39:10 UTC

- reply

Please tell me you're sending DMs to the relays in the kind:10050 event for each target user.

2025-12-29 00:46:07 UTC

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-29 00:19:35 UTC

- reply

This looks like a good enough solution.

2025-12-28 17:15:16 UTC

- reply

I wasn't. I was just talking about hosting Nostr clients in a way that is independent from domain names.
If your client is just client-side assets these can be hashed and downloaded from many different places, they don't have to come from one canonical URL controlled by one guy.

2025-12-28 16:23:43 UTC

- reply

Are all these things because of secp256k1 or because these guys who made these things decided to not support it?

2025-12-28 15:28:08 UTC

Real Nostr clients don't require any servers, they can work completely on the client side.
The fact that we have apps that still work perfectly well but are now inaccessible because a domain name has expired (or whatever) is some bullshit we inherited from the "web" world that we should try to circumvent, not embrace.
There are multiple ways to circumvent these flaws and build true Nostr clients that can't be controlled by anyone, not even by their original author.
#nevent1q…pa68

2025-12-28 15:22:21 UTC

- reply

That's not my npub.

2025-12-23 15:43:26 UTC

SQRL invented the anti-phishing public key cryptography based approach to website authentication many years ago. It was a beautiful spec of one page with multiple grassroots implementations.
Then they decided that the simple "I sign something with a key" approach wasn't good enough, they also had to cover a bazillion other key management things in the protocol so they brought a team of academics that turned the thing into a 300-page unreadable spec that no one ever implemented fully.
LNURL-auth basically reinvented the original simple SQRL version in 2019 and got many implementations and some traction within the bitcoiner realm.
But at the same time another team of academics probably by paid by some evil people were creating Webauthn, i.e. "passkeys", which solves the exact same problem and works in the exact same way, although this time the spec is much bigger than even the worst version of SQRL and apparently designed to create centralization.
It took them at least 6 years to get browsers and phones and some websites to start adopting this behemoth, but so far there are no answers to what is their real purpose or to the question: "what if I lose my phone?".
https://www.youtube.com/watch?v=xYfiOnufBSk

2025-12-23 15:36:01 UTC

- reply

Did I sunset it? I would like to keep it but I thought my rewrite had already screwed it up so I just removed that last file.
I didn't have the time to test it or use it in any way.
Are you telling me it still works? How do I test it again? I'll bring it all back if I can.

2025-12-23 14:49:41 UTC

- reply

Definitely not my specialty, although I'm not awful at it. In any case I definitely have no idea of how to deal with a neverending wave of evil scrapers with thousands of IP addresses at their disposal and I refuse to keep wasting time on that.

2025-12-22 16:26:07 UTC

Added a "spell" command to https://github.com/fiatjaf/nak
- `nak req -k 777 -a [email protected] --outbox | jq` to see all @npub107j…ncxg spells
- pick one and run `nak req -i c1214b196b3664bc7fc8c8dfaa082a24ed09b25028773bcae60fef8dfe6646fa -a [email protected] --outbox | nak spell --pub fiatjaf.com` to run it in the context of your user (replace 'fiatjaf.com' with your npub or nip05)
- `nak spell` will list your previously used spells with ids that you can use to invoke them again: `nak spell spellcgk4u9c --pub fiatjaf.com`
It's not super useful, but it is something.
#nevent1q…6rpe

2025-12-22 00:19:48 UTC

- reply

I can't find it either, but I think the original was funnier. This version borks the best part ("four thousand words just to say I don't even need you guys") by arbitrarily removing words from the original lyrics.

2025-12-22 00:13:20 UTC

- reply

I have an issue with opening entities by clicking on them. It's amazing, but sometimes they open in weird places and if I click too much I end up with a ton of panels.
If you could somehow figure out a way to open stuff in the same panel, perhaps optionally with a keyboard shortcut, that would be good, but then we would probably also need a back button for each panel? I don't know.
Another thing that would mitigate the issue would be to somehow have different colors or different borders (or something) for panels of different kinds, e.g. subscriptions are blue, events are green, profiles are yellow etc.

2025-12-22 00:07:17 UTC

- reply

Yes, but I'm waiting for bunker support, please.

2025-12-21 00:44:35 UTC

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

2025-12-21 00:30:01 UTC

- reply

It will probably break at some point because of the crazy volume, but @npub1z4d…j7rz is now timestamping everything from a bunch of popular relays instead of just stuff from wss://pyramid.fiatjaf.com.

2025-12-21 00:21:13 UTC

https://docs.nostr.wine/cellar/readme is still great.

2025-12-20 02:43:41 UTC

- reply

Drivechain activated.

2025-12-19 17:18:15 UTC

- reply

They are grouped by week at read time. Could be by day too.

2025-12-19 15:20:37 UTC

- reply

The stats are just the number of events stored. I read from the database index and count.

2025-12-19 15:04:15 UTC

- reply

Also a lot of bugs were fixed, which also means all new features probably have bugs, so please help me test.

2025-12-19 15:02:40 UTC

#pyramid has had some updates since the v1 release:
- support for nip05 addresses on the same domain the relay is running;
- more color customization, and fonts;
- support for one-click updates, no command lines required;
- /inbox relay support for filtered mentions and replies and NIP-17 DMs;
- personal /u stats page for relay members;
- global /stats page for the relay owner;
- per user on-demand negentropy sync with other relays;
- arm64 support on easy-install.
https://image.nostr.build/73f091227a11a6b3a769f2361f8c97e94cd2da0717a427465e3e1b6766f6e9c0.jpg
https://image.nostr.build/ccb31514d35f471e7bde6a0c2cf8d271b2c07af6b45acc2bc61e73461f87925f.jpg
https://image.nostr.build/7b6c6de9ef1633cd635078ef64c21c71b7452afc3ae2ffee6c9bfb5d7eb9a5f0.jpg
https://image.nostr.build/a06608f3e0ea2cb21a8d1035e59bbbfe6c9f3c71a76fe2e13e37b1b40b6e3c39.jpg
https://image.nostr.build/3295f9d590db77fd47c3f3840c5e86a0761469641cfaa04926b75ed79c6e372f.jpg
https://image.nostr.build/f5e6fe2564a39ee100548b2c137fd2abda250b4eba0303e818b6339722447676.jpg
download https://github.com/fiatjaf/pyramid
join https://chachi.chat/pyramid.fiatjaf.com/Tnq7x2ZTgrPZWFrC

2025-12-19 12:51:46 UTC

- reply

This is too good:
https://image.nostr.build/051de3a1d0c0ce2572b3d6f7a94aed9e5bea906fe1a79ef013bfbb898fc86572.jpg
Just get everything in the same feed: repositories, issues, patches, all nicely formatted, click to expand, rearrange.

2025-12-18 00:36:01 UTC

#grimoire notifications on the left, a feed of pictures and video from people I follow (with outbox by default) on the center, a feed of a bunch of kinds from selected relays on the right.
https://image.nostr.build/4eca1d905f06eaa57448a16420781eb2751fed44e175527c9f5c9caa80b7ed4d.jpg
Oh, what, you can have multiple dashboards? Then this thing can do my NIP-29 chat rooms too.
https://image.nostr.build/b2e3d49d20d2941f5830f6b4c6eb0dd7763c985733422d1abe0f2672cca21abf.jpg
https://grimoire.rocks

2025-12-17 15:35:56 UTC

Instead of "protocol" we should call Nostr a "system".

2025-12-16 15:48:41 UTC

- reply

How do you get 12k events? No relay will send that many at once.

2025-12-16 00:50:01 UTC

- reply

That game has been over for years. Ladybird will be pitifully worse. Stop holding on to a failed past and start working on a better future with better protocols for information and app distribution than "the web". In the meantime stop giving people the illusion that's all is still ok while Mozilla milks your idealist heart for money.

2025-12-15 22:48:42 UTC

- reply

I don't understand why there are still people using Firefox.

2025-12-15 15:52:00 UTC

- reply

I clearly have some things to learn from Elon Musk.

2025-12-15 11:25:15 UTC

- reply

Thank you, but before I merge this I must become familiar with the kanban stuff and be ethically ok with it. I didn't know anyone was even using that. Is there any client that does the kanban magic?
In any case it's a happy surprise to learn that anyone even noticed the mcp functionality. Are you using it? Is anyone using it? What do you use to call it? At the time I implemented it Goose was so broken it halted randomly when it tried to call the mcp, and there were no other mcp-powered agents out there, so I barely could try it.
Maybe I should expand it to just cover more generic cases then the LLM will probably be capable of doing the kanbaning itself.

2025-12-15 11:17:46 UTC

- reply

There are infinite bugs, I've fixed hundreds after I thought it was "done" and finally gave up, now I'll wait for bug reports. You can just reply here if you find any.

2025-12-15 11:15:52 UTC

- reply

@npub15qy…yejr please let wss://relay.ngit.dev and wss://gitnostr.com accept deletion requests, I was trying to delete an announcement to publish a new one with a new name but they didn't let me.

2025-12-15 11:14:17 UTC

Nostr Devtools: https://chromewebstore.google.com/detail/nostr-devtools/ogoaodeklpfbboeopebgdggammkcndcp
Get clear insight of what relays are serving what subscriptions and what events came from where.
https://image.nostr.build/e0cbb407bedfdcd3fc5e1e97e2bc85233cdd7d302cb8999442aaefb0048ddc36.jpg
Everything is filterable by arbitrary strings, groupable by relay, event, subscription or by any arbitrary Nostr filter elements (click on them, or Ctrl+click to add to existing).
https://image.nostr.build/caf6b9a04d3c2c184a7c09c8f2acb813e6d8cb25c09a8869ef020971c5debf00.png
It only captures stuff while the devtools is open, so open it first then refresh the page to use, otherwise you'll get incomplete data.

2025-12-15 01:04:24 UTC

- reply

I see what you mean now. Yes, having relays that are incompatible and serve independent purposes is indeed not the ideal or most elegant state of things possible, and I didn't predict that.
But I don't think it's as bad as you think. There is actually a lot of overlap between them. And different servers with different purposes would end up having to be created anyway, and they would either be proprietary services or we would have to standardize them (like we did with Blossom and Grasp) separately, but it's simpler for everybody if they're standardized under a relay interface that fits with other use cases automatically (i.e. a group relay can serve and ingest events to and from non-group clients, feed relays can serve the same filters as any other type of relay etc).
In other words: some extra complexity always happens in the real world, and I think we got pretty lucky here with the type of complexity you're complaining about.
Outbox was obviously in the 1.0, by the way, but with a different name. It was called "Nostr".

2025-12-14 21:30:55 UTC

- reply

I made a relay that charged for access and started working on a framework for making custom relays with arbitrary policies in early 2022: https://github.com/fiatjaf/expensive-relay
I remember using the phrase "relays must have personalities" early on too, and saying that Nostr finally realized the Mastodon vision of having communities form around servers (as Mastodon failed spectacularly on that).
I also remember getting angry at the hundreds of people who misunderstood Nostr as some kind of neutral data layer for cryptographic keys (generally the same people who are happy to just hardcode 4 relays in their apps and call it done), or people who tried to do spam prevention using any techniques that were not based on knowing some relays to be free of spam and others not, I wrote this, for example, as an early attempt to nudge the conversation in the right direction: #naddr1qq…wjvq.
I don't know why you think this is bloat. It's the opposite of bloat. I hate bloat, but relays with personalities are the only way to avoid bloat. Without relays doing custom things to prevent spam, curate content and acquire reputation we're left with megalomaniac specs for doing the same thing on the client side in a much less efficient and less personalized way (as you can see from all the bizarre specs we've seen being proposed throughout the years).
By the way, DVMs are a clear example of what happens when you start to treat Nostr as a form of neutral data layer. DMs too, probably, then in the evolution of the DM spec you see how things went, with overcomplication on the client-side in order to try to achieve some ideal privacy that in the end is only still guaranteed by the relay (NIP-17) or Marmot, which requires no comment.
Anyway: if you don't think relays should be different, then how do you account for incentives?, i.e. should every relay just accept any note from anyone or how are they supposed to filter content?

2025-12-12 23:19:49 UTC

- reply

That's the npub derived from the hex when it's interpreted as a secret key.
There's also the npub of the hex interpreted as a public key in the output.

2025-12-12 11:01:38 UTC

- reply

In the inbox commands it will read from the target's "read" relays automatically or what?

2025-12-12 04:49:55 UTC

- reply

Yes, but prettier.

2025-12-12 04:02:16 UTC

- reply

Unfortunately no because djot is really great.

2025-12-12 00:54:15 UTC

- reply

blurhash:
https://video.nostr.build/8cdb8e501507de7746210e8370d2e7427ee8ebaa4c7a44a264c9c6f387648422.mp4
thumbhash:
https://video.nostr.build/90c125f572761a56941c06448e0d696006fbf36639ab98baae067096461d300b.mp4

2025-12-12 00:46:44 UTC

https://fevela.me/ now supports https://github.com/dtonon/fevela/pull/40, which is better than blurhash. https://evanw.github.io/thumbhash/
You can see it in action on @npub1e49…sm0m if your eyes are faster than your internet.
(Or throttle the connection speed in your browser devtools network panel, this was a good idea.)
Actually after browsing through a feed of blurhashes (on Jumble) and a feed of thumbhashes I've changed my mind, I think the difference is absurd and thumbhash is not only slightly better, it's astronomically better.
@npub1syj…f6wl would you add it to Jumble? @npub1xts…kk5s please jump in the bandwagon too! @npub1n0s…lahe? @npub1gcx…nj5z? @npub1ces…t37c? @npub1yzv…rf8q?

2025-12-11 22:16:43 UTC

- reply

How many times do you live?

2025-12-11 21:47:11 UTC

#pyramid has had some updates with bugfixes since the v1.0.0 release, but there was no easy way to update the version you had running in your server that was as easy as the installation process.
Now we have the easiest thing possible, a button: https://cdn.azzamo.net/bc8fdbccbd6914cf53edd87894addcf1acce3779dae37c90c93af98a2c1baf67.png
You click and it will update your server in place.
The only catch is that you have to update manually once to get the button.
If you've installed pyramid using the easy.sh script you can do that by opening your server terminal and pasting this:
systemctl stop pyramid
cd pyramid
wget https://github.com/fiatjaf/pyramid/releases/download/v1.0.5/pyramid-exe
chmod +x pyramid-exe
systemctl restart pyramid
#nevent1q…v03m

2025-12-11 19:24:02 UTC

- reply

Crowdsourcing doesn't mean just users clicking, by the way (although that could be possible too), it means a bunch of machines competing: https://leaderboard.sbstats.uk/

2025-12-11 19:22:15 UTC

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-12-10 13:50:55 UTC

- reply

What happens? Can you send a screenshot?

2025-12-10 13:49:31 UTC

- reply

I would like to think both, but I'm not sure I did the NIP-29 part yet. NIP-43 I'm sure works.

2025-12-09 19:29:23 UTC

- reply

It supports invite codes. What must I do to give the instructions on how to join?

2025-12-09 01:58:12 UTC

- reply

What is that?

2025-12-08 23:43:23 UTC

Finally a real Nostr web client:#nevent1q…sktz

2025-12-08 22:44:03 UTC

- reply

A hard-refresh works every time for me.

2025-12-08 22:41:52 UTC

I made a new stupendous video, this time showing how to install https://github.com/fiatjaf/pyramid on a completely fresh DigitalOcean server: https://nostr.media/d1ca9bd4682054a03a228d687b90ea45ae6e71defc979c74acd409b3935cf2ee.mp4
Just because the first one wasn't clear enough.
I don't recommend DigitalOcean specifically (nor I have anything against it), it was just the most plain generic VPS provider I could think of.

2025-12-08 16:29:39 UTC

- reply

You should have tagged me! It took me 18 days to notice the bot was broken.
Satellite images upload API stopped working and this is running on a shell script, so there was no error handling.

2025-12-08 13:57:10 UTC

- reply

This is pretty easy: #nevent1q…5zkr

2025-12-07 20:26:11 UTC

- reply

That's fine, specifically because no one really follows more than 400 people. When they have more than that it's because they're interested in some "trends" more than the actual specific people, so relay feeds with whatever algorithms would be a much better choice.
Eventually users will have to learn too, they can't just expect things to work the best way for them without no work (and it can't be argued that such approach works on centralized platforms, it doesn't).
(Still, I think normal outbox will work fine with any number of users as long as you have a local database that is proportionally big and a syncing process that is slow and patient.)

2025-12-06 18:06:03 UTC

- reply

I see what you mean. Yes, one of the advantages of the Jumble model is that it allows for that kind of customization, and if it's clear to the user that they're browsing a relay and not the abstract concept of their following feed then I see it as pretty much ok.
I was thinking that you wanted to get rid of the following feed and proposing that Nostr clients switched entirely to this other model (rather than just adding a feature for browsing relays).

2025-12-06 17:31:46 UTC

- reply

And I'm telling that once you go through the centralization route because, the steps I enumerated will follow and eventually you won't be able to do "posting", "replying", "reacting" etc in the outbox model because it will not work (and won't matter either).

2025-12-06 17:29:41 UTC

- reply

Are you saying that going from connecting to the dozens of relays from people you follow to connecting to a single relay hosted by a big provider isn't a change in the model?
Or maybe you're just trying to step back and say that "some people may do this, others may do that", which is more reasonable, but still a bad idea, as you would have to have clients specialized in one model and clients specialized on the other model and one of those would end up winning, and since it looks like you're cheering for the single-relay-big-provider model to win I'm telling you it's a bad outcome that makes no sense to cheer for.

2025-12-06 16:56:09 UTC

- reply

You also assume that using that scheme Nostr will (perhaps naturally) get more decentralized and more people will use different relays, but we have no reason to expect that to happen under those circumstances. The incentives are completely in the other direction:
1. people don't want to run servers (otherwise Mastodon would have been a success)
2. people flock to a few relays that provide this "outbox-on-the-server" service for them
3. doing outbox-on-the-server is actually much harder than on the client, and impossible at scale because of relay filter ratelimits, this leads to these servers actually just giving up the outbox model and syncing with some other selected relays, which creates other types of centralization pressure on the publishing side
4. it also creates another type of centralization pressure, which is the specialization of these "aggregator servers": instead of serving a normal relay interface they are more likely to start serving some pre-processed GraphQL queries or something like that to make clients even easier to write for incompetent LLMs
5. now the barrier to running one of these aggregator is higher, which leads to less entrants
You get the idea. If we get to the end of the story we'll have like 2 or 3 of these big aggregators, with 90% of people in one of them (but even if we had 50 that would still be ridiculously centralized and censorship-resistance becomes a joke).
I don't see why we would even get to end of the story though, because why would such a broken protocol be attractive to anyone? What are its discerning features? Why not use X or Bluesky?

2025-12-06 16:46:43 UTC

- reply

There are many issues with that idea.
The outbox model is maximally decentralized as each person does their own fetching. To achieve anything close to that using your idea would require one of these read relays for each user, i.e. each person running their own server.
How close can we get to an outbox-model level of decentralization using that strategy? If we're generous and consider that for every 10_000 users there's 1 that will be ok with running a server then we'll be 0.01% as decentralized as we can be already today with basically no extra cost except for some slightly harder implementation details.

2025-12-06 00:42:13 UTC

- reply

https://web.nostr.technology/#nostr-note, but you have to style it using CSS ":part()" selectors. Or you can pass your own template that gets filled with the data.

2025-12-04 11:22:11 UTC

- reply

I'm such a happy person:
https://image.nostr.build/5c02a42f8b7fd90cb0674979369d410c846ecabe5d2cc3085f829c00cd962bc2.jpg

2025-12-04 09:05:24 UTC

I just set up a group for pyramiders. Please join if you are interested in building a pyramid: https://chachi.chat/pyramid.fiatjaf.com/Tnq7x2ZTgrPZWFrC
Bug reports, questions and comments are welcome.
The group is hosted on wss://pyramid.fiatjaf.com/ so if it even works it's already a success (I didn't test on Flotilla or 0xchat).
#nevent1q…u2qk

2025-12-03 18:59:41 UTC

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

2025-12-03 18:28:23 UTC

- reply

If you know what is your desired "state" (as represented by the kind:30618 event) you just push it everywhere and do the git push afterwards (that's what `nak git push` does), so 2222 will just catch up automatically.
The concept of "force-pushing" isn't really a thing from the grasp server perspective. The grasp server will accept any pushes that match the signed state they received.
Essentially the --force flag only exists to discard the client-side default safeguards against overwriting the state that you have locally.
To answer your question: if you force-push once while 2222 is down you won't need to force-push again after 2222 is back online.

2025-12-02 18:59:13 UTC

Here's a screencast video demo/explanation of GRASP with `nak git`, for all you that are eager to hear my voice: https://cdn.azzamo.net/39fabbda2e3932d2c5e8d552da13c92788ec1f0cd0c18ea6766f31964e519ec8.mp4

2025-12-02 18:29:35 UTC

- reply

Yes, it does!
I didn't have certbot or anything running, I say in the video that that was a completely new VPS.
This is why we need a better video.

2025-12-02 17:36:08 UTC

- reply

Did you watch my video? The certificates are automatic, no one has to think about them.