Client-side vs server-side logic

Originally posted at

What’s the pros/cons of client-sided logic (using AP C2S, dumb server, smart client) and server-sided logic (using MastoAPI, smart server, dumb client)?

I can come up with a few pros/cons for client-sided:


  • Customisable if no control over server?
  • Offline usage
  • One account for all


  • Confusing?
  • Federated timeline search must be server-sided to avoid client overload
  • Space req.?
  • Need separate inter-device sync?

Found this old and related thread: neil 🍄: "TIL that ActivityPub has a client-to-server part …" -

I’m finding a lot of discussion as to the details of implementation, but not a lot of discussion on the pros/cons of this.

Searching “client-side vs server-side logic” doesn’t do much as it’s about websites. I try to find comparisons between IMAP email clients and webclients but to no avail either.

1 Like

Woah! I don’t fully understand this yet, but it seems that even the author of IMAP was leaning towards server-sided logic/thin clients, much like what we have today with webmail and MastoAPI: A few months ago, I started working on an IMAP server, and as part of that proce... | Hacker News

From all of this, I would like to say: I believe he was actually a visionary. Many people who use IMAP do not realize this, but Mark did not (from my reading) ever believe in the offline e-mail that Google and Microsoft are slowly obsoleting, even at the benign level of IMAP synchronization; in fact, his own client (alpine) doesn’t even support that mode of operation: it is purely on “online” IMAP client with a tiny memory cache.

“”“Email synchronization is a fool’s errand; but there seem to be an abundant supply of fools that undertake it. Thus we have miserable mobile device email clients such as on the iToy, BlackBerry, and the default Mail app on Android. At least Android has k9mail which - just barely - steps over the line into “usability”.”"" –…

If you go back to the early IMAP specifications, this is actually laid out in the rationale section: the argument is that in an age where users have too many devices to easily manage and network connectivity is nearly universal–or as I will call it, “Mark Crispin’s 1988” (yes: 1988, and this is already IMAP2)–it no longer makes sense to store e-mail on the client; he then lays out a strategy for an efficient mail-specific thin-client protocol, with everything from server-side search to server-side parsing.

“”“Consequently, while the workstation may be viewed as an Internet host in the sense that it implements IP, it should not be viewed as the entity which contains the user’s mailbox. Rather, a mail server machine (sometimes called a “repository”) should hold the mailbox, and the workstation (hereafter referred to as a “client”) should access the mailbox via mail transactions.”"" – RFC 1064: Interactive Mail Access Protocol: Version 2

It is only, however, when one delves into the mailing lists where you truly get a sense for this: on various occasions, Mark has even looked at modern webmail systems as having more in common with IMAP than the alternatives people normally compare IMAP to (such as POP).

“”“It’s easy to dismiss all this, because only a few IMAP clients are sophisticated enough to take advantage of this state. The vast majority are glorified POP clients that babble IMAP protocol. This came about because of the long-obsolete notion that Internet access is a difficult and expensive commodity that requires that the client must keep a mirror of what’s on the server. The success of webmail (which transforms the browser into the ultimate thin client) proves that this notion is complete nonsense today. Yet people persist in claiming it. Webmail won the war for the hearts and minds of users, not because webmail is so much better than IMAP, but rather because webmail is so much better than POP.”"" –…

What struck me the most, though, is just how often people refused to see this: assuming that IMAP was something that it was not, or simply not giving Mark the respect he deserved from the history he has thinking about this problem; people oft would approach claiming they knew better, and wanted to start over. This meant that he often had to spend his time attempting to herd people towards a common goal, and defending what existed against misconceptions; even having to teach people what it meant to have a protocol at all.

“”“Before assuming that you are smarter than the old guy, you ought to make sure that you really understand the problem.”"" –…
1 Like

Here is a recent blog by Anthony Wang about Client-to-Server ActivityPub on the Fediverse:

C2S offers a standardized way for clients or bots to interact with ActivityPub servers and data stored on that server. In an alternate universe, imagine if all your ActivityPub server did was store data and handle messaging and forwarding. Now let’s say we want to implement something like PeerTube. We’d split it into two parts: a client app and a processing app. The client app can be either a website or a normal app, which people use to view videos, comment, like, whatever via C2S. The processing app can be a bot that handles stuff like transcoding videos. Crucially, the processing app can also use C2S. It’s basically just a bot.

It gets better. Have you ever been frustrated about having a Mastodon account and a PeerTube account and a Forgejo account and a Lemmy account and so on? With this system, you just need one account, and all the processing apps operate on the data of your one account. Boom. Problem solved.

It’s also compatible with the ActivityPub spec and existing implementations. Hooray!

Though the site is currently down, Anthony is involved in an MIT project looking at C2S, called Graffiti.

1 Like