STORY
Making private feeds with Nostr
AUTHOR
Joined 2022.06.04
DATE
VOTES
sats
COMMENTS
TAGS

Making private feeds with Nostr

What we need?

To have spaces that are "private" where only a selected subset of users can view the feed.

An example of such spaces is the Founder's Club.

Considerations

- We need to do that with nostr because our commenting system & notifications system is built on that, so if we do it without nostr we will be missing on that.
- We don't want to base this authentication on the user using his nostr-keys, because this will mean that the user can't see these private feeds on his other devices like mobile.

How this could look like

Suggestion #1: Having a private relay for each space

Each space would have its own private relay where only a list of whitelisted users could "Connect" to the relay and query/post to it.

But how can we actually make a relay private & only open it to a certain bolt.fun user??

Hmmmmm....

We can do some authentication on the relay side, so that they can assign some auth headers/cookies, and check for them when connecting, ...etc

But I don't like any method that will require changing relays' code in any way because this doesn't make them "dumb" relays anymore, and this will complicate stuff on relays side.

Another approach is to have a middle layer that handles the authentication and then connects to the relevant relays according to what the permissions the user has.

This middle layer can actually be something like nostr-proxy!

(If it has become stable)

Where we can "on user connection" check some auth header that the user sends along, using this header, we need a way to figure out which relays he is allowed to connect to, this can be done by sending an authenticated request to our API serverless functions which checks the database for some new table that contain which spaces/relays each user has access to & returns it.

After it returns this list to the nostr-proxy layer, the nostr-proxy will connect to a list of relays.

Now you might have already noticed, but this means that the secret thing will be the URL of the private relays.

There's no authentication on the actual relays side, the only secret thing is the URL of the relay.

This approach is good because:

- It keeps the relays simple/dumb, so no updates needed to relays code

- The user can connect to this private relays from any of his devices

- Everything happens in the background

Cons:

- It's not very secure, because as we said, the only secret thing is the relay URL

- We will have to maintain a new service constantly (extra costs)

Tbh, I'm not really convinced of both of those approach