I don't want my Communities tied to a specific domain name.
So, either Relays need key pairs. #keylays
Or Communities need key pairs so they can switch their main relay. #communikeys
I can't sell Communities that you cannot fully own.
Discussion
Relay = Server on a domain = Bunker
Bunkers can be set up to not have full control, Relays cannot.
If the Relay URL is the Community ID:
- you can be rugged
- you still need a key pair (or an account) to manege the relay
- you cannot switch domain
The solution is, in my opinion, neither of those options, it's relay-agnostic closed community networks that operate independently of any specific relay infrastructure, which is what I'm building :)
You need:
- **Community identity persistence** across any relay infrastructure (if ALL relays go down you as the user should still be able to access your community's data)
- **Full ownership transfer** (no relay should own ANY data about your community)
- **Multi-relay presence** for redundancy and censorship resistance
- **Encrypted communication** for communities (relays shouldn't know they're handling any particular community's data, as all the data should be encrypted and readable only by members invited to the community)
Yup, I do need all that :110percent: and this proposal gives that (and more) in a straightforward way:
nostr:naddr1qvzqqqrcvgpzp22rfmsktmgpk2rtan7zwu00zuzax5maq5dnsu5g3xxvqr2u3pd7qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcqqehxjupdvvcqy654mv
https://github.com/NielLiesmons/nips/blob/master/C0.md
Do you something written out, so that I can see if it's better than key pairs?
I don't see a simpler way to get to:Check:
- unruggable, unique IDs
- Nostr-native relay access
- targeted publications
- only teaching customers one management UX-pattern
etc...
I don't have anything written out, but this is how it works in Eve (my community building platform):
- each community is actually a nostr public private key pair
- users run their own relay (built in to the application)
- when they publish a note, it gets saved first to their local relay, then it gets encrypted (using nip44) and published to a bunch of relays, and using a PoW specified by the community
- the relays of other members of the community pull automatically any note sent to the pubkey of the community, and if it has enough PoW (to prevent DoS), attempt to decrypt it, and if it can be decrypted, they store it in their own relay
this has some issues right now:
- all members of the community have full access
- there's no way to kick anyone out
- every member will know the private key of the community
- a compromised key results in the whole community being compromised
I'm currently in the process (almost done) of rewriting this to use MLS instead of just having one key for the whole community, which will solve all the issues I outlined, but the current way it works is perfectly fine if those cons are reasonable for your use case
> each community is actually a nostr public private key pair
That's :110percent: what I'm talking about sir!
And it's good enough (if not totally awesome) for public communities in my mind.
nostr:naddr1qvzqqqr4gupzp22rfmsktmgpk2rtan7zwu00zuzax5maq5dnsu5g3xxvqr2u3pd7qq9kxmmdd46ku6ttv4uhxrgzfht
What do you think of this?
https://github.com/lez/nipls/blob/main/tribe.md
It's similar to NIP-29, but the logic is on the client side.
It doesn't do private communities yet, but expect some releases coming out soon.
A wiki edited by a community (tribe) is in the works.
I'm not building on NIP-29 for many reasons. It not being client-side is not one of those.
I need:
- simplicity
- targeted publication
- incentives for running relays
- unique IDs
- (backwards) compatibility with existing content, relays and profiles
- etc...
Your proposal might work, but it's not what I need.
:article: Article:
nostr:naddr1qvzqqqr4gupzp22rfmsktmgpk2rtan7zwu00zuzax5maq5dnsu5g3xxvqr2u3pd7qq9kxmmdd46ku6ttv4uhxrgzfht
:wiki: Wiki
nostr:naddr1qvzqqqrcvgpzp22rfmsktmgpk2rtan7zwu00zuzax5maq5dnsu5g3xxvqr2u3pd7qyt8wumn8ghj7mnfv4kzumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qqxde5hqttrxqxvn2y7