It is responses like these that make me want to offer a discount to any user migrating from nostr.land, vs having an ecosystem where each registrar would have purpose and many would be adopted for users to use for their use cases.

Your obvious conflict of interest is not seeing that it is better to not fight for users, but offer unique value to them to attract their business across offerings.

It is better to embrace the logical and optional addition to nip-05 and let users have more flexibility in the setup of providers.

I do not want to approach it in a hostile way, I want synergy. But without the synergy, it is clear who the competition is and easy to identify the actors preventing the synergy.

Reply to this note

Please Login to reply.

Discussion

The general consensus on Nostr has been to move new profile information to tags or new fields. The only reason the current scheme exists is only backwards compatibility.

NIP-39 defines identities that are not Nostr native and depend on external systems like domains, other platforms, and PGP. (this was removed due to a security issue but will be re-added with a new proof format)

I would welcome your change if you used the specification that it should be a part of (NIP-39).

But you seem to be overly hostile for someone that wants synergy.

new kinds*

If I seem overly hostile, I am sorry for that. Some things are not easily conveyed via text. I am only trying to provide context of how things play out in various ways and may have been a better conversation face to face.

Man... Semi is a good dude and a really good dev. I've been glad he's participating in the discussion. I'm not particularly thrilled that you're now attacking his motivations, as I think that he's actually one of the few devs that I don't need to wonder about. (And I can disagree with him on some things but he's still around to discuss stuff.)

So, maybe chillax just a little?

We are not arguing. We came to terms. This was not meant hostile, it was a hypothetical, but I see how it came off. I was also multitasking and did not articulate well

There was a misunderstanding that compounded, that is all

I come from a background of addressing ancient issues in knowledge management platforms that were a spaghetti of interdependent modules coupled together by a custom implementation of socks and soap apis. I am not usually in the boat of being told no, because nearly anything I proposed was an improvement on the existing architecture.

Some of that may have put me into a mindset that makes me overly optimistic about my position on items. I do respect your work and contributions. I just also see the world differently and it is usually a strong point for me.

What I want is a primary nostr id for users to do the normal everyday social items, with the ability to add niche support for other activities the are also nostr based but not exclusively social networking, but kind of are. One major use case is that I will be running several domains and I want many nip-05s for those to easily manage from one npub, but also the ability to implement similar for the user base to be able to easily manage and find other users of the platforms when the identify by other nip-05 ids outside of the ecosystem they found each other. Like finding someone from Xbox live/psn on Facebook or x.

What I am picturing is a profile setup where this is widely adopted and accepted to foster inter operation without a lot of overhead or reliance on rarely adopted nips. I want users to be able to jump on my ui or primal or Damus or any other platform that handles the profile data and search and be able to easily drop a handle in and locate their buddy.

As this is already a feature for one id, I do not see the harm in them being grouped in a more attractive profile area like nip-05 vs something that seems more related to legacy providers that have no intention of adopting nostr in the near term like the support for GitHub, instagram, facebook, x and similar.

I also think that there are many many other use cases that will emerge, given the opportunity to use the concept, but I cannot say I have any idea what they may be until I see what people come up with.

I hope that helps to clarify why I am so positioned on trying to get it as an optional parameter in nip-05 over the nip-39.