An appview doing partial sync of the atmosphere is going to have two drivers of its cost: 1. number of users being synced, 2. number of direct users of the appv

An appview doing partial sync of the atmosphere is going to have two drivers of its cost: 1. number of users being synced, 2. number of direct users of the appview. #2 because some additional work is done for the direct users, such as computation of the following feed. I won't have exact numbers until we actually finish that distro and deploy it, but my ballpark for 5k direct users with, say, 100 follows on average leading to 500k synced users, I'd say $100-200/mo with a max of $500. If you're not running a big instance, you're not paying big costs. EDIT: I should clarify that the partial sync runmodel that we're developing will still operate on atproto's "shared heap" approach which means that activity outside of the selected sync-set (the 500k users) will not be visible to the NYT users. How we solve that limitation is an open question. We could introduce message-passing to notify about that activity, for instance. I think that's the most notable downside compared to a comparable AP deployment, which inherently operates on message-passing.