Though I don't fully agree with everything he wrote, I still seriously enjoyed reding this and couldn't help nodding heavily then and now:

"Nothing about any of the protocols we’ve developed requires centralization; 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."

@z428 yeh I think its important piece of analysis.

I don't agree with it but there are some great points.

@z428 I do think a lot of folks in the libre software community (including myself) are quite naive when it comes to understanding what it takes to compete with the most popular applications out there.

@kawaiipunk Not necessarily so, but I do see a tendency in FLOSS communities to ignore or play down the effect of runtime operational aspects on overall system safety and security, for reasons not completely clear to me.

@z428 Does anyone know if this post has given rise to an in-depth discussion somewhere (mastodon, twitter, facebook, it does not matter). Also some answer on another blog . I would be intersted to read reasoned opinions on why the author is right or why not (of course apart from those reported in the post itself)

@spartaco_lemme I don't think there's a general "right vs wrong" here, rather a discussion of different requirements and threat models and different technical approaches to meet these. He obviously seems right however with his assumptions about HTTP and IP version upgrades and the general slowness in which protocols such as XMPP have moved on ever since the late 1990s, compared to competing solutions.

@z428 Yes yes, "the right vs wrong" comes from a simplified translation from my native language.

@z428 As someone who isn’t a developer and thus mostly looks at technology from a consumer perspective this part really resonates with me:

„fractured client support is often worse than no client support at all, because consistency is incredibly important for creating a compelling user experience“

@julianruf Yes, that's one reason why services such as Slack are said to refuse allowing third-party clients: Usability is a lot about client implementation and design, and by just offering an API, you completely lose control here. Not a good thing if you want to provide a well defined end-user experience.

@z428 Here is a sensible counter-deduction, which identifies the real problem, not technical but economic.

@spartaco_lemme Indeed, thanks. He does have a few valid points, however he also is a tad idealistic about XMPP in my opinion. I *completely* agree with his conclusion - we should focus on attracting mor developers, companies, supporters to, well, support XMPP and use that. Unfortunately, I am unsure whether the fact that this isn't happening at the moment is part of what's proving some of his points wrong too: After ...

@spartaco_lemme ... all, XMPP has been around for two decades and apparently hasn't, so far, managed to get this done while being "replaced" (...) by WhatsApp, Slack, Telegram, ... in just too many places. That, as far as I am concerned, speaks more for Moxies approach than for what Daniel pointed out. 😟

@z428 When I'll have some times (hours? Days? Weeks? Who knows!) I'll add some observations.

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!