diff --git a/LIPs/[LIP-26].md b/LIPs/[LIP-26].md new file mode 100644 index 0000000..fa60ad7 --- /dev/null +++ b/LIPs/[LIP-26].md @@ -0,0 +1,56 @@ +--- +title: +description: +author: +discussions-to: +status: Draft +type: +category: . +created: <(2024-06-13)> +requires: +--- + +## 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. diff --git a/LIPs/lip-template.md b/LIPs/lip-template.md deleted file mode 100644 index 37e0748..0000000 --- a/LIPs/lip-template.md +++ /dev/null @@ -1,81 +0,0 @@ ---- -title: -description: -author: , FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)> -discussions-to: -status: Draft -type: -category: # Only required for Protocol. Otherwise, remove this field. -created: -requires: # Only required when you reference an LIP which is also dependent on this to work. Otherwise, remove this field. ---- - -## Abstract - - - -## Motivation - - - -## Specification - - - -## Rationale - - - -TBD - -## Backwards Compatibility - - - -No backward compatibility issues found. - -## Security Considerations - - - -Needs discussion. - -## Copyright - -Copyright and related rights waived via CC0.