Replies (47)
It is an excellent idea, but I didn't see it on Amethyst at all (the community, not the posts). Would it work creating it on there?
On Amethyst we can ask
@Vitor PamplonaSo harsh for a 3-week development time. :(
What's the confusion it causes? I have never heard about community confusion before. You are a pioneer. You are onto things no one has ever seen or done in this field. You can shut it down or help try build it with your knowledge. We just need more details and probably some help with dev hours.
We can see a link to Jacks Satellite community in his posts but it doesn't show up in Communities on Amethyst. Are we all confused?
That’s not actually the problem when you post to the community on satellite, it shows up in your regularly feed on all of your clients completely and totally out of context.
The fact that it shows up on other clients is actually the problem
You know, I’d love to try to build it, but I can’t because it just doesn’t work. The confusion is when somebody posts to the community on satellite. It goes into their main feed and shows up on all other clients as a standalone post.
If it’s going to do that, there is literally no point to trying to create a Community with it.
It would be like having a Reddit community but when you post to it, it shows up in your Twitter feed completely unlinked to the community itself.
I get that it’s new, but it is completely and totally unusable a total train wreck and makes absolutely no sense to anybody tries to use it
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.
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?
Hey
@Jack Spirko I'm the developer of Satellite. The issue you're describing is not something I can change on without changing the way that communities work on a protocol level (NIP-172 specifically). I actually agree with you there there should be a way to control which posts show up on your main timeline, and I was talking with
@Vitor Pamplona about this a few days ago. These communities are very new. I'm sure we'll get the UX hammered out soon.
Eles querem conteudos exclusivos 😁😁😁
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.
> Não é mais facil segui somente as pessoas
Depende. Eu espero comunidades com 1000 moderators de vários níveis. Seguir a comunidade faz mais sentido ao invés de ficar atualizando a lista de follows com a lista de moderadores o tempo todo.
Num outro caso, talvez vc só queira ver os posts de uma pessoa referente a um tópico. Seguindo a comunidade e não a pessoa, vc filtra os posts irrelevantes pra vc.
What you said in number two makes it clear you don't comprehend the problem, at all. I assume that this will be worked out in time. My comment was never meant to bash anyone, so stop taking it personally or some such shit.
This is just how I talk, something doesn't work, so I will wait until it "gets its shit together".
The solution exists. There is a client called blogstack. It is like a Nostr version of substack. No one really uses it and it needs work if anyone is going to but it "works".
In that I can connect with my keys, if any of my followers do so they are connected to me when they do etc. But when I post an article it does not show up in my primary feed. So it can be done, I guess.
Why do you go try to use the freaking thing and then may be you will understand the problem. It isn't that I don't want people on iris or snort or whatever seeing posts to groups, it is...
1. They likely do not want to, communities are niche specific.
2. The way it displays, I would call them disembodied notes. Consider it like comments with no reference back to the original note. But worse because they also don't have any indication that they are related to a community.
Again try using the damn thing and may be. you will understand.
Interesting — I'm not suggesting to encrypt the event though.
What do you think about this being a way to control community posts showing up in the main feed?
Cause (I agree with you) that we need new event kind for community posts, I'm just saying why not use the new event kind to wrap up the event you're trying to post into the community.
That way communities are compatible with all event kinds. Just wrap em up
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.
Our problems are different
The kind 1 post as the first post, as
@Vitor Pamplona pointed out exactly, it appears everywhere so people I follow I can see everything they post.
This is a design feature, not a bug. Of cause like all things, there’s always different school of thoughts, you can’t make everyone happy.
For this “4549” event it can be the exact same thing just like the existing kind 1 with “a” tag, but it’s a community only post. This could work.
I think doing a kind 1 copy is the easiest thing. We did the same for live activities.
> 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
Good point. Although when posting an existing note into a community, the user will only be signing one event. (that's actually one additional benefit of this approach, it allows users to "pull" other notes into communities with kind 4549 events, just like how mods can pull events into communities with kind 4550 events)
> 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?
Correct, that's my understanding as well. Zaps/reactions would go to the post request, since that event will be present and indexed on relays.
> in case the user doesn't want the new note in their feed, there will be no "e" tag in their post request, right?
Actually I think it *would* make sense to include the 'e' tag so that clients can query to find all the post requests for an event (this would be relevant when an existing note was posted-requested into a community).
> I think it is a neat way to ask A client not to look for the actual event.
Well clients that don't support communities are not going to pull the kind 4549 post-requests in the first place, right? So they'll never have any reason to look for the actual events. And clients that *do* support communities won't need to look for the events since they already have the actual events (they can parse them from the content string)
Thanks for the in-depth response, and please let me know if I misunderstood any of your points!
I agree with both of you, there is a lot of value in posts being able to be seen outside of community's as well. That is a good thing.
The only thing that would be better is if the user could control that behavior and choose which posts to show on main and which ones to keep as a community-only post.
> For this “4549” event it can be the exact same thing just like the existing kind 1 with “a” tag, but it’s a community only post.
Yeah exactly. The only reason I suggest having it be a "post request" that wraps an event (just like "post approval") is so that all the existing event kinds (e.g. long form, media) and whatever will be invented in the future is compatible with communities. Cause it would be boring is communities could only work with basic text notes, right?
But don't you think it would be boring if communities were only compatible with basic text notes?
Oh.. I didn't mean to be only compatible with the new event kind. It's still compatible with everything. But if people want, then there is a kind that would appear only inside the community.
This is great. Thanks for the responses. I am good with this proposal
Ah I see. But other event kinds would still appear on main by default, like if there was a community for kind 1063 photos. I guess the question is how big of a deal this will become in the future as communities develop and specialize in non-text-note events, i.e. if having a general way of preventing an event from showing up on main is worth the additional complexity.
Currently there are long form tagged with “a” tags too.
Yes, support all currently and future nostr content types is necessary
I really think there is no need to exclude the community post in the main feed. in some sense, community is just like hashtag, you will never feel strange that people post something with hashtag appear on the main feed. community is just another way to do content filtering and classification.
Would/could a “repost” action post a community post to a user’s main (I.e. kind 1) timeline?
Could allow users to post to community and then broadcast to all followers.
Yup. It’s a design feature.
This was actually my initial take as well. But thinking about it a bit more, I don’t think it’s just filtering/classification. We already have hashtags and lists for that. Communities have different norms, formats, inside jokes etc. which make people reluctant to post if they know it’s going to main
Sure you could always repost any note, but it would be simpler to just publish the original kind 1 directly. The whole point of the post request event is to itself act as a kind of repost *into* a community.
thx for discussion. I get your point. and here is how I think about this: if people are reluctant to post on main feed, they should post to private communities(if there need such one). use another kind and hiding them on main feed doesn't solve their problem since people always have ways to find out what you post on the communities. instead, keeping public community post on main feed is actually a good reminder to people that this thing is not privacy.
Im afraid there are differing visions, goals and requirements for communities. Honestly I don't know what to expect out of it, but Jack is a "power user" of social media so its good to get his "requirements validation" feedback. The production code is apparently the only working document in this open market development process.
Will the NIP be changed like
@Stuart Bowman suggested?
Can I go ahead and make these changes this weekend?
Cc:
@Jingles
@Vivek So I’ve been thinking about this.
To keep things simple, for Satellite, I’m going to go ahead and use kind 4549 as a direct clone of kind 1 as
@Vitor Pamplona suggested. So the content string of 4549 will be text just like kind 1.
My initial concern was that having a single kind defined as a “community post” would preclude the reuse of other event kinds, which is why I suggested “wrapping” the events.
I still intend to use kind 4549 as a wrapper to post non-kind-1 events into communities. When a non-kind-1 event is posted, the 4549 event will include a “k” tag indicating the kind of event that was wrapped.
But for 4549 events that do not have a “k” tag (or a “k” tag equal to 1), Satellite will assume that they should be treated like kind 1 and render the content directly.
I like this cause it’s just doing the simple “clone kind 1 thing” but adding the “k” tag allows me to do also do the wrapping thing so I can support other event types on Satellite. If other apps only care about kind 1 that’s fine.
I’m also implementing this weekend and writing up some documentation. Lmk if you wanna collab 🤙
Also Damus was bugging out and caused me to triple post this reply 🤦♂️
So sorry if you got spammed with notifications m!
Awesome :) thanks for the detailed response 🙏 I will try to do the same
I will get back to you with questions if I get any during implementation.
My weekend schedule is still adhoc and me being in India makes synchronous collab impossible.
Will keep a message channel open for async collab, if that's ok with you.
Sounds good!
So 4549 is will not show up in feeds but a request post for community just like the current kind 1 event with “a” tag.
Yep
Just pushed this update. Some rough edges here and there but usable now.
Actually I haven’t implemented it yet. I plan to make type 1 default, but with a checkbox on the new post editor like “hide this post from profile feed” to make 4549 optional
Thanks! I will do the same.
Also, how do we make the 4549 official? Should we write a NIP? Can I start a draft of that?
Sure, I think it would make the most sense to just make a pull request into NIP-172. If you link the pull to me I’ll review it and leave my comments
