fiatjaf

Public Key

npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6

NIP-05 Address

Profile Code

nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gpz3mhxue69uhkzet8d9ejuat50phjummwv5qjyamnwvaz7tmwdaehgu3dwejhy6txd9jkgtnhv4kxcmmjv3jhytnwv46qc2cay8

Publishing to

aegis.utxo.one

nostr-verified.wellorder.net

Author Public Key

npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6

Show more details

Last Notes

2025-06-17 23:08:21 GMT

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 19:42:29 GMT

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

2025-06-03 21:54:34 GMT

Darwin was wrong and Jesus did not exist.

2025-06-03 21:38:30 GMT

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-05-31 01:35:50 GMT

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

2025-05-28 23:34:26 GMT

- reply

Satisfactory.

2025-05-28 01:34:48 GMT

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

2025-05-26 18:49:13 GMT

- reply

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

2025-05-20 18:03:53 GMT

- reply

[insert rant about DHTs]

2025-05-19 20:19:19 GMT

- reply

On Coracle there is clear visual feedback.

2025-05-19 18:37:18 GMT

- 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 01:50:35 GMT

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

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

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

- 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 12:34:53 GMT

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

- 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 02:55:30 GMT

- 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 01:10:58 GMT

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

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

- 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:25:17 GMT

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

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

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

- reply

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

2025-05-08 15:13:35 GMT

- reply

@npub1utx…50e8 is underdelivering.

2025-05-06 13:35:13 GMT

- reply

You're evil.

2025-05-06 04:13:45 GMT

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

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

- reply

What do you mean by "test"?

2025-05-06 04:02:12 GMT

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

2025-05-06 02:42:47 GMT

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

2025-05-06 02:13:00 GMT

- reply

Why all this sudden interest in BUD-04?

2025-05-06 01:04:08 GMT

- reply

This was very mindblowing, for sure.
I pasted that command on my terminal and it played some music.

2025-05-05 13:08:18 GMT

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 00:33:50 GMT

James O'Beirne has the best takes:
https://www.youtube.com/watch?v=JathbmXKwVg
Except for wanting bigger blocks: we actually need smaller blocks and Drivechain. He is also wrong about Nostr being awful. But aside from these two he is great on everything.

2025-05-03 15:30:06 GMT

- reply

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

2025-05-03 15:28:06 GMT

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

2025-05-03 15:25:57 GMT

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

The first DVM:
#nevent1q…y0er

2025-05-03 15:06:20 GMT

- 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 11:27:13 GMT

- reply

It was supposed to be kept private by the relay, but Jumble was refusing to AUTH (@nprofile…3ve2 I don't know why this happened but it did, it generally works but sometimes Jumble just decides to not perform AUTH after getting an `auth-required:` error?) so I kept retrying and eventually I must have forgotten to click on the "send only to this relay" checkbox (@nprofile…txj9 maybe the checkbox state should be persistent?).

2025-05-03 11:13:33 GMT

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

Hopefully no one can read this note.

2025-05-03 02:35:33 GMT

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 GMT

DVM drama > OP_RETURN drama

2025-05-02 15:10:54 GMT

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

- 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 14:51:52 GMT

- 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 10:57:25 GMT

- reply

I forgot to say that @nprofile…wvxz is right in the sense that HTTP services could also be considered DVMs.
It's hard for me to imagine that the feed-generator DVMs wouldn't be better as HTTP services rather than Nostr event publishers, or the Vertex DVM (which, by the way, is not listed in the official DVM specs, do not follow them strictly and is being used as an HTTP service even by their own website https://npub.world/ ).
In that sense every zap provider is a DVM: you call it via HTTP and it emits a kind:9735 event.
But today apparently people feel they're not being nostric enough if they do not turn what could have been an HTTP service into a service that listens on a bunch of relays for events and responds with events. I think a new NIP with clearer recommendations would address that, by which I mean we should tell people that sometimes it's better to do an HTTP service, and we can even standardize those HTTP services if they call for it (again, like NIP-57 did).

2025-05-02 10:42:53 GMT

- reply

@nprofile…wnez would you say @npub1z4d…j7rz qualifies as a DVM or not? Shouldn't that kind of thing also be considered a DVM?
What about a thing like https://bsky.app/profile/did:plc:bpkpvmwpd3nr2ry4btt55ack? I think the way Bluesky did this "labeler" stuff is interesting in a way: the DVM is just a "bot".
The bot should have a kind:0 profile and it can even post notes sometimes, perhaps advertising their services.
Some bots respond to kind:1 commands, others respond to kind:5001 commands, some send DMs, others publish content when prompted, others do it without being prompted.
If multiple people are running bots that behave similarly -- or if we expect that to happen -- it's time to standardize their behavior, otherwise there is no point.
There are tons of bots out there, I'd say some will never qualify as a DVM because they're just shitposting (which is good), but some are posting weather data, others are posting bitcoin data. It would be nice if bots publishing weather data could be standardized as DVMs, for example. I don't know bitcoin data, but what do I know?
I don't have a very concrete plan.

2025-05-02 10:32:10 GMT

- reply

Is there any thinking person who thinks Nostr isn't much better than the fediverse at this point? Or Bluesky? Or X?
They just happen to have a little more network effect.

2025-05-02 10:23:34 GMT

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

This is a note no one can read.

2025-05-01 23:14:27 GMT

- reply

You can't do a Nostr client with htmx, it's impossible.

2025-05-01 23:07:45 GMT

@nprofile…u0w6 was right. Svelte 5 is a supreme blunder.

2025-05-01 20:02:00 GMT

- reply

You can talk all day, I have the screenshot, and screenshots never lie: https://aegis.utxo.one/a91ab475fb596ec6f781e25106cca2b20319d4a5f036365c5784a502698abe2b.png

2025-05-01 16:20:59 GMT

- reply

There are some "DVM" use cases that make sense, but framing it as this super generic tool that encompasses all "machine" use cases is absurd and counterproductive. Also trying to have a single spec for everything hurts all the use cases at the same time. The specs aren't even machine-readable (unless you're paying Sam Altman to read them for you).
If someone wanted to write a "DVM" that did one thing that person should have done that one thing, not called it a DVM, and we could have created a standard for it if it was useful, or not, maybe that machine job was a proprietary spec that didn't need standardization, maybe it would fit in some other NIP and enhance it, each case is different.

2025-05-01 16:17:02 GMT

- reply

The fact that they don't use the DVM on their own website says it all.
Instead they use a normal HTTP API at https://npub.world/api/query and server-rendered profile pages apparently.

2025-05-01 12:08:09 GMT

DVMs are not a useful concept.

2025-05-01 12:07:18 GMT

"I love Sam Antman and will give him all the money I can because ChatGPT is so good", said all bitcoiners and nostrers.
#nevent1q…6758

2025-04-30 19:12:59 GMT

- reply

@nprofile…axjj here you have it, a bigger article about Git on Nostr that does mention many projects:
#naddr1qv…hjvt

2025-04-30 16:51:22 GMT

- reply

We have too few users and barely any content, so there is nothing to filter and no users to do the filtering. Many good ideas will only show their true potential at a bigger scale.

2025-04-30 13:48:17 GMT

- reply

https://github.com/nostr-protocol/nips/blob/master/B7.md

2025-04-30 10:49:49 GMT

It's time for clients to start displaying kind 1111 in their "replies" feeds.
What clients are doing it currently besides https://coracle.social/?

2025-04-30 10:48:40 GMT

https://noflux.nostr.technology/, for example, uses a Postgres database and that's so awful because it's meant to be used by a single person in a desktop home machine. I even tried to switch it to SQLite because it would be a strict improvement (https://github.com/fiatjaf/narr uses it luckily) but couldn't (yet) because SQL is so bad it's not even standard among all databases (and everybody knows that, but it's impossible to do anything about it).
I also tried to use https://pglite.dev/, but it didn't have easy to use Go bindings apparently.
#nevent1q…t5re

2025-04-30 10:45:53 GMT

- reply

Or is it because SQL is associated with servers running externally to the programs that use the data and as such they constitute a weird unnecessary slow abstraction that isn't needed for 99% of the programs we write today that could pretty much use an embedded simpler database or sometimes just some files?

2025-04-30 10:42:33 GMT

@nprofile…4s0j is this because you don't think it's wise for a weird Cobol-like string of instructions -- that first have to be generated by the host (with all the care to prevent malicious injections and all the refinement of string concatenation otherwise) and then parsed by the database -- to act as the API between two programs because they could pretty exchange structured data instead?
#nevent1q…vfqt

2025-04-30 01:21:13 GMT

- reply

This should be on https://nstart,me/, I think.

2025-04-29 23:22:37 GMT

This starter pack website is great not only because it can help some with onboarding, but also because it's the first non-kind-1 app to have enough usage to become useless in its normal form of "just display all lists by anyone", and now some anti-spam or curation mechanism will have to be invented.
It's even better that, since it's made to be used by people who have just joined Nostr, using their follows as a filter can't be a good solution because they simply do not follow anyone.
I just hope whatever solution @nprofile…v72v comes up with isn't centralizing and specific, but something more generic and interoperable (like relying on relays).
#nevent1q…2dxk

2025-04-29 18:12:00 GMT

The GitHub right sidebar is useless and annoying.

2025-04-29 03:07:38 GMT

This interoperability thing is actually very amazing: https://v.nostr.build/ic7VsRonqBUrNBIX.mp4

2025-04-29 02:11:17 GMT

- reply

Add Thumbhash instead! https://evanw.github.io/thumbhash/
Here's an example event:
#nevent1q…zlma

2025-04-28 18:11:23 GMT

This is such a good talk:
#nevent1q…85f5

2025-04-28 16:48:25 GMT

- reply

The WoT circle is great.

2025-04-28 16:47:54 GMT

- reply

I read it in the thread, maybe I misunderstood it but doesn't matter.
The other question is more important, and it's not even a rhetorical question. When you register on the Bluesky app do they make a special allowance on their relay for your account? Or do they label your account with something that tells the relay to fetch your posts? Why can't @nprofile…t7fy's Bluesky bridge automatically put all of Nostr's content inside Bluesky?

2025-04-28 15:57:40 GMT

- reply

That's interesting, but it's deleting data after 48 hours and having trouble connecting to 40 PDS servers?
How does it decide what users it will fetch posts from?

2025-04-28 15:41:42 GMT

- reply

First the expected use case must be written in the NIP, otherwise they can't even abuse it (i.e. use it in a different way than expected).

2025-04-28 15:40:27 GMT

- reply

It would already be bad if they only used a "global" server for content discovery, but no, they also use that for the normal feed building anyway, instead of the outbox model.

2025-04-28 15:38:47 GMT

- reply

By the way: Pubky solves content discovery in a way that is very similar to what Bluesky does though, and both are also similar to Farcaster. They all see Nostr and think something like: "oh, there are these centralizing tendencies that may affect Nostr and that would be very bad for Nostr if it happened, so we will just hardcode those in our protocol description and pretend that somehow it is not broken from the start?" (it ends with a quotation mark and they are super confused and the rest of their lives makes no sense anymore).

2025-04-28 15:34:26 GMT

- reply

I don't see how PKDNS solves that. I'm talking about learning that someone exists and if I should be following them or not. That's about content, not about how to find their relays.
Finding their relays is easy, we don't need Pkarr for that. Yeah, it's not 100% guaranteed but what we have here is practical enough for the current world.

2025-04-28 15:03:34 GMT

- reply

Should it be made it clear that these are relays made to be browsed directly and not some accessory relay that holds all kinds of garbage or a normal public relay you just happen to "like" for whatever reason?

2025-04-28 15:02:32 GMT

- reply

Nice scam.

2025-04-28 15:01:33 GMT

Best news of the year:
#nevent1q…2988

2025-04-28 14:57:58 GMT

- reply

Maybe, although I'm not sure that should be a thing currently since no one is making any money on Nostr, everybody working on Nostr clients is supposedly doing it for idealistic reasons and/or being paid by grants.
But I'm not talking about outbox now, outbox only comes up after you've decided to see or follow some specific person's notes, before that you need to discover that that person exists, and to me the only reasonable way to have that is by relying on relay feeds -- and these could be created by centralized indexers, like https://algo.utxo.one/, but if they are exposed through the relay API that makes them very easy to be reused and exchanged by other clients.

2025-04-28 14:54:10 GMT

- reply

I tend to agree and I wish https://listr.lol worked.
But at the same time I must ask: how exactly? And why aren't normal contact lists already good enough?

2025-04-28 14:52:16 GMT

- reply

This is irrelevant.

2025-04-28 14:45:49 GMT

Here's an example of a relay that uses artificial artificial intelligence (i.e. human intelligence) to build a curated feed of potentially interesting notes: https://relays.land/spatianostra
You can probably access its feed by clicking on wss://relays.land/spatianostra if your client supports relay feeds, or use Jumble: https://jumble.social/?r=relays.land/spatianostra

2025-04-28 14:37:40 GMT

Discovery on Nostr still sucks and everybody is just relying on a centralized platform:
#nevent1q…9ctz
Coracle doesn't even have the "network [WoT] feed" it used to have anymore -- but that also didn't scale anyway.

2025-04-28 14:32:09 GMT

- reply

First you would need an interoperable format for slides that multiple apps could implement.
Or you could just associate content with a specific website and that website could use any format they want, then they have an internal database that associated slides with a Nostr public key, which is not a "real Nostr client" but it's also something that we need (we can't make everything an open protocol at once), in that case we don't need a kind or a NIP.

2025-04-28 14:07:38 GMT

- reply

In order to do that the signers will have to see some reliable evidence that such a person is actually whom they pretend to be. In the case of a platform like Ditto that should be easy if you can just trust the Ditto-like server (and also safe because the owner of the Ditto server can't fake it without being caught -- because the signers will only do it once so if the server owner fake it and steal the key then the actual user will know that as soon as they try to request their key for themselves).
But another interesting idea is to do this:
#nevent1q…w2r9
The only problem with that is defining how these signers will determine if the person is who they're saying they are, but I think we can just use some common sense.

2025-04-28 14:00:34 GMT

- reply

But now I think we have a better way: we can get some trustworthy signers to create a NIP-46 bunker like the one in
#nevent1q…p7fz
But in such a way that they generate the key without any single entity ever seeing the full key.
Then these signers also commit to participating in ceremony to reconstruct the key and hand it to the legitimate owner of that key _only once_ in such a way that only that owner ever sees the key.

2025-04-28 13:56:30 GMT

- reply

That's what I wanted Ditto to be at first but @nprofile…t7fy wanted to become a cool bitcoiner and give keys to users.
But also @nprofile…u0w6 made something like this for Flotilla.

2025-04-28 01:04:22 GMT

Do we have something to learn from XMPP?
https://xmpp.org/software/?platform=linux

2025-04-27 15:02:35 GMT

- reply

Great business idea.

2025-04-27 13:31:29 GMT

Correct assessment of the meme culture:
#nevent1q…fya8

2025-04-27 13:29:26 GMT

Nostr casually mentioned as if it was obviously known to everybody here at 26': https://www.youtube.com/watch?v=rdE00-1xoqU

2025-04-27 03:47:58 GMT

- reply

Oh, right. Thank you for using it. Please let me know of all the bugs you find.

2025-04-27 02:38:49 GMT

- reply

You mean nak?

2025-04-27 01:41:28 GMT

Lantern v0.3 will come with an automatic detector of Nostr events even when they're being displayed in a web client (by looking at the URL) or when they're in a completely arbitrary webpage (by looking at @nprofile…7jp9's <link> tag):
https://v.nostr.build/4K5ldYVqLh8QIToa.mp4
That means that you can use Lantern to highlight and annotate and comment on an article on Yakihonne, njump or Habla or a website like https://fiatjaf.com/ or https://nostr.kosmos.org/@raucao and your comments will show up on every other instance of that same article.