Reflections: the ecosystem is moving

tags

Protocol Coordination Costs

Federation brings stasis that is fatal in a fast-moving software ecosystem (re: Why isn't Signal federated?)

Notes

Software exists as part of an ecosystem, and the ecosystem is moving.

NOTER_PAGE: (1 0.2855392156862745 . 0.0626486915146709)

it’s entirely possible to build a federated Signal Protocol-based messenger, but I no longer believe that it is possible to build a competitive federated messenger at all.

NOTER_PAGE: (1 0.47181372549019607 . 0.2006344171292625)

We got to the first production version of IP, and have been trying for the past 20 years to switch to a second production version of IP with limited success. We got to HTTP version 1.1 in 1997, and have been stuck there until now. Likewise, SMTP, IRC, DNS, XMPP, are all similarly frozen in time circa the late 1990s. To answer his question, that’s how far the internet got. It got to the late 90s.

NOTER_PAGE: (1 0.7077205882352942 . 0.2069785884218874)

once you federate your protocol, it becomes very difficult to make changes.

NOTER_PAGE: (1 0.8167892156862745 . 0.15305313243457574)

cannibalizing a federated application-layer protocol into a centralized service is almost a sure recipe for a successful consumer product today. It’s what Slack did with IRC, what Facebook did with email, and what WhatsApp has done with XMPP.

NOTER_PAGE: (1 0.8995098039215687 . 0.1260904044409199)

while it’s nice that I’m able to host my own email, that’s also the reason why my email isn’t end-to-end encrypted,

NOTER_PAGE: (2 0.1133578431372549 . 0.0880253766851705)

So long as federation means stasis while centralization means movement, federated protocols are going to have trouble existing in a software climate that demands movement

NOTER_PAGE: (2 0.16299019607843138 . 0.45598731165741474)

If XMPP is so extensible, why haven’t those extensions quickly brought it up to speed with the modern world? Like any federated protocol, extensions don’t mean much unless everyone applies them, and that’s an almost impossible task in a truly federated landscape.

NOTER_PAGE: (2 0.39767156862745096 . 0.3965107057890563)

In the consumer space, fractured client support is often worse than no client support at all, because consistency is incredibly important

NOTER_PAGE: (2 0.5790441176470588 . 0.317208564631245)

choose what provider gets access to your metadata.

NOTER_PAGE: (2 0.8321078431372549 . 0.4591593973037272)

every email I send or receive seems to have Gmail on the other end of it anyway.

NOTER_PAGE: (2 0.8590686274509803 . 0.5067406819984139)

Federated services always seem to coalesce around a provider that the bulk of people use, with a long tail of small scattered self-hosting

NOTER_PAGE: (2 0.883578431372549 . 0.5297383029341792)

sadly the worst of both worlds.

NOTER_PAGE: (2 0.9356617647058824 . 0.7287866772402855)

protecting metadata is going to require innovation in new protocols and software. Those changes are only likely to be possible in centralized environments with more control, rather than less.

NOTER_PAGE: (3 0.09129901960784313 . 0.16019032513877876)

federation becomes a sort of implicit threat. Nobody really wants to run their own servers, but they know that it might be possible if their current host does something egregious enough to make it worth the effort.

NOTER_PAGE: (3 0.37316176470588236 . 0.7787470261697066)

user cost of switching between centralized communication services reduced substantially, particularly given the tendency towards addressing with user- owned identifiers like phone numbers.

NOTER_PAGE: (3 0.4577205882352941 . 0.3362410785091198)

notification center on a mobile device has become the federation point for all communication apps,

NOTER_PAGE: (3 0.5545343137254902 . 0.1324345757335448)

An open source infrastructure for a centralized network now provides almost the same level of control as federated protocols, without giving up the ability to adapt.

NOTER_PAGE: (3 0.7990196078431372 . 0.063441712926249)