i don't support it :) i am a douchebag i guess.
Discussion
Nip-05 is very useful even if other decentralized variants emerge. What reasoning is there to oppose it, since it is an optional parameter to extend existing functionality and does not require a code change from existing implementations with it being optional?
i understand that Nostr Addresses (NIP-05 IDs) are very useful. i was the very first person to sell them as an identity service provider on nostr. i founded nostrplebs.com in December 2022.
simply put, i think NIP-05 ID aliases defeats the purpose of having a displayable unique identifer as it makes them no longer unique.
what's the end game here?
i have 1 display name. if we allow users to have 100 nostr addresses, then why not have 100 display names too?
it makes zero sense to me. i'm sorry.
It is so that users of multiple services can be identified on each portal uniquely. Such as gamer tags or other name spaces they use in a nip-05 implementation. Sometimes the length of existing nip-05 is not suitable internally when using legacy software that is integrated and unique short names (before the @) are useful on the platform.
I have intentions of launching several portals and a few of them would thrive much better this way.
Also, it allows users to search for these verified aliases without it being the primary display on the profile. It is about enabling more use cases that are not easily enabled now.
it's an interesting use case, but i think it is more negative than positive. for example, it makes it easier for scammers to impersonate someone if you can have multiple nostr addresses. all someone would have to do is spin up a few domains and use a few identity providers and they could have many aliases. some may think the more the better or the more they have, they more legit and that's simply not the case.
to me it sounds like you want to display nostr badges as gamer tags. they were designed exactly for this reason. nostr:npub1qqqqqqyz0la2jjl752yv8h7wgs3v098mh9nztd4nr6gynaef6uqqt0n47m created them as a method to cosmetically display somemthing on a user's profile. i feel like you should go this route.
anyways, depending on the client, you've always been able to search for non-active nostr addresses. they wouldn't show as active or / valid though.
for example, im still derekross@nostrplebs.com and before that i was @derekross.me. you can search for those addresses on some clients.
+1 for Badges, specially since this seems to be cosmetic in nature
I plan to use badges, but this is about synergy between platforms and users ability to have varied identities for purpose. Not everybody wants their gamer tag to be the same as their public posting identity, and these will already be using the nip – 05 identifiers which have an entire ecosystem of verification and code written to handle them, since the users will be registering a wouldn’t it be good to allow them to utilize that more effectively in the ecosystem. We want to enable more platforms to adopt Noster and embracing varied used cases will help enable that adoption. We want to use standard identifier that are already embraced by users on NOSTR and just extend that capability to be more adaptive for the users and the platforms that offer registration that ties directly to their NPUB.
if you don't want your gamertag to be your public identity, then nostr addresses don't solve that. the identiy is still the same. nostr addresse are just human readble formats of the same identity.
if you're a dick in a video game, i can lookup your nostr address and get your public key. an alias doesn't solve that. a different public key does though.
It is not about anonymity, but division of identity. On Xbox live or psn, you may not want to be Derek Ross, might be bigrossman or w/e. But you may want to be discoverable and verified as both, using the same npub.
My goal is to enable more use cases and adoption.
Basically it would you rather the user be able to use both your service to register and my service to register rather than have to pick one because they both offer different things to the user and with seamless integration via aliases they can pick which one is displayed as their primary identify action on most based portals
That is a fair point, but . . .
It also brings up the key issue about . . . well, keys. It is frictionless to spin up another keypair. Is is NOT frictionless (in most cases) to get a nip-05 from a respected, established, trusted domain/relay/whatever. Sure, you can just abuse the nip-05 services like the spambots do, but, if you note . . . they all come from the same core domains, which . . . would be handy to have to block domains entirely, and I don't see a good way to do that at a lower level that some clients (very poorly implemented) block/mute lists.
Badges are cool, but also useless to me since they are way easier to make and collect than domains.
This isn't an either/or. It is a both/and.
Collecting identities seems odd. Are there any examples where someone would collect different identities on another platform that you have as an example?
Some users want a different id for social, gaming, Pinterest and other utilities because they desire different personal brands, but also users may want nip-05 providers with the same name due to add on features of the registrars that extend their use cases across their interactions on nostr.
We could further limit it down to 10 to 25 aliases in the spec by 100 allows for the network to grow an additional use cases to be invented. I don’t really care if it’s 1025 or 100. I would like to see the ability for users to have the utility along with the providers to have a path to not needing them to use it as a primary identifier on their profile if they desire a specific aesthetic as a user.
Another use case is that if you own or run Multiple Companies, you may want to have a nip identifier for each of the domains related to those companies. Let’s say for your registrar and five other projects that you run, you may want to have the same short name at multiple domains to identify that you’re a good actor for each of those services
Collecting identities is odd . . . to you.
To me, this gives people or groups more options with a simple, ignorable if you don't want to support it, array.
I could say that using one identity across all your stuff is actually, as far as I'm concerned, wet dream of the snoopers charter fans. 😂
Yes. You can collect a decent amount of metadata and use that to corelate an identity, though. That's hard to defend against. But... I am still a fan of various identity for various uses.
I want a verified account that verifies my upcoming nostr portal, nostr gaming project, future podcast, personal website, and other projects I am affiliated with in one npub.
It can show more of a trust across them and unifies the account as I wish. I could do individual accounts as the root domains and brand, but my administration account can be unified.
They can do that now, anyway, and it hasn't prevented any spam at all.
But, for example, if someone has a nip-05 from The Forest and GitCitadel and Alexandria, I, personally, and very reasonably sure that this person is who they seem to be, since I am familiar with all those particular corners of the web.
If a bio displays a bunch of random nip-05s that I am not at all familiar with, it isn't hard to discover that they are junk domains being spun up.
I also think this is another avenue of discovery, which, I think, is going to be more important in the future as more and more relays are spun up for ever more niche communities.
Please forgive me as I am on mobile and mining fiat right now, so I have limited access to resources
For why? What possible reason do you have for not supporting that?
I honestly cannot think of any other than just stubbornness at this point.
I want to see how many nip05s an npub is rocking at a glance. Plus, this is also going to be necessary for further AUTH stuff in the future, so . . . we better get on it.
this is not necessary for AUTH lol
Necessary? No.
But it could be an easy way for communities to self-ID on related communities.
If not, WTF is the point of it in the first place?
it’s a username
Yes, and why should we not have multiple usernames?
Or Keys, for that matter. (I still think we need better key management, in general.)
Because it’s pointless. This should be a NIP-39 extension and end there
i was thinking NIP-58 badges, but NIP-39 is also a good alternative too, probably even better than badge.
My thoughts, if it is nip-05, why re-trigger the verification code in another nip functionality.
I just want to have them be checked like all nip-05 addresses are for primary display and adoption is optional.
you'd already be asking clients to implenent this change, which no clients support since it's new, at least with badges, half a dozens clients already support this.
As an optional parameter in the json it can be ignored until they feel it fits their needs. Only those who see value would need to adopt it.
I plan on using badges, but for instance, game clients from the 2000s have somewhat low character limits, so I was planning to have all users be unique nip-05 on my platform and use it to limit characters. Then they would get badges anyway on the npub, but with the ability to display aliases, sites could offer the ability to show all specified nip-05 addresses for all services, mine and others, that the user has registered nip-05 for. Allowing better identification verification.
It is not a question of if there are other more clunky ways to do it, but about streamlining it for better platform adoption and verification in a way that is useful to users and platforms
Great points!!
No client supports it. Yet.
I know of at least two that ARE going to support it eventually. Worst case, they just fork everything and then things get silly, but at least in this case, the extra list stuff isn't going to muck about with previous iterations.
There is no loss here. It benefits some people without interfering with anything else.
How is that a bad thing?
Seriously.
It could be a nip-39 extension, no reason why not, but clients should still handle it like they do 05s
I just read nip-39. I will politely disagree, unless you want to just mash domains and platforms together, which I don't think is technically correct, but begs the question...
Why not mash them together, then?
#multinips.
Domains are platforms
When they natively support nip-05, they should be handled as nip-05 in the same context
Domains are adresses, not platforms. Some platforms utilize domains. Not all domains use platforms.
Not all rectangles are squares.
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.
I don't know squat about nip-39, so I can't interject much.
It is around additional identities from centralized platforms where you post something and it verifies your identity or ownership of that centralized identity whereas my proposal is for the nostr based nip-05 which should just be an extension of the original nip-05
This makes sense from a simplicity of design standpoint.
Sorry but you're full of crap lol! It's not pointless at all. It may be unnecessary for most people. But not pointless for everyone.
I agree to both of these.
And it's NOT just a username unless I have my nips mixed up (wouldn't be the first time). It's a method of verification and identification that verifies control of an Internet domain or resource.
Yeah ID between communities or between individuals is a key usecase.
It is not needed for nostr side auth, but in my use case a full nip-05 w/ domain does not work with legacy apps that I PMP an to integrate, think 2000 lan multiplayer games that have a 16-32 char limit. So for me to auth, I plan to use my local nip-05, without the domain, just the id, to tie a user to the npub.
How many Display Names are you rocking?
😂
#metoo