Comment by cxr

I know how Fritter works, I just don't know what we're supposed to do with rakoo's comment in the context of this discussion (esp. since the claim at the end isn't even true...)

> As you said, in a server-side model you're using a server and you have a lot of freedom in how you manage the system.

This is an aside, but: I didn't say that, and it's not how I'd characterize a backend-heavy ("server-side") design, like the current way the fediverse operates, but that's really an eye-of-the-beholder thing. I think of the dumb server approach as being the more flexible and convenient one if I'm putting myself in the shoes of the person wanting to publish—for several of the reasons you mention—which is the basis for my recommendation to define a static profile, after all.

PS: The discovery problem was pre-emptively raised in the original comment. The crawler approach is more or less sufficient (and something worth encouraging), but wouldn't actually be necessary. We're augmenting an existing network here that already supports push among accounts that don't deliberately choose to operate as static nodes. If Alice wants to respond to Bob, and Alice's client sees that Bob chooses to publish through a static node but is advertising in his profile the fact that he subscribes to the "Facebook Fediverse Feedsource" account, she can push a parallel notification to it. (Bob's choice to run his account as a static node doesn't have any implication for whether FFF is static or not—or whether Alice's is, either, for that matter.)