nip-64: inbox model

[fiatjaf]

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 #1134

[staab]

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.

[alexgleason]

Inboxes and outboxes are both just relays in reality. Put another way, an outbox is a relay with a "write" marker, and an inbox is a relay with a "read" marker. So this nip can reuse kind 10002 events from NIP-65.

[fiatjaf]

I think we gain nothing by conflating two different kinds of relays. Relays specified on kind 10002 are already there and already being used. Relays that implement this NIP would require a little bit of special behavior, so it's better to signal them properly.

Also I think it's very important that users announce that they support this NIP before others start engaging with them through it, having a special kind published serves that purpose.

[arthurfranca]

it's very important that users announce that they support this NIP

After #991 gets merged, you can pick a new relay usage flag to mean "nip64 relay" instead of introducing kind:10064. nip65 regular inbox relays may be enough don't know..nip11 may help client choose to load feed using nip64 while it can default to always send follow intent when user follows someone?

[fiatjaf]

We could use a different tag in kind 10002 if people prefer that, but I honestly thinks it's always better to use a different event kind when the use case and implementation contexts are different. It's not a super strong argument, more like a rule-of-thumb I came up with, same as I said in #686 (comment).

What I don't think we should do is just rely on the "read" relays that already exist in kind 10002, as they were not chosen to be there explicitly to deal with the inbox model specified in this NIP and won't be prepared to handle it.

[alexgleason]

Why not use kind 10 and 11 events? #349

[fiatjaf]

These kinds are already being used by NIP-29.

[dcadenas]

This could be useful https://undocumented.nostrkinds.info/

[alexgleason]

6401 is within the reserved DVM Job Result range. 🤦

[vitorpamplona]

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.

[mikedilger]

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.

[arthurfranca]

This breaks how absent authors filter works.

Instead of NIP-42, better to filter like this { "nip64": "<sarah-pubkey>", kinds: [1], ...etc }. The nip64 key clearly asks for relay to change how an absent authors filter should be treated.

It is ok to let anyone see the "feed" as Sarah cause follow list is public.

[fiatjaf]

This introduces unnecessary complexity. A new term to remember, libraries would have to add support for this and everything would be awful.

I don't see any issue with using an empty "authors" and expecting the relay to treat that in a certain way, as long as the relay is carefully chosen to be treated differently by the client. A relay is already allowed to return anything they want as long as it matches the filter, it isn't mandated or expected to always return everything.

There are already other experiments out there of relay that behave differently when AUTHed and when not and I hope to see more.

Also specifying the AUTH stuff from the beginning is nice as it allows for private feeds in cool ways that, although not explicitly specified in this NIP, could be implemented somewhat easily.

[mikedilger]

I must have missed this entire paragraph. You are suggesting to put the smarts in the relay. I thought Walter would just tag Sarah when he puts her notes into her inbox relay. If the relay really handles the subscriptions as a service without the tagging, then of course this is not synonymous with a NIP-65 inbox relay and it should be specified differently.

[fiatjaf]

I don't think there should be any tagging. Walter writes one note, signs it once and sends it to all the relays of people who have previously announced their intent to follow him (and also sends it to his own outbox relays). If he had to write a different note for each I think this would be a cumbersome nightmare.

[fiatjaf]

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.

[alexgleason]

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.

[vitorpamplona]

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.