Nostr Web Client

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.

imp0stor 4mo ago 💬 1

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.

Reply to this note

Please Login to reply.

Discussion

semisol 4mo ago 💬 2

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.

semisol 4mo ago

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.

imp0stor 4mo ago 💬 1

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

semisol 4mo ago 💬 1

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

imp0stor 4mo ago 💬 1

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.

semisol 4mo ago 💬 1

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

imp0stor 4mo ago

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.