[LIP-26]: Enhancing Social Media Interaction through User-Owned Feeds #56
Conversation
Idk if something like this is already in the works, but I think it could be a great addition to a users ownership and power over their own social experience and would love to hear others thoughts.
|
ZKJew
changed the title
|
"Who would design the algorithm? Honestly, I think there could be a market for algorithms. If there is a token that represents it let’s add a market into it, because it would incentive developers to create and maintain competitive algorithms. Overall I support this especially if it can be standardized across multiple clients." -Augustus Ceaser |
|
"I like the idea to store preferences somewhere, apps can use to improve the UX. |
|
OK, first of all, I think this is a very important issue, especially because I feel that the initial "Hey + Karmalabs custom feed algorithms" approach has been somewhat sidelined, and we are forced to use the algorithms created directly by the apps. At the same time, I feel that the implementation is quite difficult. The use of Open Actions at the protocol level is a good example of this - although the Swap Open Action has been available for a long time, no one has integrated this very useful feature except for one app. So, applications built on Lens would need to fully commit to this solution - which, of course, could mean that their own algorithms might take a back seat. My second concern is how exactly do you envision this? Are you only thinking of a pure list of wanted/unwanted profiles stored/connected to each ser Owned Algorithm Token, to which profiles can be added "manually", and the wanted profiles would appear more frequently than neutral profiles in the user's feed through some simple weighting, and unwanted profiles would appear less frequently (or be completely excluded)? In addition should "wantedness" and "unwantedness" be totally new Lens primitives or can we express this by upvotes and downvotes/blocks? If they are new options to do, do we need a new Lens-based dapp where we can customize our token? What would be the basis for creating the feed algorithm? Even if it's just a simple weighting of the Wanted - Unwanted options, 1, I think we need to handle every profile included nor in Wanted or Unwanted lists as Neutral profiles (because do not want to exclude them from our feeds totally, right?) - so this is a 3rd category 2, We need to build up customizable algorithms for weighting the 3 categories. But who will create the algorithm itself? The average user doesn't have enough knowledge for this. I can imagine creating a basic algorithm library that users can access and, with the necessary technical knowledge, fork/modify. However, this exceeds the capabilities and perhaps even the needs of the average user. So, this must be solved mainly from the Lens side. In summary, I have a lot of "hows" but I find it a very interesting LIP, and I think it's worth dealing with something like this to get back to our Lens roots. Sorry for not responding directly on Github, I only have my personal profile, which I didn't want to reveal. 😄 |
|
"What would be the basis for creating the feed algorithm? Even if it's just a simple weighting of the Wanted - Unwanted options, 1, I think we need to handle every profile included nor in Wanted or Unwanted lists as Neutral profiles (because do not want to exclude them from our feeds totally, right?) - so this is a 3rd category 2, We need to build up customizable algorithms for weighting the 3 categories. But who will create the algorithm itself? The average user doesn't have enough knowledge for this. I can imagine creating a basic algorithm library that users can access and, with the necessary technical knowledge, fork/modify. However, this exceeds the capabilities and perhaps even the needs of the average user. So, this must be solved mainly from the Lens side." "At the same time, I feel that the implementation is quite difficult. The use of Open Actions at the protocol level is a good example of this - although the Swap Open Action has been available for a long time, no one has integrated this very useful feature except for one app. So, applications built on Lens would need to fully commit to this solution - which, of course, could mean that their own algorithms might take a back seat." |
|
Amazing would be another layer based on semantics / content. “Show me cat, coffee and L2 related content“. But I think it must be as easy as this to be used at scale." -Punkess |
|
"Having spent a couple of years trying to figure out any sort of viable Lens algo (ours or 3rd party), I’m not very optimistic that 99% of users would be able (not to mention willing) to calibrate a custom algo that actually improves their experience. I’m therefore a lot more a proponent of an ”algo marketplace” and allowing users to choose between transparent 3rd party algos once we have some good enough ones. These could store username level algo parameters if needed to keep it transferrable. Technically there could be some standard for those parameters but I’d expect that to restrict the format too much and not get too widely adopted. For Phaver specifically, since we have content from Lens, Phaver and Farcaster mixed into one supergraph, any algos we adopt can’t be Lens-specific so that’s another limitation." |
|
This is great feedback, so I am going to try to go over where I agree, disagree, and need help to see if there's a potential solution. "Having spent a couple of years trying to figure out any sort of viable Lens algo (ours or 3rd party), I’m not very optimistic that 99% of users would be able (not to mention willing) to calibrate a custom algo that actually improves their experience." I really agree with this. I don't think that a lot of users will knowingly create or like their own algorithm - however, I think the ability to generate and custody ones own surfing algorithm is still a valuable ability whether its adopted by every user or not. Additionally, I think that custom to app based algorithm curation is more of a spectrum rather then an either/or, so let's say a user comes to phaver with a social graph. Phaver could ask for preferences and then tweak the algorithm according to its own algorithm on top of the preferences. This is more what I envision by "calibration." "I’m therefore a lot more a proponent of an ”algo marketplace” and allowing users to choose between transparent 3rd party algos once we have some good enough ones." I completely agree - I think 3rd party algorithm curation will be very meta, but I also think any user should be able to design and export an algorithm on chain. Think of governments censoring news, but journalists are able to export feeds to citizens. "Technically there could be some standard for those parameters but I’d expect that to restrict the format too much and not get too widely adopted." I agree, but the same could be said for Lens Protocol itself. Applications that allow users to import and export algorithms should dominate over ones that don't unless that application has an extreme advantage imo. I don't think that doesn't mean its not functionality that shouldn't be available especially because what if its needed or done by a competitor, ext. I certainly don't see any downside risk from implementing it. "For Phaver specifically, since we have content from Lens, Phaver and Farcaster mixed into one supergraph, any algos we adopt can’t be Lens-specific so that’s another limitation." This is definitely above my pay grade, but all I would say is that imo, the endgame is everyone on phaver having a lens profile and using that. I don't think we will see a world with multiple social graph protocols - its an all or none world to me. That being said I definitely sympathize with why apps integrate both protocols in the meantime. I guess the question really is what input data for the supergraph do you need the algorithm token to mimic or house in the mean time. I do understand that importing is probably much more feasible to get done then exporting in this example. I also do think there's a certain point when you are looking at application specific trade offs rather then protocol relevant trade offs. Sorta like censorship - except for here lets say tiktok doesn't want a proprietary algorithm exported. But overall, I do think that ownership and self-custody of user centric algorithms can be implemented and done well with good/seamless UX and is an important part of the pie for apps and users. I will edit the backwards compatibility part on github when I get the chance. Curious on any solutions you could think of (mostly bc idk how you generate your supergraph haha). |
|
Dude, this concept kinda hits home. The whole idea of owning your social media algorithm sounds like a game-changer. Imagine curating your feed without the random junk we get now. But, how would this token actually function across multiple platforms? Also, wouldn’t the privacy concerns skyrocket if our preferences are stored on-chain? 🤔 |
|
The way this could work is that User-Owned Algorithms are preference settings on all metadata and the preference setting here means that you could either have a simple preference (no content about "Cats" or "Dogs") or you use an separate algorithm that is more sophisticated. Then the question is where do we store these preferences. Onchain on Lens Network or decentralized storage. |
|
"The way this could work is that User-Owned Algorithms are preference settings on all metadata and the preference setting here means that you could either have a simple preference (no content about "Cats" or "Dogs") or you use an separate algorithm that is more sophisticated." Maybe I should rename to User-Owned Feeds or something. Basically I didn't write this out well because I didn't write it all at once but in my head heres how I hoped it'd work: A user has certain data set and preferences based on on chain activity. An agent is hired to precure a feed for this user. The agent runs an algorithm to determine what kind of feed is best for the user. The agent creates a base feed and fills the rest of the feed with inputs from 3rd parties. The User Owned Algorithm is then the product of this interaction. So the agent basically builds a feed using its algorithm and negotiates other inclusions to the feed with 3rd parties. The feed is all that is on-chain for the user in addition to interactions between the agent and a third-party. "Then the question is where do we store these preferences. Onchain on Lens Network or decentralized storage." I think the answer probably is what has the best guarantees and privacy as some of the information would probably desired to be encrypted like political preferences. Idk the backend trade offs though. |
|
Yes basically those can be either preferences or just preference to use a specific agent or combination of both where user is setting preferences that is fed as parameter for the agent. All interesting parts of the spectrum. |
|
Sick, so basically feeding a users data set and preferences in a way the user has access to to a specialized agent, who in turn posts the product of their algorithm to a readable token by front ends? |
Updated terminology to align with present understanding and better vocabulary
ZKJew
changed the title
Enhancing Social Media Interaction through User-Owned Feeds
Abstract:
The purpose of this LIP is to introduce the concept of user ownership over their feed algorithm through a User Owned Feed Token (UOF). This token, attached to a user's profile, would be used to host the user's preferred feed on any front end integrated with Lens Protocol.
Motivation:
The motivation for this LIP is to give users greater ownership over their social media experience. Currently, users own their profiles, collections, content, and followings. It is clear that users should also own their feeds, especially given the widespread issues with lack of control over algorithms in traditional social media. Both users and apps face problems with the current methods of feed algorithms, which are either limited by following degree of separation logic or rely on generalized algorithms that are poorly tailored to individual users. A User Owned Feed Token that is generated by a user delegated algorithm provider would empower users to switch apps and view the content they desire while alleviating the burden of algorithm generation from app developers.
Specification
There are several ways to manage ownership over a user's desired feed algorithm, but it should serve two primary functions.
First, it should allow a user to supply data and chose the feed generator for their own feed and import it into a Lens-compatible app.
Second, it should enable a user to export a feed from an app to an on-chain token, which can then be read by other Lens-compatible apps. This means a user should be able to mint their feed or authorize an app to export it on their behalf by acting as the delegated feed generator.
This can be accomplished by having a token that can be host inscribed data such as a string of posts by the delegated feed generator, or the user themselves.
These two functions form the core purpose of a user owning their feed. The token could either contain metadata with a list of posts ex. 0xdd33-0x0954-DA-7834aa60 that are inscribed according to a metadata standard that is accepted by the protocols actors.
Rationale
The main rationale behind this design is to give users more options in how they interact with social media and more power in app selection, preventing them from being restricted to a closed-off algorithm generation. Additionally, it should allow users to utilize an app even if there is a high propensity for bots. A user-focused approach might also prove to curate algorithms more effectively than a generalized algorithm approach.
Backwards Compatibility
For apps that service multiple protocols and uses Lens' graphs as subgraphs to a super-graph, exporting would not only be difficult, but also worthless in most cases, and imports might require workarounds depending on their input system for their super-graph.
Copyright
Copyright and related rights waived via CC0.
`