I like the idea of being able to easily run your own node, but this sounds like a UX nightmare unless there's also some way to better manage relays.

I'm imagining having to add a relay for every single person I want to follow and it sounds tedious.

The other concern is discoverability. If many people are only posting to their own relays, I'd never find them unless they have a webpage or something that I happened to stumble across. And if they're posting to public relays, why bother having a private mirror (which may be incomplete in terms of replies)?

I get that it could serve as a backup, and I appreciate that aspect. The other benefit would be that it'd be easier for small communities to form like I could set up a server for my local Makerspace or HAM club or whatever.

Bottom line: limited value unless combined with other changes

I'm also suspending disbelief that anyone would take a one-time payment to host something forever. That's a huge economic problem that would need to be addressed to go from "thought experiment" to "implementation"

Reply to this note

Please Login to reply.

Discussion

To be clear, I think there's something here, but it either needs to have more to it, or have a clearly defined goal (e.g. "this is to provide a backup service, use other solutions for other problems")

Thanks! okay perfect, this is exactly why I'm asking because my Nostr knowledge is lagging behind my knowledge of personal servers.

1. what if your personal relay "subscribed" to the personal relay of every user you followed? such that your relay served as a sort of "relay federation" backend for your followed users

2. what are the Nostr network congestion implications of 1:1 user:relay?

in general I think the best solution is something like you described: there are "public relays" which serve as discovery points and "town squares" and then each user has their own backend that handles their "local federation" of their myriad private communities.

agreed in general about the difficulties of hosting and payment. there are "other solutions" to that which are tangential to the Nostr network points at hand, so let's table that aspect.

1. That seems workable. I don't know all the details about the nostr protocol, but AFAIK follower lists are public, so stashing your follower list on your own server should allow the server to start checking those relays

2. Having a lot of connections on a mobile device isn't great, but with the above approach, you'd only need endpoints to connect to your own server (and some public relays to assist in finding new people to follow). Servers can handle thousands of concurrent connections, and there's no reason the connections have to remain constantly open to every relay.

I'd want to make sure that each of my clients has a complete copy of everything I'd need to spin up a new server. This would be things like DMs, following list, follower list, relay list, and so forth. I think that was assumed here, but I just wanted to point out that it's an important feature. Little servers go away all the time, so we want to make sure users have the confidence that people can recover when that happens.

Encryption can satisfy the desire for confidentiality, but it's important to be clear about what is being stored where and who has access. For example, "DMs are stored on your server, but the server can only see the sender and recipient, not the contents", and "list of people you follow is on your server and the server can see everyone on this list"

precisely: edge clients (like mobile devices or browsers) would only have a single connection to your own backend (not counting any other public relays you choose in the client). furthermore, the same backend would be serving you the client code: so you have a personal, uncensoredable front end that only connects to your own backend, which is a nice bonus and removes dependency on single point of failure clients.

another happy side-effect: content hosting (like images, music, videos) is also solved. the same VM that is providing the Nostr relay would also host static content. so every user is also a content provider, which solves the problem that nostr.build and others are currently struggling with.

not only is this convenient and cost-effective, but it also means an uncensorable content distribution network. with no single choke to squeeze, censors can't put pressure on content hosting. (it also means lots of pirated movies flying around, but let's not go there just yet :)