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

NIP-114: ids_only filter #99

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

NIP-114: ids_only filter #99

wants to merge 4 commits into from

Conversation

mmalmi
Copy link

@mmalmi mmalmi commented Jan 31, 2024

When a subscription has a filter with ids_only: true, the relay responds with [HAVE, subId, eventID] messages. The client can then request the full event from only one relay instead of receiving it from all subscribed relays. If the event is already in a local database, the full event request can be skipped altogether.

I have not implemented this for the stream command yet, but this could save a lot of bandwidth if you're connecting to many other relays and subscribing to everything.

@mmalmi
Copy link
Author

mmalmi commented Jan 31, 2024

We might want a GET message that is sent in response to HAVE messages to request the full event without creating a subscription.

@mmalmi
Copy link
Author

mmalmi commented Jan 31, 2024

Added ["GET", eventId] handling. Response is sent as ["EVENT", "*", eventJson]. Is "*" a good subscription id here or should it be something else?

@hoytech
Copy link
Owner

hoytech commented Jul 19, 2024

Thanks for this! I'm looking into it. My first impression is that negentropy would be a more optimal solution.

@mmalmi
Copy link
Author

mmalmi commented Sep 1, 2024

Negentropy is better for past data, but doesn't work for ongoing subscriptions. Both can be used, but this is a lot easier to implement in all clients.

@hoytech
Copy link
Owner

hoytech commented Sep 5, 2024

I think this is a pretty good idea. Did you try starting a discussion on this in the NIPs repo? I'm a bit hesitant to add non-standard protocol extensions unless there is some consensus.

@hoytech
Copy link
Owner

hoytech commented Sep 7, 2024

Found it: nostr-protocol/nips#1027

Yes I agree, this solves an issue that negentropy does not, and is in fact complementary to it. You could do an initial sync with negentropy and then stream new IDs down as they come in, without duplicating the download of full events. In fact, this may be quite useful for a nostr multiplexer I am working on.

Let me think about this a bit more, but I'm leaning towards merging this. Thank you!

@hoytech
Copy link
Owner

hoytech commented Sep 8, 2024

I left some comments in the NIP above. In short, I think the GET/HAVE functionality should be separated from the ids_only: IMO they are better accomplished with existing functionality.

I also think ids_only should somehow be a property of the request, not an individual filter. If some filters in the same REQ have ids_only and others don't, it will be unpredictable which receive the full event versus just the ID.

@mmalmi
Copy link
Author

mmalmi commented Sep 16, 2024

Thank you, good points. I can help if needed, but you're more familiar with the code and can probably implement it better.

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

Successfully merging this pull request may close these issues.

2 participants