I do not have an X account
Public Key
npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 Profile Code
nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gppamhxue69uhkummnw3ezumt0d5q3vamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmnymfpunn
Show more details
Published at
2025-07-09T21:01:39Z Event JSON
{
"id": "b4c1240b0a09660358cc95f97e41ecfcd658a304cb8c6a6af79dc6c70c447c8a" ,
"pubkey": "3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d" ,
"created_at": 1752094899 ,
"kind": 0 ,
"tags": [],
"content": "{\"name\":\"fiatjaf\",\"about\":\"I do not have an X account\",\"picture\":\"https://fiatjaf.com/static/favicon.jpg\",\"nip05\":\"[email protected] \",\"lud16\":\"npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6@npub.cash\",\"website\":\"https://stuff.fiatjaf.com\"}" ,
"sig": "863cb37209ada1b2b4d1254b0743cd8a340df5ff86ee220c58036a9db48ab9be1a95f01e5922e68a85b34177bc221abdbf99eb6886b3b65536f1947643e3446e"
}
Last Notes npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf https://github.com/lumehq/coop (compile from source for now) works great. https://chachi.chat/ also pretty good but I think you must enable it in settings. NIP-17 only. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf Here's a reasonable explanation if you're tired of just empty rants: #nevent1q…ywdl npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf They go into a black hole because Nostr is too small today and we're living with these public relays anyone can write. That situation cannot work if Nostr gets bigger, there will be too much spam. Many relays will be forced to close themselves only to users that meet a certain criteria (payment, relationship, content quality, PoW, etc), then once you have that it becomes in the interest of these relays to exclude people who aren't behaving well, therefore reporting them to the relays they use becomes a meaningful act. https://pyramid.fiatjaf.com/ has a reports page where presumably I or other users can check if some bad actor got accidentally invite and remove them, for example (not that it has ever happened). Anyway, the crucial part is that what can be bad behavior for me may not be for you, so my relay may only accept notes full of love and kindness, but yours may accept notes full of rage and sarcasm, and both are ok -- that brings us to the next step: if a user only wants to see love and kindness they should be able to configure their stuff to only see replies that come from my relay in some situations, for example. How all of this works in practice I cannot say for sure, but I see zero centralization pressure in any of these steps. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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 npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf I don't know if @nprofile…n7yc was joking but clients should actually offer protection against that kind of stuff -- perhaps not explicitly, but by means of allowing advanced relay choice for each kind of action and circumstance. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf Thank you, it was a simple bug in a completely unrelated thing that was crashing the server and preventing votes to be computed. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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 npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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 npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf Honestly if something is commercially viable it shouldn't be funded by OpenSats. OpenSats is not VC capital as far as I understand. And Nostr is not "data access and subscription", you don't need Nostr for that, you can run a server and provide that very easily without Nostr. It makes no sense to pretend to like Nostr but actually just abuse it to build a proprietary business on top, there is plenty of space for businesses that adopt the protocol without destroying it, but for any of that to be commercially viable we'll have to go past the barrier of 1000 users and for that we need to appeal to nerds and idealists first. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf Nothing on Nostr has commercial viability today because we only have 120 users. Twitter clones also have no commercial viability. Or, if you disagree, please tell me what are some projects that could be commercially viable. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf Yes, I've never seen anyone serious here complain about Bluesky or Farcaster based on the content, I have no problem with their content. Their only problem to me is fake decentralization. But yes, people in the external world do see Bluesky as a community of leftists, and Nostr shouldn't be like that but for the other side. Someone has to make a new set of default relays, with a new client that people can be onboarded into but that doesn't feature a million bitcoiners posting all day. The Japanese people did that with their geo-supremacist relays that only accept posts in Japanese made from Japan. We should prove it's possible to do it for other niches. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf @nprofile…pt5w can probably arrange that. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf This is horrible so I couldn't listen, but imagine a real world rapper doing a music with this title: #nevent1q…dssg #nevent1q…ye3f npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf What do you think of going full p2p with iroh instead of using relays? (Assuming it works.) I mean, if the idea is to ditch Nostr to something more idealistic and more "correct" than that path should at least be considered. Relays were the Nostr compromise to make things "work" because p2p has never worked in practice (in theory I also think it doesn't work), but the iroh people swear it works now, so who knows. One problem with pure p2p is that people have to keep devices online, but that can be solved with adhoc "relays" which are actually just nodes -- you eliminate the distinction between clients and relays and just query nodes for stuff, people can nominate other nodes (identified by public keys just like their own devices) to host their stuff while they're offline. Another problem with pure p2p is that you don't get discovery of new content, you only fetch stuff from people you already know -- but again here we can defer to these adhoc relays to curate and host content from others and you can call these to download stuff and expect to get back quality content from people you don't know, and maybe you'll start following these people. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf `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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf https://lockbox.fiatjaf.com, https://zapbox.fiatjaf.com and https://labour.fiatjaf.com will be shut down soon. If all goes right they will be revived later under a different domain. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf I'm not against that. Another of my plans is to make "blockchain domains" that do not suck using a Bitcoin spacechain, but so far that hasn't been possible and who knows if it would actually work. I don't understand how to connect the blockchain to the real world though. How would TLS fingerprinting help? And isn't DANE a niche thing that browsers refuse to implement? npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf You're still not getting my messages, right? @npub1zfs…w445 please fix! npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf It's just for DMs, you still have to build all the other things. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf @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). npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf https://chachi.chat/ npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf You should have never revealed your nationality. Now I'm paralyzed and can't reply to your DM. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf We don't have many users or developers. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf I have many plans for fixing bugs and adding things but couldn't yet. Maybe I should just migrate to fritzer? npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf Yes, apparently he wasn't a good person. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf https://www.youtube.com/watch?v=M33mfhQUJnM npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf I don't have any appetite to tackle anything related to PGP, but maybe it's a good idea, I don't know. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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 npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf @nprofile…49mr can you do Android and iOS apps with gpui? npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf Darwin was wrong and Jesus did not exist. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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? npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf alphaama is back! https://i.nostr.build/EqAR02jrIGM8YV81.png https://wip.alphaama.com/ npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf Satisfactory. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf A single one of these files has actual code in them: https://aegis.utxo.one/839c7a09911e2b01ddadbad607cb275863d3ab70bdc447ce90239ead691930f4.png npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf Não faço idéia de como funciona essa extensão aí, o código dela não é aberto. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf [insert rant about DHTs] npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf On Coracle there is clear visual feedback. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf He wasn't looking for a solution for him personally, it was a comment on the general state of these platforms. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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). npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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! npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf Would they also deem cars illegal if they were introduced today or not? npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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://`? npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf I've answered there, thank you very much. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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? npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf Instead of "EVENT" the message must be "AUTH". npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf Voting is working again, another stupid bug. Thank you for insisting. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf @npub1utx…50e8 is underdelivering. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf Apparently Gossip was also the only that replied to the correct place, wss://inbox.fiatjaf.com, and not to wss://lockbox.fiatjaf.com. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf You're evil. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf What do you mean by "test"? npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf @nprofile…58km "nak publish" should work if you install it from this commit: go install github.com/fiatjaf/nak@67e291e80dace3dd8c10252b4a3c8b4363afc894 npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf After a brief interruption, this bot is back and catching up: #nevent1q…s6pd npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf Why all this sudden interest in BUD-04? npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf This was very mindblowing, for sure. I pasted that command on my terminal and it played some music. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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 npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf Nostr relay wars: #nevent1q…m4d2 npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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 npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf For sure you're a fake account from someone, but I have no clue of who. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf Has anyone tried https://github.com/jj-vcs/jj? npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf The first DVM: #nevent1q…y0er npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf Oh, his follow pack app could take nprofile strings, extract a relay URL and put it in the tag like ["p", "<pubkey>", "wss://whatever"] npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf Yes, that. Did you just do that? npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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?). npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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 npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf Hopefully no one can read this note. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf DVM drama > OP_RETURN drama npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf There is a Formula 1 news bot in here somewhere. I just wanted to say that. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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". npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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. npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 fiatjaf 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.