[HN Gopher] Protocols, not platforms: A technological approach t...
___________________________________________________________________
Protocols, not platforms: A technological approach to free speech
(2019)
Author : uberdru
Score : 71 points
Date : 2022-06-09 15:37 UTC (7 hours ago)
(HTM) web link (knightcolumbia.org)
(TXT) w3m dump (knightcolumbia.org)
| Barrin92 wrote:
| I think this is largely a futile effort because the equilibrium
| the author thinks of when he talks about protocols does not
| exist.
|
| All existing internet platforms already sit on top of protocols,
| the internet's running on them. Anyone can built a platform on
| top of ActivityPub, on whatever crypto network or what have you.
|
| The old internet consisted of smaller islands not because of
| protocol technology, but because it had a small userbase overall
| and discovery was bad. The benefits of aggregation hadn't kicked
| in. If Mastodon gets to hundreds of millions of users I will bet
| that one or two instances will grow very large, develop their own
| rules, and what do you have then? A proprietary platform on top
| of what was once a 'first order' protocol. The protocol is still
| there but doesn't matter for end users, same way HTML doesn't to
| your average Facebook user or the blockchain doesn't matter to
| your average guy on coinbase.
|
| People need to recognize that anything that increases
| connectivity between people tends towards agglomeration. Tech is
| _inherently centralizing_ , even ironically enough the
| superficially decentralizing tools, if they lower the cost of
| communication. This isn't just the history of internet companies,
| it's the history of movement of peoples from fractured townships
| to large urban centers. It's not malicious platform lock-in, but
| simply gravity.
| veltas wrote:
| This is very true and I think it applies to everything, not
| just software. I was an anarchist at heart until I understood
| that if you just remove all the rules they all just come back
| with different names, and often in an inferior form.
| eddd-ddde wrote:
| So maybe we need the opposite, a completely authoritarian and
| centralized way of handling internet services. Imagine if
| there was a single mail service, provider and client,
| handling all possible uses cases, a single web browser, etc.
|
| Its like the complete opposite end, instead of using a
| standard protocol to implement your use case, simply improve
| on _the_ service.
|
| [Edit]: Oh, and by 'centralized' I don't mean BigCo is in
| charge of it and manage the servers for it. What I mean is
| Public Organization 'owns' the service, but this service
| could very well be self-hosted by users, decentralized, etc.
| It's just that it is 'forbidden' that any other organization
| works or develops a similar service.
| dane-pgp wrote:
| > If Mastodon gets to hundreds of millions of users I will bet
| that one or two instances will grow very large, develop their
| own rules, and what do you have then?
|
| Are you saying that these large instances would refuse to
| interoperate with each other? There are already signs of that
| happening even among small instances, but people are able to
| move their accounts from instances that are blocked by (or
| block) too many of their friend's instances, onto instances
| that have moderation policies they are more comfortable with.
|
| Better yet, because all account actions are covered by an open
| API, it would be possible to create an account on a service
| that lets you make posts on multiple sub-accounts on different
| instances, and aggregate messages from your friends across
| them, which should heal any fracturing of the network for
| people who really have friends who (are in communities which)
| hate each other.
| notriddle wrote:
| > Are you saying that these large instances would refuse to
| interoperate with each other?
|
| Likely. It's the same thing that happened to the big XMPP
| instances.
|
| There are other ways that open systems turn closed. I'm not
| sure which one would happen to the Fediverse, but given how
| often it has happened, and the variety of proximate causes
| and exact end-states, I'm betting my money on the Fediverse
| turning closed somehow.
|
| * The XMPP path where the biggest instances just decide they
| aren't going to federate with anyone else any more.
|
| * The SMTP path where the big instances gradually accumulate
| anti-abuse mechanisms that make the barrier to entry too high
| for anyone who requires reliable delivery and isn't one of
| them.
|
| * The IRC path where the network fractures into centrally-
| controlled coalitions that federate with each other but not
| with anyone outside the coalition.
|
| * The NNTP path where the cost of running a server kept going
| up, the number of servers kept going down, and now if you
| want access to the entire network, you have to pay a
| subscription fee to one of four companies.
|
| * The Git path where a single instance bundles value-adds
| that lead to most users just using the one central service.
| shkkmo wrote:
| The mastodon community of today is very different from what
| it would be if it had hundreds of millions of users. Once the
| plaform grows enough to critical mass, the costs of switching
| off that platform become high enough that it can close itself
| off without mass exodus.
|
| The only way I see to end up with anything like what the
| author lays out is to mandate interoperability for platforms
| (possibly over a certain size). Unfortunately I have zero
| faith that our legistlators can craft and pass a bill that
| does that without bastardizing it to the point that is simply
| creates moats for the incumbent tech giants. I'd love to be
| surprised.
| zozbot234 wrote:
| Mastodon is not built for a single community comprising
| "hundreds of millions of users". Individual users and
| communities will interact on a far smaller scale, much as
| they might with email.
| slg wrote:
| Hiding abuse from the end user only stops direct forms of abuse,
| but it won't stop all abuse. Revenge porn is a classic example
| because that is usually directed at everyone in a target's life
| without needing to reach the target themselves.
|
| Imagine a scenario in which the target uses a client that
| aggressively hides content. However since this system is protocol
| based, other users would be using clients that aren't as
| aggressive. What happens if an abuser responds to every post
| their target makes with a revenge porn image? Maybe the victim of
| the abuse never sees that image because of their clients
| settings, but numerous people following them do. Isn't that still
| abuse even if the target doesn't see it? How do you stop this
| type of indirect abusive behavior without some centralized
| authority?
| wmf wrote:
| At a certain point we need to remember that the legal system
| exists.
| slg wrote:
| Clearly a sizable audience wants protections above and beyond
| what the law requires or else there wouldn't be such strong
| support for these systems curtailing abuse. Saying _the legal
| system will handle it_ is not a neutral position. It is a
| clear decision in favor of the anti-censorship side over the
| anti-abuse side.
| humanistbot wrote:
| (2019). Previously discussed at:
|
| https://news.ycombinator.com/item?id=25942632
|
| https://news.ycombinator.com/item?id=20841059
| dang wrote:
| Thanks! Macroexpanded:
|
| _Protocols, Not Platforms: A Technological Approach to Free
| Speech (2019)_ - https://news.ycombinator.com/item?id=25942632
| - Jan 2021 (269 comments)
|
| _Protocols, Not Platforms: A Technological Approach to Free
| Speech_ - https://news.ycombinator.com/item?id=20841059 - Aug
| 2019 (67 comments)
| amadeuspagel wrote:
| > Rather than relying on a few giant platforms to police speech
| online, there could be widespread competition, in which anyone
| could design their own interfaces, filters, and additional
| services, allowing whichever ones work best to succeed, without
| having to resort to outright censorship for certain voices. It
| would allow end users to determine their own tolerances for
| different types of speech but make it much easier for most people
| to avoid the most problematic speech, without silencing anyone
| entirely or having the platforms themselves make the decisions
| about who is allowed to speak.
|
| Most platforms have APIs that allow people to "design their own
| interfaces, filters, and additional services". Many also allow
| people to build their own platforms on top of them - subreddits,
| discord servers, facebook groups, etc. that they can moderate as
| they please. It would also be possible to build browser
| extensions that automatically block certain speech. But this is
| all besides that point, because this debate is not about letting
| people "determine their own tolerances for different types of
| speech", it's about preventing other people, who are willing to
| tolerate certain types of speech from doing so. This is the
| reason subreddits, discord servers and facebook groups get
| banned. The people who joined them have decided that they are
| willing to tolerate certain types of speech, but others are not.
| cryptonector wrote:
| Protocols, sure, but then you still need to have HW running them,
| which enables platform building. Also, that HW (and bandwidth)
| has significant, non-zero costs, which again tilts the field in
| favor of those with the capital to pay for it, and they'll want
| to monetize their investment, which again means platform
| building.
| [deleted]
| karpierz wrote:
| I don't see how this approach stops a centralized service from
| taking over via the standard approach of Embrace, Extend,
| Extinguish [1]:
|
| - Embrace: BigTech implements the protocol. For example, say text
| messaging.
|
| - Extend: BigTech implements some custom additions to the
| protocol, that only work for their service. For example, add
| support for sending photos, but only ones stored on BigTech's
| servers.
|
| - Extinguish: Once people get hooked on your custom features,
| make it hard for competitors to replicate. For example, stop
| competitors from being able to load photos from BigTech's
| servers.
|
| 1:
| https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
| userbinator wrote:
| We've already seen this happen with Google and browsers. In
| this case, they extend so quickly and also manage to spread
| much propaganda about how their way is better, that they're
| basically using change as their weapon.
|
| Protocols aren't the solution when people are so easily
| manipulated. Perhaps _stagnation_ is the solution. Something
| that stays static for a longer time is also going to have more
| implementations.
| cuteboy19 wrote:
| The most successful example of EEE is not Microsoft but rather
| Linux. It embraced the Unix* style, extended it with its own
| stuff and now all non Linux unices are basically an
| afterthought
| vorpalhex wrote:
| [2] is the step that can be addressed.
| karpierz wrote:
| Extend? How do you address it?
| vorpalhex wrote:
| "Protocol extensions must be able to be implemented by all
| users of the protocol and may not require a particular
| providers service but allow any alternative so long as it
| is protocol compatible"
|
| Basically force those extensions to be equally cross-
| compatible.
| karpierz wrote:
| Two key issues with a rule like that:
|
| 1. What forces me to comply with this rule?
|
| 2. What does "able to be implemented" mean? In theory,
| you can re-implement my entire codebase. In practice,
| you'll find it very difficult to maintain feature parity
| with me if I repeatedly extend the protocol faster than
| you can implement it. Especially if I don't publish my
| code or document the extension or if I simply have more
| resources available to me (either in terms of server-
| bandwidth or programmers).
| jacobr1 wrote:
| Though protocols are not law. You can have non-conforming
| implementations. If these are popular enough (potentially
| due to $proprietary_thing) then people will just use
| them. Other services will need to decide if they want to
| continue to interoperate.
| viksit wrote:
| Disagreements with this article via a claim that says technology
| _inherently centralizes_ , to me, seems flawed.
|
| The concept of democracy was evolved as a system that could
| distribute social power in order to catalyze the wider
| involvement of its members in their own social and economic
| concerns.
|
| All the way back to Alexis De Tocqueville in the 1800s (in his
| book Democracy in America),
|
| _Tocqueville attributes the ultimate success of liberty in
| America, however, to a feature of American political order he
| refers to as "administrative decentralization," which-going
| beyond federalism as such-fosters the participation of citizens
| in "real . . . political life" beginning at the local (sub-state)
| level_. [1]
|
| To me, a series of decentralized, shared ownership systems that
| come together to provide and replace the functionality that has
| today been built into centralized networks is the only way to
| achieve any kind of "liberty" (however one may define that word).
|
| The missing link for these systems has historically been cost -
| who runs the servers that runs these systems, and who pays to
| develop them? It is exactly for this reason that they were
| centralized in the first place.
|
| Today, we've got one way to solve for these problems (tokens).
| I'm sure there will be more. But they will all be catalysts
| towards this direction.
|
| Edit: To comments talking about how protocols won't just be
| replaced by big companies.
|
| All companies ultimately care about one thing -- distribution.
| They will continue to be the direct link between customers /
| users and the service they provide. The difference is that they
| will need to build upon the protocol that has the most
| distribution.
|
| If we imagine a new open protocol for "online document comments"
| that existed, Google Docs AND Office online could use it and have
| interoperable commenting from each other's identity systems vs
| the state of the landscape today. what would their motivation be
| to do it? Same as using open source libraries like ffmpeg or
| openSSL -- except this time, they don't pay to host the APIs that
| power this protocol.
|
| [1]
| https://www.catholicculture.org/culture/library/view.cfm?rec...
| RcouF1uZ4gsC wrote:
| > The concept of democracy was evolved as a system that could
| distribute social power in order to catalyze the wider
| involvement of its members in their own social and economic
| concerns.
|
| Even in democracy there is a tendency to centralize. For
| example, there are big differences between ancient Athens,
| modern Switzerland, the USA, and the EU.
|
| They all are implementations of democracy, but as democracies
| have grown larger, it becomes more centralized.
| avgcorrection wrote:
| > Democracy in America
|
| Relatively speaking. Written by a French aristocrat.
| transfire wrote:
| And coming from the other end...
|
| "Protocols, not APIs"
___________________________________________________________________
(page generated 2022-06-09 23:01 UTC)