Fix typos in manifesto#2
Open
koute wants to merge 1 commit into
Open
Conversation
koute
commented
Sep 27, 2022
|
|
||
| Secondly, as pointed out by Moxie recently \cite{TODO} major networks almost universally fail at facilitating decentralised usage of their service to their users. In order to gain the guarantees offered by the decentralised service, it is generally required to participate on the network directly by running the node software. This generally requires large amounts of time, a reliable, high-speed connection, plenty of storage and the installation of specialist software. Almost all real users are unable to do this and instead simply trust a centralised intermediary which relays information to and from the network.\footnote{Polkadot is actually far ahead of the pack on this, and can provide its service securely to users both in-browser or on mobile without the need for such an intermediary.} A notable example of this is the Infura infrastructure of Ethereum which is used by default in Metamask, the predominant way of accessing Ethereum-based applications. | ||
|
|
||
| Thirdly, finally and most importantly for the present work is the practical means by which node operators fulfil their role. It must be understood that blockchains are inhererntly software systems: operating a node on the network involves securely running a piece of software on a machine able to correctly operate according to the network's protocol. We generally call this piece of software the ``blockchain client'' or the ``node software''. Node operators may a decision to run this software and must manually select the software to download and may even need to decide when and whether to apply updates to it. Most node operators are uninterested in arcane protocol discussions and defer to very basic social factors in their decision. This leads to a silent and hithertoo little-explored centralisation risk for the network. And, unlike the first two points which can arguably be solved purely through mathematics and technology, I posit that this is instead a more entrenched social issue and as such a harder problem to solve. To understand the centralisation risk, it is crucial to understand the factors by which node operators select \emph{which} software to use, and \emph{whether} they should apply some upgrade. If these factors lead to the possibility of a small, well-aligned group of people able to widely deploy changes to the protocol, then it can gravely undermine the protocol. |
Author
There was a problem hiding this comment.
GitHub seems to butcher this diff and doesn't show changed words; two words were changed here:
inhererntly->inherentlyhithertoo->hitherto
|
While you are at it. There is a type for |
ltfschoen
reviewed
Sep 28, 2022
| As with most software projects, there is generally a single team behind the node software. In highly commercial blockchains, the software is subject to a closed development model in which a company's CEO has ultimate and absolute control. This makes the blockchain laughably compromisable and entirely unfit for use. | ||
|
|
||
| However, even in highly open blockchain projects with open-source software (OSS) development models, decisions in software development must still be made and they will tend to happen under the benevolent dictator model as written about in the seminal work by Raymond\cite{cathedral_and_bazaar}. This can lead to a problem where a minority, including said dictator, are of one opinion and the majority are of another. If both sides feel strongly and cannot be reconsiled in a technical manner, then OSS projects may schism and become ``forked'', leading a single project and community to be split into two. The resultant projects and their teams fight for users on the merits of their relevant decision. Typically one project eventually wins out but co-existence and even cooperation is not entirely unheardof. | ||
| However, even in highly open blockchain projects with open-source software (OSS) development models, decisions in software development must still be made and they will tend to happen under the benevolent dictator model as written about in the seminal work by Raymond\cite{cathedral_and_bazaar}. This can lead to a problem where a minority, including said dictator, are of one opinion and the majority are of another. If both sides feel strongly and cannot be reconciled in a technical manner, then OSS projects may schism and become ``forked'', leading a single project and community to be split into two. The resultant projects and their teams fight for users on the merits of their relevant decision. Typically one project eventually wins out but co-existence and even cooperation is not entirely unheard of. |
There was a problem hiding this comment.
Suggested change
| However, even in highly open blockchain projects with open-source software (OSS) development models, decisions in software development must still be made and they will tend to happen under the benevolent dictator model as written about in the seminal work by Raymond\cite{cathedral_and_bazaar}. This can lead to a problem where a minority, including said dictator, are of one opinion and the majority are of another. If both sides feel strongly and cannot be reconciled in a technical manner, then OSS projects may schism and become ``forked'', leading a single project and community to be split into two. The resultant projects and their teams fight for users on the merits of their relevant decision. Typically one project eventually wins out but co-existence and even cooperation is not entirely unheard of. | |
| However, even in highly open blockchain projects with open-source software (OSS) development models, decisions in software development must still be made and they will tend to happen under the benevolent dictator model as written about in the seminal work by Raymond\cite{cathedral_and_bazaar}. This can lead to a problem where a minority, including said dictator, are of one opinion and the majority are of another. If both sides feel strongly and cannot be reconciled in a technical manner, then OSS projects may schism and become ``forked'', leading a single project and community to be split into two. The resultant projects and their teams fight for users on the merits of their relevant decision. Typically one project eventually wins out but co-existence and even cooperation is not entirely unheard-of. |
Author
There was a problem hiding this comment.
I think the unhyphenated variant should also be correct and is used more often? So I'll leave this for Gav to decide.
Author
I think I already fixed that one, unless you see another one somewhere that I missed? (: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I was reading the manifesto and noticed a few typos, hence here's a PR with a few fixes. (: