In the case of Ditto, whether your posts can go a community (like this Gleasonator demo community) is determined by your NIP-05. That's your authority to post.

If there was such a thing as a NIP 5.1 (a NIP 5.0 for communities) and you could have multiple of those, it seems at first glance that the end result of such a thing would be pretty similar to the end result for communi-keys. As in you could publish to multiple communities at once, one community could span relays, there'd be moderation, etc.

Reply to this note

Please Login to reply.

Discussion

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.

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.

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

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

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.

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 nostr:naddr1qqrxuethg389xq3qwamvxt2tr50ghu4fdw47ksadnt0p277nv0vfhplmv0n0z3243zyqxpqqqp65w7fdn8s

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

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 nostr:npub1kpt95rv4q3mcz8e4lamwtxq7men6jprf49l7asfac9lnv2gda0lqdknhmz 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) nostr:npub1q3sle0kvfsehgsuexttt3ugjd8xdklxfwwkh559wxckmzddywnws6cd26p where is "behind the scenes"?

2) What's simpler than #communikeys ?