Inbox model

[alexgleason]

Lots of talk about outbox model. People still discussing whether Nostr is decentralized etc.

ActivityPub uses an inbox model. I think it's easier and more intuitive than an outbox model.

The script is flipped. It starts with this premise:

1. As a poster, I want wide reach for my post. I am therefore motivated to ensure my post reaches all my followers.
2. As a reader, I want to read posts from a relay of my choice.

Then the implementation looks like this:

1. When I post, my client gets a list of my followers.
2. Client loops over my followers.
3. For each follower, use existing outbox methods (NIP-65 or NIP-05) to get the best relay for that follower.
4. Add that relay to a set.
5. After finishing the loop, send the event to each relay in the set.

Sample code:

function publishEvent(event: NostrEvent): Promise<void> {
  const relays = new Set<string>();

  for (const pubkey of await getFollowersPubkeys(event.pubkey)) {
    const url = await getBestRelay(pubkey);
    if (url) {
      relays.add(url);
    }
  }

  return pool.publish(event, relays);
}

This doesn't take away from the outbox approach, and maybe should even be used together instead of as a replacement. But my point is that clients should be trying harder to deliver posts instead of just fetch posts. Because it benefits users when their posts can be seen.

[vitorpamplona]

It makes sense for new posts (basically, when I post a kind1, get all the inbox relays of my followers and send it there), but this will take forever for 1000+ followers.

It gets a little trickier for reactions, replies, zaps, etc. Do my followers want to receive all of this stuff or just the notes? Shouldn't a reply to a person be only in that person's inbox relay?

It's best to have a DVM that is designed to receive an event from the client and send it to all the appropriate receivers. There are some interesting privacy implications to this as well (because Clients don't need to connect/auth with so many relays directly).

[alexgleason]

I am imagining a future where personal relays are the norm.

This is currently a problem faced by ActivityPub. Well, I should start by saying, that will never happen. The majority of people won't run their own server. Anyway, in a situation where there are 1000+ inboxes, that is already happening on ActivityPub, and it's not that bad.

[vitorpamplona]

Well, I should start by saying, that will never happen.

Then Nostr will never be truly decentralized.

The majority of people won't run their own server.

Their phone will be their server.

[alexgleason]

That's a cool idea. It's a bit outside the original discussion. But I think it should definitely exist. People will complain it drains their battery life and makes their phone hot.

[vitorpamplona]

Yep, we will get there, step by step.

I think the first need is a simple website to tell people which are the best relays for them, based on follows and followers. Follows is easy to calculate on the phone, followers is a bit more complicated.

[alexgleason]

We should make it a lot easier to get a NIP-05 name, and then use that as the main way to get/set relays for a user.

[staab]

A combination of inbox and outbox will be necessary. This is how Twitter organizes their network. Big accounts push their tweets to everyone's inboxes, while small accounts' tweets get pulled from their outboxes (or so I'm led to understand). But I prefer the pull model, because by default it results in the least duplication of content, with the option to replicate based on requested content (this would be implemented by user inbox relays or read proxies rather than by clients directly pushing content out).

[fiatjaf]

This is quite a good idea, and it's so obvious I wonder how we have all missed it.

The problem of "just doing it" today is that it will centralize things. In a way a naïve version of this model is what everybody is already doing: just publish to the top-3 relays as you can be sure everybody is listening to these relays already.

But I think we can make it better, for example, by specifying two new event kinds, follow and unfollow, and publish those to the inbox relay of the person we're following/unfollowing. And in these events we specify a special relay URL which is where that person should send their notes if they want us to read them.

This way we can have special relays that keep track of who we follow and index (or reject) received notes properly to where we can just send a blank REQ (with AUTH) and get our feed, clear and immaculate.