What’s the state of relays? Do any have any web management interfaces? Can you login to it with your nostr identity?
I moved to NZ last year and so far haven’t made it over the explore Australia yet aside from one layover in Sydney. I’m looking forward to Melbourne at the top of my list.
It’s a lot cheaper than $44 billion
I think we’re in agreement. If the DHT is setup in such a way that to write to it you need to use your nsec to sign the 10002 post which lists your relays with the lookup based on the npub. DHT’s are particularly censorship resistant, there are lots of kinds of DHT’s and ways to use them. We’d want to have somebody double check and help with its design.
There might even be a good way to take 10002 messages from a relay and push it to the DHT. It has to be signed, so even if the original person who created it doesn’t post it to the DHT with their app, others or relays could. The other half is to then provide a web UI for looking up npubs from the DHT. That way it would work without a chicken and egg problem.
Yes, that’s what #[5] did with his NIP-65 spec for a signed message with relays, but there’s nothing yet about putting that signed message on the nip-05 verification / identity server or in a DHT where you could look it up without knowing at least one relay for that npub.
I’m personally fine with DNS, I mean relays rely on dns for example. But I don’t like the idea that something as important as what relays you’re using isn’t signed by you.
We could host the 10002 message signed as part of the webfinger file that nip-05 uses, or put them in a DHT.
It feels like DHT’s are less fragile and dependent on a service provider.
Snark aside, it is a good move, finally following through with one of the things that made me hopeful about the acquisition.
Well with a DHT you connect to one of several known root servers. This is how you bootstrap in to tor, ipfs, or BitTorrent. Then from there that root server keeps a record of other peers and you can start querying.
In this case, the relays hosted by NIP-05 aren’t signed and often aren’t updated. Not as big an issue where folks are hosting it just for themselves like you’re doing’s but for people using the cloud nip-05 services, it is.
I’m pretty sure we could post NIP-65 events to a DHT, it’s signed, so we know somebody didn’t forge it, and then we could allow lookup based on npub.
Well if we started signing our hash chain that potentially brings up the issues that held secure scuttlebutt back. The p2panda, moderator/atacama, and earthstar projects solve that with nifty ways of signing through Merkel trees instead of a linear chain.
Your nip-65 is good. Simple, straight forward. And solves one of the problems. How do you reliably, in a signed way, state what relays you’re using. But it only works once I already know one of those relays in order to see the message.
What I’m saying, is would it be useful to not just have you spread your 10002 message to multiple relays but also to be able to push it to a DHT, would be useful.
Especially if we get to a world where because of spam, most relays end up with gatekeepers like needing to pay satoshi to join.
It’s not hard to know what relays somebody’s using AFTER you’ve started downloading their messages. But what about when first want to connect to #[2] and I don’t know which relays you’re using.
So one problem I see with nostr is that often I don’t know what relays a person is using. So people follow a bunch, in the hopes of getting some overylap. Has anybody explored using a DHT to register what relays an identity is using? It would be optional, but each nostr key pair could write to a section of the DHT, with messages signed by them, saying what their current relays are. Then when you go to look up an identity, you could get the relay address from there rather than asking all of your relays.
Lots of decentralized projects from BitTorrent to IPFS use DHTs. Although there’s no incentive structure for running them, that doesn’t seem to be a problem given the value / cost that we see in real life situations.
Has this been discussed already? I’d like to know before I dig in to making code and a proposal. Or is there a strong reason why lots of people hate the idea?
I haven’t looked in to setting one up but your post makes it sound nearly impossible for most people. You needed a weekend and a community of people to support you in order to make it work?!!? And you’re on here so you’re more technically minded than most even if you’re not a computer professional.
People say understanding fediverse user names is beyond most people’s ability. And that takes like 5 minutes in an explainer video at most.
It Is Journalism’s Sacred Duty To Endanger The Lives Of As Many Trans People As Possible
https://www.theonion.com/it-is-journalism-s-sacred-duty-to-endanger-the-lives-of-1850126997
Of course. I’ve been following it since before it was publicly announced.
I think we should setup up a DHT where you can post the relays that your key pair uses. You can also point to / from verifiers/directories.
Scuttlebutt uses prefixes like that. @ for identities (npub), % for messages, and & for blobs (off sig chain binary data). I find the convention useful.
I agree clients should also support switching between multiple identities. But as relays become the way spam is prevented it will open up the debate about what is or isn’t spam. Because it’s a spectrum
Just because it’s not possible to be sure something got deleted, doesn’t mean that we shouldn’t be designing systems that are immutable. Users should be able to request their own content be deleted, either with a new message, or setting the expiration. Well behaved relays should respect that, and actually delete instead of just leaving it up to the client which might only get a partial feed and miss the delete message.
There will DEFINATELY be relays and bots which craw the network and archive things. But in the normal flow of the app, most users, will stop seeing and hosting content the original poster wanted to remove. It will take it out of normal circulation on the nostrverse and while not perfect, is important.