Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

kind-scoped follow #1605

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
+45 −0
Open

kind-scoped follow #1605

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 45 additions & 0 deletions FA.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
NIP-FA
======

Kind-scoped follows
-------------------

`draft` `optional`

This NIP defines kind `967`, a kind-scoped follow event.

```jsonc
{
"kind": 967,
"tags": [
["p", "<followed-pubkey>", 'relay-url'],
["k", "<some-kind>"],
["k", "<some-other-kind>"]
]
}
```
Comment on lines +11 to +20
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

@pablof7z pablof7z Nov 23, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not a big deal

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 }


Multiple `p` tags and multiple `k` tags are allowed.

The `k` tag(s) define the scope of the follows.

### Unfollow action

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>"]
]
}
```
Comment on lines +28 to +39
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


### Constructing specialized follow lists

A client can fetch the events of the kinds they are interested in, and perhaps adjacent kinds if they choose to. For example, a client specialized in videos might also want to extend its computed follow list to include events related to live streams.

Clients can use the last `kind:967` and `kind:5` tagged with a `k` they care about and use the last `created_at` they have seen to REQ for updates.