Beautiful reading!
As you and nostr:nprofile1qqs8eseg5zxak2hal8umuaa7laxgxjyll9uhyxp86c522shn9gj8crspzdmhxue69uhhyetvv9ukzcnvv5hx7un8qyxhwumn8ghj7mn0wvhxcmmvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hs5l62g9 already know, I think that topical/private/paid relays are the right tool to implement communities, at every level.
A "configurable client implementation" (selected relays for single feed, and granular access to feeds) paired with a personal relay is my top wish for Coracle on the functional list, because we could push it to families and so offer a healthy way to introduce young people to digital communication. This format can easily expands to schools, sport groups, church, etc. Raising a new generation of conscientious, privacy and free speech minded people, can really change the society for the better.
I share all your values and goals, so now I'm doubly excited to collaborate to push Coracle forward!
🤝
I'd love to see/do a quick brainstorm of what "selected relays for single feed, and granular access to feeds paired with a personal relay" would look like. These innovative, multi-dimensional interfaces seem very hard to locate in the design space. Maybe part of the problem is that right now very few relays are usable without filters, and it's impossible to find the ones that are.
Here's a quick sketch. I'm imagining that content would be 1. public, no group, 2. posted publicly to a group (whether someone is allowed to do so depends on the client's implementation of group moderation), or 3. posted privately to a group. Public notes (whether posted to a group or not) could be cross-posted to a group. If cross-posted, it would show an indication of from where and by whom. Private notes would be visible only by group members (protected either by relay or encryption). Notes from groups you're a member of — or following as a non-member — would show up in your main feed with an indicator of where it was posted.
This gives the publisher/group owner/group members the ability to control 1. the context/audience (group) of a given note and 2. who sees it independently.
Looks cool! 🔥
But I was thinking about a different scenario: a client deployed with a hard configuration that locks a list of relays (family, sport-1, sport-2, church, friends-children, friends-parents, ...) that can "auto discover" which relays show to the user testing the access authentication.
I was also speculating if this config can be managed dynamically, for example, using only one hard-coded "bootstrap relay", write accessible by an admin, where he can post kind:10002 events (NIP-65) to populate and update the relays list.
There could be a mechanism (via giftwrapped messages?) to config the accessibility of public relays.
Of course, the two worlds can work hand in hand. I will explore both by design and share the results with you.
