kind-scoped follow

[pablof7z]

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 a kind:967 with ["k", "30023"] has "pubkey2", "pubkey3"

it might REQ with:

{ "kinds": [<everything-the-app-supports>], "authors": ["pubkey1", "pubkey2"] },
{ "kinds": [30023], "authors": ["pubkey3"] }

Read here

@vitorpamplona @staab @fiatjaf

[fiatjaf]

why is it necessary to copy the "k" tags? isn't this just a normal delete?

[pablof7z]

allows a client that didn't do the delete to know that it's local state should be updated

[fiatjaf]

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?

[pablof7z]

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)

[fiatjaf]

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.

[fiatjaf]

not a big deal

[pablof7z]

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

[fiatjaf]

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).

[pablof7z]

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 }

[vitorpamplona]

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.

[fiatjaf]

I agree, but how do we solve that?

[arthurfranca]

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 { kinds: ["many", "kinds", "app", "supports"], authors: ["many", "follows", "from", "intersection", "relays"] } , the simplest way would be if Alice had a pubkey she used just for bitcoin content, although a bit cumbersome for Alice.

If we want to encourage multiple pubkeys for each user, each of her profile pages could link to each other like:
Follow my other profiles:
npub1abc #recipes
npub1xyz #ww3
npub1qhj #games #mmorpg #arpg

Probably by making kind0 reference the other pubkeys while adding some hashtags to each kind0.

[arthurfranca]

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.

[vitorpamplona]

We likely need improvements in two areas:

• Enhanced multi-key support for signers: Ideally, when an app is installed, it should display all the accounts the user is signed into on Amber or Alby and allow the user to select one. The extension should enable different sites to utilize distinct keys simultaneously, rather than relying on a single active account that requires switching as it does today.
• Improved support for follow lists across apps: When a user logs in, the client should be able to detect all available follow lists and assist in building a new one based on those contacts. Effective list management is crucial—if a user follows someone on one list, other clients should recognize this action and suggest following the same person on additional lists as appropriate.

I recognize that this is all very complicated. But it has to happen.

[erskingardner]

Same for Olas and say an OnlyFans client. Both use kind 20, but the user doesn't want to see those things mixed.

This, to me, starts to stink of data silos. I know that we still have open relays but the more we allow for fragmentation, the harder it gets for general clients to support and the more we collapse to a few very highly sophisticated (and usually well funded) clients.

That's not to say I'm against this proposal, I actually sort of like it. BUT the resulting UX implications for users becomes almost impossible to reason about (other than to think that in Olas I have one follow list, and in OnlyNIPs I have another - which is basically us admitting defeat and going back to the closed web paradigm).

[fiatjaf]

BUT the resulting UX implications for users becomes almost impossible to reason about (other than to think that in Olas I have one follow list, and in OnlyNIPs I have another - which is basically us admitting defeat and going back to the closed web paradigm).

This is a good point.

[fiatjaf]

Perhaps instead of a kind-scoped we should just use arbitrary user-defined lists, and then an app like Olas could prompt the user to use their "default" list or select a new list upon login?

Or create one if the user clearly doesn't know anything about the matter since it doesn't have any lists.

It might be that only developers, overorganizers and nerds will like the scoped lists feature and most users actually prefer a global follow list and we are overoptimizing for the wrong target here.

Allowing power users to pick custom lists might be the best solution.

[pablof7z]

Perhaps instead of a kind-scoped we should just use arbitrary user-defined lists, and then an app like Olas could prompt the user to use their "default" list or select a new list upon login?

Or create one if the user clearly doesn't know anything about the matter since it doesn't have any lists.

It might be that only developers, overorganizers and nerds will like the scoped lists feature and most users actually prefer a global follow list and we are overoptimizing for the wrong target here.

Allowing power users to pick custom lists might be the best solution.

Yes, I agree, the more I think about this the less I like it and the more I think it undoes a lot of what is cool about nostr.

There is still some segregation that users need to be able to do; i.e. I might be interested in a businesses' products and I want to "follow" them on an ecommerce site, but I don't want my tweeter feed cluttered with their tweets.

I think the predetermined user lists is the way to go, i.e. just have a bunch of 1xxxx kinds that represent a bunch of different use cases; I think the fragmentation won't even be that high, perhaps there's really just four or five different "areas" of follows and powerusers can always go with as many 30000 lists as they want.

[erskingardner]

It might be that only developers, overorganizers and nerds will like the scoped lists feature and most users actually prefer a global follow list and we are overoptimizing for the wrong target here.

I would say that history has overwhelmingly proven this to be the case.

I think the predetermined user lists is the way to go, i.e. just have a bunch of 1xxxx kinds that represent a bunch of different use cases; I think the fragmentation won't even be that high, perhaps there's really just four or five different "areas" of follows and powerusers can always go with as many 30000 lists as they want.

This feels way more manageable and easily understandable for clients and users. I don't even know that we need any 1xxxx kinds, just allow users to create lists and give them their own meaning with names and descriptions.