Thread

Interesting approach with NIP-05, I need to check out Ditto but we are doing a similar thing. > you could publish to multiple communities at once, one community could span relays, there'd be moderation, etc. that's the plan! working on a spec and a couple of implementations (chachi, Zapchat) rn

we're also adding blossom servers and a mint. if someone gets onboarded via a communikey they automatically get the ability to send/receive ecash and upload files.

That's retarded. NIP-05 relies on DNS, you're filtering any users that use tor-only nostr etc

That's cool, we are already using NIP-05 as a whitelist for using our outbox/inbox relay and blossom server

If i understood correctly, the user can still use everything tor-only, only the community relay or blossom server needs to check whether the user pubkey matches the whitelist and doesn't involve any interaction on the user's part other than sending an auth which is independent of the way you connect to the relay

NIP-05 definitely relies on DNS, it doesn't allow onion services Nobody interested in decentralization is using it. For example, people who only use tor-compatible nostr implementations aren't using it because DNS isn't tor

Yeah, ditto is interesting, I think Alex is going in a pretty similar direction. The NIP-05 as I understand it is a sort of a placeholder to speed up the fediverse port (this all started on Mastodon) but how it's been evolving behind the scenes now I'm not sure, maybe some synergies.

Sure, NIP-05 relies on DNS, my point is the user doesn't need to interact with DNS, only the servers

The user can't add a working NIP-05 address to their profile without interacting with DNS. Working NIP-05 addresses are DNS addresses. NIP-05 addresses do not work if DNS isn't working.

False. They don't even need to add it to their profile. The NIP-05 is valid regardless, as long as the entry exists with their pubkey. One user can have many valid NIP-05s whilst only adding one or none to their profile

Are you sure that all applies to ditto? Same app that thought a persistent notification dot begging me to add NIP-05 to my profile wasn't enough so they added a banner that straight-up lies and says I don't have a username, while my username shows up in the same app and there are multiple valid NIP-05 entries for it out there just not on my profile

I like the idea of NIP-05 resolving handshake.org domains because then you don't have to change anything about the UX or the flow, clients when noticing a handshake domain just have to add the "hns.to" before the URL and they'll find the json, so for example me.nostr/.well-known/nostr.json just make it hns.to.me.nostr/.well-known/nostr.json and done. This is idea usually loudly booed because another chain. But it's a pretty frictionless update.

I don't know, never used ditto so I can't tell you. We host our own relays and blossom and NIP-05

Sounds pretty frictionless but in the long run the best solution I see is a DNS alternative built on doggie coin. Wrote about idea in this article View Article →

If the ditto filter that was mentioned works with every known NIP-05 registry as you said, that wouldn't be so bad

You don't need domain names to make Communities work. I don't want to rely on one relay domain for Community IDs or the publication authority of members. They bring all this obvious attack vectors and allow for about zero flexibility. I want to able to optionally set, per content type: - a fee - a filter (think @Vertex etc...) - a list of "roles" that can publish that content type - a retention time - exclusivity to that community VS interoperability with others NIP-05, NIP-29, NIP-72, ... all don't even come close to allowing for that. #communikeys do.

I think some stuff Alex is updating behind the scenes is very much along those lines, might be worth giving him a shout.

1) @Alex Gleason where is "behind the scenes"? 2) What's simpler than #communikeys ?