Good comments @cft. I also had similar thoughts, but phrased in a different way. The problem with pubs is not that they host too much data (so mirrors, having less data, are not the solution), the problem is that clients request way too much data (by default) even when they don't want so much.

In fact it seems like if you're going to host an SSB server of any kind, then it's worth (in terms of efficiency) to fill up its storage as much as possible, while still staying within healthy limits (RAM and Storage limits).

This thread was very valuable to me, because initially I was quite excited to publish this to the world, but now that we know of all the implications it would have, I don't think 1 mirror per person, many thousand times, would currently be a good solution.

There are two main problems that ssb-mirror tries to solve, and I think are worth treating separately:

Resource underuse or overuse. This problem can be experienced either in servers, when they host too much data and crash frequently, or experienced in apps, when they request too much data at once and consume a lot of bandwidth and CPU power. Ideally, servers host as much as possible but not too much to be efficient hot spots for feed updates, and apps request as little as possible but not too little to be efficient consumers.

Skills required for server admininistration. Setting up servers is not for everyone, unless they invest with some learning (terminal, SSH, docker, logs, etc). Also maintaining them when they crash often is not for everyone. So one thing ssb-mirror is solving is making it easy to setup and maintain a server. I think this is the good innovation.

Then there are secondary problems, such as the legal aspects of hosting other people's data. If it's random people, it's more of a problem. If it's friends, it's less of a problem, but then you have to be careful to respect the publicHosting setting.

I think the problem worth solving with more care is the resource underuse/overuse. A server replicating 1 feed is resource underuse, and contributes to problems instead of solving them, although it has the benefits of simplicity, as a concept, and legally too.

Maybe one improvement would be a chatbot interface for the mirror to replicate more accounts, for instance:

• Upon setup, @mirror_andrestaltz sends @andrestaltz a private message asking for other accounts to be replicated
• @andrestaltz answers that private message by listing some SSB ids
• @mirror_andrestaltz includes those feeds into its list of feeds to replicate, and fetches data from @andrestaltz

Of course another way to do this is to simply configure hops setting, but for legal reasons you might want to distinguish between "I want to follow this person's updates" and "I want to re-host this person's data to the world". The latter is an opt-in commitment to rehost. We could also consider implementing this with fractional hops, e.g. friends at distance 0.9 are accounts that I am willing to re-host to the world, accounts at distance 0.1 are #sameas, accounts at >=1 distance are just normal follows without re-hosting.

Thoughts?