[LIP-10] - Open Communities Standard #33
Conversation
|
|
An amazing idea. I think communities shouldn't be fragmented however they are a draw on certain apps. I think the feed should the same but communities should be able to opt into closing to an application. This means a community chooses Orb or Buttrfly or whichever platform rather than the platform itself disabling the community to be multi client. The power of the location of a community should be up to the community. If this is not possible, then I surely agree that all communities should be available on all clients. |
|
In favour of the idea given that there has been lot of excitement with communities, especially with Orb clubs. Actually really nice to see additional standards and composable features being build on top of Lens. Would be great hear opinions from @nileshrathore and Kimmo from Orb and @bigint from Hey around what kind of standardization could work for interoperability. When it comes to standards, my biggest recommendation is that the standards are as lean as they can be so they would not limit any potential future use-cases and gives wide flexibility for applications to integrate them. |
|
orb |
|
orb not work for me for a long time |
|
Not dev based, But whatever that could be the positive outcome of this, Let it come. |
|
I support, likes well-defined rules |
|
The new version of Orb is Fabulas |
|
Huge +1 for open and composable communities! I want to point out some technical capabilities that Lens already has, to get the discussion started on specifications. Right now, a Lens "Profile" could be used to manage a Community fairly effectively.
In may ways, open composable communities are possible on Lens today, and all that is needed is to establish an open standard! |
|
yes! not only that but a standard that can be group/club/community agnostic, allowing a post to belong to 0 or N groups/clubs/communities |
|
This is a great LIP, as currently we already have:
Would be nice to come across a standard for all of them, making them portable. |
|
This is a great idea, and I agree that having a standard here is very important. The first question I have here would people mind if it was purely in the Lens API for now? or do people want to see full contracts made so these communities are owned on-chain? |
|
great to see this finally get traction! Would be great to flesh out the desired feature set, ie.
etc. Also will the feed in the group be only chronological (could get noisy) or weighted by engagement (likes+comments+some recency component) - or both? |
|
Improve dapp smoothness |
|
I think there's a simple, decentralized solution mentioned by @iPaulPro, that could standalone as a protocol standard and address the core issue immediately: apps attach and surface posts with tags included in publication metadata.
If applications opt-in to this standard, this creates a public layer for communities to share content between apps. Individual apps can still filter content based on their own moderation, curation, and access preferences (NFT or follow gating, only posts originating from certain apps). I would not be in favor of creating any central registry for communities. The direction I'd like to see communities develop is encouraging attestations (votes) from within communities that are published through open actions, and can be filtered by apps / algorithms to create standards for group settings like metadata and access requirements. The format of these attestations should probably be a separate LIP once public communities gain traction. |
|
Could all these be at the protocol level? Clubs - Orb |
I'd argue that Groups should be at the protocol level, for many reasons, but namely:
I believe the most important part of a "Group" in Web3 is ownership. In my opinion, having to pay rent to manage a Group, while not owning the treasury wallet, the handle, or the Profile (Group) NFT, is arguably worse than starting a subreddit. If there was a simple way to turn a "Profile" into a Group, we could use many existing features of Lens Protocol, like the governing features built into Follow NFTs, custom Follow Modules, and custom Reference Modules that actually reward engagement based on referrals. A Group should allow for DAO ownership and moderation, and Lens Profiles can already do this. A We've discussed renaming "Profiles" for this exact reason; they're capable of a lot more than a traditional "profile" in social media. I believe no core contract changes are required to achieve permissionless Groups that are owned by the creator(s). Ideally the API would allow for more control over comment moderation, and the ability to exclude Group posts from feeds. What are the key features and requirements for Groups?
I'd love to see a Lens Group Standard defined before the launch of V3. Would be great to have participation in this discussion from the apps that you mention, @IamYakuza. |
|
Any updates when this LIP goes live @EthWarrior @joshstevens19? |
|
@iPaulPro Hey, I think we're actually on the same page here. Just like you, I want groups/clubs to be managed with the same level of control as a profile. That's why I mentioned them being "at a protocol level." Your idea of a simple way to transform a profile into a group is exactly what I was thinking! It would be a game-changer. I'd love to tag ppl from the apps I mentioned but I don't know their githubs :( |
|
I completely agree with @iPaulPro here is an old post of mine on the topic |
|
"I would not be in favor of creating any central registry for communities." agreed |
This is not true. Orb and Buttrfly are making use of tags to form their communities, orb prefixes them with Pingpad allows for cross-posting between these standards by attaching multiple tags, but it is suboptimal as it is
My proposal is to:
|
I mean there is no standard for using tags, and they have no assigned purpose. Apps can use them however they want, but they're currently handled differently in each app and not used (for anything) at the protocol level.
I don't understand the difference between a "group" and "community" here. They're largely different names for the same things in a social media context, and I worry it's confusing to have both. It sounds like your suggestions for "communities" are just the tags acting like hashtags. Is that right? If so, I don't think that should be called a "community" or "group", it's simply tags on a post. I'm strictly using the term "Group" here, for clarity.
Your second suggestion doesn't allow for cross-posting in multiple Groups, right? Tags already exist, are used by Orb, and fit perfectly with this use case while allowing cross-posting (which I believe is a key feature). A standard prefix makes sense to distinguish from other types of tags. The cross-posting issues you describe are easily-solvable client-side UX issues.
Good point, I forgot that mirrors don't allow for specifying their own reference modules. So that approach would only work for public Groups unless new capabilities were added to mirroring. A "pending" status is useful for moderation and curation. Without it, we don't have feature parity with subreddits. Without the mirror referrals, there's no way for the Group to earn from curating the posts. This could be a setting controlled by the Group owner, allowing for open submissions.
I'd love to see more APIs around tags, in general; especially getting a list of the most-used ones. As far as querying for Group Profiles, we could filter by custom metadata params (the Group settings) if additional filter options were added to the API. |
the difference is in the governance over them. having groups with vaults, moderation, pending statuses, private members is good, but it's 1) too high of an entry barrier to create one (you must buy a new handle) 2) doesn't really work for a community with no governance (not every group of interests needs moderation and rules) this leads me to believe that there must be an easier and cheaper way to connect with people with the same interests, thus the distinction between the two.
i can see how these two names can be confusing, which is why i proposed to use of something like
correct, the second suggestion is intentionally a let me restate my current proposal:
|
|
@kualta this is basically the wording that each Lens client gave: Infact, their content and way of working should be all the same, for instance in Buttrfly you see Orb clubs as channels and they are the same. |
|
@IamYakuza neither phaver nor hey utilize community tags, i believe phaver curates their communities off-chain and hey doesn't implement them yet: phaver post metadata & hey post metadata (notice the the way to name it is quite irrelevant and can be left up to the clients, i do find buttrfly naming |
I don't think we need names for posts that have tags; that's the confusing part. They're just tags in the way that you're describing.
You can only have 5 tags on a single publication, so that stops you from posting to every Group at the same time. I strongly disagree that posts should only be allowed as part of a single Group. Like Reddit, it should be up to the Group whether or not it allows cross-posts.
This proposal is about Communities/Groups/Clubs, not about tags. If anything a separate LIP should be made if you want to propose calling tagged posts something else. Whether or not a Group is private should be up to the group owner/mod. |
except they're standardized. consider the following example: as a developer, would you really prefer to list 4 communities ("contemporary", "minimalist", "funny", "black and white") over one ("art") channel? tags are not distribution channels.
reddit only allows for a single community posting, usually users choose the one that matches their intention the best. |
My preference as a developer doesn't matter as much as supporting features that users might want. I'd much prefer to have a single post show up on feeds, rather than have to render multiple mirrors of the exact same content. Reddit requires that every post be part of a sub, which isn't a requirement in Lens, so the comparison is not 1:1. Apps can choose to show the first tag and/or all. Something like "Posted in g/contemporary and 3 other Groups".
Says who? Tags' purpose are not defined at the protocol level, and I believe they were added to expand classification capabilities. The primary way they're currently used is to specify an Orb Club (Group); seems only natural to build upon this.
Why require mirroring when we can easily support "cross-posting" to five communities with tags? Your suggestion requires change to core to allow for specifying a Group at the Post and Mirror level, while using tags requires no core changes; only a spec to be agreed upon. Moreover, the mirror approach wastes gas and time while adding noise. I'm not, at all, opposed to adding new Publication metadata to support specifying Groups, but I strongly believe that it should support an array, rather than enforce single-group posting. |
you probably missed my point, my point was that it's probably not what the users want.
i agree, i think tags' purpose is defined in their name and in the future they can be used for better classification at the client level by using image classification models, for example. or maybe clients would allow users to specify their own tags more commonly. if we utilize tags for the purpose of defining distribution channels, there would be no space for these use cases left...
there's a problem with "agreeing on the spec" part as well. as a fresh developer, the purpose of a
when you create a publication, you are given one ticket to the land of algorithm, where the future of your post is further determined. regardless of the algorithm, we usually want to raise high quality content higher in your feed. when crossposting the way you described, users are given five attempts at winning the algorithm lottery, at no extra cost. due to the sheer amount of people engaging in the classical social media we do not want your post to appear five times in the algorithm, regardless of how awesome it is. we want it one time, in the place it will be most expected and appreciated.
for the reasons described above, this is by design. luckily, we live in a world where mirroring gas comes to you at no cost, but you can imagine a world where we run lens on L1 and every mirror costs you something. this is good. mirroring should cost you gas. |
I was saying I disagree as a user and developer. As a user I'd much prefer to have a single post in the feed rather than multiple copies of it. I'd also prefer to be able to specify multiple Groups at the time of publishing. As a developer, I'd prefer to only render a single instance of the post. In fact, a well-designed feed UI would collapse multiple Mirrors of the same post and display them as a single instance. I try to not to impose my own philosophy and opt for the proposal that is the most flexible. As an app developer, if you believe posts should only be allowed to be posted in a single Group, you have the ability to enforce that in your app. If it's enforced at the protocol level, the option is taken from you. I believe this, alone, is the strongest argument for supporting cross-posting at the protocol level.
There's no reason Tags can't be used in both ways. After all, they're doing the same thing. For me, "posting to a Group" is literally the same as tagging that Group, so I don't think it's unusual to use the existing Tags. A "Group" Tag could be one that has a specific prefix; simple as that. Just to reiterate, though, I'm not opposed to adding a new field as long as it supports cross-posting.
I expect them to read the docs, which would be updated to include this spec.
I think we fundamentally disagree on the nature of a Lens Publication. My understanding is informed by the way the Protocol currently works, while yours requires some changes to it. A Lens Profile is the direct "distribution channel" of a Lens Publication. Everything else is curation, classification, and ease of access. In Blockchain, goods are delivered directly from the chain to wallets. Apps can be seen as indirect channels, but it's important to note that apps are not required for distribution. If I see an ad for a product, and then order that product directly on the manufacturers website, was the ad the distribution channel? When someone "posts in a Group", they are still actually posting on their Profile. The post will show up in the feed of any follower as well as the user's Profile feed. The distribution channel is not the Group, that's just a way of classifying it. The direct channel is the Profile and the indirect channel is the app. Similar to the way tags/hashtags work, a Community/Group/Club simply groups posts around a specific topic. The only difference is that a Group is moderated. The way you describe a Group would seem to indicate that a Group Post, in fact, would not be shown in the Profile or in the feed of followers unless they were also in that Group. This is similar to limiting the sale of your physical goods to a single brick-and-mortar store. You also seem to imply that there will only be single Groups around specific interests, when there's no reason to think this will be the case in a permissionless protocol. As a developer, I might want to cross-post to
Just because you're not paying the gas doesn't mean it's free. Every transaction has a gas cost, and in blockchain we generally try to avoid being wasteful. Avara is currently footing the majority of the Polygon gas bill, but it may be left to apps in the future. Lens Network may help to keep transaction costs consistent and low, but at scale, it still adds up. |
Proposing a unified standard for creating and managing Communities which allows using them in an interoperable manner across the Lens ecosystem.