kind-scoped follow #1605
kind-scoped follow #1605
Conversation
| Unfollowing is done by deleting the follow event, copying over the `k` tags from the follow event. | ||
|
|
||
| ```jsonc | ||
| { | ||
| "kind": 5, | ||
| "tags": [ | ||
| ["e", "<follow-event-id>"], | ||
| ["k", "<some-kind>"], | ||
| ["k", "<some-other-kind>"] | ||
| ] | ||
| } | ||
| ``` |
There was a problem hiding this comment.
why is it necessary to copy the "k" tags? isn't this just a normal delete?
There was a problem hiding this comment.
allows a client that didn't do the delete to know that it's local state should be updated
| ```jsonc | ||
| { | ||
| "kind": 967, | ||
| "tags": [ | ||
| ["p", "<followed-pubkey>", 'relay-url'], | ||
| ["k", "<some-kind>"], | ||
| ["k", "<some-other-kind>"] | ||
| ] | ||
| } | ||
| ``` |
There was a problem hiding this comment.
should we encourage multiple kinds per follow events? isn't it better to have a different follow event for each kind such that they can be fetched and deleted independently?
There was a problem hiding this comment.
that will likely get too hairy; an app that supports 4 different kinds now needs to read/write 4x the number of events -- I think there's not enough benefit to forcing so much granularity and an app could just delete the event that has more kinds that it knows what to do and recreate with the kinds it doesn't understand (although even that might not even be an overkill)
There was a problem hiding this comment.
but then we're back to lost followers again.
and also weird situations in which the same user will be following the same person multiple times because different apps have created different follow events, some bundled, some unbundled.
There was a problem hiding this comment.
but then we're back to lost followers again.
If an app misbehaves and deletes beyond what it should then it's a misbehaving app, but even within a misbehaving app, accidentally unfollowing someone across more use cases than the user intended to is FAR less problematic than unfollowing everyone across all use cases
and also weird situations in which the same user will be following the same person multiple times because different apps have created different follow events, some bundled, some unbundled.
An app that is interested in kind:20 will REQ for #k: "20", if it finds a follow it will use it, regardless of the fact that there are other ks in the follow event -- it will just ignore them, so it will show that person as followed.
Obviously when an app computes the authors filter based on the follow list it computed then it must make the list unique, but that's already pretty basic, same as if you have the same pubkey in a kind:3 which is also a thing
There was a problem hiding this comment.
ok, so apps must keep track of the event ids they're using to build their internal follow lists, right?
that means these same apps won't need k tags on the kind:5 events in order to interpret an unfollow correctly (merging this with the other thread).
There was a problem hiding this comment.
if the unfollow is a delete and some other app deletes the follow event then they can't know the unfollow happened
they way I'm thinking about it is the app queries with
REQ with { "kinds": [5], "#k": ["967"], "since": last-known-unfollow }
|
I think I passed the stage that app brands or app types == event kinds. To me, there will always be a need for more subjective follow-lists. We may have a different purpose when using different apps in the same kind. For instance, I might use Amethyst for my political takes and Primal for my nerdy posts. The app defines my mindset and each mindset has a different follow list for the same npub. Same for Olas and say an OnlyFans client. Both use kind 20, but the user doesn't want to see those things mixed. Same for Youtube Shorts and TikTok. They can use the same event kind (short vertical videos) but the content is so different that you will need different follow lists. |
|
I agree, but how do we solve that? |
|
I think if I like Alice's bitcoin content I won't bother seeing her bitcoin content from all the different event kinds the app I'm using supports. Considering how clients bulk fetch with If we want to encourage multiple pubkeys for each user, each of her profile pages could link to each other like: Probably by making kind0 reference the other pubkeys while adding some hashtags to each kind0. |
|
Yet its ok for my non-creator friends to use just one pubkey for everything. People follow non-creators just to keep up with whatever they are doing. Meaning, 95-99% of users can keep using just 1 pubkey for everything. |
|
We likely need improvements in two areas:
I recognize that this is all very complicated. But it has to happen. |
This proposal does NOT (necessarily) replace
kind:3, it's a way to do a very simple follow of one or more kinds that might be of interest.A user might be interested in following someone's classified updates but don't care about the rest of their content.
Following in a classified app might create one of these follows.
This way we also start moving away from huge follow lists that can get wiped at a moment's notice and instead clients are responsible for computing the follow list and updating its local state.
This also allows apps to show "followed" notifications without a central source.
Example
Apps like Amethyst and Coracle, that support a vast range of kinds can REQ for updates merging the filters
If a user has in kind:3
ps"pubkey1", "pubkey2"and in akind:967with["k", "30023"]has"pubkey2", "pubkey3"it might REQ with:
Read here
@vitorpamplona @staab @fiatjaf