1. That's a quick fix. We just need to duplicate the "tweet" infrastructure in the community with a new event kind so that a post can be exclusive to the community. 2. I don't think that's confusing at all. If I follow a person, I want to see everything that person does, including new submissions to a community. I want to see all chats, all messages on live streams, etc. 3. Even if you make point 1, clients can still opt to show in the regular feed. You will never have the control to not allow posts to get out of the community.

Replies (5)

what if being in the community provides a key derived from your own nsec that can decrypt messages in a specific community? is that possible?
Sem conteudos exclusivos quem iria querer entrar na comunidade? NΓ£o Γ© mais facil segui somente as pessoas 😁😁 Essas comunidades de administradores querendo um poder centralizado πŸ₯±πŸ₯± alguma novidade
@Vitor Pamplona So here's an idea: Instead of tagging a post with an 'a' tag to request that it goes into a community, the user publishes a new event that contains (stringified in the content field) the event he wants to post into the community, like how reposts work. This community post event would contain 'a' tags of all the communities the user wants to post into, as well as the 'e' and 'k' tags for the stringified event (just like kind 4550). For the sake of discussion, we can call this a "kind 4549 post request" When mods create a 4550 post approval event, they can just copy the content string of 4549 post request event. All the tags are the same, so the person who created the request can still get notified that the post was approved. If a user only wants his post to show up in communities, he creates whatever kind of event but does not publish that event directlyΒ β€” rather it gets posted as the content of a new 4549 event If the user wants the post to show up in the main feed as well, he can publish the original event as well. I like this solution it means event existing event kind can be posted into a community, not just text notes. (like long form, media, ect.) Communities would just have a modqueue of 4549 events.
I like this proposal. This - allows any event kind to play with communities - allows unmoderated feed to be displayed - allows notifications of approvals - allows a mod queue display I have a few questions though: - After a person clicks the submit button after composing a community note, he will see two popups from the signer extension . Not sure if that would startle them as generally only one is expected - When someone zaps or reacts to a community post, we need to make sure to count it against the post request and not the approval event or the orginal kind 1 event if it exists. Is my understanding correct? - in case the user doesn't want the new note in their feed, there will be no "e" tag in their post request, right? I think it is a neat way to ask A client not to look for the actual event.
↑