4 ms·
Protocols need not always be client-server. The barrier raised by middleboxes is mainly to peer-to-peer applications, whose progress may have been systematical
by inopinatus 9y ago
Protocols need not always be client-server. The barrier raised by middleboxes is mainly to peer-to-peer applications, whose progress may have been systematically inhibited as a result, in favour of server-based i.e. centralized applications. If that hadn't happened, then your personal micropublishing social media tool might today be a peer-to-peer application, rather than a centralized advertising behemoth. There's no intrinsic expectation that end-users must feel like they're running a server in that user story.
Consider this: the application protocols that arose in the early days of the Internet were decentralized/federated systems such as NNTP, SMTP, IRC. But application-level protocols that are developed with a P2P or federated architecture today are niche rather than mainstream (like BitTorrent), or dead because a major company killed their adoption (like XMPP).
The canary was the loss of old-school active-mode FTP, broken by middleboxes impeding connections. Plenty of people saw this coming.