Incorporate feedback from TWIM discussion

This article received some good feedback from #twim:matrix.org in
Matrix. Some clarifications I made:

- @cos:hacklab.fi mentioned that Element/Synapse are open-source; I
  opened the article by mentioning that FOSS alone isn't enough and
  added a note on their complexity to the matrix/element case-study
- @sorunome:sorunome.de mentioned that there is no "reference
  implementation" of Matrix; I rephrased a sentence to state that
  Element "practically serves as the reference client implementation".
- Clarify that Element builds "most of" the spec instead of being in
  charge of it; the Spec Core Team (SCT) is a different entity but is
  made mostly of Element employees.
- Changed leaving implementations out of decisions to leaving
  implementation feasibility out of decisions.

content/posts/keeping-platforms-open.gmi

@@ -1,3 +1,5 @@
+This article is the second entry of series of posts exploring situations in which FOSS alone isn’t enough to secure user freedom.
+
 My previous article, Whatsapp and the domestication of users, got more attention than I was expecting. Some responses gave me a lot to think about,¹ especially regarding *actions* we can take. I suggest reading that article first; it explained what "user domestication" is and why it's a problem. It enumerated three countermeasures: FOSS, simplicity, and open platforms.
 
 =>  ../../../2021/01/27/whatsapp-and-the-domestication-of-users.html WhatsApp and the domestication of users
@@ -42,7 +44,7 @@ XMPP is still alive and well, but its current popularity is a fraction of what i
 
 Standards are a form of agreements made to ensure compatibility between implementations. Such agreements need to be agreed upon by the implementations themselves. When one implementation grows dominant, so too does its leverage in the decision-making process over shared standards. Too much dominance can create a monoculture in which the dominant implementation is the only implementation that conforms to the spec.
 
-With enough leverage, a dominant implementation can serve as a reference implementation. Reference implementations are typically quite helpful, serving as a source of truth to test other implementations against. Problems may arise when development of the spec and production-grade reference implementation grow tightly coupled, leaving other implementations out of the decision-making process.
+With enough leverage, a dominant implementation can serve as a reference implementation. Reference implementations are typically quite helpful, serving as a source of truth to test other implementations against. Problems may arise when development of the spec and production-grade reference implementation grow tightly coupled, leaving third-party implementation feasibility out of the decision-making process.
 
 ### Case study: Matrix and Element
 
@@ -50,9 +52,13 @@ One example of this phenomenon is Matrix.
 
 => https://matrix.org/ Matrix.org
 
-Matrix is an open and federated instant-messaging platform similar to XMPP, with a very large spec boasting many features: server-side history, replies, rich text, reactions, room versions, end-to-end encryption (E2EE), avatars, display names, typing indicators, read receipts, device verification...the list goes on and grows every month.³ The only client that implements all the necessary features is Element. In addition to being the most popular client, Element is the reference client implementation developed by the same company that builds the dominant servers and spec. The tight coupling between Element and the Matrix spec allow it to add features at a rate too fast for other clients too keep up; pretty much every Matrix user has to open up Element at some point to perform an action that isn't supported in any other client. On the server side, Synapse is the only server that implements enough of the spec to be usable, with Dendrite coming in second. Both are made by the same company that develops Element.
+Matrix is an open and federated instant-messaging platform similar to XMPP, with a very large spec boasting many features: server-side history, replies, rich text, reactions, room versions, end-to-end encryption (E2EE), avatars, display names, typing indicators, read receipts, device verification...the list goes on and grows every month.³ The only client that implements all the necessary features is Element. In addition to being the most popular client, Element practically serves as the reference client implementation: it's developed by the same company that builds the dominant servers and most of the spec. The tight coupling between Element and the Matrix spec allow it to add features at a rate too fast for other clients too keep up; pretty much every Matrix user has to open up Element at some point to perform an action that isn't supported in any other client. On the server side, Synapse is the only server that implements enough of the spec to be usable, with Dendrite coming in second. Both are made by the same company that develops Element.
 
-Since there aren't any third-party clients and servers that can replace the official ones, one vendor is close to controlling all parts of the platform. Matrix is close to being a boxed platform because the official client and server can iterate independently of the greater ecosystem.
+Since there aren't any third-party clients and servers that can replace the official ones, one vendor is close to controlling all parts of the platform. The growing complexity required of clients and servers can also further entrench these dominant implementations, as I explained in the previous article's "Simplicity" section:
+
+=> gemini://seirdy.one/2021/01/27/whatsapp-and-the-domestication-of-users.gmi
+
+Matrix is close to being a boxed platform because the official client and server can iterate independently of the greater ecosystem.
 
 I don't think that Matrix is going to become a fully closed platform anytime soon; the blog post "On Privacy versus Freedom" seems to put it on the right side of the closed/open spectrum.
 

content/posts/keeping-platforms-open.md

@@ -11,6 +11,8 @@ tags:
   - user domestication
 title: Keeping platforms open
 ---
+This article is the second entry of series of posts exploring situations in which <abbr title="free and open-source software">FOSS</abbr> alone isn't enough to secure user freedom.
+
 My previous article, [Whatsapp and the domestication of users](../../../2021/01/27/whatsapp-and-the-domestication-of-users.html), got more attention than I was expecting. Some responses gave me a lot to think about,[^1] especially regarding _actions_ we can take. I suggest reading that article first; it explained what "user domestication" is and why it's a problem. It enumerated three countermeasures: FOSS, simplicity, and open platforms.
 
 Hard problems, by definition, lack easy solutions. Simply choosing (or creating) a platform that avoids user domestication isn't enough if that platform can change. The price of freedom is eternal vigilance; in addition to settling on the right platform, we must ensure that it honors its users in both the present _and the future_. Keeping a platform FOSS and simple is more straightforward[^2] than keeping a platform "open".
@@ -50,13 +52,13 @@ XMPP is still alive and well, but its current popularity is a fraction of what i
 
 Standards are a form of agreements made to ensure compatibility between implementations. Such agreements need to be agreed upon by the implementations themselves. When one implementation grows dominant, so too does its leverage in the decision-making process over shared standards. Too much dominance can create a monoculture in which the dominant implementation is the only implementation that conforms to the spec.
 
-With enough leverage, a dominant implementation can serve as a reference implementation. Reference implementations are typically quite helpful, serving as a source of truth to test other implementations against. Problems may arise when development of the spec and production-grade reference implementation grow tightly coupled, leaving other implementations out of the decision-making process.
+With enough leverage, a dominant implementation can serve as a reference implementation. Reference implementations are typically quite helpful, serving as a source of truth to test other implementations against. Problems may arise when development of the spec and production-grade reference implementation grow tightly coupled, leaving third-party implementation feasibility out of the decision-making process.
 
 #### Case study: Matrix and Element
 
-One example of this phenomenon is [Matrix](https://matrix.org/). Matrix is an open and federated instant-messaging platform similar to XMPP, with a very large spec boasting many features: server-side history, replies, rich text, reactions, room versions, <abbr title="end-to-end encryption">E2EE</abbr>, avatars, display names, typing indicators, read receipts, device verification...the list goes on and grows every month.[^3] The only client that implements all the necessary features is Element. In addition to being the most popular client, Element is the reference client implementation developed by the same company that builds the dominant servers and spec. The tight coupling between Element and the Matrix spec allow it to add features at a rate too fast for other clients too keep up; pretty much every Matrix user has to open up Element at some point to perform an action that isn't supported in any other client. On the server side, Synapse is the only server that implements enough of the spec to be usable, with Dendrite coming in second. Both are made by the same company that develops Element.
+One example of this phenomenon is [Matrix](https://matrix.org/). Matrix is an open and federated instant-messaging platform similar to XMPP, with a very large spec boasting many features: server-side history, replies, rich text, reactions, room versions, <abbr title="end-to-end encryption">E2EE</abbr>, avatars, display names, typing indicators, read receipts, device verification...the list goes on and grows every month.[^3] The only client that implements all the necessary features is Element. In addition to being the most popular client, Element practically serves as the reference client implementation: it's developed by the same company that builds the dominant servers and most of the spec. The tight coupling between Element and the Matrix spec allow it to add features at a rate too fast for other clients too keep up; pretty much every Matrix user has to open up Element at some point to perform an action that isn't supported in any other client. On the server side, Synapse is the only server that implements enough of the spec to be usable, with Dendrite coming in second. Both are made by the same company that develops Element.
 
-Since there aren't any third-party clients and servers that can replace the official ones, one vendor is close to controlling all parts of the platform. Matrix is close to being a boxed platform because the official client and server can iterate independently of the greater ecosystem.
+Since there aren't any third-party clients and servers that can replace the official ones, one vendor is close to controlling all parts of the platform. The growing complexity required of clients and servers can also further entrench these dominant implementations, as I [previously explained](https://seirdy.one/2021/01/27/whatsapp-and-the-domestication-of-users.html#simplicity). Matrix is close to being a boxed platform because the official client and server can iterate independently of the greater ecosystem.
 
 I don't think that Matrix is going to become a fully closed platform anytime soon; the blog post ["On Privacy versus Freedom"](https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom/) seems to put it on the right side of the closed/open spectrum. Clients like [gomuks](https://github.com/tulir/gomuks) and [FluffyChat](https://fluffychat.im/) seem to keep up with Element well enough to serve as partial replacements. I do, however, find its current state problematic and much closer to "closed" on the closed/open spectrum than XMPP, IRC, and email.
 
@@ -106,7 +108,7 @@ For example, Element and the Matrix.org Foundation would alleviate most of my co
 Drawbacks
 ---------
 
-The biggest drawback to the advice I've presented is development speed. Keeping compatibility and spec compliance slows down the rate at which new features can be added. As Moxie [argues](https://signal.org/blog/the-ecosystem-is-moving/), Signal might not have been able to implement as many features if it was an open platform; spec-constrained development is, by definition, *constrained*. Users are limited by the lowest common denominator among popular participating implementations.
+The biggest drawback to the advice I've presented is development speed. Keeping compatibility and spec compliance slows down the rate at which new features can be added. As Moxie [argues](https://signal.org/blog/the-ecosystem-is-moving/), Signal might not have been able to implement as many features if it was an open platform; spec-constrained development is, by definition, _constrained_. Users are limited by the lowest common denominator among popular participating implementations.
 
 Open platforms with multiple providers and implementations often suffer from poorer usability, especially with regards to onboarding. Instead of just opening the official app/website, users need to choose from multiple clients and providers. This can be a turn-off for casual users just wanting to try something out. One of the best ways to improve the onboarding experience is to offer recommendations to your non-technical friends; you know them well and can probably help them make an informed decision.