Comment by cxr
4 years ago
I don't understand your comment. What are you responding to, and what am I (or someone else) supposed to do with the information that your comment tries to convey?
4 years ago
I don't understand your comment. What are you responding to, and what am I (or someone else) supposed to do with the information that your comment tries to convey?
I think rakoo was contrasting your observation as a "server-side vs client-side" distinction. 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. The p2p model in Beaker put everything in the client (the browser and thus the frontend js) and you're constrained to that model.
The nice thing about client-driven p2p is that the local-first model mirrors the intuition of using a desktop app, kind of like editing files in vim. Rakoo is overselling it a bit though, because the p2p network we used doesn't guarantee uptime unless you keep your device on. You might still want a caching supernode in the system. P2P also introduces coordination challenges with multiple devices, though the hypercore protocol folks are developing some answers to that now.
The idea you're discussing of dumb files on an HTTP server can work. There's a shocking amount you can accomplish if you just add the ability to enumerate files with range-queries (aka "list files in folder") though solving that with generated index files as in RSS is also fine, and a bit more flexible to boot. If your goal is to keep the server "dumb" then you're probably looking at a pull-based architecture -- again like RSS -- which reduces the amount of coordination between servers. This tends to mean you sacrifice discovery because you don't receive information you're not pulling, so a @mention or reply or subscribe by a random won't reach you. That might be a feature more than a bug for some. The solution is either to add push or to do some network-crawling. Secure Scuttlebutt does the latter along N expansions of the FoaF graph, which has a nice web-of-trust concept embedded in it. You could also go "full google" and run a service that crawls the entire network, then serve the crawled output to users, at which point you're pretty much at Twitter-levels of connectivity with a pull-based network.
The one other observation I'd make is that dumb file servers are most limited by the kinds of queries they can satisfy over the network. You can solve that either by crawling a site into your local index before attempting queries, or by trying to produce index-files on each server (which, again, is basically what RSS is). If you do the latter, I'd look into a file format in which range queries could be used so that a query can fetch a subset; perhaps using a fixed-length header and/or fixed-length records.
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.)