From 19561b0b76dc0960bf3318d9821131cd5904aaee Mon Sep 17 00:00:00 2001
From: ZKJew <106914330+ZKJew@users.noreply.github.com>
Date: Thu, 13 Jun 2024 20:11:32 -0400
Subject: [PATCH 1/6] Update and rename lip-template.md to [LIP-26].md

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.
---
 LIPs/[LIP-26].md     | 49 +++++++++++++++++++++++++++
 LIPs/lip-template.md | 81 --------------------------------------------
 2 files changed, 49 insertions(+), 81 deletions(-)
 create mode 100644 LIPs/[LIP-26].md
 delete mode 100644 LIPs/lip-template.md

diff --git a/LIPs/[LIP-26].md b/LIPs/[LIP-26].md
new file mode 100644
index 0000000..d1bcc7c
--- /dev/null
+++ b/LIPs/[LIP-26].md
@@ -0,0 +1,49 @@
+---
+title: <Introducing User Ownership Over Algorithms>
+description: <Giving users the ability to own their own algorithm>
+author: <zkjew.lens @zkjew>
+discussions-to: <N/A>
+status: Draft
+type: <Protocol/Lens Open Algorithm Standard>
+category: <Contracts/API>.
+created: <(2024-06-13)>
+requires: <N/A> 
+---
+
+## Abstract
+
+<!--
+    The purpose of this LIP is to introduce the concept of a user's ownership over their feed algorithm through what I call a User Owned Algorithm Token. This would be carried out by some expressive token that is attached to a user's profile, which can be read to generate the user's preferred algorithm.
+-->
+
+## Motivation
+
+<!--
+  	The motivation for this LIP is to give the user even more ownership over their social media experience. Right now, users own their profile, collections, content, and followings. It is quite clear that the user’s algorithm should be owned by the user - especially when the lack of control over algorithms is such a problem for users in traditional social media.
+-->
+
+## Specification
+
+<!--
+  There are a couple ways that ownership over a user’s desired feed algorithm could go - however it should serve a couple functions. One, allow a user to design and calibrate their own algorithm and import it into a Lens compatible app. Second, it should allow a user to export an algorithm from an app to an on-chain token, which can be read by other lens compatible apps. These two functions are the main purpose behind ownership of a user's feed algorithm. The token itself could either contain metadata with a list of wanted and unwanted profiles to be served, which may require another lip/token standard to mark unwanted profiles - and it should be able to carry out aggregation of lists in a degree of separations manner. Or, it could just include the basic functions a user has calibrated to generate their feed. The ladder may be the more effective to start with - especially if scale could pose an issue.
+-->
+
+## Rationale
+
+<!--
+The main rationale behind the design is to give the user more optionality in how they interact with social media and giving them more power in app selection, where they are not siloed to a closed off algorithm generation. Additionally, it should allow a user to use an app even if there is a high propensity for bots on the app. The user focused approach might also show to do a better job of curated algorithms then a generalized algorithm approach.
+-->
+
+TBD
+
+## Backwards Compatibility
+
+<!--
+  Since this is an addition to the protocol - I assume there would be no backwards compatibility issues at the protocol levels. But, this may not be true for apps with ingrained algorithm generation systems.
+-->
+
+
+
+## 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: <The LIP title is a few words, not a complete sentence>
-description: <Description is one full (short) sentence>
-author: <a comma separated list of the author's or authors' name + GitHub username (in parenthesis), or name and email (in angle brackets).  Example, FirstName LastName (@GitHubUsername), FirstName LastName <foo@bar.com>, FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)>
-discussions-to: <URL>
-status: Draft
-type: <Protocol, Lens Metadata Standard, or Lens Open Algorithm Standard>
-category: <Contracts, API, SDK> # Only required for Protocol. Otherwise, remove this field.
-created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
-requires: <LIP number(s)> # Only required when you reference an LIP which is also dependent on this to work. Otherwise, remove this field.
----
-
-## Abstract
-
-<!--
-  The Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does.
-
-  TODO: Remove this comment before submitting
--->
-
-## Motivation
-
-<!--
-  This section is optional.
-
-  The motivation section should include a description of any nontrivial problems the LIP solves. It should not describe how the LIP solves those problems, unless it is not immediately obvious. It should not describe why the LIP should be made into a standard, unless it is not immediately obvious.
-
-  With a few exceptions, external links are not allowed. If you feel that a particular resource would demonstrate a compelling case for your LIP, then save it as a printer-friendly PDF, put it in the assets folder, and link to that copy.
-
-  TODO: Remove this comment before submitting
--->
-
-## Specification
-
-<!--
-  The Specification section should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Lens platforms
-  TODO: Remove this comment before submitting
--->
-
-## Rationale
-
-<!--
-  The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.
-
-  The current placeholder is acceptable for a draft.
-
-  TODO: Remove this comment before submitting
--->
-
-TBD
-
-## Backwards Compatibility
-
-<!--
-
-  This section is optional.
-
-  All LIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The LIP must explain how the author proposes to deal with these incompatibilities. LIP submissions without a sufficient backwards compatibility treatise may be rejected outright.
-
-  The current placeholder is acceptable for a draft.
-
-  TODO: Remove this comment before submitting
--->
-
-No backward compatibility issues found.
-
-## Security Considerations
-
-<!--
-  All LIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. For example, include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. LIP submissions missing the "Security Considerations" section will be rejected. An LIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.
-
-  The current placeholder is acceptable for a draft.
-
-  TODO: Remove this comment before submitting
--->
-
-Needs discussion.
-
-## Copyright
-
-Copyright and related rights waived via CC0.

From c54f7d891fc210db8fabfa223889fb03139f42d7 Mon Sep 17 00:00:00 2001
From: ZKJew <106914330+ZKJew@users.noreply.github.com>
Date: Sat, 22 Jun 2024 14:57:03 -0400
Subject: [PATCH 2/6] Update [LIP-26].md

---
 LIPs/[LIP-26].md | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/LIPs/[LIP-26].md b/LIPs/[LIP-26].md
index d1bcc7c..d6f2ba4 100644
--- a/LIPs/[LIP-26].md
+++ b/LIPs/[LIP-26].md
@@ -13,25 +13,33 @@ requires: <N/A>
 ## Abstract
 
 <!--
-    The purpose of this LIP is to introduce the concept of a user's ownership over their feed algorithm through what I call a User Owned Algorithm Token. This would be carried out by some expressive token that is attached to a user's profile, which can be read to generate the user's preferred algorithm.
+The purpose of this LIP is to introduce the concept of user ownership over their feed algorithm through a User Owned Algorithm Token. This token, attached to a user's profile, would be used to generate the user's preferred algorithm.
 -->
 
 ## Motivation
 
 <!--
-  	The motivation for this LIP is to give the user even more ownership over their social media experience. Right now, users own their profile, collections, content, and followings. It is quite clear that the user’s algorithm should be owned by the user - especially when the lack of control over algorithms is such a problem for users in traditional social media.
+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 algorithms, 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 Algorithm Token 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 a couple ways that ownership over a user’s desired feed algorithm could go - however it should serve a couple functions. One, allow a user to design and calibrate their own algorithm and import it into a Lens compatible app. Second, it should allow a user to export an algorithm from an app to an on-chain token, which can be read by other lens compatible apps. These two functions are the main purpose behind ownership of a user's feed algorithm. The token itself could either contain metadata with a list of wanted and unwanted profiles to be served, which may require another lip/token standard to mark unwanted profiles - and it should be able to carry out aggregation of lists in a degree of separations manner. Or, it could just include the basic functions a user has calibrated to generate their feed. The ladder may be the more effective to start with - especially if scale could pose an issue.
+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 design and calibrate their own algorithm and import it into a Lens-compatible app. Practically, this could be as simple as a user interacting with content displayed on an algorithm generation front end or within an app itself.
+
+Second, it should enable a user to export an algorithm 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 algorithm or authorize an app to export it on their behalf.
+
+These two functions form the core purpose of owning a user's feed algorithm. The token could either contain metadata with a list of desired and undesired profiles to be served, potentially requiring another token standard to mark unwanted profiles, and should be able to aggregate lists in a degrees-of-separation manner. Alternatively, it could simply include the basic functions a user has calibrated to generate their feed. The latter approach may be more effective initially, especially if scaling poses a challenge.
+
+(Note: I lack expertise in updating metadata cost-efficiently, which is relevant for this last part.)
 -->
 
 ## Rationale
 
 <!--
-The main rationale behind the design is to give the user more optionality in how they interact with social media and giving them more power in app selection, where they are not siloed to a closed off algorithm generation. Additionally, it should allow a user to use an app even if there is a high propensity for bots on the app. The user focused approach might also show to do a better job of curated algorithms then a generalized algorithm approach.
+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.
 -->
 
 TBD

From 74642df976b1f4e7309fa410a3e1a2526fed7a2c Mon Sep 17 00:00:00 2001
From: ZKJew <106914330+ZKJew@users.noreply.github.com>
Date: Sat, 22 Jun 2024 18:36:09 -0400
Subject: [PATCH 3/6] Update [LIP-26].md

---
 LIPs/[LIP-26].md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/LIPs/[LIP-26].md b/LIPs/[LIP-26].md
index d6f2ba4..b278ac1 100644
--- a/LIPs/[LIP-26].md
+++ b/LIPs/[LIP-26].md
@@ -47,7 +47,7 @@ TBD
 ## Backwards Compatibility
 
 <!--
-  Since this is an addition to the protocol - I assume there would be no backwards compatibility issues at the protocol levels. But, this may not be true for apps with ingrained algorithm generation systems.
+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.
 -->
 
 

From 55aa1fac509740703523b789478636290d5aaa38 Mon Sep 17 00:00:00 2001
From: ZKJew <106914330+ZKJew@users.noreply.github.com>
Date: Fri, 23 Aug 2024 19:58:32 -0400
Subject: [PATCH 4/6] [LIP-26].md

Updated terminology to align with present understanding and better vocabulary
---
 LIPs/[LIP-26].md | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/LIPs/[LIP-26].md b/LIPs/[LIP-26].md
index b278ac1..a979b22 100644
--- a/LIPs/[LIP-26].md
+++ b/LIPs/[LIP-26].md
@@ -1,6 +1,6 @@
 ---
-title: <Introducing User Ownership Over Algorithms>
-description: <Giving users the ability to own their own algorithm>
+title: <Introducing User Ownership Over Feeds>
+description: <Giving users the ability to own their own feed generated by a delegated algorithm runner>
 author: <zkjew.lens @zkjew>
 discussions-to: <N/A>
 status: Draft
@@ -13,13 +13,13 @@ requires: <N/A>
 ## Abstract
 
 <!--
-The purpose of this LIP is to introduce the concept of user ownership over their feed algorithm through a User Owned Algorithm Token. This token, attached to a user's profile, would be used to generate the user's preferred algorithm.
+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 generate 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 algorithms, 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 Algorithm Token would empower users to switch apps and view the content they desire while alleviating the burden of algorithm generation from app developers.
+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
@@ -27,13 +27,13 @@ The motivation for this LIP is to give users greater ownership over their social
 <!--
 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 design and calibrate their own algorithm and import it into a Lens-compatible app. Practically, this could be as simple as a user interacting with content displayed on an algorithm generation front end or within an app itself.
+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 an algorithm 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 algorithm or authorize an app to export it on their behalf.
+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.
 
-These two functions form the core purpose of owning a user's feed algorithm. The token could either contain metadata with a list of desired and undesired profiles to be served, potentially requiring another token standard to mark unwanted profiles, and should be able to aggregate lists in a degrees-of-separation manner. Alternatively, it could simply include the basic functions a user has calibrated to generate their feed. The latter approach may be more effective initially, especially if scaling poses a challenge.
+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.
 
-(Note: I lack expertise in updating metadata cost-efficiently, which is relevant for this last part.)
+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

From 58ac69b412aca4fc261ad91d63dfbf15d2c016f5 Mon Sep 17 00:00:00 2001
From: ZKJew <106914330+ZKJew@users.noreply.github.com>
Date: Fri, 23 Aug 2024 20:03:16 -0400
Subject: [PATCH 5/6] [LIP-26].md

---
 LIPs/[LIP-26].md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/LIPs/[LIP-26].md b/LIPs/[LIP-26].md
index a979b22..080615f 100644
--- a/LIPs/[LIP-26].md
+++ b/LIPs/[LIP-26].md
@@ -13,7 +13,7 @@ requires: <N/A>
 ## 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 generate the user's preferred feed on any front end integrated with Lens Protocol.
+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

From cc7f1af0bc4c6c736125f2e39fc2480c9008992f Mon Sep 17 00:00:00 2001
From: ZKJew <106914330+ZKJew@users.noreply.github.com>
Date: Fri, 23 Aug 2024 20:04:33 -0400
Subject: [PATCH 6/6] [LIP-26].md

---
 LIPs/[LIP-26].md | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/LIPs/[LIP-26].md b/LIPs/[LIP-26].md
index 080615f..fa60ad7 100644
--- a/LIPs/[LIP-26].md
+++ b/LIPs/[LIP-26].md
@@ -12,19 +12,19 @@ requires: <N/A>
 
 ## 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. 
@@ -34,21 +34,20 @@ Second, it should enable a user to export a feed from an app to an on-chain toke
 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.
--->
+>
 
-TBD
 
 ## 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.
--->
+>