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.

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

[Follows] Add a nos tag to all follows events #1455

Open
setch-l opened this issue Sep 4, 2024 · 3 comments
Open

[Follows] Add a nos tag to all follows events #1455

setch-l opened this issue Sep 4, 2024 · 3 comments

Comments

@setch-l
Copy link

setch-l commented Sep 4, 2024

We want to know if there is ever a point in the future when the Nos app is the cause of lost follows lists. To do this we will add a Nos app tag to all follows events that we publish across the network.

Daniel has some code to track when follows are lost already, so we can pair the tag with the large instances of lost follows.

AC:

  • Add the Nos tag to all follows events that take place in Nos.
  • Give Matt a link to the PR, so he can post about the idea on Nostr.
@rabble
Copy link
Contributor

rabble commented Sep 6, 2024

Shouldn’t we tag all events our app emits with the Nos tag anyway not just follows. It’ll help with discovery of Nos in other nostr apps.

@dcadenas
Copy link
Contributor

The server-side implementation is complete, and we now expect a client tag with nos as the content. More details are in the Slack conversation here. The other tag values should be present to comply with the protocol described in NIP-89, although the server doesn't check them.

We need to be aware that this tag isn't signed by nos, so its presence doesn't guarantee the event actually came from our app—it can be faked. When we detect these, they should be considered hints to aid in filtering, not definitive proof. To be certain, we'd need to map public keys to some internal nos pubkey list.

I wonder if we should update the NIP (cc @mplorentz) to clarify that the client tag should be interpreted as a recommendation of a client, not an assertion that the event came from our app—much like agent headers in HTTP. If this approach isn't acceptable, we could propose including an optional signature of a partial hash, implement server-side partial signatures by nos, or use NIP-06-based hidden secrets on app installs. However, these options would add significant complexity, especially if we don't care about client spoofing.

@rabble
Copy link
Contributor

rabble commented Sep 15, 2024

Nostr doesn’t have a follow event. That’s the issue I want to address by updating the spec. Nostr just has a replaceable list event and a follow is done by replacing the list with a new one.

Anyway our kind 1 and 0 events should also include the app tag.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests

4 participants