nips
nips copied to clipboard
nostr-protocol
nip-64: inbox model
just throwing out the idea, I don't know if it is worth exploring.
read here: https://github.com/nostr-protocol/nips/blob/inbox-model/64.md
from the text:
The approach described in this NIP doesn't replace any of the other models for following people that are already in use in Nostr, and doesn't claim to be strictly superior to the Outbox Model, but just provides an alternative way to do things.
In reality, clients should implement both approaches and can never assume others will implement this.
based on https://github.com/nostr-protocol/nips/discussions/1134
I don't really see what this accomplishes. All it does is make an empty filter meaningful for auth'd users. This seems like a job for a content recommendations DVM instead, or a tool that can pull Walter's notes into Sarah's relay. But if she wants to retrieve Walter's content she should just ask for it.
The idea is good and it serves as an alternative to the pull model. We can have both running at the same time.
To @staab's point, we can also use the subscription events to help a service provider or a DVM to redistribute events where they are supposed to be.
But I do think the unfollow event should just be a deletion request.
The inbox model has different characteristics from the outbox model. Neither replaces the other and both can co-exist.
... but the outbox model is superior of course.
I'm not sure we need a separate list of inbox relays for the inbox model. It adds complexity, and I don't see the benefit.
I guess we could remove the special handling of events by the inbox relays and the blank filter behind AUTH and this NIP could still work somewhat (one would have to pick a permissive relay for their inbox, then query it manually with an "authors" filter later), but it would lose much of its appeal to me and probably not worth doing. Probably not even worth specifying as it becomes just a free-for-all.
I'm still thinking about this NIP. My original suggestion in #1134 was just that clients should try harder (a "free-for-all"). But I like that you envisioned something more.
I think this will be a slow burn. It's the start of something. Next someone needs to make an all-in-one "inbox/outbox" package in some programming language (~~TypeScript~~ Rust) that does all the hard parts of this. What is maybe missing is the yin-yang of inbox/outbox used together.
I guess we could remove the special handling of events ... probably not worth doing
I would never use that special filter anyway. All I need to do is add the user's own inbox relay to the relay list of the usual authors: filter. If the client knows about the subscriptions and is sure the writer is using a compliant client, it can even switch to the user's relays. Rergardless, the filter stays the same.