Naming for "inherited" and "platform" centralization

[tfpauly]

I'm having a bit of trouble with the names for "inherited" and "platform" centralization. I think these are useful points, but the names don't seem to be the most intuitive to me.

Section 2.2.4, “Inherited centralization”. I find the name to not match with what’s described well. It’s mainly about layering, and what a lower layer can do to force centralization on the layer above. Inheriting sounds more passive, whereas the example seems to require active interference of the lower layer.

Section 2.2.5, “Platform centralization”. Is this really a unique type of centralization? It may be, but I'm having trouble with how this is described. It’s more just saying that a protocol might be used as part of a centralized solution, even when that protocol itself isn’t centralized. The social networking example given here was supposedly also the “consolidation” category already. It seems like there, the driver of centralization is consolidation, that just uses the platform. The platform here (HTTP) seems to be neutral to the centralization question — it neither encourages or discourages centralization.

[mnot]

These are the two that I haven't yet found new names for - would love suggestions.

I'll think more on platform. I included it because this factor does come up in discussions, and while we can't prevent it, we need to be able to talk about it (if only to say that we can't do anything about it).

[tfpauly]

I'll think about the names.

This is likely too strong, but "inherited" could be called "coercive centralization" or "forced centralization", where another layer tries to enforce centralization on a higher layer by blocking other or new services.

For "platform", it seems like it is about "enabling" centralization, by having a protocol that doesn't actively discourage or prevent centralization above it? But I'm still not sure about this one. It seems like it could be a separate category — like even if you aren't actively centralizing, you may be participating in a centralized system by enabling it.

[mirjak]

I also just wanted to open an issue that these two „kinds“ are unclear to me. I think the text in the section is good but why this is a different kind is unclear. However I think this is a general problem with the section. I don’t find it too useful to try to classifying centralization into different (separate) „kinds“. Maybe the section should be rather title something like „causes of centralization“ or something like this….?

[tfpauly]

I'm wondering if we could talk about this as "conditions for centralization to exist", with "motivating" and "enabling" factors.

For example, in the case of social media concentration, it seems like the concentration is a motivating factor, and that platforms that do not prohibit centralization are enabling to concentration.

In the case of inherited centralization, I think there's a motivating factor of some lower layer to do centralization for some reason, but there's an enabling factor of revealing upper layer info by not encrypting that allows the lower layer to block things it doesn't like, etc...

[jfinkhaeuser]

I like the conditions approach.

I see this in HTTP quite strongly: it contains the conditions for centralization, even skews in favour of it by making it harder to have servers or proxy act as oblivious intermediaries in an end-to-end scenario. But it's really external (e.g. commercial) factors that motivate the exploitation of this. Still, in the case of HTTP I would think "enabling centralization" is too soft, "motivating centralization" maybe to harsh a phrasing, but it certainly nudges towards centralization because other approaches are harder.

[jariarkko]

I also like the conditions -approach!

[mnot]

Any more thoughts about these names?

[jfinkhaeuser]

After revisiting this draft, I think the naming is good enough. But this is in part because of #88, which distinguishes between centralization and consolidation.