fiatjaf

https://stuff.fiatjaf.com

I do not have an X account

Public Key

npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6

NIP-05 Address

_@fiatjaf.com

NIP-57 Address

npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6@npub.cash

Profile Code

nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gpr9mhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5q3yamnwvaz7tmhda6zuat50phjummwv5wpz56m

Publishing to

pyramid.fiatjaf.com

wot.utxo.one

relay.westernbtc.com

Author Public Key

npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6

Show more details

Last Notes

2025-07-14 16:18:19

- reply

Imagine what would you think if you wrote there that Bitcoin is great but got a "community note" that stated that, in fact, Bitcoin is bad for such and such reasons.
They are incredible preposterous and condescending, and who the hell is the "community"?
Also X does censor a lot of people. Stop buying these "don't censor" fake news from Elon lovers.

2025-07-14 16:06:25

Some form of "moderation" is absolutely necessary if you want any open space to remain usable by good people.
And shared blocklists are a completely inefficient solution, it belongs more to the domain of "p2p-like ideas that are very cool but do not work at scale".
The only solution I can see is to do it with smart relays that the users choose to act on their behalf, relays with clear policies, reputation and name-recognition, community relays etc -- all interchangeable, of course, and easily swappable on the client side.
Muting people or hiding posts from people outside of your WoT can good solutions to catch anything that slipped through relays, but they cannot work in an actually adversarial environment without destroying the experience in multiple different ways.
#nevent1q…pkus

2025-07-14 15:53:41

- reply

I think your imagination is lacking. But if you can paint to me how that scenario appears on Nostr I'll be glad to hear.
Twitter Content Moderation is both impossible and completely unnecessary on Nostr.

2025-07-09 02:13:54

Just made a website which tracks nostr projects I've created that are approximately useful: https://stuff.fiatjaf.com/
Maybe they will be approximately useful to you too.
This is only a little bit inspired by:
#nevent1q…d5ph

2025-07-08 10:48:36

- reply

To talk about stereotypical "Nostr users" is to reinforce the problem.

2025-07-08 10:31:31

- reply

It's not a closed group at all. Unless you assume everybody who gets a grant immediately becomes part of the group, then it is by definition a closed group at any point in time.
Anyway, you'll have to open-source your stuff if you get a grant, but if you want to show it to me first I'll appreciate that too. Send me a NIP-17 DM.

2025-07-07 23:19:10

Maybe following people is overrated.
It's totally doable to use Nostr by just following relays instead. You can get a very nice and well-curated feed today by just browsing wss://nostr.wine or wss://pyramid.fiatjaf.com -- and this is because basically no one even knows or is aware of this mode of doing things and we don't have the relay infrastructure necessary to enable such flows, so it has a lot to improve.
Maybe we should really only be following at most 50 people each, only the people we want to ensure we will not lose sight of, and people who have been banned or inhabit a different ecosystem (of relays) than the one we frequent the most. Aside from that just following a bunch of relays, either grouped together or in different tabs.

2025-07-07 21:37:28

- reply

You mean https://github.com/fiatjaf/narr? I had forgotten that one.
That was one of those bounties, but then his pull request to the base project (yarr) was rejected, so I renamed it, fixed and changed some things here and there and released it under my name (because the guy who got the bounty didn't want to do it even though I asked him to).
I'm not sure what else I could have done. Perhaps abandoned the unmerged Nostr branch of yarr forever? Would have that helped anyone?

2025-07-07 14:06:53

Many people external to Nostr perceive it as a single community of "crypto" or Bitcoin lovers.
People inside Nostr also feel like they're in a very warm and friendly "community" too.
One perception probably reinforces the other, and both damage the idea of Nostr as a neutral, open protocol that can accommodate any type of community.

2025-07-01 15:47:09

`nak bunker` should now persist your authorized pubkeys, secret key and list of relays, so you can do something like `nak bunker --profile myself --sec ncryptsec1whatever relay.nsec.app khatru.nostrver.se` once, then later `nak bunker --profile myself` and it will keep your previously authorized client connections working.
Please report bugs.

2025-06-28 16:28:39

- reply

I'd say it's extra complexity that is not really solving any problem we have. Nostr is already pretty resilient against DNS issues.
But if someone is really out to get someone and Nostr isn't good enough then DNS isn't much worse than the entire IP protocol that relies on one central registry and hierarchy of addresses that is very permissioned.
If we are to spend efforts on this layer then I'd rather go for the entire IP thing and make it possible for networks to be assembled in decentralized and permissionless ways using local cables and wireless infrastructure, then merge together forming an ever-growing parallel internet, with decentralized routing that scales globally.
This is my idea: #naddr1qq…smcd
But, if Nostr is already struggling to get a few users and not be irrelevant, imagine something like this.

2025-06-27 19:49:53

- reply

Coop only does NIP-17 and NIP-17 is very clear: just giftwraps, NIP-44 and you must send the message specifically to the announced DM relays of the other person and receive messages at yours, so there is really no room for confusion.

2025-06-26 16:07:18

- reply

That's what Frostr does.
My assumption is that it's worse because it creates this requirement on all clients, while the Promenade bunker works anywhere with a generic interface. It's faster also in theory because signers are already connected directly to the coordinator.
See #nevent1q…5a5u
But yes, if everybody agreed and all apps included this coordinator then it would be technically better. We'll need a strong standard for it and bully everybody to support it.

2025-06-25 02:16:27

- reply

You should have never revealed your nationality. Now I'm paralyzed and can't reply to your DM.

2025-06-24 19:24:24

- reply

We don't have many users or developers.

2025-06-23 13:43:48

- reply

That can be argued against hashtagging too. Labeling is already strictly better than that.
Many people like to curate and categorize things, and, as I said, reactions are already that to some extent except they are more cryptic, uglier and less useful.
And there may be other benefits, I'm just saying there is room for experimentation. We can also watch to see what Pubky does and perhaps copy them later.

2025-06-22 22:28:00

- reply

No need for those complicated attacks, the protocol itself is a vulnerability already: @npub1l8w…6m2c

2025-06-22 15:09:47

https://i.nostr.build/CRWltdSr3mX2hRbP.png
The Pubky app has one thing that at least looks interesting: this tagging stuff with words.
It's the only useful feature of NIP-32 that is underexplored on Nostr.
Thinking about it's very similar to what people have been doing with emoji reactions here and in many other apps, except for the fact that emoji reactions are stupid, undecipherable and useless and emojis are one of the lamest inventions of the internet.
Also self-tagging posts is stupid, it's much better to allow yourself or anyone else to add tags after the fact instead of requiring the post creator to somehow figure out the best tags forever for their post at creation time.
But, again, even with NIP-32 tagging of posts we still cannot do "trending tags" or "hashtag feeds" without relying on relay native filtering capabilities, otherwise it will always be a slugfest.

2025-06-20 14:48:18

- reply

That part is irrelevant, who cares. The sad part of it is that they don't allow updating the text to actually explain how the protocol works.

2025-06-20 14:39:52

@nprofile…3k9m can you please stop following the fake "fiatjaf" on X? You're one of the last few high-profile accounts lending some cred to the scam.

2025-06-20 11:52:18

- reply

Is that really what we need? To lock people's access to things in their phones that can be lost or break anytime? Or they (and services) have to go through infinite undocumented hops for things to work in other ways?
Besides that it's proprietary technology with a 300-page or more spec that is impossible for normal people to implement but they try to sell it as an open protocol or something.

2025-06-19 22:35:28

- reply

The only way "-" can do is if you put its access under AUTH for specific use cases that exclude most people and necessarily exclude the aggregators.
Oh, it also works in reverse, if you control/trust a relay and want to ensure that it will be free from non-"-" events.
Otherwise it's impossible to prevent the aggregators.

2025-06-18 00:16:45

- reply

These are fine ideas in theory, but the amount of complexity and necessary code and network-effect they would require in practice should be factored in your thinking.

2025-06-18 00:06:29

- reply

What do you want to use Torrents for? This is about Git repositories, not filesharing.
I like torrents, I experimented with making torrents the default for Nostr image sharing but they would never gonna make it because HTTP image download is just magnitudes easier. Blossom makes these HTTP links more resilient and safer, optionally.

2025-06-18 00:03:11

- reply

To be fair the write-up on that page is not the clearest possible. I think @npub15qy…yejr may be working on a better protocol description.
The idea as far as I know is just that there may be many Git servers anywhere -- like Blossom servers -- that host repositories from anyone (maybe they'll ask for a pre-payment, maybe they will have a free quota for some Nostr users and so on) that you can just push your repositories to. And your pushes are pre-authorized by publishing a Nostr event beforehand that says what is your repository state (branch=commit, HEAD=branch or something like that).
Then when announcing your repository you can include multiple git+http URLs to these servers that people can clone the project from. And Git-enabled Nostr clients can contact these servers to download and display source code and Git history data.
It's a very simple idea but a very powerful one.

2025-06-17 23:08:21

This is the best idea since Blossom.
If I understand it correctly the plan is to create a cloud of servers that host Git repositories and that each programmer can be affiliated to (just like you can do with Blossom servers) and they will host all your Git repositories (such that if one of them is down the repositories can always be found on the others) and everything is automatically addressed and authorized using Nostr keys, repositories are discovered using Nostr events and the magic can work easily.
I've been trying to self-host my repositories at https://git.fiatjaf.com/ for a while now, and keeping the server running and safe from the aggressive AI crawlers has been a challenge. My intent was to make a nice self-hosted server with a NIP-34 integration so people could send patches (the biggest hurdle these days when using anything to host your code except for GitHub is that it's too hard for external people to contribute), but that integration was never finished and I couldn't even focus in getting the "self-hosted git" part good enough. The truth is that, even with the best self-hostable software ever, still most programmers wouldn't run it.
I had hoped that someone was going to make a service that hosted repositories on behalf of others, and that NIP-34 integration would make that automatically interoperable and easy for external contributors, thus removing the network-effect that GitHub has and enabling competition between multiple providers. @npub1myg…sn5p had hinted at building something like this at some point.
That could have worked, but at least problems would have remained: even if repositories were addressable via Nostr, the URLs of the git repositories would have remained too important and fragile, and so people would have still become more-or-less dependent on these services and on DNS; that and it would still be a hard thing to send any contributions to repositories that didn't fit in a "patch" Nostr event.
The natural solution for the big patch problem is to have your changes pushed to your own Git server as a branch, than propose that as a change to the base repository, asking the owner to pull them from your server and merge them upstream. We can call that a "merge request" or "pull request" if you prefer. But before this new revolutionary idea from @npub15qy…yejr that flow would be arcane and hard, but if we have a new Blossom-like protocol that makes it easy and straightforward to setup new Git repositories and push branches, all automated, pre-authorized and authenticated with Nostr events, the problem becomes as easy as uploading an image.
At the same time I don't have to worry anymore about making a nice self-hostable Git server with code browsing HTML UIs and all that stuff: now Git servers can be basically headless and the job of browsing code and patches and whatnot can be entirely delegated to NIP-34 clients.
We can kill Radicle now.
#nevent1q…mw99

2025-06-17 20:12:54

- reply

There is basically no data that supports the crazy theory that small mutations and natural selection create the enormous macro-evolution that darwinists think they're explaining, the fossil registry is very clear. The main theory is full of holes, paradoxes, unexplained oddities, ad-hoc fixes that defy reason, and it still falls much short of achieving what it intends to. Even Lamarckism has to be invoked these days to save Darwinism.

2025-06-17 20:07:30

- reply

I don't have any power to change the protocol, all I can do is create a new protocol with different rules and I don't think that would help anyone.
Also dynamic keys introduce too many complications that ultimately make Nostr suck.
There are solutions to make our single keys safer. The main solution is called the bunker. And there are solutions to make it so that losing your main key isn't as bad as it may be currently. These solutions do not require creating a new protocol.
Also any scheme that involves key rotation or whatever still requires the concept of a "master" key. And that key has to be kept secure anyway, so you're really not solving anything.

2025-06-17 20:02:04

- reply

I don't know how to do that or even what you're talking about!

2025-06-17 19:42:29

@nprofile…49mr can you do Android and iOS apps with gpui?

2025-06-03 21:54:34

Darwin was wrong and Jesus did not exist.

2025-06-03 21:38:30

https://blog.tangled.sh/stacking @npub15qy…yejr @npub1use…k5ks this is interesting.
Could this work more-or-less automatically under NIP-34 by just making patches refer to previous patches with tags? Without using any martial arts?

2025-06-02 01:12:27

- reply

It's very hard to make a proper client that doesn't take shortcuts that undermine the entire point, and JavaScript and browsers are a magnitude slower than what a proper native client should be.
Have you tried Gossip?
Still, it should be possible to do reasonable web clients if you buy into the correct architecture and don't try to vibecode the logic.
I still think Coracle is pretty good. Jumble I like too, but I only use it to browse relays directly -- which is a much easier flow to implement than an outbox-powered "following" feed. Recently I'm playing with https://wip.alphaama.com/ and I like the style, it feels fast enough.
But I must reiterate that all of these still feel slow in comparison with a native client, but they do _not_ feel slow in comparison with almost all other websites on the web, everything is crazy slow, including X and centralized platforms. I've basically given up loading websites on my phone.
I wish all these web developers spent a week with a computer and a cell phone that wasn't the best of the best just so they could contemplate their life mistakes.

2025-06-02 01:04:18

- reply

I didn't get your mention on my inbox relay, by the way, I'm seeing it now by accident elsewhere.

2025-06-01 21:50:58

- reply

Seems to work correctly, I like it.
Can I get your opinion on https://github.com/nostr-protocol/nips/pull/1647?

2025-05-31 01:39:02

- reply

.aa u setup
.aa r add wss://nos.lol read write, wss://relay.damus.io read write, wss://relay.primal.net read write
.aa q stuff
reload the page.
.aa q out f
click on the small "e" at the top-right to see your outbox-powered following feed.

2025-05-31 01:35:50

alphaama is back!
https://i.nostr.build/EqAR02jrIGM8YV81.png
https://wip.alphaama.com/

2025-05-30 23:56:46

- reply

What if instead of an exact number per hour some relay wants to do a token bucket thing or whatever other method?

2025-05-29 03:22:43

So I made this IndexedDB event store thing that is somewhat insane but kinda works: https://jsr.io/@nostr/gadgets/doc/store/~/IDBEventStore
It seems to be significantly faster than the SQLite-based worker relay according to these amateur benchmarks: https://github.com/fiatjaf/js-eventstore-benchmark
But even if it was slower it could still be a good option because it's pretty easy to use, just import the library and save events, query with a filter, done.
Please let me know if it's completely broken.

2025-05-28 23:34:26

- reply

Satisfactory.

2025-05-28 02:44:13

https://www.youtube.com/watch?v=GWjDUEsD6lU&list=OLAK5uy_kx_eKDqDqSIhjWh-cv_Ob0_sHRXAFnvj8

2025-05-28 01:34:48

A single one of these files has actual code in them: https://aegis.utxo.one/839c7a09911e2b01ddadbad607cb275863d3ab70bdc447ce90239ead691930f4.png

2025-05-27 21:51:41

- reply

A local signing key introduces too much bloat everywhere.
But a local key dedicated to encryption would be the ideal, I think: https://github.com/nostr-protocol/nips/pull/1647

2025-05-26 18:49:13

- reply

Não faço idéia de como funciona essa extensão aí, o código dela não é aberto.

2025-05-26 15:31:50

- reply

I remember that opening a file in my old hard disk being drastically slower than opening the same file from the internet some years ago, and the internet wasn't even that great. Maybe my disk was worse than normal too, I don't know, it was very old.

2025-05-26 15:27:52

- reply

Still? It's been 18 years!

2025-05-20 18:03:53

- reply

[insert rant about DHTs]

2025-05-19 20:19:19

- reply

On Coracle there is clear visual feedback.

2025-05-19 18:37:18

- reply

Coracle already fixes the URL on behalf of the user, which is the correct implementation if you ask me. Damus also does this at least in part, and others I forgot. I think it's going to be well.

2025-05-19 12:14:29

- reply

The only problem here is that your list advertises a bunch of relays but you're not publishing to all of them, only to some.
No client can connect to all these relays to fetch your notes, they generally connect to only 2 or 3 or 4. And it happened that the 4 (?) Jumble connected to didn't have any notes newer than from September 2024.

2025-05-19 01:50:35

- reply

This is definitely a client flaw on the part of @npub120r…x44g's client since he is advertising publishing to 12 relays, but he actually only publishes to the 4 big ones.
What client are you using, @npub120r…x44g?
In my library I've decided that people who advertise more than some number (I think it's 8 or something) of relays are clueless and their relay list shouldn't be trusted, so we default to reading from the big hardcoded relays from them.

2025-05-18 16:58:09

- reply

He wasn't looking for a solution for him personally, it was a comment on the general state of these platforms.

2025-05-18 16:56:12

- reply

I have written about the general idea of "value for value" before. I think it's just a marketing term for donations, and donations are not new nor revolutionary.
See
#naddr1qq…8903
I've also wrote extensively about DVMs, they're just a bad framework for selling API services, and the economic viability of these must be analyzed on a case-by-case.
In short: it depends.

2025-05-18 16:52:37

- reply

No. I don't know what you mean by that. It's better to talk about more specific examples, I don't think economic incentives -- when spoken about in a general sense -- are a good thing in social networks.

2025-05-18 16:49:58

- reply

This doesn't even make sense as an analogy.
But I wouldn't have expected a reasonable take from you anyway given the way keychat deals with relays.

2025-05-18 16:41:55

- reply

Nowhere.

2025-05-18 16:41:29

- reply

Facts are not arguments. People do what they need to achieve their goals.
The same rationale you're using could be used to defend edits, markdown, bbcode syntax, whatever. As long as enough clients support these things people will start doing them, then you can start claiming it's not realistic to remove support.

2025-05-18 16:35:20

- reply

It's not possible, but publishing then quoting like you're doing is a much better flow anyway.

2025-05-18 12:37:24

- reply

I think it's an idea worth pursuing if you think you can bring new better stuff to the table, but on the other hand it goes against all my (not super strongly held anyway) principles, so I don't know what to say about it.

2025-05-18 12:34:53

- reply

In other words: if relays are not the right abstraction for publications I'm interested in learning what new things relays are a good abstraction for -- and how these new things can be better than old style publications.

2025-05-18 12:33:35

- reply

I'll wait for you to solidify your understanding, and maybe I don't know what a "publication" entails anyway (because I have no experience with that) and that specific thing is better done with a dedicated keypair or something, but that doesn't change the fact that relays are the unique Nostr superpower (and that we don't have any other superpower, so we should use that one wisely).

2025-05-18 03:02:16

- reply

You would like to have met @npub14lu…7m8m:
#nevent1q…scvg
But with that said I also think, like @npub1t6j…ksrw below, that following people directly is an important feature -- even though, as you said yourself, that is just automating the work of going to a relay and asking for posts of such and such. That's kind of the description of the "outbox model", but also I do agree it should be made more explicit in UIs and that ultimately extreme configurability should be an option.
The user should be able to say, for example: "I only want the posts from Bob that he publishes on the astronomy relay, even though he is also publishing stuff to other relays".

2025-05-18 02:55:30

- reply

There is no guarantee of anything anywhere, much less on the internet. Most good faith relays will probably respect "-" (and currently all the big ones do), but "piracy" exists and I'm not even saying that's a bad thing.
I don't believe in "intellectual property" myself, but "-" is not (only) for preventing copy, it's for making intentions explicit and keeping content and boundaries organized, which benefits everybody most of the time.

2025-05-18 02:52:30

- reply

https://zapbox.fiatjaf.com/ is kind of pay2read.
If someone is browsing your relay directly instead of just specific notes or specific pubkeys you can also serve ads by just hosting them as notes.

2025-05-18 01:10:58

- reply

What else will you abstract? Just abstracting login is not enough to justify this. Login is easy with bunkers and something like window.nostr.js.
Or even if you don't think it is, that's the same thing the Spring browser tried to do, and you could do it on a platform by rehosting web clients and force-including a window.nostr global that implements NIP-07 even for people that do not have an extension, and done.
But why?
I think it could be more interesting if you done something different like abstracting the UI and providing all apps with a homogeneous theme, or doing what I said on the note above, or perhaps also abstracting relay pooling, connection and selection and smart relay picking on behalf of apps, I don't know.

2025-05-18 00:56:34

- reply

You're not alone in thinking that: #nevent1q…ez6l @npub1rau…dees
Turns out relays are a great abstraction, infinitely flexible and easy to use and reason about. Relay feeds and other types of custom relay usage could be the thing that differentiates Nostr from all other Twitter clones and are vastly underexplored today.
One example that does one form of "curation" today is #nevent1q…afg2
Try also wss://algo.utxo.one, but we need more!

2025-05-18 00:47:37

- reply

Turns out that involves a ton of complications like keypairs.
But I agree.

2025-05-17 22:11:56

- reply

How are these apps going to be written? Are you trying to make a browser? I hope it's not just wrapping Chrome and asking people to write JavaScript.

2025-05-16 14:27:35

- reply

Would they also deem cars illegal if they were introduced today or not?

2025-05-16 14:25:17

- reply

The OS will try to open something? No, the app will parse that much more easily and display the quoted event, or turn it into a link of its choice. There are literally no downsides. It's super easy for the client that is publishing the event to automatically prefix quotes with a `nostr:`.
But if the normal thing is to expect all clients to parse all nevent strings for all events ever that is unnecessary overhead that literally overheats the planet much more than necessary.
What is next? Expecting clients to also go through all of the events' contents multiple times with a huge list of TLDs or an infinitely slow regex to try to find URLs because publisher apps can't be bothered to prefix URLs with `https://`?

2025-05-16 14:11:42

- reply

Yes, please stop creating totally unnecessary and avoidable protocol bloat.

2025-05-13 15:54:32

Graphviz is still great.

2025-05-12 23:41:36

- reply

I've answered there, thank you very much.

2025-05-12 23:31:01

- reply

I switched to that today and it's actually quite good, better than the other. I switch to wss://relays.land/spatianostra and wss://algo.utxo.one too but they're too low-frequency so they don't give me the impression that next tweet will contain revolutionary disrupting incredible news about something completely good and unexpected.

2025-05-12 19:04:09

- reply

Macau spotted.

2025-05-09 11:00:49

https://relays.land/ now has an option to create moderated relays.
Moderated relays accept any events, but events only become publicly visible when manually approved by a moderator. Approval can be given either through the relay web dashboard or using NIP-86 methods.
Is this what was needed for moving the bitcoin-dev mailing list to Nostr?

2025-05-09 04:08:24

- reply

Instead of "EVENT" the message must be "AUTH".

2025-05-08 21:00:59

- reply

I didn't mean custom implementation for this purpose, I think you can probably do better with a custom relay implementation.
I mean, if it's already custom you can assign a serial number to each event and map those numbers to real events in a custom database. Then convert those numbers into single or double-word mnemonics for users.
Or is that boring, doesn't contain cryptographic tricks, centralized? Maybe it is, but I think boring is good and centralized is fine as long as it plugs into the rest of the Nostr ecosystem.

2025-05-08 19:44:26

- reply

I should probably remove myself from the voting pool, I never vote on anything anyway. I tried for a while to force myself, but I can't. At this point I'm just preventing notes from being accepted.
To whom should I give my shares? Or should I just delete them?

2025-05-08 19:41:11

- reply

Technically can't find an event even if you have the full ID anyway, because you don't know the relays the event is in. That's why we have nevent1 codes and relay and author hints in tags.
Choosing the relays for each client action is the most important part of Nostr but people have assumed that part away way too many times by hardcoding popular relays and expecting all events to be there, which works as long as we're ridiculously small, but kills the value proposition of Nostr entirely.
It's like assuming Bitcoin will always be zero: it's only true if the entire project is a failure, and in that case nothing matters anyway.

2025-05-08 19:36:24

- reply

It's just unnecessary complexity. REQ filters are already too powerful, they should be simpler. The use cases are marginal and never important, often just "cool". They can all be implemented using custom relays with crazy logic, which is what we should be doing anyway for many other things.

2025-05-08 16:12:45

- reply

Voting is working again, another stupid bug. Thank you for insisting.

2025-05-08 15:13:35

- reply

@npub1utx…50e8 is underdelivering.

2025-05-07 19:30:22

- reply

Sorry, I'll turn it into a CLI tool as soon as possible.

2025-05-07 10:41:51

- reply

Must be a caching issue.

2025-05-07 02:02:27

- reply

What did they do?

2025-05-07 01:54:52

- reply

We're at a point I'm almost liking any note.

2025-05-07 01:49:21

- reply

Let's do CBOR then.

2025-05-07 01:48:09

- reply

Actually there is a bug: the relay favicons don't load, nor their icons. Except for one. The wss://pyramid.fiatjaf.com/ for sure should load, right? But it doesn't.

2025-05-07 01:46:50

- reply

I've just used Flotilla for 2 minutes on wss://pyramid.fiatjaf.com/ and couldn't find any bugs. This must be the first time in history something like that happened with a Nostr app, so definitely this is a v1 release. Actually you should make it a v2, v3, v10 already. And never touch the code again.

2025-05-07 01:40:01

- reply

That's an attack on Bitcoin in two fronts.

2025-05-06 18:32:11

- reply

I always use Bouquet, but lately it has been saying I don't have Blossom servers configured and trying to get me into some default ones, it's weird because if I click around it generally realizes I do have servers configured and allows me to just upload.

2025-05-06 13:35:13

- reply

You're evil.

2025-05-06 13:34:11

- reply

You can use environment variables maybe? $NOSTR_SECRET_KEY is used by default by nak if nothing is specified, but you could just use arbitrary environment variables while constructing your commands.

2025-05-06 13:32:31

- reply

The functionality was merged into nak.

2025-05-06 04:14:32

- reply

@nprofile…u2lh --confirm flag is here too if you want to test.

2025-05-06 04:13:45

- reply

Well, Coracle has broken my example non-URLs and non-Nostr URIs by changing them to rich text at read-time. @nprofile…7pju please fix.

2025-05-06 04:11:41

- reply

Then you can do stuff like
echo "#surely you're joking, mr npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft olas.app is broken again" | nak publish
It will add the hashtag, turn the npub1 code into a nostr:npub1 URI, turn the olas.app string into https://olas.app, add the "p" tag (and "q" tags too if you were mentioning an nevent1 code or naddr1 code) and finally publish it to your "write" relays and to any mentioned person (or author of mentioned events)'s "read" relays. There is also a --reply flag that you can pass an nevent, naddr or hex id to and it will do the right thing (including setting the correct kind to either 1 or 1111). And there is a --confirm flag that gives you a chance to confirm before actually publishing the result to relays.

2025-05-06 04:02:35

- reply

What do you mean by "test"?

2025-05-06 04:02:12

@nprofile…58km "nak publish" should work if you install it from this commit:
go install github.com/fiatjaf/nak@67e291e80dace3dd8c10252b4a3c8b4363afc894