Dikaios1517

https://linkstack.brightbolt.net/@dikaios1517

│Christian│Husband│Father│Presbyterian│Bitcoiner│

In that order.

Find my reviews at Nostr Reviews (npub1rsv…4dke)

Bolt12: lno1pgz95ctswvtzzq3kw0eghxwlgwrsq84tp28uqc8cewk83vhendsnz3jdum7hut3y75

Public Key

npub1kun5628raxpm7usdkj62z2337hr77f3ryrg9cf0vjpyf4jvk9r9smv3lhe

NIP-05 Address

[email protected]

Profile Code

nprofile1qqstwf6d9r37nqalwgxmfd9p9gclt3l0yc3jp5zuyhkfqjy6extz3jcpzpmhxue69uhkummnw3ezumrpdejqzhrhwden5te0wpex77re9ehx7um5wgkhyetvv9ujuctswqhnxdmyx33nxvmzxejxgvf3v5cn2dfnvvekgdmpv93xyetyxg6xycm989sn2vrxvvmnye3hxy6rvdryxvukvwrxx5exxefcxd3x2cmx8qq35amnwvaz7tmjv4kxz7fwvfexjemgw33x7mr59ehx2aqpzamhxue69uhhxurpw35kzttpwf3kzmnp9e3k7mgkhys7c

Publishing to

nostr.land

proxy.nostr-relay.app/37d4c33b6dd11e1553c3d7aabbed24bce9a50fc72f71464d39f8f52ce83becf8

relay.brightbolt.net

spatia-arcana.com

Author Public Key

npub1kun5628raxpm7usdkj62z2337hr77f3ryrg9cf0vjpyf4jvk9r9smv3lhe

Show more details

Published at

2025-11-06T07:47:19+01:00

Kind type

0 Metadata

Event JSON

{ "id": "04cd822666ba4825025380e229986a37d4436a9be2c6cc6e8f3552b6f5332567", "pubkey": "b7274d28e3e983bf720db4b4a12a31f5c7ef262320d05c25ec90489ac99628cb", "created_at": 1762411639, "kind": 0, "tags": [ [ "alt", "User profile for Dikaios1517" ], [ "client", "Coracle", "31990:97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322:1685968093690" ], [ "name", "Dikaios1517" ], [ "display_name", "Dikaios1517" ], [ "picture", "https://i.nostr.build/iQvgmYTilwvrXJVw.jpg" ], [ "banner", "https://relay.brightbolt.net/5c7bc3df8314f453c1d6a55a72c94253ad5ec414ea57082d58eaf44f405b604b.jpg" ], [ "website", "https://linkstack.brightbolt.net/@dikaios1517" ], [ "about", "│Christian│Husband│Father│Presbyterian│Bitcoiner│\n\nIn that order.\n\nFind my reviews at nostr:npub1rsv7kx5avkmq74p85v878e9d5g3w626343xhyg76z5ctfc30kz7q9u4dke\n\nBolt12: lno1pgz95ctswvtzzq3kw0eghxwlgwrsq84tp28uqc8cewk83vhendsnz3jdum7hut3y75" ], [ "nip05", "[email protected]" ], [ "lud16", "[email protected]" ] ], "content": "{\"about\":\"│Christian│Husband│Father│Presbyterian│Bitcoiner│\\n\\nIn that order.\\n\\nFind my reviews at nostr:npub1rsv7kx5avkmq74p85v878e9d5g3w626343xhyg76z5ctfc30kz7q9u4dke\\n\\nBolt12: lno1pgz95ctswvtzzq3kw0eghxwlgwrsq84tp28uqc8cewk83vhendsnz3jdum7hut3y75\",\"banner\":\"https://relay.brightbolt.net/5c7bc3df8314f453c1d6a55a72c94253ad5ec414ea57082d58eaf44f405b604b.jpg\",\"display_name\":\"Dikaios1517\",\"lud16\":\"[email protected]\",\"name\":\"Dikaios1517\",\"nip05\":\"[email protected]\",\"picture\":\"https://i.nostr.build/iQvgmYTilwvrXJVw.jpg\",\"website\":\"https://linkstack.brightbolt.net/@dikaios1517\",\"lnurl\":\"lnurl1dp68gurn8ghj7mn0wd68yurvv438xtnrdakj7tnhv4kxctttdehhwm30d3h82unvwqhkg6ttv95k7ue3x5cnwpmy9la\",\"displayName\":\"Dikaios1517\"}", "sig": "4064fc6cf15de9005455b86b14b356292f20d9738a335b9eb9a3402f5fdf94c8f8ee36845a3903b9a6394f0b4ed5c30500c39a7ec541ad3d27d5fdc8d62d52ed" }

Last Notes

2026-03-02 17:44:16 CET

- reply

Still trying to send and receive between White Noise and White Noise.

2026-03-01 05:30:59 CET

- reply

Clients won't fetch the blobs from the new server when they can't find it on the old one?

2026-02-28 20:55:31 CET

- reply

Was thinking the same thing. 😂

2026-02-27 19:25:32 CET

- reply

Very nice! I have no room for adding new physical books to my bookshelf (I can only fit one at this time), so I have been sticking to digital books for now. Driving me crazy because I much prefer physical.

2026-02-27 07:02:57 CET

- reply

Freerse is still being worked om?

2026-02-27 05:17:37 CET

- reply

LunaNode

2026-02-27 04:23:38 CET

- reply

Yeah, Amethyst properly ignores future-dated notes.

2026-02-27 03:07:16 CET

I am still immortalized on Wisp, and any other client that doesn't ignore future-dated notes.
#nevent1q…wnmd

2026-02-27 03:05:48 CET

- reply

Is the "Extended" feed just the next layer out of WoT from a user's follows?

2026-02-27 03:01:07 CET

- reply

Grab the latest release.
https://github.com/barrydeen/wisp/releases/tag/v0.1.2-alpha

2026-02-27 02:33:50 CET

- reply

Gotta say, it's really good already.
I did have it crash a few times earlier this morning, but it has bern very stable all afternoon. Makes me think there must have been a note in my feed that it wasn't handling well and isn't an issue now that it is buried beyond the number of posts that Wisp loads.
Wallet setup was really easy. Amber login was smooth. It handles notifications really well. The UI is really nice. Intuitive and attractive.
There are still some things to be worked on, but I have no doubt @nprofile…jejf can deliver.

2026-02-26 19:55:53 CET

- reply

Any plans to improve search, particularly relating to user results?
https://relay.brightbolt.net/bef4b0d365e7112ba388a221ae5375baa190a96bc46c628ad11425a9045d6f3c.jpg https://relay.brightbolt.net/444dd0d715fa43ffe095447a3bf2816b723d65eb638326f67d97e6d9cb87f3c4.jpg

2026-02-26 18:58:23 CET

- reply

Should probably ignore future-dated notes. 😉
https://relay.brightbolt.net/dcf3447e2fe407b41de0448ca9f1070315557396edc017b92333d881f1918689.jpg

2026-02-25 23:56:01 CET

@nprofile…radp now has NIP-55 login and a LARGE changelog! Anyone want to give ot a try with me?

2026-02-22 01:52:48 CET

- reply

*Came to Android.
https://zapstore.dev/apps/naddr1qqt8gmm0d3ejuun9d3shjtnjv4kxz7t5dahkcuczyp7vx29q3hdj4l0elxl800hlfjp538le09epsf7k9zj59ue2y37quqcyqqq8uzcutgh5r
More options are ALWAYS welcome, though!

2026-02-22 00:12:31 CET

- reply

This reminds me of my response to @nprofile…d5tl back when there was a lot of discussion about whether to just start calling sats bitcoins. He asked what the fuss was all about, and asked "if it ain't broken, why fix it?"
Here's what I said to steelman the argument and then give my reason why I am not on board with it yet:
#nevent1q…pjma

2026-02-21 00:28:48 CET

- reply

It's 2026! Why the heck didn't they at least go with NIP-17!?

2026-02-17 20:52:39 CET

- reply

Reply you sent or reply you received?
I think Amethyst handles replies differently regardless. It should be fetching replies others send you from your inbox relays and sending your replies to your outbox relays.
The proxy relays are for loading your feed of original posts, if I understand correctly.

2026-02-17 20:43:53 CET

- reply

I've noticed that Amethyst still shows I am connecting to hundreds of relays, but every post only shows that the note was found on one of my proxy relays, and the app definitely feels like it loads faster, especially profile information.

2026-02-17 05:58:05 CET

Changed my Amethyst setup to use a couple proxy relays and WOW what a difference!
Much faster and more stable, and profiles actually load so I know which of my follows posted the note.
My proxies: aggr.nostr.land and my own WoT relay.
Yes, I lose out on the outbox model for fetching notes from my follows' relays, but the tradeoff is worth it for actually having a functional app.

2026-02-17 05:51:07 CET

- reply

In my experience, there is usually a direct and inverse relationship between a person's disdain for Calvin and his lack of familiarity with church history in general.

2026-02-17 05:40:59 CET

- reply

But ser, he burned Servetus at the stake! How can you support such a monster? /s

2026-02-16 03:38:48 CET

- reply

So... Project Alexandria remake?
https://next-alexandria.gitcitadel.eu/

2026-02-12 17:54:02 CET

- reply

Nothing new. Anything in particular you're trying to achieve by updating your setup?

2026-02-12 06:52:38 CET

- reply

Nose to the grindstone with seminary. Still keeping an eye on how things are going round here, though.

2026-02-12 06:49:59 CET

- reply

2026-02-05 21:45:45 CET

"Wear you out" is over. "Scare you out" has arrived.

2026-02-05 04:03:16 CET

When I tell people that progressive sanctification looks like a Bitcoin price chart, it's times like these that keep the statement accurate.

2026-01-17 21:58:29 CET

- reply

Depends on your definition of "client."
#naddr1qv…re6k

2026-01-13 19:14:01 CET

- reply

"Centralize around relays" is a mischaracterization, I think. There are over 900 known relays, all being administered by different individuals. Many users run their own relays, at minimum for backing up their own notes, if not as personal outbox/inbox relays. More people could run their own relays, but assume it is harder than it really is. Tools like Nostr Relay Tray make it incredibly easy to run a relay from a home PC.
It may not be as fully decentralized as P2P would be, but it is a far cry from centralized. Not unless you would characterize Bitcoin as making the same mistake by "centralizing around nodes," because not everyone who uses Bitcoin runs a node, but instead rely on someone else's node.
I'd say that both Bitcoin and Nostr strike a good balance between ease of use and decentralization. Anyone just coming in is not required to run a node or a relay to participate, but we keep building tools to make it easier and easier for people to do so when they understand the benefits.
You say I point to Tor as a good solution. I think you may have misunderstood. Tor is the only available solution to allow you to use Citrine as an outbox relay others can read from, but not necessarily a good one. It only works if your audience is using a client that can access relays over Tor, such as Amethyst. As a result, your potential audience size is greatly reduced.
As you mentioned, though, people can and should post to multiple (at least 3) relays, with three of them being announced as their outbox relays where their notes can reliably be found. That allows people to find their notes, even if they don't have the ability to connect to the phone relay over Tor, or because the phone isn't able to connect to the internet, etc.
I think a relay on the phone is much better as a local-first relay, though, that pulls in notes from other relays for the relay owner to read in their favorite client, and that blasts their own notes out to other relays, keeping a local copy. This would allow users to browse notes and post their own, even if they are currently offline, and the relay will automatically broadcast their notes once they have signal or WiFi, and pull in more notes for their feed. I believe this is the approach that Damus is taking, but I am not sure if that built-in relay will be accessible by other clients running on the same device, or if it will only be available to Damus itself. If the latter, then I would much prefer to use a dedicated relay on the phone like Citrine than to use a client-specific relay for each and every client, which would each be independently retrieving notes and sapping bandwidth, storage space, and battery life.

2026-01-12 21:28:32 CET

It's easy to forget how far you've come in your #Bitcoin journey, until you start helping someone who's new remember how to send a transaction from their self-custody wallet.
Concepts that seem basic to me now are completely foreign to newcoiners. Things as straightforward as, "Your hardware wallet can't sign for a transaction you haven't imported into it yet, because every signature is unique to the transaction it is signing for."

2026-01-12 19:57:37 CET

- reply

Definitely. Nice and warm here in the lodge, though.

2026-01-12 19:43:31 CET

View from my "office" today:
https://relay.brightbolt.net/ae51265e472d4d6c55f18b83dd292c9c7ff33bdd69899dafb1c6835b8b34048b.jpg

2026-01-12 19:31:55 CET

- reply

Is NIP-46 finally getting more reliable?

2026-01-12 04:03:58 CET

- reply

Not sure if he's still actively working on improvements, but @nprofile…vyxv is the guy you want to hit up if there are changes you want to see that would make longform.space better.
I haven't tried out Habla again since the recent updates, but longform.space was my favorite for publishing my last few articles.
Reading, though? I would agree that Primal is top dog right now.

2026-01-08 06:41:11 CET

- reply

Thanks! On winter break for another week and a half, then back to the grind.

2025-12-25 03:32:25 CET

- reply

Go to the top of your feed and tap on "All Follows" or whichever other feed option you have selected. Then scroll doen to the subject/hashtag you want to unfollow and tap on it. This should load a feed with just that subject and you should see an "Unfollow" button in the top right.

2025-12-22 03:53:45 CET

- reply

I still have them do on-chain and lightning separately, explaining that Lightning is like their checking account, or a small savings that you build up a bit before putting the funds into long-term savings (on-chain).
As for what wallet, generally stick with Phoenix for lightning and Nunchuk for on-chain. Nunchuk CAN be connected to your home node via Tor by pairing it with Orbot, but I feel like that's something they should do with their own node when they are ready.
Another thing to note is, I make sure to get them set up with a sizeable channel on Phoenix so they are not likely to run into surprise fees for needing increased liquidity.

2025-12-22 03:41:49 CET

- reply

That's going to depend on the client you are using. It is best to remember when asking questions about how to do something on Nostr that there are a wide variety of clients that all have different ways of doing the same thing. So, always include the client you are using when asking your question to get the best quality answers quickly.
Some clients allow you to long-press on the zap icon to change your default settings. Other clients will require you to navigate into your settings options and find the zap settings there.
Some popular clients:
Amethyst - Long press the zap icon.
Primal - Go to Settings>Zaps
Yakihonne - Go to Settings>Wallets and scroll down to the Default Zap Amount setting.
Coracle - Go to Settings>App Settings and Default Zap Amount will be right at the top.
Jumble - Go to Settings>Wallet and if you have a wallet connected you can change the default zap amount.
Nostrudel - Go to Settings>Lightning and you can set various zap amount options separated by commas.
As you can see, they are ALL slightly different. So which are you asking about?

2025-12-22 03:25:53 CET

- reply

What client?

2025-12-22 03:24:40 CET

- reply

Hashtags, used appropriately and in moderation are absolutely appropriate on Nostr and useful for discovery.
You can do anything you want on Nostr, and no one can stop you from using hashtags inappropriately, though. Hashtag spam is definitely an issue here. Little will get you muted faster than using hashtags to make your unrelated content more visible. So, keep that in mind when deciding to add them to your notes.
My general advice would be to only add a maximum of three or four highly relevant hashtags to your note. Bonus points if you can fit them inline within the context of your note, rather than placing them at the bottom or top of the note. If you have to choose top or bottom, choose the bottom of the note so people can read what you have to say first, and disregard the hashtags.

2025-12-21 13:11:06 CET

- reply

👀

2025-12-20 21:11:58 CET

- reply

It's based on the pool. Any pools that payout via on-chain will have a payout threshold, because they want to minimize the amount of on-chain fees they have to pay.
The way to avoid these thresholds is to 1. have enough hashrate that you will meet or exceed the threshold more often, or 2. select a pool that will do payouts via Lightning, so you can receive payouts daily, even if they are very small amounts.
Two pools that will do payouts via Lightning are Braiins and OCEAN. Brains is, by far, easier to set up. However, they use FPPS, which means you will be paid less overall over time. OCEAN is much more difficult to set up, and requires the ability to receive via BOLT-12, and you may not agree with their stance on spam. However, you CAN choose to use a mining template that doesn't filter spam at all, if that is your conviction.

2025-12-20 21:00:51 CET

- reply

On Nostr everything is a note stored on relays, right?
That includes when you follow someone. The first time you follow someone, a note called a follow list gets created and stored to your relays. It is also referred to as a "kind 3" because different types of notes are differentiated by their kind number. The second time you follow someone, another new kind 3 is created, but it's not really separate from the first, because it has the original npub you followed on it plus the new one you just followed. Once a relay sees the new follow list with two npubs on it, it is supposed to delete the first one, so you only have one follow list at a time.
This makes it very easy for Nostr clients to display how many npubs you are following. They just need to look at your relays to find your most recent follow list and count the number of npubs listed on it. Done.
Now consider how a Nostr client like Amethyst would calculate how many people are following you. Remember, when someone follows you, the exact same thing happens as when you follow someone else. THEIR follow list gets updated to include your npub and saved to THEIR relays. So, if 200+ people have followed you, then a Nostr client has to try to find all of those follow lists, without knowing what relays they have been saved to, it just has to check as many relays as seems reasonable to the dev. But what if a follow list containing your npub is on a relay that the Nostr client didn't check, or it tried to check, but the relay was down or otherwise unreachable? Well, then its count will probably change every time you look at your follower count, because it is able to reach different relays each time.
Amethyst in particular updates the count in real time as it checks the relays, so when you first look at the number on your profile page, it will almost certainly be a ridiculously small number, even if you know you have more followers. Then, as it is able to reach more relays, the number will go up. Other Nostr clients may cache the information and update it periodically, so that you see a static number when you go to check it on your profile. Other Nostr clients recognize that follower counts are pretty meaningless, since anyone can spin up bots to follow them, so they don't show follower counts at all.
The reason Primal is able to "better" display your follower count than most other clients is because Primal does not work like most Nostr clients. Instead of reading directly from relays, Primal apps only read from Primal's centralized caching server, which in turn tries to aggregate all notes from all known relays. This means that instead of trying to look for follow lists from hundreds of relays in real time, Primal apps just have to check one server that the apps consider to have all the relevant information. That doesn't necessarily mean that Primal's number is accurate though, even though it is more stable. There still may be relays out there that have follow lists with your npub on them that Primal's caching server isn't aggregating notes from. There are also a lot of decentralization and censorship resistance trade-offs that come with using a caching server, rather than reading from relays directly. So this doesn't necessarily make Primal better overall, just different.

2025-12-19 20:45:55 CET

- reply

There are several problems with this proposal, but let's start with the most practical ones.
First, how will anyone know who to pay? Every node would somehow need to announce what Bitcoin address they should be paid at, and there would need to be a way to verify that the address is associated with a legitimate and separate node, not just someone announcing an address into the network without actually running a node. This is not an issue with mining rewards because the proof is in the data itself. They found a valid hash, so they get paid, and they put in the block that they created exactly how they get paid. Nodes don't do any PoW, though, so there is no way to verify whether an announced address really belongs to a node operator, or just some dude who wants some easy passive sats.
What happens when new nodes come on the network? They will need to store all the same data as existing nodes, so shouldn't they be paid by those who put that data on the network, too? Or should they only be paid for data that is added after they joined? If the latter is the case, then they are storing a lot of previous data that they aren't compensated for, but others were. What is their incentive to store that data?
The economics here is ridiculous. There are currently somewhere between 45,000–50,000 Bitcoin nodes. That number is not exact because it can't be. We don't know how many are running behind Tor or in other private networks, so the best we can do is estimate. Refer back to the first main issue with your proposal above. But let's just spitball some numbers here. If the proposal was something like 1 sat per KB per node, then a 1 KB piece of arbitrary data would cost 45k-50k sats with the current node count, plus the transaction fees for sending each of those transactions. Assuming this would be done using 1 input and 45,000 outputs on the low end, and best possible case scenario of 1 sat/vbyte transaction fee, the cost would be somewhere around 1,400,000 sats for the transaction fee alone, even with the lower estimate on how many nodes there are on the network. And node count would almost certainly go up, since this would be a direct financial incentive to run a node.
Things get more ridiculous from there, because 1 sat UTXOs are dust and unspendable. For a UTXO to be spendable, even in a low fee environment, it needs to exceed 546 sats, and practically, it needs to be more than 20k sats to be worth moving on-chain. And you HAVE to do this on-chain, because there is no way for Bitcoin to verify anything that takes place off-chain. If the node runners are paid via lightning, for instance, how will miners who select the transactions they put into a block know whether a particular transaction with arbitrary data included has paid the nodes to store that data or not? This means that even in the best-case scenario, each node must be paid a minimum of 546 sats for it to be above the dust limit, raising the cost to put arbitrary data on chain to a minimum of 24,570,000 sats for the 45,000 node runners to each get 546 sats, plus 1,400,000 in transaction fees, plus the transaction fee for the amount of data they are including in the transaction...
The final practical issue I will address is the fact that there is no way to prevent miners from including transactions that don't pay nodes a single sat. This is part of the basic game-theory that Bitcoin is built on. Miners select what transactions they will include in a block based on their own priorities, and since there are enough miners with different priorities, most transactions will eventually find their way into a block. Most miners operate on economic incentives, selecting the transactions that will result in them receiving the most fee income, but not always. If someone who really wants to put data onto the blockchain includes a high enough fee to the miners, without any payment to nodes whatsoever, some miner WILL pick up that transaction and include it in a block. The nodes could reject that block, but this would require a concrete consensus rule as the basis for doing so. A node couldn't just reject it because it contained a transaction with arbitrary data that did not also include a payment to the node's Bitcoin address to store that data. This would result in the nodes falling out of consensus with one another whenever there was a transaction that didn't pay absolutely every node on the network. But it couldn't be as simple as rejecting any block containing a transaction with arbitrary data that didn't pay any nodes, either. Otherwise the system could be too easily gamed, paying only one node, but all nodes then need to store the transaction forever. So it would need to be set to some standard of at least 90% of nodes. This would require each node to store a database of nodes and their Bitcoin addresses, so they could verify that the correct threshold had been paid, and this would become a new attack vector for breaking Bitcoin's consensus.
So, with all of the above practical issues, plus almost certainly a host of technical issues that would be above my head, and the social issue that such a change would be incredibly controversial, I think I can confidently say this idea is dead in the water.

2025-12-19 19:41:50 CET

- reply

I believe nostrplebs.com still offers this with their NIP-05 addresses. It would use a human-readable handle @nostrplebs.com rather than the user's npub, though.
The tough part is being able to go the other direction, so you can send a Nostr DM and it would convert it to an outgoing email. I am not aware of any services that allow both directions.

2025-12-18 09:53:38 CET

- reply

I am assuming that "free for anyone to use" is what you meant by permissionless. They are each centralized and moderated services. The only way for a blossom server to be truly permissionless is for the user to run their own.

2025-12-18 09:50:51 CET

- reply

Pretty sure both Primal's and Nostr.Build's blossom servers allow free uploads of up to 100MB.

2025-12-16 23:07:19 CET

- reply

Self-hosted and frictionless are not compatible terms, particularly in Lightning.
The most user-friendly is probably Alby Hub, by far, which is what I use on my Start9. However, you still have all of the same friction points of every self-hosted lightning node that come with having to manage your own channels, their liquidity, choosing quality channel partners, etc.
And then your Tor connection goes on the fritz, so half your channels are offline until you can get it back up, hoping your channel partner didn't force-close on you.
The constant cry is that we need to make this more straightforward for normies so they can self-host their own lightning infrastructure. Sorry, but that's not possible. Some of these things can be automated, for sure, but that just introduces a different set of friction points when the normie gets a much larger than expected fee, because they had no idea what inbound liquidity is, let alone that they ran out of it.

2025-12-16 22:59:20 CET

- reply

Most of the popular ecash wallets, such as minibits, provide a lightning address, and you use their mint by default. I believe any sats sent to that lightning address from outside of their mint would be converted to ecash from their mint, even if you have added other mints in the wallet.
The same would apply to lightning addresses from other mints, like cashu.me or npub.cash. Ecash sent to the lightning address from a different mint would first be melted and sent via lightning, and then minted as ecash from the mint that provided the lightning address. Ecash from the same mint that provided the lightning address would simply be sent as ecash from within the mint, though.

2025-12-16 01:53:56 CET

- reply

Use a client that reads from your actual relays for following people. Seems like you already figured out that Amethyst is much better for this.

2025-12-09 02:08:56 CET

- reply

This sounds like it would be a nice feature to have, but only if virtually every client supports it.
For instance, say I set this up for myself and start posting from a derived key. Any client that does not support this would treat me as a completely new user, right? So no one on such a client would be able to see my pfp or any other info that I had created with my root key on my derived key's profile page. And anyone who was following my root key's npub would not see any of my new key's posts in their feed unless they actively added my derived key's pubkey to their follow list, and even then, they would need to somehow remember that npub with no profile info is actually me, unless I republish a new kind 0 with the derived key.
Any client or relay that uses web-of-trust but does not implement this would also exclude any derived key's pubkey from the WoT by default, since that new key won't have any follows or anyone following it.
So, while it is not required for anyone to implement it, and Nostr will go on working as it had before for anyone who doesn't implement it, in practice it is next to useless unless virtually all clients implement it, since derived keys will be treated as completely new users by any client that doesn't, effectively wiping out their entire post history and social graph. Sure, all the previous notes will still exist, but that doesn't matter if the clients aren't associating them with the derived key.
I guess that means a user probably wouldn't want to set this up until there is pretty widespread client adoption.
And what is the idea for how users will safely store their root key?
My assumption is that ideally we would all want to switch to a new root key, rather than use our existing nsec, since it has been used hot. So that would require us to start fresh regardless.
Then what? We would need to get a device like a ColdCard to safely store our root key offline and generate our first derived key using that?
I can see the Nostr guides now... "Welcome to Nostr! To get started, first go buy this $150 piece of hardware. You can also build your own for a fraction of that price. You can also get started completely free by simply generating a key pair, but this is not recommended since there is a greater danger of your key being compromised, and if you wanted to upgrade to a more secure means of using Nostr later, you would need to start a whole new identity anyway."
Don't get me wrong, I think having a way to rotate keys and keep your root key offline is great, and I would probably do it myself if this method gained widespread client support. I am a bit more technical and familiar with cold storage already, though. I can't imagine this being the main way new users keep their keys safe, though.
Maybe I am misunderstanding how this works, though, and all the above concerns are moot.