fiatjaf

I do not have an X account.

Public Key

npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6

NIP-05 Address

Profile Code

nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhyetvv9ujuam9wd6x2unwvf6xxtnrdakszrthwden5te0dehhxtnvdakqd2jg2h

Publishing to

Author Public Key

npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6

Show more details

Last Notes

2025-07-10 02:12:57 UTC

Reporting bugs on Coop is very good, @nprofile…k7sq not only fixes all of them, he also replies with a video showing the new behavior working, like on https://github.com/lumehq/coop/issues/76#event-18556330014
https://cdn.satellite.earth/f63fd9cc25cb236a5c0cae9ffb9859468d0c7efae6e3e9d039321113ee1489b1.mp4

2025-07-09 02:45:55 UTC

- reply

ahahah

2025-07-09 02:37:26 UTC

- reply

I see a guy wearing VR glasses and crushing some fools.

2025-07-09 02:35:29 UTC

- reply

I'll see him in court, the abject plagiarizer.

2025-07-09 02:13:54 UTC

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-07 23:51:58 UTC

- reply

I wonder if Jack had coded Samiz in a weekend it would have been mostly ignored by the press like what happened with all his other Nostr-related endeavors and even Bitcoin ones.

2025-07-07 23:46:45 UTC

- reply

YOU'RE WELCOME @npub1gcx…nj5z, and this was funny but just a note to anyone confused here: I'm not saying the outbox model is useless at all, it is fundamental and necessary and everything I say or think about Nostr assumes outbox. Nothing can work without outbox.

2025-07-07 23:21:08 UTC

- reply

Other relays to try today: wss://relays.land/spatianostra or wss://algo.utxo.one or wss://140.f7z.io (again, this is early).
Relays that do automatic curation, manual curation, relays that slurp data from others and filter them, relays that belong to closed or closed-ish communities, relays that have weird incentive models to get people to post. There are many unexplored possibilities.

2025-07-07 23:19:10 UTC

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 14:06:53 UTC

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 UTC

`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-29 11:43:03 UTC

- reply

Thank you, but you explained too much and I still have no idea of what is the job of the client and what is the job of the user in this case, concretely.

2025-06-28 12:07:25 UTC

- reply

The "wisely" bit is doing a lot of work there.
Menial digital labor is the result of software and programming in general not having been used wisely. Probably because most software developers have no experience with anything in the rest of the real world and mostly do not care about the stuff they're building.
AI is just making that worse so far.

2025-06-27 11:12:50 UTC

- reply

You're still not getting my messages, right? @npub1zfs…w445 please fix!

2025-06-27 10:47:11 UTC

- reply

It is perfectly rational to dislike when someone has 10 items and wants to give each a unique identifier that is a number larger than the number of atoms in the universe.

2025-06-26 16:07:18 UTC

- 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-26 01:00:29 UTC

@npub1syj…f6wl is it time for you to set-up NIP-17 DMs for yourself? (Don't worry, this isn't a Jumble feature request).
If you think it is then I recommend https://github.com/lumehq/coop (compile from source).

2025-06-25 12:02:31 UTC

https://chachi.chat/

2025-06-25 02:45:00 UTC

- reply

Couve wallet will be huge in Brazil.

2025-06-25 02:16:27 UTC

- reply

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

2025-06-25 02:09:07 UTC

- reply

I've given plenty of explanation, wrote many notes about it. You may have not read them because maybe you don't follow me or your client didn't bother to fetch them from my relays.

2025-06-24 19:24:24 UTC

- reply

We don't have many users or developers.

2025-06-24 11:25:51 UTC

- reply

I have many plans for fixing bugs and adding things but couldn't yet. Maybe I should just migrate to fritzer?

2025-06-23 19:52:12 UTC

- reply

I see your point, but that's such a small thing to question my judgement for. At least you agree with me that Lightning is a bad idea and that we should activate BIP-300 tomorrow?

2025-06-23 19:28:25 UTC

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

2025-06-23 19:17:43 UTC

- reply

NIP-32 was created from discussions related to NIP-56 already, by that same reasoning I imagine.
I have no idea of how to do the graperank thing already, even less if one is supposed to input arbitrary tags, but if such a thing is possible than I can only imagine it will be great.

2025-06-23 13:43:48 UTC

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

- reply

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

2025-06-22 20:16:22 UTC

- reply

What did I say that made you consider my judgement and why?

2025-06-22 15:09:47 UTC

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 UTC

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

@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-19 22:35:28 UTC

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

- 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-17 23:08:21 UTC

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 UTC

- 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-03 21:54:34 UTC

Darwin was wrong and Jesus did not exist.

2025-05-31 01:39:02 UTC

- 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-29 03:22:43 UTC

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 UTC

- reply

Satisfactory.

2025-05-28 01:34:48 UTC

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

2025-05-27 21:51:41 UTC

- 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-27 02:00:35 UTC

- reply

ahahahah

2025-05-26 18:49:13 UTC

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

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

- reply

Still? It's been 18 years!

2025-05-19 20:19:19 UTC

- reply

On Coracle there is clear visual feedback.

2025-05-19 12:14:29 UTC

- 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-18 16:52:37 UTC

- 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:41:29 UTC

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

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

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

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

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

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

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

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

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

- 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-17 22:11:56 UTC

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

- reply

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

2025-05-16 14:25:17 UTC

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

- reply

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

2025-05-12 23:41:36 UTC

- reply

I've answered there, thank you very much.

2025-05-12 23:31:01 UTC

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

- reply

Macau spotted.

2025-05-09 11:00:49 UTC

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

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

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

- reply

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

2025-05-08 15:13:35 UTC

- reply

@npub1utx…50e8 is underdelivering.

2025-05-08 15:11:58 UTC

- reply

Apparently Gossip was also the only that replied to the correct place, wss://inbox.fiatjaf.com, and not to wss://lockbox.fiatjaf.com.

2025-05-07 10:41:51 UTC

- reply

Must be a caching issue.

2025-05-06 13:32:31 UTC

- reply

The functionality was merged into nak.

2025-05-06 04:02:35 UTC

- reply

What do you mean by "test"?

2025-05-06 02:42:47 UTC

After a brief interruption, this bot is back and catching up:
#nevent1q…s6pd

2025-05-06 02:13:00 UTC

- reply

Why all this sudden interest in BUD-04?

2025-05-06 00:57:26 UTC

- reply

We don't support it, yes. Give me some time, please. We're in the middle of ASL.

2025-05-05 13:08:18 UTC

Bitcoin Core had 4 pull requests merged in the last 5 days.
It's pretty clear that none of these had consensus from the broader Bitcoin community.
#nevent1q…kedw

2025-05-04 01:29:45 UTC

- reply

If you have YAML frontmatter maybe you can do something like this for every file:
echo '---
title: Bla
---
# Bla
blablabla
' | yq --slurp '{tags: [["title", .[0].title]], content: .[1]}' | nak event -k 30023 relay.damus.io

2025-05-03 15:30:06 UTC

- reply

For sure you're a fake account from someone, but I have no clue of who.

2025-05-03 15:28:06 UTC

Has anyone tried https://github.com/jj-vcs/jj?

2025-05-03 15:25:57 UTC

- reply

Jokes aside it was a good idea that someone should still implement, but instead of a DVM-via-events like this we should do it in a DVM-via-HTTP-API or DVM-via-special-relay.

2025-05-03 15:21:03 UTC

The first DVM:
#nevent1q…y0er

2025-05-03 15:06:20 UTC

- reply

I don't know much about the drama, but I think it's absolutely stupid to try to block OP_RETURNs when the alternative (data encoded in unspendable fake pubkeys) is much worse. Also there is no practical difference between a transaction from a person you don't like and a bunch of arbitrary data.
The blockchain has always been a necessary evil, a bad thing that we have to tolerate, it was never a sacred beautiful place that only now is being tarnished.

2025-05-03 15:03:33 UTC

- reply

Yes, that.
Did you just do that?

2025-05-03 11:23:39 UTC

This may interest some people, it's a brief explanation of how I think outbox should work ideally (criticism and suggestions welcome):
#nevent1q…kj50
You can't have this local database thing in all contexts like all microapps and whatnot (those can probably just use a naïve NIP-65 approach) but a full-fledged Nostr client should.

2025-05-03 11:13:33 UTC

- reply

You can have a relay hint for each tag in kind:3 follow lists, some clients have it there, there is no reason why you can't have the same for the tags in the follow pack.
But you can't just add all these relays indiscriminately into a flat list and start querying them all -- or maybe you can, but that's very inefficient. It's better to have always a handy list of 2 or 3 relays that are "optimal" for each pubkey and only query their posts from those.
The best way I came up with (well, more reasonably I stole the idea from @nprofile…442w) is to have a local database (see https://github.com/nbd-wtf/go-nostr/blob/master/sdk/hints/interface.go) that associates relays with pubkeys that tracks the last timestamp we saw a hint from for that specific pubkey on that specific relay. Hints can come from other people's event tags, nprofile and nevent codes seen in the wild, nip05 and nip65 relay lists, then there is also a timestamp for the latest successful event fetched from and the last attempt.
There are different weights for each of these hints such that when we add them all up the nip65 list will get a higher score, but failed attempts will get heavily discounted so if a person stops publishing on a relay but we keep trying to get their posts from there eventually that relay will lose score.
The nprofile or event tag hints have very little weight but they serve at least to point to relays we can target briefly if the others stop working so clients can recover even from the most brutal forms of censorship.
I tried to illustrate that process at https://how-nostr-works.pages.dev/#/pathological

2025-05-03 02:38:09 UTC

Hopefully no one can read this note.

2025-05-03 02:35:33 UTC

So I have this very basic NIP-29 unmanaged forum thing here that is meant to be hosted by the same relay that is hosting the content:
https://pyramid.fiatjaf.com/forum/topic/28d0eb39bfc8658dc4d6eb53b10b3bcfc2e8b42e785c1fe39e6e6815ceedc4f8
Of course the same content is available on other apps like Florilla: https://app.flotilla.social/spaces/wss%3A%2F%2Fpyramid.fiatjaf.com%2F/threads/28d0eb39bfc8658dc4d6eb53b10b3bcfc2e8b42e785c1fe39e6e6815ceedc4f8
And Chachi: https://chachi.chat/pyramid.fiatjaf.com/e/nevent1qgsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hsqgpg6r4nn07gvkxuf4ht2wcskw70ct5tgtncts0788nwdq2uamwylq7zztxm
As well as Nostrmo and 0xchat.
Please @npub1njs…7fqx enlighten me about everything that is missing or wrong here aside from the square avatars.

2025-05-02 19:08:05 UTC

DVM drama > OP_RETURN drama

2025-05-02 15:17:39 UTC

- reply

There is a Formula 1 news bot in here somewhere.
I just wanted to say that.

2025-05-02 15:10:54 UTC

- reply

It wasn't clear to me at first, but now I think we should reframe DVMs as bots, instead of as a standard for RPC communication via Nostr events.
"Bots" are often seen as useless, playful things, but if we call them "DVMs" it's clearer they can also be useful tools. Ultimately it doesn't matter, it's all marketing.
Finally, we can also reframe HTTP/JSON APIs as yet another type of DVM. Zap providers, for example, are an HTTP/Event-hybrid DVM. @nprofile…7rj8 's translator API is another type of HTTP/JSON DVM that follows an existing standard (which is to copy some other translation provider I forgot) and is implemented in some clients (Damus?). Primal, Nostr.Band and Nostr.Wine also offer trending feeds HTTP/JSON-based DVMs, but they're all incompatible among each other (meanwhile Snort and Iris use the Nostr.Band API while Primal and Yakihonne use the Primal API, I don't know who uses the Nostr.Wine API), we should try to get them to standardize these (or offer these feeds as custom relays, which would be better).
That would solve our problems instead of creating more.

2025-05-02 15:02:51 UTC

- reply

It uses an HTTP/JSON-based DVM.
A competitor should investigate exposing the exact same API under a different hostname and then clients could decide to implement support for both at the same time without having to write two different integrations.

2025-05-02 15:00:16 UTC

- reply

This is good feedback specifically because that's more or less what I have in mind too: document what is working, reframe DVMs as a more flexible umbrella term going forward, do not try to make a generic event-based RPC spec.

2025-05-02 14:51:52 UTC

- reply

It looks like you mostly agree with me, except you want to reserve the kinds. Reserving the kinds, at least to me, was a good idea when I thought there could be a generic interface for interacting with DVMs --and that's why I tried to make a `nak dvm` command but failed, and that may also be why DVMDash doesn't show details about each request and response, only statistics: because they're not really generic, you would have to write dedicated code for each.
Doing as you suggest wouldn't improve things. Now besides knowing what parameters each DVM takes as input and as named parameters, the format and shape of the response we will also have to know if a DVM accepts a prompt or not, or if it returns a response or not -- and, worse, if it uses the feedback in any particular way that has to be handled or not. This is all excluding the fact that a DVM may just not respond you and you wouldn't know if that was because you did something wrong or if the relay is broken or the DVM is broken.
What I'm trying to say is: hardcoded specs, one for each DVM, is already how it has to work, and will work better. Reserving a kind range doesn't make sense in that context, and getting rid of the reserved range and of the strictly request-response format allows us to grandfather in other forms of automated interaction into the DVM umbrella.
I've said before that "DVMs as a concept make no sense", but I think they're a great marketing term, we just need to stop pretending they describe a "standard".

2025-05-02 14:44:06 UTC

- reply

I agree about calling things bots, it was poorly worded. I guess we could say that a bot can be a person and a person can be a bot, just like Bluesky labelers can also be either bots or humans. I think I was just trying to convey a different concept of bot, which is that of a profile that can be interact with in a programmatic way, so it "looks like a bot", doesn't matter if there is a human inside the box.
I think you can understand and agree with this because DVMDash uses a robot icon for its list of DVMs tab, too.

2025-05-02 12:38:27 UTC

- reply

This is not true, you're not forced to implement them, but once you decide to implement them you must follow the rules.
Unless you're just saying "you can't force anyone to do anything", which is also true but then it also applies to the required ones.

2025-05-02 10:23:34 UTC

- reply

"Each DVM kind can have its own flow, NIP-90 flow is a suggestion, not a requirement."
This is basically why. There is no point in having a spec that is just a suggestion.
All I want is clarity, the current model is producing way too much confusion.
Deleting everything was meant as a first step only.

2025-05-02 03:25:41 UTC

This is a note no one can read.