2025-06-28T02:48:34Z https://yabu.me Daniel A Cummings https://yabu.me/npub19d7920ygnhrknv96h8m0tmx76p9xfyt4d6l5vv3uga0w8zew5d5s3tgvwq https://avatars.githubusercontent.com/u/52766983?v=4 https://avatars.githubusercontent.com/u/52766983?v=4 https://yabu.me/nevent1qqsdhkw952t3v5mr4ed0k85knscthnhls5z3hvc95qapnrkuqwe68xszyq4hc4fu3zwuw6dsh2ulda0vmmgy5ey3w4ht733j83r4acut963kjfp0apn In reply to <a href='/nevent1qqszj8t4scdxpl0a0h20ta3qm8dtvhrhusjmtkwspvwlez0ghva9hjspzdmhxue69uhk7enxvd5xz6tw9ec82c30zmwcwf'>nevent1q…wcwf</a><br/>_________________________<br/><br/>Hi, <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszxnhwden5te0wfjkccte9c6rgcnfd3kxjmmw9ehx2ap0qy2hwumn8ghj7cnpwdehq6tnw3hkctn0wfnj7l6pqyq" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>fiatjaf</span> (<span class="italic">nprofile…pqyq</span>)</a></span>. I forgot to tag you in my response:<blockquote class="border-l-05rem border-l-strongpink border-solid"><div class="-ml-4 bg-gradient-to-r from-gray-100 dark:from-zinc-800 to-transparent mr-0 mt-0 mb-4 pl-4 pr-2 py-2">quoting <span itemprop="mentions" itemscope itemtype="https://schema.org/Article"><a itemprop="url" href="/nevent1qqsrj65uxjjapkgt9wr3ukq8ppeg2fhfav40wajhkhmyfljcnudshscpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgszklz48jyfm3mfkzatnah4an0dqjnyj96ka06xxg7ywhhr3vh2x6grqsqqqqqpgcqa0q" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1">nevent1q…qa0q</a></span> </div> I agree that Nostr is very resilient against DNS attacks, but relying on DNS at all is still its biggest weakness. The DNS reliance issue isn't just about how well the network could hold up against a coordinated attack. Individual relay operators would hugely benefit from not relying on DNS while still having it as a nice option for easy discovery & user-friendly lookup. It's a lot harder for an individual relay operator to switch domains especially if they're repeatedly attacked at the DNS level each time they switch. But if they had their public key as a backup method for clients to connect to them with, clients could seamlessly stay connected to them after a DNS attack took place. There could even be a simple mechanism for DNS-based relays to announce their npubs which clients could automatically save in case connection at the DNS level failed at some point.<br/><br/>There are also privacy issues & additional hurdles caused by making DNS mandatory for any sort of client-relay connection that will last through a dynamic IP change. I personally don't want to have to choose a domain registrar, choose a domain, purchase it, renew it, & deal with remote hosting of relay software. I also don't want before that to give my name, home address, & email address to a domain registrar & also ICANN if I'm not willing to pay extra to keep ICANN from having that info.<br/><br/>Many more people would be running relays if all we had to do was download a relay app & run it on our laptop using a standard, home internet plan with a dynamic IP address. I should add that, based on other replies to my original message to you, I no longer think all content sent by relays not using DNS should be signed by the relay's nsec. But something like a TLS handshake when the WSS connection is 1st made should be performed so the relay can prove its identify.<br/><br/>Regarding complete overhaul of the IP protocol, I agree that needs to happen. But I think it will be much more successful if done in more than 1 jump to a fully decentralized system without even having ISPs in the mix--especially because you'd be going against their financial incentives. As a step in the right direction which also keeps ISPs & their financial incentives intact, I propose what I'll call IPvPK (pub key) for lack of a better term.<br/><br/>Instead of IPs being assigned at the ICANN or even ISP level, they could be user-generated pub keys. The user could send their self-generated pubkey to their ISP, & then the ISP could register it, share it with other ISPs, & hopefully provide a way for the user to update it as needed or wanted. Like with IPv4/6, any computer attempting to connect to another computer by IPvPK would be routed by 1 or more ISPs to it. Then something like a TLS handshake could take place where the connecting computer would send arbitrary data to be signed by the corresponding IPvPK's private key.<br/><br/>With this system, we'd never run out of IPs like with IPv6, no central authorities (ICANN, ISPs, or CAs) would fully control who had what IP, & none of them could spoof packets meant to be from any given IP since each owner of each IP would prove their IPvPK identity with digital signatures.<br/><br/>ISPs could continue offering IPv4/6 while any number of them at any adoption rate could start to support IPvPK. Not only could they keep their same financial incentives in place, but I imagine they would want to encourage their users to adopt iPvPK since it means less coordination for them with ICANN.<br/><br/>Also, IPvPK connections would work between users of the same ISP even if that ISP was not connected to any other ISPs that supported IPvPK since no coordination with other ISPs or ICANN would be needed to ensure they didn't use IPvPK IPs used by others. That's because the odds of that happening would be similar to that of 2 people generating the same Bitcoin wallet address. </blockquote> 2026-03-31T01:25:48Z https://yabu.me/nevent1qqsg8xc5qrymq5kz2axmqte3utwy6903t4kk5xz7wefpqsh266rzcfqzyq4hc4fu3zwuw6dsh2ulda0vmmgy5ey3w4ht733j83r4acut963kj993lsr In reply to <a href='/nevent1qqsznu6fnqg0w3tef0nyh6e8pedkrj5733hrpq0k068l2xg90w8qe0cpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhs96trct'>nevent1q…trct</a><br/>_________________________<br/><br/>Nice, good to know. I hope to convince work to use it some day. 2026-03-06T00:26:59Z https://yabu.me/nevent1qqsrj65uxjjapkgt9wr3ukq8ppeg2fhfav40wajhkhmyfljcnudshsczyq4hc4fu3zwuw6dsh2ulda0vmmgy5ey3w4ht733j83r4acut963kjgkdy8d In reply to <a href='/nevent1qqszj8t4scdxpl0a0h20ta3qm8dtvhrhusjmtkwspvwlez0ghva9hjspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsl2lxwa'>nevent1q…lxwa</a><br/>_________________________<br/><br/>I agree that Nostr is very resilient against DNS attacks, but relying on DNS at all is still its biggest weakness. The DNS reliance issue isn&#39;t just about how well the network could hold up against a coordinated attack. Individual relay operators would hugely benefit from not relying on DNS while still having it as a nice option for easy discovery &amp; user-friendly lookup. It&#39;s a lot harder for an individual relay operator to switch domains especially if they&#39;re repeatedly attacked at the DNS level each time they switch. But if they had their public key as a backup method for clients to connect to them with, clients could seamlessly stay connected to them after a DNS attack took place. There could even be a simple mechanism for DNS-based relays to announce their npubs which clients could automatically save in case connection at the DNS level failed at some point.<br/><br/>There are also privacy issues &amp; additional hurdles caused by making DNS mandatory for any sort of client-relay connection that will last through a dynamic IP change. I personally don&#39;t want to have to choose a domain registrar, choose a domain, purchase it, renew it, &amp; deal with remote hosting of relay software. I also don&#39;t want before that to give my name, home address, &amp; email address to a domain registrar &amp; also ICANN if I&#39;m not willing to pay extra to keep ICANN from having that info.<br/><br/>Many more people would be running relays if all we had to do was download a relay app &amp; run it on our laptop using a standard, home internet plan with a dynamic IP address. I should add that, based on other replies to my original message to you, I no longer think all content sent by relays not using DNS should be signed by the relay&#39;s nsec. But something like a TLS handshake when the WSS connection is 1st made should be performed so the relay can prove its identify.<br/><br/>Regarding complete overhaul of the IP protocol, I agree that needs to happen. But I think it will be much more successful if done in more than 1 jump to a fully decentralized system without even having ISPs in the mix--especially because you&#39;d be going against their financial incentives. As a step in the right direction which also keeps ISPs &amp; their financial incentives intact, I propose what I&#39;ll call IPvPK (pub key) for lack of a better term.<br/><br/>Instead of IPs being assigned at the ICANN or even ISP level, they could be user-generated pub keys. The user could send their self-generated pubkey to their ISP, &amp; then the ISP could register it, share it with other ISPs, &amp; hopefully provide a way for the user to update it as needed or wanted. Like with IPv4/6, any computer attempting to connect to another computer by IPvPK would be routed by 1 or more ISPs to it. Then something like a TLS handshake could take place where the connecting computer would send arbitrary data to be signed by the corresponding IPvPK&#39;s private key.<br/><br/>With this system, we&#39;d never run out of IPs like with IPv6, no central authorities (ICANN, ISPs, or CAs) would fully control who had what IP, &amp; none of them could spoof packets meant to be from any given IP since each owner of each IP would prove their IPvPK identity with digital signatures.<br/><br/>ISPs could continue offering IPv4/6 while any number of them at any adoption rate could start to support IPvPK. Not only could they keep their same financial incentives in place, but I imagine they would want to encourage their users to adopt iPvPK since it means less coordination for them with ICANN.<br/><br/>Also, IPvPK connections would work between users of the same ISP even if that ISP was not connected to any other ISPs that supported IPvPK since no coordination with other ISPs or ICANN would be needed to ensure they didn&#39;t use IPvPK IPs used by others. That&#39;s because the odds of that happening would be similar to that of 2 people generating the same Bitcoin wallet address. 2026-03-05T21:07:37Z https://yabu.me/nevent1qqsynw69nqfzucyhc4u66zzs6l7av389zfhnuze4r2ca55tth675j4czyq4hc4fu3zwuw6dsh2ulda0vmmgy5ey3w4ht733j83r4acut963kjw4us2x In reply to <a href='/nevent1qqsrjj0hsnjm0ae0lp8sq9syprnkn3lr76l47snfhvmxwzc4kzln0hcpzpmhxue69uhkummnw3ezumt0d5hs6v8264'>nevent1q…8264</a><br/>_________________________<br/><br/>It&#39;s great that that option is available for more technical users. But even for them, it&#39;s only worth using with static IPs. That setup doesn&#39;t scale &amp; isn&#39;t worth using with a relay run by the average Nostr user who wants to quickly set up a node on their laptop running at home which likely uses a dynamic IP.<br/>Nostr adoption would be hugely helped if anyone with a standard internet connection with a dynamic IP could download a relay app, run it on their laptop, then give people an npub which their clients could use to stay connected to that relay even with IP changes. No purchasing a static IP (which is also easier to censor) or domain is required, &amp; it would make Nostr way harder to censor. 2026-02-01T21:41:59Z https://yabu.me/nevent1qqsvnpqd8mwqunl5av5rxy0zt2x5c53fsmssa5vh37jsf3jq83rp8wczyq4hc4fu3zwuw6dsh2ulda0vmmgy5ey3w4ht733j83r4acut963kjr32hu7 In reply to <a href='/nevent1qqs2gcnnztv7lxl88qcmhlf9p53w0sxtva4mzygvrkguerjnpe6405qpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhstdwn6m'>nevent1q…wn6m</a><br/>_________________________<br/><br/>What about this?<br/><blockquote class="border-l-05rem border-l-strongpink border-solid"><div class="-ml-4 bg-gradient-to-r from-gray-100 dark:from-zinc-800 to-transparent mr-0 mt-0 mb-4 pl-4 pr-2 py-2">quoting <br/><span itemprop="mentions" itemscope itemtype="https://schema.org/Article"><a itemprop="url" href="/nevent1qqszc28qfse33mf5j4kpmvfd960tqs3csrxmrmk8fkr6g0sg3knh2pcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygpt032nezyaca5mpw4e7m67ehksffjfzatwharry0z8tm3ckt4rdypsgqqqqqqs2rsrxj" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1">nevent1q…srxj</a></span> </div> I go into a little more detail about the idea in the note below. But I would change what I said about relays signing all the content they send to clients. Instead, once per WSS connection, some sort of proof could be sent by the relay to the client to show it's the relay belonging to the public key that the client is using to track it.<br/><br/><span itemprop="mentions" itemscope itemtype="https://schema.org/Article"><a itemprop="url" href="/nevent1qqsya2d266df7s8jecr6mfey06tkr8q5dz2nhja44qwdf7q5l5t5wqcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygpt032nezyaca5mpw4e7m67ehksffjfzatwharry0z8tm3ckt4rdypsgqqqqqqsktter9" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1">nevent1q…ter9</a></span> </blockquote> 2026-01-05T23:31:32Z https://yabu.me/nevent1qqszc28qfse33mf5j4kpmvfd960tqs3csrxmrmk8fkr6g0sg3knh2pczyq4hc4fu3zwuw6dsh2ulda0vmmgy5ey3w4ht733j83r4acut963kj7gxx2w In reply to <a href='/nevent1qqs8pwqxcpegxgpzs6qlx0thd2e0f77ygpp2v6xj6pz2e8u6ade74aqpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsherpjd'>nevent1q…rpjd</a><br/>_________________________<br/><br/>I go into a little more detail about the idea in the note below. But I would change what I said about relays signing all the content they send to clients. Instead, once per WSS connection, some sort of proof could be sent by the relay to the client to show it&#39;s the relay belonging to the public key that the client is using to track it.<br/><blockquote class="border-l-05rem border-l-strongpink border-solid"><div class="-ml-4 bg-gradient-to-r from-gray-100 dark:from-zinc-800 to-transparent mr-0 mt-0 mb-4 pl-4 pr-2 py-2">quoting <br/><span itemprop="mentions" itemscope itemtype="https://schema.org/Article"><a itemprop="url" href="/nevent1qqsya2d266df7s8jecr6mfey06tkr8q5dz2nhja44qwdf7q5l5t5wqcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygpt032nezyaca5mpw4e7m67ehksffjfzatwharry0z8tm3ckt4rdypsgqqqqqqsktter9" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1">nevent1q…ter9</a></span> </div> Hi, <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9us2xuyp" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>fiatjaf</span> (<span class="italic">nprofile…xuyp</span>)</a></span>. I have an idea for using Nostr's existing network architecture to allow for optionally DNS-free relays. It would ideally be applied to Nostr & Blossom.<br/><br/>Relays could have their own Nostr pubkey which they would use to<br/>1. Send a new, IP address location event type to Nostr relays containing their current IPv6 or IPv4 address & port number, &<br/>2. Sign the data they send to clients so that clients can verify that they're receiving the data from the expected relays.<br/><br/>With this setup, for a client to find their DNS-free relays, they would<br/>1. Attempt to connect to their last known IP locations<br/>2. If this fails, they would query all relays they know the location of for the most recent location broadcasts they have<br/>3. Reattempt to connect using the new location data<br/><br/>This way, a relay could run without a domain name of any kind on a non-static IP address that could change at any time. As soon as the relay detects that its IP address has changed, it could broadcast its new location so it could be quickly connected to again.<br/><br/>What are your thoughts? </blockquote> 2026-01-05T23:30:01Z https://yabu.me/nevent1qqs8pwqxcpegxgpzs6qlx0thd2e0f77ygpp2v6xj6pz2e8u6ade74aqzyq4hc4fu3zwuw6dsh2ulda0vmmgy5ey3w4ht733j83r4acut963kj6rm3g6 In reply to <a href='/nevent1qqsvu65dgp28zegdwd68qar5yxrlj0farandntcc8kzmcvc4p3ujvfqpz9mhxue69uhkummnw3ezuamfdejj74eu2qh'>nevent1q…u2qh</a><br/>_________________________<br/><br/>Nostr is amazing, but it still relies on centralized DNS to connect to relays rather than DNS being optional. You mentioned a while ago that you were considering a P2P layer for Amethyst. What about 1st implementing a simpler solution which 1. Allows for connecting to relays by IP address &amp; port number, &amp; 2. Sets a standard for relays to broadcast their IP address &amp; port number to other relays so that they can be found by clients? Relays would, of course, broadcast this information to other relays that do use DNS &amp; to those that don&#39;t for maximum discoverability.<br/><br/>That would make running relays simpler since relay operators wouldn&#39;t need to set up domains. Domain registration is privacy invasive, costs money, &amp; adds a hurdle to setting up a relay which I think is a significant hurdle to Nostr adoption. It would also get rid of the single biggest censorship weakness of Nostr &amp; could be a simple, gradually adopted standard since it&#39;s backwards compatible with current Nostr architecture.<br/><br/>Imagine anyone being able to freely set up their own relay in minutes by downloading a relay, broadcasting their IP address &amp; port number, then telling their friends to add their relay to their client&#39;s relay list? It would help a lot in getting more people onboarded to Nostr, I think. 2026-01-05T20:57:21Z https://yabu.me/nevent1qqs2jmdvyujqluxsnkjvr4n7lxq2lseaezlnaadpr0ypke3kft2v04gzyq4hc4fu3zwuw6dsh2ulda0vmmgy5ey3w4ht733j83r4acut963kjk9j0w4 In reply to <a href='/nevent1qqsyjanm4lqmsjr6evrj9c5mjkjc4jrr0umwe3p445nwnngfmlewktspz9mhxue69uhkummnw3ezuamfdejj7pk87ez'>nevent1q…87ez</a><br/>_________________________<br/><br/>Connecting to relays that don&#39;t use DNS just by using IP address &amp; port number would be amazing. It would help Nostr be way more censorship resistant &amp; make it easier for people to run nodes since they wouldn&#39;t need to buy a domain or give out their address to ICANN or a domain registrar to do so. 2025-11-30T17:27:28Z https://yabu.me/nevent1qqsd9h9jmsed0u2laz0xlpwe7wfydxrycfesrhj2kep7lazvkdmmgqqzyq4hc4fu3zwuw6dsh2ulda0vmmgy5ey3w4ht733j83r4acut963kjxrngfj In reply to <a href='/nevent1qqsyjanm4lqmsjr6evrj9c5mjkjc4jrr0umwe3p445nwnngfmlewktspz9mhxue69uhkummnw3ezuamfdejj7pk87ez'>nevent1q…87ez</a><br/>_________________________<br/><br/>Locally store all my events so I don&#39;t need to run a local node to back them up. 2025-11-30T17:26:51Z https://yabu.me/nevent1qqsqmzpmx2hdp36wu8uhgpceea02e3mv5k5rxfqmnajwr5et3agrfjczyq4hc4fu3zwuw6dsh2ulda0vmmgy5ey3w4ht733j83r4acut963kjg4ykav I&#39;ve been having fun with IPFS (InterPlanetary File System) again, &amp; I just used it to make my resume easily available online. IPFS is a free and open source protocol that lets you make files of any kind globally available without using DNS/websites &amp; with nothing but a laptop running the IPFS app. No server setup needed. It can be used with folders as well, so I plan to eventually use it to make a static website.<br/><br/>Here&#39;s my current resume on the Pinata gateway: <a href="https://gateway.pinata.cloud/ipfs/bafkreigpjsz3x6ge7lxx3nevijv76lq2tkvh6scw7dyer5cydayqlo3dru">https://gateway.pinata.cloud/ipfs/bafkreigpjsz3x6ge7lxx3nevijv76lq2tkvh6scw7dyer5cydayqlo3dru</a><br/>Note that since the file&#39;s ID is based on its content, any future versions of my resume will not be available at that ID-specific link. I would eventually like to experiment with IPNS (InterPlanetary Name System) so that I can share a single ID which can point to changeable content. IPNS is a great way to host your own website without needing to use a website domain.<br/><br/>#ipfs #resume #websites #decentralized #peertopeer 2025-11-25T03:51:53Z https://yabu.me/nevent1qqsfwr2mpevnrm6qus4kuryzfgstuqjnkjve8zq6wkhzx4d7adjwg8szyq4hc4fu3zwuw6dsh2ulda0vmmgy5ey3w4ht733j83r4acut963kjqkdmj5 I got to use the Python tool for deleting files from Git history called git-filter-repo for the first time. It was easy to use &amp; ran quickly. Git&#39;s website recommends using it instead of Git&#39;s own filter-branch command: <a href="https://git-scm.com/docs/git-filter-branch#_warning">https://git-scm.com/docs/git-filter-branch#_warning</a>.<br/><br/>Hopefully I&#39;ll try out Jujutsu (jj) someday for the same purpose. It looks like a very promising Git alternative since it&#39;s simpler &amp; it&#39;s compatible with all services that use Git, like GitLab &amp; Bitbucket, because it can optionally use Git under the hood. Here&#39;s the Jujutsu documentation if you want to learn more: <a href="https://jj-vcs.github.io/jj/latest/">https://jj-vcs.github.io/jj/latest/</a>.<br/><br/>#git #python #jj #jujutsu #softwaredevelopment 2025-11-15T04:18:21Z https://yabu.me/nevent1qqsya2d266df7s8jecr6mfey06tkr8q5dz2nhja44qwdf7q5l5t5wqczyq4hc4fu3zwuw6dsh2ulda0vmmgy5ey3w4ht733j83r4acut963kj5sg32j Hi, <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9us2xuyp" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>fiatjaf</span> (<span class="italic">nprofile…xuyp</span>)</a></span>. I have an idea for using Nostr&#39;s existing network architecture to allow for optionally DNS-free relays. It would ideally be applied to Nostr &amp; Blossom.<br/><br/>Relays could have their own Nostr pubkey which they would use to<br/>1. Send a new, IP address location event type to Nostr relays containing their current IPv6 or IPv4 address &amp; port number, &amp;<br/>2. Sign the data they send to clients so that clients can verify that they&#39;re receiving the data from the expected relays.<br/><br/>With this setup, for a client to find their DNS-free relays, they would<br/>1. Attempt to connect to their last known IP locations<br/>2. If this fails, they would query all relays they know the location of for the most recent location broadcasts they have<br/>3. Reattempt to connect using the new location data<br/><br/>This way, a relay could run without a domain name of any kind on a non-static IP address that could change at any time. As soon as the relay detects that its IP address has changed, it could broadcast its new location so it could be quickly connected to again.<br/><br/>What are your thoughts? 2025-06-28T02:47:22Z https://yabu.me/nevent1qqs2h0vrcdd6m85hnvmrlxdvzxyyqyskn6859u5l30wdh6x30h7gntgzyq4hc4fu3zwuw6dsh2ulda0vmmgy5ey3w4ht733j83r4acut963kjrzne2v Hi, <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/nprofile1qqswuyd9ml6qcxd92h6pleptfrcqucvvjy39vg4wx7mv9wm8kakyujgpypmhxue69uhkx6r0wf6hxtndd94k2erfd3nk2u3wvdhk6w35xs6z7qgwwaehxw309ahx7uewd3hkctcpypmhxue69uhkummnw3ezuetfde6kuer6wasku7nfvuh8xurpvdjj7a0nq40" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>Mike Dilger ☑️</span> (<span class="italic">nprofile…nq40</span>)</a></span>. I found a bug in v0.14.0 of Gossip for Linux that let&#39;s me open the app without entering a passphrase. Should I share the details in a direct message? 2025-04-27T02:31:08Z https://yabu.me/nevent1qqsdh0xrzjfkr3rys835hpjgg85na89f936c3hg7rd20x2e0kwzsvdszyq4hc4fu3zwuw6dsh2ulda0vmmgy5ey3w4ht733j83r4acut963kjy0td4v I just discovered the API client, Insomnia, which is a completely free &amp; open source alternative to Postman. I was having header issues with Postman, but Insomnia&#39;s intuitive interface helped me resolve the issue right away. Try it out at <a href="https://insomnia.rest/download">https://insomnia.rest/download</a>. 2023-10-05T22:54:49Z https://yabu.me/nevent1qqsfj3fk4wtzys97w7ams2mezdw5nt23puh9fh4eyvs92h6aznmkemszyq4hc4fu3zwuw6dsh2ulda0vmmgy5ey3w4ht733j83r4acut963kjpxqjgf For my fellow software developers interested in learning Rust, here&#39;s a great intro video to the Tokio runtime for asynchronous/concurrent programming: <a href="https://www.youtube.com/watch?v=dOzrO40jgbU">https://www.youtube.com/watch?v=dOzrO40jgbU</a> 2023-08-24T20:26:31Z