Daniel A Cummings / Daniel A Cummings is on Nostr

Full stack software developer interested in decentralized, free & open source software

Last Notes

2026-05-28 02:08:43 UTC

- reply

Thanks for the info. It is a bummer that JavaScript in browsers can't use my idea, but at least browser clients are (I assume) the least censorship resistant kind of client already.
That's cool that your library could easily be updated to add support for npub-based relays.

2026-05-26 15:18:40 UTC

- reply

FIPS has lot of potential, I hope it succeeds, & I hope to use it some day. But I share your concern about its complexity. What are your thoughts on my idea for a simple, Nostr-native, non-P2P way for clients & relays to not need to rely at all on DNS?
#nevent1q…3q40

2026-05-24 19:23:41 UTC

- reply

Agreed. How do we convince the Nostr community that DNS should be optional rather than required for connecting to relays? Nostr's reliance on DNS is its biggest weakness. I'm hoping that we'll eventually see relays & clients (with or without a Nostr protocol change) support relay connection by relay npub.
How it could work is that a user would enter a relay's npub into their relay list instead of a DNS name, but clients would still support using DNS names for relays that want to use them. The relay would use that npub to publish their current IP address & port number (IP for short) whenever they changed by using a replaceable event type. The client would use that information it receives from other relays in order to stay connected to the relay. If a Nostr protocol change is made to support this, it would involve a new, replaceable event type just for IP updates. Without a protocol change, relays could put their IP in their bio.
If enough relays did this, a user could choose to only use npub-based relays since all of those relays would keep each other's IPs publicly available by posting them to each other.
This change could also be gradual & opt-in for both clients & relays. Npub-based relays could still publish their IPs to DNS-based relays.
In addition to the Nostr network becoming far more resilient, this would also greatly lower the barrier to entry for relay operators. Someone wanting to run a relay would not have to give up personal information to a domain registrar to purchase an ICANN domain & then pay to keep it. It would be as easy for them as downloading relay software on a laptop, creating a new npub to publish their IP with, then leaving their laptop running.
This solution fits the Nostr ethos because it uses Nostr's client-servers architecture rather than being peer-to-peer.
Lastly, on a technical note: SSL encryption between client & server would be based on self-signed, relay-issued certificates that would be cryptographically linked to the relay's npub to avoid man-in-the-middle attacks.
#dns #relays #ssl #npub #p2p

2026-03-31 01:25:48 UTC

- reply

Hi, @nprofile…pqyq. I forgot to tag you in my response: #nevent1q…qa0q

2026-03-06 00:26:59 UTC

- reply

Nice, good to know. I hope to convince work to use it some day.

2026-03-05 21:07:37 UTC

- reply

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

2026-02-01 21:41:59 UTC

- reply

It's great that that option is available for more technical users. But even for them, it's only worth using with static IPs. That setup doesn't scale & isn'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.
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, & it would make Nostr way harder to censor.

2026-01-05 23:31:32 UTC

- reply

What about this?
#nevent1q…srxj

2026-01-05 23:30:01 UTC

- reply

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.
#nevent1q…ter9

2026-01-05 20:57:21 UTC

- reply

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 & port number, & 2. Sets a standard for relays to broadcast their IP address & 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 & to those that don't for maximum discoverability.
That would make running relays simpler since relay operators wouldn't need to set up domains. Domain registration is privacy invasive, costs money, & 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 & could be a simple, gradually adopted standard since it's backwards compatible with current Nostr architecture.
Imagine anyone being able to freely set up their own relay in minutes by downloading a relay, broadcasting their IP address & port number, then telling their friends to add their relay to their client's relay list? It would help a lot in getting more people onboarded to Nostr, I think.

2025-11-30 17:27:28 UTC

- reply

Connecting to relays that don't use DNS just by using IP address & port number would be amazing. It would help Nostr be way more censorship resistant & make it easier for people to run nodes since they wouldn't need to buy a domain or give out their address to ICANN or a domain registrar to do so.

2025-11-30 17:26:51 UTC

- reply

Locally store all my events so I don't need to run a local node to back them up.

2025-11-25 03:51:53 UTC

I've been having fun with IPFS (InterPlanetary File System) again, & 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 & 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.
Here's my current resume on the Pinata gateway: https://gateway.pinata.cloud/ipfs/bafkreigpjsz3x6ge7lxx3nevijv76lq2tkvh6scw7dyer5cydayqlo3dru
Note that since the file'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.
#ipfs #resume #websites #decentralized #peertopeer

2025-11-15 04:18:21 UTC

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 & ran quickly. Git's website recommends using it instead of Git's own filter-branch command: https://git-scm.com/docs/git-filter-branch#_warning.
Hopefully I'll try out Jujutsu (jj) someday for the same purpose. It looks like a very promising Git alternative since it's simpler & it's compatible with all services that use Git, like GitLab & Bitbucket, because it can optionally use Git under the hood. Here's the Jujutsu documentation if you want to learn more: https://jj-vcs.github.io/jj/latest/.
#git #python #jj #jujutsu #softwaredevelopment

2025-06-28 02:47:22 UTC

Hi, @nprofile…xuyp. 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.
Relays could have their own Nostr pubkey which they would use to
1. Send a new, IP address location event type to Nostr relays containing their current IPv6 or IPv4 address & port number, &
2. Sign the data they send to clients so that clients can verify that they're receiving the data from the expected relays.
With this setup, for a client to find their DNS-free relays, they would
1. Attempt to connect to their last known IP locations
2. If this fails, they would query all relays they know the location of for the most recent location broadcasts they have
3. Reattempt to connect using the new location data
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.
What are your thoughts?

2025-04-27 02:31:08 UTC

Hi, @nprofile…nq40. I found a bug in v0.14.0 of Gossip for Linux that let's me open the app without entering a passphrase. Should I share the details in a direct message?

2023-10-05 22:54:49 UTC

I just discovered the API client, Insomnia, which is a completely free & open source alternative to Postman. I was having header issues with Postman, but Insomnia's intuitive interface helped me resolve the issue right away. Try it out at https://insomnia.rest/download.

2023-08-24 20:26:31 UTC

For my fellow software developers interested in learning Rust, here's a great intro video to the Tokio runtime for asynchronous/concurrent programming: https://www.youtube.com/watch?v=dOzrO40jgbU