1st one makes sense. 2nd one also makes sense but it's not necessarily near 100% right? So I'm thinking of two things:

I dabbled with the idea before with kind:0 can have a new content tag that specifies a proxy npub and nostr clients accommodate this, where you keep your main npub safe and put a more exposed npub in that kind:0 value, and clients that show kind:1 would show on your main profile posts from that proxy npub with a UI label saying that this is a proxy post, and people following your main would see posts from that proxy npub as if it was you.

This is both a preventative measure and a countermeasure. Decrease the chance of compromising your main npub, and in the case of a compromised proxy npub, you'd just swap to a new proxy npub.

That's the first thing. The other thing I'd want to mention is pre-setting a 'just in case' npub, where on nostr wallet/book creation (there's a complex way and a simple way, but let's go with the simpler one), you'd generate and attach an npub to the first one, and somewhere down the line, if it gets compromised then you'd using that 'just in case' npub and people would know, pretty much 100%, that npub is actually you and not compromised. This would also help with the first scenario you mentioned.

Didn't know this repost existed x3

Yeah, I guess so, but without the new coin/separate chain and relying on its security, but rather this solution relies on Bitcoin's full security without even touching it (/putting junk in it) =3

Happy you checked it out =3

I understand that concern, or rather, it’s more of a practical consideration than a true problem. To acquire a DNN name/ID, a user would typically need at least two transactions: one to fund the Nostr address, and another to perform the transaction that anchors the name/ID. A third transaction could be used to return remaining funds.

On one hand, it is a practical issue, more so on that third transaction if it happened, for the user, but beneficial for miners, of course, since they'd get more fees x3. However, I'd counter the general presented practical issue with 3 points:

What I'd summarize from all of these points is, yes, there's a bit of a practical overhead, but it wouldn't dissuade the user from using this protocol, especially considering its counter-benefits and general various primary and secondary-effect benefits.

Side note: This is also making me think of a 'nostr-first' approach of a wallet wallet, where a wallet can be developed/released, where it would, from its seed, generate multiple nostr addresses and from it their corresponding bitcoin addresses. With altered UX tweaks, this would result in having a user use their wallet (new wallet based on this setup/scheme of course) for their normal bitcoin transactions/saving, but also can be used for nostr purposes as well (with careful UX planning as to avoid, or rather decrease the chances of, privacy and ID matching). Just an interesting thought I had while writing this reply =3

Most of them require running a separate blockchain that is not the most secure in comparison to Bitcoin, and most of them seem to be centralized (or at least not as decentralized), and having to deal with a currency that is not as solid as Bitcoin, and for those that have used Bitcoin, they're adding non-transactionary data and bloating bitcoin with said data where aside from being limited by their sizes, there might be a future that these loop-holes get removed.

So I basically looked at all their problems (from what I knew and from what people have mentioned), and thought, "Can there be something that doesn't have any of those issues?" and came up with this solution with those points mentioned in the OP.

From my pov, it seems like this solves all those issues, scales well, and is secured (without bloating/adding junk to Bitcoin), etc.

I'm basically differentiating between an "ID" and a "name", where "alice.n50.5" can be "bob.n50.5" where the change happens in nostr event kind:61600

This is a really good idea/tool imo

Happy to have nostr social posting up on my project (game mod site), and realized an opportunity that I'm planning out to have it up and running so a lot of people can benefit from with it.

Aside from that, learning a new video editing software, KDenLive, as opposed to Premier/AE (would've used DaVinci, but audio output is broken on it so had to skip it).

Also enjoying a bunch of game demos released on PC Steam.

Yup.

Unless Steam provides a developer with tickbox that removes the need for Steam's DRM system for the game being sold, and a tickbox mentioning there's no other DRM verification for the game by the devs/publisher, and a last checkbox (becomes togglable after the first 2 checks) to mention "I am selling a product that people will own. I am not selling a license to the game."

If all those boxes are ticked, the button will change to "Buy product". Otherwise, everything should be "Purchase license"

On a side note, before this change was made clear, people would/should assume (rightfully so IMO) that all of their purchases, prior to this change, are games that they 'own'.

Updated it to include this visualization

i guess so. just a nice helping visualizer to help myself and others understand WoT / this version of it at least.

(side it doesn't seem like you can change the steps in iris?)

There's also the steps function, meaning 'also show me posts from people they follow'. Example: I've set my WoT to 1 with step 0, User-A (whom I follow, and I see their posts) is following User-B (whom I don't follow, and I see their) who is following User-C (whom I nor User-A is following, and I don't see their posts).

If I've changed the step to 1, then I can also see User-C's posts.

I think I'll add that to the visualizer too.