Nostr Web Client

I'd say it's extra complexity that is not really solving any problem we have. Nostr is already pretty resilient against DNS issues.

But if someone is really out to get someone and Nostr isn't good enough then DNS isn't much worse than the entire IP protocol that relies on one central registry and hierarchy of addresses that is very permissioned.

If we are to spend efforts on this layer then I'd rather go for the entire IP thing and make it possible for networks to be assembled in decentralized and permissionless ways using local cables and wireless infrastructure, then merge together forming an ever-growing parallel internet, with decentralized routing that scales globally.

This is my idea: nostr:naddr1qqyr2wpjvd3kgvtyqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c53smcd

But, if Nostr is already struggling to get a few users and not be irrelevant, imagine something like this.

Mike Dilger ☑️ 6mo ago 💬 2

I agree that you can have your IP addresses rug-pulled just like you can have your DNS rug-pulled.

But using a keypair for a relay solves some other things. It allows a single relay to serve multiple endpoints (e.g IPv4, IPv6, Tor). It avoids the confusion of clients not knowing if a URL path is a new relay or the same relay. And it allows relays to switch endpoints in the event that DNS and IP addresses are both pulled, without all the clients not being able to know that it is the same relay.

Also CAs won't need to be trusted anymore if we use that keypair for TLS. CAs are such a scam. I've done some development at https://github.com/mikedilger/alt-tls on this, but haven't gotten it working with secp256k1 keypairs yet (I think I can, but it would not be standards compliant and wouldn't interoperate with other SSL software)

But this change is massively disruptive to how nostr currently works. Relay URLs are all over the place currently. Maybe there is a migration path, but it seems rugged with a lot of switchbacks, and you'll have to carry a water bottle to make it to the end.

Reply to this note

Please Login to reply.

Discussion

Garbage nsec 6mo ago 💬 2

But why not just blockchain domains and TLS fingerprinting or DANE? No CAs in the mix, and if you lose your IP then just pick up another, domain stays the same. It's dynamic resolution, alt-root updates are instant more or less, and you stick to URLs. Going after the entire network fabric is cool and all, but is there really a need?

Garbage nsec 6mo ago

You could have another infrastructure class (next to blossom servers, mints and all the rest) which is transparent alt root resolvers (TEE based), and that would abstract away the blockchain and the fingerprint validation for users (they just enter the URL) and would work with whatever alt root that the server op wants to publish IP and fingerprint records on. I just dunno if that's that much of an upgrade to ICANN DNS. ICANN could have turned out a lot worse than it did.

fiatjaf 6mo ago 💬 1

I'm not against that. Another of my plans is to make "blockchain domains" that do not suck using a Bitcoin spacechain, but so far that hasn't been possible and who knows if it would actually work.

I don't understand how to connect the blockchain to the real world though. How would TLS fingerprinting help? And isn't DANE a niche thing that browsers refuse to implement?

Garbage nsec 6mo ago 💬 1

The approach would be to let server operators use any blockchain naming system they want, be it Handshake, ENS, this SpacesProtocol.org (which anchors names on Bitcoin on chain), the Rootstock .rsk one, Tezos domains, Unstoppable Domains, whatever, doesn't matter, whatever the server op likes the most or doesn't hate the most.

The server op (Nostr relay server, Cashu mint server, Blossom server) adds 2 records to their blockchain domain of choice: the server IP and the TLS fingerprint. The fingerprint can be SHA256 of the Subject Public Key Info of the cert, this is pretty easy to generate from a cert they've just made.

Then you have a resolver that runs in a TEE (could be Intel SGX, AWS Nitro). You can run a light client resolver for whatever blockchain in a TEE, all you need is some early block headers to pre-load and you're good, even if the host/parent goes malicious and feeds in forged block headers in real time the resolver will not validate those, the host/parent would need to be doing the equivalent of a 51% attack to forge the block headers needed to force a false domain resolve. So you can trust that if the TEE said it resolved a blockchain domain then it did.

The TEE would get the IP and the TLS fingerprint for the domain for the client, along with a transparency report (various PCR hashes, timestamp...).

Clients would access the TEE via websocket API gateway. Basically in goes request ("yo TEE, get me hello.joe on Handshake!") and 50 milliseconds later out comes the IP and TLS fingerprint, verifiably resolved. Or faster if from cache. (A DANE cert can work too, but only for Handshake cause it's purpose built and bakes in the DS records and so there you can get DNNSEC without ICANN. With DANE the server op doesn't need to publish the TLS fingerprint on chain, the resolver can just go to the domain and get what it needs to share forward. Anyway a TLS fingerprint is fine too, DANE is kinda overkill.)

Once the client has the IP and TLS fingerprint from the TEE then it connects to the IP and the server presents its TLS. The client has to make sure the TLS matches the fingerprint, which is quick. If it does then the client knows it's connected to the server that the server op intended for the blockchain domain. So WSS/HTTPS basically.

There's other stuff like how to force re-resolve, etc. And you'd need to let Nostr users choose their TEE resolver, same way they choose their Cashu mints or relays. We're about 2/3 of the way to a protocol design for all this, started as a project for something else but the idea could work fine for Nostr too, I'll write it all up when done.

It just comes down to is it really worth it? A user could make their Nostr experience free from ICANN DNS (only add relays mints, etc. that are on blockchain domains) but at the cost of an additional infrastructure layer that needs to be paid for and all the client side implementation to abstract away the TEE.

On the other hand it can be little by little, nothing stopping such a parallel alt root universe from entering nostr one user/relay/client at a time.

fiatjaf 6mo ago 💬 2

Thank you, but you explained too much and I still have no idea of what is the job of the client and what is the job of the user in this case, concretely.

Garbage nsec 6mo ago 💬 1

For the user it's simple. Instead of adding an ICANN domain for a relay or mint, they just add a blockchain domain. So I go to Jumble, I add a relay, instead of adding wss://nos.lol I add hns://nos.haha (if say it's a .haha domain on the handshake blockchain). If that's my only relay then I'm off ICANN for relays, as an individual user anyway.

I (as the user) will at some point have had to have added a "resolver service" to Jumble so that Jumble can know where to go to get what it needs to make a secure connection to nos.haha for when I query it. I will have entered my chosen blockchain domain resolver service (one or more) in some special field(s), same as if entering blossom mirrors or whatever.

To allow me to be able to add hns://nos.haha in the first place, Jumble would have update a lot of logic (versus now). And each time I refresh the connection Jumble also has to do the back and forth with the TEE. A client like Jumble or Damus can't resolve blockchain domains on its own (especially if on a mobile device) so it has to outsource that to the resolver service. And the resolver service has to be transparent so that you don't get MITM attacks. Thus the TEE on the Nitro enclave or wherever.

Mike Dilger ☑️ 6mo ago 💬 4

This sounds to me like everybody has to use the same DNS resolver or plug into the same DNS resolution services somehow. And those have to plug into blockchain. And then you've got DANE and TLS fingerprinting, and how much other stuff?

I find it far simpler to just use self-signed certificates, set the certificate verifier to ignore the issuer-trust relationship and just verify the self-signature matches the pubkey, and then check if the key in the certificate is the nostr key of the relay you were trying to connet to. Zero external services, no DNS, no blockchain, nada. Just client-server. Of course, where my idea falls down (which I think I already explained) is that in nostr relays don't have keys they have URLs. But other than that, far simpler.

Garbage nsec 6mo ago 💬 2

DNS resolvers would be like relays, the user chooses which to add (1 or more). Some resolvers might be free, some might be paid, some might handle different chains, etc. DVMs, essentially.

For DANE and TLS fingerprinting is one or the other. If you're doing TLS fingerprint then no need for DANE. In both cases they are self signed certificates (DANE-EE if DANE). Also it's the TLS pub key that gets fingerprinted, not the whole cert, to allow for updates.

The key is (I think anyways) is that ICANN or not ICANN you will always need a source of uniqueness for human readable labels that can link to records, and there are only two ways to get that in a decentralised way, blockchain or some DHT-based Frankenstein. So blockchain it is.

But yeah, it adds another layer and I don't know if it's worth it, I think perhaps not. I actually think ICANN is pretty okay as far as systems go, they get an unfairly bad rap here sometimes.

Mike Dilger ☑️ 6mo ago 💬 1

Ah. I guess I don't care too much about shared human-readable names. I'm more of a "send me your key" kind of guy who builds up his network that way, or "scan this QR code". There is value in human-readable and memorable names, but maybe I'm not willing to pay for them.

Garbage nsec 6mo ago

That's fair enough. In terms of the price for unique + human readable + decentralised + stores relevant records... I think that's pretty much as cheap as it gets in the off-ICANN world. And as cheap as it gets still isn't that cheap.

I'm skeptical that anything not human-readable can scale, for relays, mints, or anything of the like. But yes it would be nice to have a QR-based network of sorts, that's a cool idea.

Daniel Wigton 6mo ago 💬 1

Human readable names are a great shortcut for IDs you already know. They are nothing but a web of lies for IDs you don't.

Garbage nsec 6mo ago

I think truth and lies is a few layers below. Human readability at the top layer is simply about encapsulation.

aljaz 6mo ago 💬 1

So to solve the centralization of dns we add another layer of complicated infrastructure that people need to run besides already unprofitable relays?

I dont think that solves anything besides another year or two of development efforts wasted on making using nostr even more complicated for people

Garbage nsec 6mo ago 💬 3

I more or less agree. I'm in the "ICANN is pretty okay" boat.

I think it's helpful to illustrate what it would take if Nostr wants off ICANN DNS but still secure connections to relays and mints leveraging uniqueness + human readability (without which I very much doubt any alternative can scale). The only honest option IMO is blockchain domains, and that is about the minimum cost to integrate them.

But again as you point out, what does all that really solve versus just chilling out about ICANN?

semisol 6mo ago 💬 1

The answer is simple.

All sorts of weird and illegal shit is operating over the internet already. Nostr will never be illegal in all countries, so who cares?

Worst case we start using Tor hidden services and I2P

Mike Dilger ☑️ 6mo ago 💬 3

IMHO the world is just barely entering a phase of much greater warfare and cyber attacks. You haven't seen nothing yet. I want several levels more security -- for my private keys, and also for the trust relationships. And I think we can do it.

I believe the NSA (or similar) can easily right now spy on anybody's SSL by just directing LetsEncrypt to print them a fraudulent certificate, directing Cloudfare to steal the traffic, and the only thing the target could potentially notice is that the bits in the certificate have changed (but it validates perfectly)... routing the traffic back to the real TLS server with only a minor performance hiccup. That is because routing is not trustable, CAs are not trustable, DNS, etc.

So yes you could solve this with Tor and I2P at great performance cost. Or you could lookup a relay's current IP address in the Mainline DHT every hour (and they can jump to a new IP network every hour) and use that to connect to that relay under a TLS connection that is secured with the relay's nostr key. You bypass CAs, DNS, and even though routing can be fucked around with you can just hop somewhere else. And you maintain full performance. And you didn't have to build a new packet switched loran network.

Anyhow, this isn't nostr really I'm talking about anymore, it's Mosaic. It already does all this. Not quite ready to debut.

semisol 6mo ago 💬 1

“I believe the NSA (or similar) can easily right now spy on anybody's SSL by just directing LetsEncrypt to print them a fraudulent certificate”

Read up more about Certificate Transparency

Mike Dilger ☑️ 6mo ago

Yes, yes, but that doesn't prevent. In theory it can only detect, after the fact, and only if someone bothers to investigate. And even then how do I prove that this was an NSA issued certificate and not issued to the true website? Hard one. Also, CTs have been pretty leaky so far. Either they were not enforced for all certificates, or the CT logs were run by the CAs themselves (fox guarding the henhouse) who simply don't have to put the abusive certs into the log (Let's Encrypt did this, which makes me suspicious of them). Browser enforcement is the right place to do it, but researching Chrome's CT policy refers to a deeper CT Log Policy which basically opens up the logs to as many log providers as wish to exist. The NSA probably has their own log.

And in any case, it's completely the wrong solution. When mistakes are made, people shouldn't double-down and triple-down with more crap. X.500 publication of public keys turned into publishing signed documents just in case X.500 data was corrupted, signed by the X.500 administrator. That made sense. But taking X.509 certificates out of an X.500 context was a mistake, a misunderstanding. Even worse when Verisign popped up and claimed they were the authority for the entire Earth. Adding OCSP was another pile on top, because the entire point of certificates is proof WITHOUT a trusted online service. If you have a trusted online service, you don't need certificates+OSCP, you can just give the public key and be done with it. The technology stack being deeper and more complex is IMHO not an improvement, it simply makes it more difficult for normal people (and even security researchers) to comprehend all the ways it can be used against people.

We have precident for tearing down the giant stack of kludges and starting over: QUIC. QUIC dared to dispense with the core protocol of the internet, TCP.

Garbage nsec 6mo ago 💬 2

Whoa serious? Hard fork incoming?

Mike Dilger ☑️ 6mo ago 💬 1

Mosaic is an experiment not a fork. There are no clients and no users and I'm not going to advertise it. It could become a fork but I really don't want to fork nostr. Maybe down the line it will become a fork if we can't solve the problems in nostr.

What I want is to solve the hard problems. It is far easier to solve them free of the shackles of existing software (needing to be compatible, needing migration steps, etc). Just making something that solves these things is Step 1. Step 2 can be figuring out how to migrate from current nostr to the solution. Step 2 is far harder than Step 1. But trying to solve them both together in one fell swoop has not proven successful.

The current place Mosaic is at is probably unachievable for nostr. So Mosaic can work it's way back towards nostr, perhaps by first figuring out how to use secp256k1 keys in SSL. And of course nostr can simultaneously work it's way towards Mosaic, and they can meet in the middle somewhere.

hodlbod 6mo ago 💬 2

I'm reading the spec now, liking it so far. I'm glad you separated general purpose flags, application specific flags, and tags. I'm not sure about human readable payloads, it seems like they should always be structured, especially since the only other place to put data is in tags, which is indexed (I think?) Also, limiting tags to 253 bits might be a tricky limitation for referencing URLs which might be much longer.

Mike Dilger ☑️ 6mo ago

Good point on the content-segment tags, since all outer tags are indexed, and these don't seem like they need to be. Probably have to rethink this part. I haven't really gotten to the higher layer stuff like that yet, beyond the rough first draft. I was imaginging application-layer tags (longer ones) inside of the content for stuff like this, but it's not written that way.

hodlbod 6mo ago

You'll also want to find a way to avoid duplicating tags if they need to be indexed but also used in content. Which means content likely needs to be able to reference tags in either place.

semisol 6mo ago 💬 2

secp256k1 is a permitted curve for X.509 certificates

You could allow any root that has the npub’s key, so it could sign sub-CAs or temporary keys for servers.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 6mo ago 💬 1

it's gotta be the ecdsa public key tho, 33 bytes and all that. i didn't know that x509s can be secp256k1 tho. i thought r1 was the only one that most of the things permitted. TLS definitely. also JWT only r1.

semisol 6mo ago 💬 1

x-only pubkeys are prefixed with 02

it doesn’t matter though, you can flip it

Garbage nsec 6mo ago 💬 1

Not sure if x-only have a 02 prefix like same way compressed public keys do?

semisol 6mo ago 💬 1

No, you can prefix them with 02 to get a compressed pubkey.

Garbage nsec 6mo ago

Ah right, yup!

Mike Dilger ☑️ 6mo ago

When i tried to code it a few months back, I got stuck on some PKIX assigned number that didn't have an entry for secp256k1. But I'm recalling this from memory so I could be wrong here.

Emperor Kuzco 6mo ago 💬 1

I'm just now figuring out how to us Gossip because both Damus and Primal have failed me. I downloaded a brief tutorial from Rumble that I believe you made.

I'm trying to figure out 1/4 of the options and settings it has. Bare with me, I'm retarded.

Mike Dilger ☑️ 6mo ago 💬 1

Gossip will fail you as well I'm sure!

It works well enough for me most of the time but something about the libraries it depends on interacting badly with Debian testing Xfce sometimes freezes my desktop as I'm typing into it. And it frustrates me. I don't think it is my bad code, but somehow I'm triggering a deeper bug.

The lower left "lights" indicate if something needs to be handled.

The circle buttons on the right of a post go into that post's thread view.

Relays is it's own complex set of pages.

People Lists is where you define your feed views.

Emperor Kuzco 6mo ago 💬 1

It's more complexed than any mobile client I've used. Is there an option for spell checking? I only want to appear half retaded.

I have relays set, nPubs I follow, fonts bigger in the UI, and enough that I can function pretty well though. It took me almost a year to take the plunge into Gossip because of the complexity and not knowing all the technical lingo.

Mike Dilger ☑️ 6mo ago 💬 1

Spell checking! Brilliant idea. No.

Desktops having more screen real-estate lend themselves to having more complex UIs. A tool that you use a lot and know well should have a complex UI. A tool that you are new to should have a simple UI. The Ideal UI would get more complex as you used the tool. But I'm not a UI developer, I actually abhor UI development, so I had other people work on the UI as much as I could: nostr:npub10000003zmk89narqpczy4ff6rnuht2wu05na7kpnh3mak7z2tqzsv8vwqk and nostr:npub1hlq93jdtkfg29a8s7fqzzzh82q3pkc20rxucwt4geh6e56wk3y2qxdz5wg . Now and then I meddled and messed up their plans so I take all the blame for UI problems, and they get all the praise for UI brilliance.

Emperor Kuzco 6mo ago 💬 1

This maybe another dumb idea but I cannot highlight and select a given not text copy/paste it into a reply within the app. All in all Gossip is pretty cool and I'm glad I have another solution (probably more secure than mobile) rather than a mobile client.

Mike Dilger ☑️ 6mo ago 💬 1

You want to cut-and-paste images? I started on that but didn't complete it: https://github.com/mikedilger/gossip/issues/995

Emperor Kuzco 6mo ago 💬 1

Say I'm looking at your reply right in front of me as I am and I think you have some great information and was wondering if I could just select the specific text that I highlight and copy it. As of right now (I'm using an AppImage) I can highlight your text text but I have no option to copy or paste it. I even tried contol C/V with no wookie.

As an example: If I write a bang up post and want to save it to my offline notes I am unable to select my text and copy it. I can write something offline and control V it and it works.

As for pics, I have a totally different idea that I proposed to the code slinger of Damus and I found out that Primal was able to pull it off. If I can find my old note describing what my idea was I'll post it to you.

Mike Dilger ☑️ 6mo ago 💬 1

Are you using version 0.14? I think cut-and-paste works in 0.14. Maybe I'm wrong and it only started working later.... and if so I should release again.

Emperor Kuzco 6mo ago

Yes, currently on .14. Again it is the AppImage, not sure if that matters.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 6mo ago 💬 1

the final boss is not domain names but IP address ranges.

it would be simple to create a distributed registry that associates a relay npub with an IP address, but if IANA for whatever reeson is leaned on to yank the privilege to some IP address range, what's important to understand is that this is INBOUND connection is snuffed out. OUTBOUND is still ok, so long as there are relay/middlemen to act as rendezvous points.

honestly, i doubt that they can really police IP numbers as a means to stop a network from functioning. they'd sooner do it to shut down Tor, for a start, but they won't because every government spook agency depends on having that tool as a means to cover their activity, among many other tools, it is still one they can and surely have used.

forget about DNS, all you need to do is have a distributed registry of relay/server IP addresses with the pubkey, and the issuer, from this address, signs it. replicas can then be queried for a pubkey, and then you find the addresses associated with the key, and connect this way.

tor hidden services already function by use of a PKI, just the same.

names is a separate layer, this requires something like a blockchain. probably it would be a perfectly fine use of the small space needed, like an OP_RETURN gives you 80 bytes, that's a pubkey, a name up to 48 characters long, and can be signed by the pubkey itself. then there needs to be some kind of first-come-first-served scheme of property claims of names, and those directories i spoke of with the IP/key bindings, can use a common algorithm to read off the claims on chain and only allow the first claim, and then using a key transfer protocol (i assign this name to new claimant) which would also fit in an OP_RETURN.

i don't think that it really needs to be monetised, if you design the protocol to be robust, people can build their own implementations of a marketplace in names at this point, but if the name hasn't been claimed, you only need to pay a bitcoin transaction fee.

Garbage nsec 6mo ago 💬 1

>like an OP_RETURN gives you 80 bytes, that's a pubkey, a name up to 48 characters long, and can be signed by the pubkey itself.

That already exists in the form of spacesprotocol.org . On chain is like 80 bytes, the root of the merkle tree, then ZK proof linked off chain for the domain records and subdomains, which they have a DHT for but can be stored anywhere really.

It's pretty neat, the team behind it are legit.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 6mo ago 💬 1

there ya go! yes, of course there has to be name records for stuff like subdomains and claims and whatnot. and you need a resolver installed somewhere on the device, either in the browser/app or as a system service.

but i can see such a thing becoming eventually a big deal.

also, IPv6 addresses are so numerous that they are basically worthless. at this point the minimum you can buy is 64k worth of them. presumably at some point people will start trading them at units of 256 later on.

the thing about IP addresses is that you essentially only have to have a neighbour recognise your address and the ARP records propagate outwards from that, very quickly. it's extremely hard to control it centrally because it is an extremely decentralised protocol, practically peer to peer, and originally born in a single LAN.

anyway, i just don't think there is any reason to be concerned about DNS, and it's highly impractical to police addresses, and with an address you have inbound connectivity. there only has to be about ~20% of nodes in a p2p network (by bandwidth capacity) for a p2p network to function perfectly fine, if you have a rendezvous protocol, and virtually all p2p networks have a rendezvous protocol, because you can't count on all nodes having inbound addresses in the endless shortage of IPv4 that has been the doom of the internet for which IPv6 was the solution that has never been fully implemented but ... lol... dooom! the IPv4 is running out! be afraid, be very afraid. shit, a whole generation has passed since that dooming started, still nothing.

Garbage nsec 6mo ago

The problem is the resolver. You have to first resolve the Bitcoin chain, and with an SPV in theory it's lighter, all the block headers you need are like under 100MB, but still quite an ask for a nostr client to integrate. Also in an iOS app you're kinda screwed because it'll stop resolving when the app isn't open then you have all this catching up to do and cant do much until it catches up, cause the on-chain commit for a name can be updated any time. Then you need to hit the off-chain DHT and follow the ZK chain back to the name on chain.

Resolver pretty much needs to be in cloud, which is its own kettle of fish.

ChipTuner 5mo ago 💬 1

I'm in the ICANN can GFY boat. The internet relies on a central authority for which governments abuse routinely to control the web.

Garbage nsec 5mo ago

True, but also true is that it could have been *so* much worse.

OceanSlim 5mo ago 💬 1

HNS is a joke. It's not possible to generate SSL certificates for HNS domains and HTTPS:// protocol is not available for their TLDs. You also can't resolve them with a regular browser.

Garbage nsec 5mo ago 💬 1

For Cashu mints etc., there is no need for a browser. You do need TEE resolution (node in TEE) instantly processed via DVM or API though, that's my point.

You can generate DANE-EE certs, which are better than CA TLS certs.

Garbage nsec 5mo ago

To add, what does the “S” in https even mean? For most people it means secured by TLS as attested to by a Certificate Authority. Which in the nostr scheme of things should raise eyebrows.

DANE-EE is about self-signed authentication for TLS as the secure tunnel itself. But you still have TLS with Handshake, it's just via DANE-EE, which is an objectively more secure way of going about it, given that DNSSEC is baked in all the way through.

So any argument that HNS isn't inherently secure doesn't hold up, at least for headless client-to-server or server to server where you don't need certificate authorities or Chromium devs on your side.

That said the Handshake chain itself is not so healthy, which is another matter and is the real reason to go and look for something else.

PPRGB 6d ago

I wonder how you get your ip stealed ??

I thought it was unique