Domains are adresses, not platforms. Some platforms utilize domains. Not all domains use platforms.
Not all rectangles are squares.
Discussion
For all intents and purposes they are identities outside nostr and therefore are NIP-39
These are nostr projects, so therefore NIP-05.
domains are not nostr
When they implement the protocol and interact with it, they are part of the implementation. I am building a platform for nostr users, which also is a nip-05 registrar. By your measure no nip-05 is nostr.
It is an external identity.
All nip-05 addresses are in that case, which means it should be part of that group with the rest.
This is a simple thing. It is cut and dry. You are intentionally being dense about it.
NIP-39 came after NIP-05, that is the only reason it isn’t one
Then nip-39 should have extended or deprecated nip-05, which is not the case. It is a simple birds of a feather issue. We are talking about nip-05 and the associated design, nip-39 is a different design not even mentioning nip-05 or referencing it as a use case.
Nip-05 should be extended to include this, nip-39 is not suitable as it adds unnecessary complexity to a simple task. The only reason to suggest it is to push off an idea that might have consequences to your personal take.
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.
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.
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.
NIP-39 did not deprecate NIP-05 because NIP-05 is a way of having Nostr identifiers while NIP-39 is a way of *listing* identifiers.
If you view using a tag which is standard convention to list NIP-05 IDs as “unnecessary complexity” and prefer a JSON field (the usage of which is being phased out) then I don’t know what to say.
I will just pivot to a full offering for each nip-05 registrar I am making and incentivize it when it is used as primary with best in class offerings for all the features the competition is offering, with a discount for migration from other ones. Adding unique value on top of it.
Then it will not be an issue anymore.
Nip-39 is a way of listing non-nostr based identities on platforms that do not support nostr specific logic.
The idea that this is even a debate is telling in many ways. It very much seems to be a random hill to die on, until you look at the financial interest in all those who opposing it are running nip-05 registrars, but do not see the value in allowing an array of the same into the profile.
Nip-39 is far less implemented, user/dev friendly and its original intent seems to be for services that cannot provide a link to the npub.
For a project that is supposed to be about freedom and empowerment of the individual, there sure seem to be a lot of reasons to not do simple things that have demand and use cases.
It seems that we are also not the first to ask for similar and even when I pivoted from a new nip, to the suggested extension of nip-05, as requested, there is still a myriad of roadblocks put up by others who are selling nip-05 addresses and do not seem to want to enable any other potential entry into that space.
While NIP-39 is not popularly implemented, your specification is not even implemented so I don’t get your point.
If you intend to take any criticism that suggested changes and nothing else and twist it into your own view of “everyone that runs a paid NIP-05 service hates my proposal”, then you just want a yes-man for your proposal.
Go spend your time building services that provide value to users like nostr.land, not baseless attacks on others.
This is what I am trying to do. I want to build services and have put extensive time into design and hardware build out. Much of the implementation is planned and waiting for my time, which is scarce.
My point is, the technical implementation of this change is minimal and optional for most existing systems. It is not a risk.
I am not really trying to start a war, I was trying to get a point across that there is a viable and desired use case here that many potential contributors to the ecosystem see value in. The pushback seems very excessive considering the request and the motives of the opposition to it are more questionable than the motives of those requesting it, considering it enables more capabilities for all providers in a way that would be mainly non-intrusive. It does not have to be json, it could be an array in any preferred method of storage.
I just do not see the wisdom in preventing this from becoming available for use. It has upsides for nostr.
If you read my feedback the only thing I have proposed is that you use NIP-39 for this as it is already designed for that purpose, and not trying to prevent its use.
The current *approach* you propose is technically inferior and therefore deserves pushback.
Any proposal should be separated into concept and approach/implementation. A proposal’s idea does not have to be bad for the implementation to be bad.
Nip-39 is not really the same. It requires basically reusing the nip-05 login on a case by case basis, where the code could just iterate the array of aliases where it does the nip-05 now. It seems like more technical debt than needed. It also does not even include any reference for nip-05 ids
And that is why you extend the proposal.
This is how you get all aliases using your method:
JSON.parse(e.content).nip05_aliases
And this is how it works with NIP-39:
e.tags.filter(t => t[0] === "i").map(t => t[1].split(":")).filter(t => t[0] === "nip05").map(t => t[1])
Both fit in one line, and the latter allows you to also support PGP keys and similar
Fair enough on this, but it still faces the fact that it does not achieve much of the intended goal do to the lack of general adoption for nip-39. So basically it just goes into a black hole.
Whether it be NIP-39 or your proposal does not matter, both currently do not have adoption for multiple NIP-05s and clients will have to do equivalent effort to implement either approach
I would see them adopting an enhancement to an existing nip they support before adding one they have dismissed so far, but yes adoption would still have to happen. It is just a much larger curve for the nip-39 and nip-05 is already basically what is needed, just a small addition to support the array.
Same could be said of nip-39, but I think you see my point.
protocol purity tests are the new gatekeeping. build what works, let users decide with their pixels and sats. my canvas runs on both.