Tbf, being able to verify yourself with DNSSEC TXT records isn't a bad idea. I've been suggesting it for Nostr a while back.

Just needs to be done right e.g. putting your npub in the record. Functionally the same as NIP-05 but no need to mess around with server implementations.

Reply to this note

Please Login to reply.

Discussion

Too bad #[4]​ can’t be bothered with explaining why this ‘can’t’ be done in Damus.

“The web can’t make requests” was his response to me. 🙃

As much as I respect all he's done as a builder, he does have an aggressive "my way or the highway" approach to development.

He went on a big rant against me just for giving polite feedback on OnlyZaps that he didn't like.

I had to point out to him that users testing experimental features and giving feedback is literally what a public beta is for.

Doesn't seem to wanna hear it unless someone is kissing his backside tho.

And every push seems to create another bug so I can understand him being aggressive if he’s fearful of breaking things.

Also, if one doesn’t know how to do something it can also be scary and a lot of people have a hard time keeping their composure when trying to think through things.

From what I remember you suggested to replace secp256k1 keys with ed25519. This isn’t even a serious suggestion and would hard fork nostr.

I’d love to hear the rationally behind that suggestion

Seriously

Yes I am opinionated when it comes to my client. I am allowed to do that, and if you don’t like it you can write your own client that does the “better thing”. That’s the beauty of nostr. No one needs to force anyone else to adopt their “better” idea, it should roughly all work together regardless, unless you break a core thing like signatures.

This is exactly what I'm talking about.

Why are you being so aggressive?

Please point to where I claimed you are "not allowed" to have an opinion?

I'm merely pointing out the futility of having an open beta to gather user feedback when your response to anything you don't agree with is "fuck off and make your own one then."

You're entitled to your view as much as I am mine, but I wouldn't solicit user feedback on experimental new features if all I'm doing is responding with hostility to anyone I disagree with.

I just don’t see being opinionated as aggression, but alrighty ✌️

Another strawman.

You can be opinionated without being aggressive.

You just happen to do both.

You’re the most aggressive person I’ve interacted with on this network.

How so?

I actually agree with many of your suggestions and have complimented the UX and stability of Damus many times.

In fact in the OP that started this very discussion I said I respect you as a developer and all the work you've done on Damus.

Where are you seeing this hostility exactly?

Because I disagree with you sometimes?

Why you being so hostile to me bro.

🙄🙄🙄

#[3]​ #[5]​ I appreciate the both of you 💜 you do have very different energies. Sometimes things don’t translate well, even within the same language 🫂

It’s a Larry alt angry you didn’t go in on .btc

No I'm referring to my feedback on OnlyZaps where you went on a tirade in response to my politely expressed opinion that the implementation could be improved if you only altered the UX for the user who turned the feature on, not other users, as well as listing other issues like the assumption "no one would see your likes" which is only true if every Nostr client in the world adopted your feature the same way, plus it'd create more noise as people would use replies instead of hitting a like button.

Clearly my views were shared by many as you did eventually relent on this, but even then you did so with sarcastic changelogs.

Wrt Ed25519 it wasn't a feature request but more a general musing. You talked about using Nostr keys to replace PGP. I supported this idea but pointed out the inherent weakness in only being able to use sepc256k.

The addition of more secure (and better performing) ECC curves wouldn't require a fork of anything. Did moving away from RSA fork PGP and SSH?

A NIP could establish support for both curves. Clients can easily add support, there's libraries for Ed25519 in every programming language. New keys could be generated using Ed25519. Existing keys could even use the delegation feature Nostr already has.

I implemented your feedback even though I didn’t agree with it, this makes it “my way or the highway”?

I think you’ve listened to almost everyone and tried to find the best way to implement something if you can. I don’t understand all that’s going on around here but have always felt you’ve had good intentions. Thanks for #[6]​ and thank you to all the other devs making amazing apps using nostr!

I did say you eventually relented on it, but again I'm simply pointing out that responding to user feedback on a beta with rudeness and hostility kinda defeats the purpose of a public beta.

And let's be real, so many people disliked your implementation that you knew someone would call your bluff and fork your client if you didn't change it, and many of your users would rather use that fork.

I also note you didn't respond to my rather obvious point that adding support for additional elliptic curves doesn't require a hard fork of anything. This isn't a blockchain where changing the cryptography creates a new consensus protocol.

This is a decentralised network built on top of TCP/IP where clients can add support for additional curves while providing backwards compatibility - exactly as TLS, SSH, and PGP have already done many times.

That's why my SSH and PGP keys use Ed25519 without requiring a fork.

I think it’s fair to give JB a lot of credit for his efforts and listening to feedback. Be mindful it’s all experimentation, and sometimes burning bridges is the only way to encourage change.. some people still use fax machines… why..

I think of a lot of Nostr devs may be a little raw in their responses because things are moving fast, dev time limited, and in reality, we’re slowly working towards a burnt-out like state. I’d try not to take it personally.. it’s a side effect of a new crazy little chaotic thing called Nostr.

That's how I view it as well. We're seeing all this stuff built in real time and devs of different clients have their own visions of how Nostr should work.

Since it's all decentralised, the market will ultimately decide what gets implemented as a standard across all clients and what ends up a failed experiment.

It's part of being early and it's exciting to be part of it.

I also respect that the devs are probably burnt out. They probably also see their creations as their babies, they form emotional attachment to what they've made, which is only natural.

But I don't think that justifies taking it out on the users, especially ones who are happy to beta test and provide feedback.

nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z dev of Amethyst for example works hard and I'm sure gets burnt out too, plus his experimental features have also generated a lot of controversy, but I have never seen him behave aggressively towards his users.

I've given him feedback on how I think he could better approach implementations of features and never received an angry or aggressive response or been told "go make your client then."

It's not that I take any of this personally, but if you care for Nostr as we all do, we aren't going to help mass adoption if a dev of a major client is aggressive and hostile towards anyone who doesn't like 100% of his ideas.

How is this not a valid response. The web can’t make dns requests. This was #[5]​ ‘s original concern as well if I remember correctly. Generally I try to not add features that web clients can’t take advantage of to not further fracture nostr.

It’s a straw man? The web isn’t a thing. And surely you’re not trying to put that off on me like I am misunderstanding something fundamentally, right?

Whatever limitation you have failed to articulate may not be valid and that’s why the question was asked.

Looking forward to more professional nostr implementations where the developers don’t shoe people away and who can keep up and not settle for a hodgepodge twitter clone.

What do you mean the web isn’t a thing ? Web clients can’t make dns requests so they would not be able to use this core identification mechanism you keep suggesting. Just because non-web clients can doesn’t mean we should fracture nostr clients around a core mechanism.

I’d love to hear why this is the case.

I wonder if you can with https://en.m.wikipedia.org/wiki/DNS_over_HTTPS #[4]​ can you make dns requests on the web these days ?

Yea should be possible with DoH, but probably CORS will be an issue

This is cool! I guess you can as long as you hardcode some default public resolvers.

https://dohjs.org

Seems to work, just replaced my nip5 code with txt resolver: {name}._nostr.v0l.io

which is the same as kieran@v0l.io

https://void.cat/d/WHLQSKWcZ9VfmC7YcBdUFz.webp

very cool. There you go #[3]​ ! It’s doable. I have less of an issue adding it to damus now if someone wants to PR it. Although seems a bit niche.

Generally the web is sandboxed and can’t access the full networking stack. I can’t tell if I’m talking to an engineer that understands the technical tradeoffs or if you genuinely didn’t know this. Sorry if it sounded dismissive, that was not the intention. It’s just a technical reality that web clients can’t make dns requests so the idea wouldn’t work.

Web clients. You’ll notice that this has near zero browser compatibility. And I don’t think it can even do DNSSEC.

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/dns/resolve

Web browsers are still heavily sandboxed today.

OpenAlias does it just fine and is capable of fetching arbitrary data (including Bitcoin addresses) from DNSSEC records right now and has for years.

Electrum has supported it since version 2.0.

https://openalias.org

The centralisation and privacy issues are solved by using a network of DNSCrypt resolvers. Anyone with a VPS can fire up one of those. If configured correctly they don't log DNS requests.

To go a step further you can even use ODoH which proxies your DNS requests though multiple servers in an onion routing type design so the server resolving the name doesn't know your IP, and such a setup is by nature decentralised.

You can even go a step further and run all your DNS requests through a Tor hidden service. Not hypothetical, this already exists, Cloudflare does it.

There's plenty of ways that already exist to overcome the centralisation and privacy concerns of DNS resolution so dismissing the idea offhand seems premature.

I forgot about DoH existing 🙃

By all means write up a NIP and see how far it’s possible to get. Key signing is likely the next major issue. A less stateful lookup approach would be interesting.

I’m already wondering if NIP-05 is the best approach for people long term. Likely not. Businesses maybe. I think something else can replace it in future.

Yeah I think NIP-05 works for now, but for mass adoption it will confuse newbies. And obviously the same goes for the DNS approach.

Like you say it's useful for businesses, or really any individual who has a well known presence under a certain domain, but for most people they just want some kind of username.

I'm not sure what better implementation exists that could actually be implemented in the near term through.

I personally like the .btc domains and they have their own TXT records so shouldn't be hard to implement, but they don't solve the core issues of domain based authentication, just move them to a different platform, and arguably make things even more difficult for the new joiners.

No easy answers here but I suspect what'll end up happening is basically this...

You sound like a super fun guy. 👍🏼

nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 's main concern was to keep it simple.

We already have one way of NIP-05 checking through HTTPS/json, so he didn't want to add a new way through DNS:

https://github.com/nostr-protocol/nips/issues/146

https://github.com/nostr-protocol/nips/pull/29

My concern was that there were two ways of doing the same thing and supporting both would just double the work for everybody, so we had to pick one.

The /.well-known/nostr.json HTTP request is better because

1. a single provider can host infinite names

2. it's still simple and free to host a static site once you have your own domain

3. it could be expanded with more metadata if necessary

Web support was a thing but I've implemented it with DoH which was good enough before deciding to switch to the HTTP.

Interesting… so a web based AT Protocol client would have to rely on a backend api for verification?

they host all the did documents right now... If you hosted the did document you would feel like it was exactly like nip 05

You can't host anything, they have a centralized trusted server that hosts all identities and you cannot opt-out of that. The DNS part is just a hint that you give to this central server.

Kinda seems like they just want to be another twitter and are using decentralized/sovereign/freedom/etc type language as a marketing tactic.

As of today yes... But my understanding was once production ready anyone could self host this... Sure they might decide post closed beta to only index bluesky hosted did or bluesky hosted repos, although I think a lot of their beta testers would love this, the team seems to dismiss this notion, unless I'm missing something about how did works.

I know nothing about AT tbh

Who pissed in your Wheaties?