cheng/wallet
0
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

new file: images/anon_report_from_people_who_tried_to_keep_unmoderated_discussion_viable.webp

Browse Source 
modified:   scalable_reputation_management.html
modified:   social_networking.md
deleted:    docs/contributor_code_of_conduct.html
deleted:    docs/scalable_reputation_management.html
This commit is contained in:
reaction.la 2022-05-22 16:43:48 +10:00
parent c475f46de2
commit 5c0c8a2a67
No known key found for this signature in database
GPG Key ID: 99914792148C8388
4 changed files with 10 additions and 232 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

167
docs/contributor_code_of_conduct.html
View File

@ -1,167 +0,0 @@
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<meta charset="utf-8" />
<meta name="generator" content="pandoc" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />
<title>Contributor Code of Conduct</title>
<style>
code{white-space: pre-wrap;}
span.smallcaps{font-variant: small-caps;}
span.underline{text-decoration: underline;}
div.column{display: inline-block; vertical-align: top; width: 50%;}
div.hanging-indent{margin-left: 1.5em; text-indent: -1.5em;}
ul.task-list{list-style: none;}
.display.math{display: block; text-align: center; margin: 0.5rem auto;}
</style>
<link rel="stylesheet" href="./pandoc_templates/style.css" />
<!--[if lt IE 9]>
<script src="//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js"></script>
<![endif]-->
<link rel="shortcut icon" href="../rho.ico">
</head>
<body>
<p><a href="./index.html"> To Home page</a></p>
<header id="title-block-header">
<h1 class="title">Contributor Code of Conduct</h1>
</header>
<nav id="TOC" role="doc-toc">
<ul>
<li><a href="#peace-on-earth-to-all-men-of-good-will"><span class="toc-section-number">1</span> Peace on Earth to all men of good will</a></li>
<li><a href="#operational-security"><span class="toc-section-number">2</span> Operational Security</a>
<ul>
<li><a href="#no-namefags"><span class="toc-section-number">2.1</span> No namefags</a></li>
</ul></li>
<li><a href="#code-will-be-cryptographically-signed"><span class="toc-section-number">3</span> Code will be cryptographically signed</a></li>
<li><a href="#no-race-sex-religion-nationality-or-sexual-preference"><span class="toc-section-number">4</span> No race, sex, religion, nationality, or sexual preference</a></li>
<li><a href="#no-preaching-supererogation"><span class="toc-section-number">5</span> No preaching supererogation</a>
<ul>
<li><a href="#no-claims-of-doing-good-to-random-unknown-beneficiaries"><span class="toc-section-number">5.1</span> No claims of doing good to random unknown beneficiaries</a></li>
<li><a href="#no-victim-classes-no-identity-politics-and-no-globalism"><span class="toc-section-number">5.2</span> No victim classes, no identity politics, and no globalism</a></li>
</ul></li>
</ul>
</nav>
<h1 data-number="1" id="peace-on-earth-to-all-men-of-good-will"><span class="header-section-number">1</span> Peace on Earth to all men of good will</h1>
<p>May you do good and not evil. May you find forgiveness for yourself and
forgive others. May you share freely, never taking more than you give.</p>
<h1 data-number="2" id="operational-security"><span class="header-section-number">2</span> Operational Security</h1>
<p>A huge problem with software that relates to privacy and/or to money is
that frequently strange and overcomplicated design decisions are made,
(passive tense because it is strangely difficult to find who made those
decisions), decisions whose only apparent utility is to provide paths for
hostile organizations to exploit subtle, complex, and unobvious security holes.</p>
<p>These holes are often designed so that they can only be utilized efficiently
by a huge organization with a huge datacentre that collects enormous
numbers of hashes and enormous amounts of data, and checks enormous
numbers of hashes against an even more enormous number of potential
pre-images generated from that data.</p>
<p>Another huge problem is that if we get penetrated by enemy shills,
entryists, and buggers, as the Patriot Front is and the Jan Sixth protestors
were, we are likely to wind up like the January sixth protestors, who as I
write this are imprisoned indefinitely being tortured by black guards
recently imported from the northern part of black Africa, awaiting
trial with no likelihood of any actual trial for years.</p>
<h2 data-number="2.1" id="no-namefags"><span class="header-section-number">2.1</span> No namefags</h2>
<p>A participant who can be targeted is likely to introduce unobvious security
flaws into the software architecture. All contributors should make some
effort to protect themselves against a third party subsequently coercing
them to use the reputation that they have obtained by contributing to make
subsequent harmful contributions.</p>
<p>All contributors will use a unique name and avatar for the purpose of
contributing to this project, and shall not link it to other names of theirs
that are potentially subject to pressure. In the event of videoconferencing,
the participants shall wear a mask over the lower part of their face that
conceals the shape of their mouth and jaw and a rigid hat like a fedora that
conceals the shape of the upper part their head.</p>
<p>Apart from your mouth, the parts of your face that communicate non
verbal information turn out to be surprisingly useless for identifying
individuals.</p>
<p>If you wear glasses, should not wear your usual glasses, because facial
recognition software is very good at recognizing glasses, and easily
distracted, confused, and thrown off by unusual glasses.</p>
<p>Even if there are gaping holes in our security, which there will be, and
even if everyone knows another name of a participant, which they will, no
need to make the hole even bigger by mentioning it in public. People who lack
security are likely to result in code that lacks security. They come under
pressure to introduce an odd architecture for inexplicable reasons. We see
this happening all the time in cryptographic products.</p>
<h1 data-number="3" id="code-will-be-cryptographically-signed"><span class="header-section-number">3</span> Code will be cryptographically signed</h1>
<p>Of necessity, we will rest our developer identities on GPG keys, until we
can eat our own dogfood and use our own system’s cryptographic keys.
Login identities shall have no password reset, because that is a security
hole. If people forget their password, they should just create a new login
that uses the same GPG key.</p>
<h1 data-number="4" id="no-race-sex-religion-nationality-or-sexual-preference"><span class="header-section-number">4</span> No race, sex, religion, nationality, or sexual preference</h1>
<figure>
<img src="./images/nobody_know_you_are_a_dog.webp" alt="On the internet nobody knows you are a dog" /><figcaption aria-hidden="true">On the internet nobody knows you are a dog</figcaption>
</figure>
<p>Everyone shall be white, male, heterosexual, and vaguely Christian, even
if they quite obviously are not, but no one shall unnecessarily and
irrelevantly reveal their actual race, sex, religion, or political orientation.</p>
<p>All faiths shall be referred to respectfully. Even if they happen to be
making war on us, this software may not be very relevant to that kind of
warfare, in which case that discussion can be held elsewhere.</p>
<p>All sovereigns shall be referred to respectfully, if they are referred to at all,
which they should not be. If this software is likely to frustrate their
objectives, or even contribute to their overthrow, no need to make it
personal, no need to trigger our enemies. War will come to us soon
enough, no need to go looking for it.</p>
<h1 data-number="5" id="no-preaching-supererogation"><span class="header-section-number">5</span> No preaching supererogation</h1>
<p>Status must be on the basis of code, good code, and clever code, not on
cheap claims of superior virtue.</p>
<p>When someone plays the holier than thou card, he does not intend to share
what we are sharing. Out of envy and covetousness, he intends to deny us
what we are sharing, to deny us that which is ours.</p>
<p>If he is holier than we are, he not only wants what we have, which we will
gladly share. He wants us to not have what we have.</p>
<p>Christians are required to turn the other cheek, and people attempting to
maintain a politically neutral environment need to turn the other cheek.
But you very quickly run out of cheeks, and then it is on. You cannot be
politically neutral when the other guy is not being neutral. You have to
bring a gun to a gunfight and a faith to a holy war. People who start
politics in an environment intended to be politically neutral have to be
purged, and a purge cannot be conducted in a politically neutral manner.
You have to target the enemy faith and purge it as the demon worshiping
heresy that it is, or else those attempting to maintain political neutrality
will themselves be purged as heretics, as happened to the Open Source and
Free Software movements. You may not be interested in war, but war is
interested in you.</p>
<p>We want to maintain a politically, racially, religiously, and ethnically
neutral environment, but it takes two to tango. You cannot maintain a
politically neutral environment in a space where an enemy faction wants
their politics to rule. Neutrality cannot actually be neutral. It merely means
that the quietly ruling faction is quiet, tolerant of its opponents, and does
not demand affirmations of faith. If an enemy faith wants to take over,
the ruling faith can no longer be quiet and tolerant of that opponent.</p>
<h2 data-number="5.1" id="no-claims-of-doing-good-to-random-unknown-beneficiaries"><span class="header-section-number">5.1</span> No claims of doing good to random unknown beneficiaries</h2>
<p>We are doing this for ourselves, our friends, our kin, and our posterity, not
for strangers a thousand miles away, and we only care about strangers a
thousand miles away to the extent that they are likely to enable us to make
money by making them secure.</p>
<p>If someone mentions the troubles of people a thousand miles away, it
should only be in the frame that we will likely have similar troubles soon
enough, or that those people a thousand miles away, of a different race,
religion, and language, could use our product to their, and our, mutual
advantage, not because he cares deeply for the welfare of far away
strangers that he has never met in places he could not find on a map.</p>
<h2 data-number="5.2" id="no-victim-classes-no-identity-politics-and-no-globalism"><span class="header-section-number">5.2</span> No victim classes, no identity politics, and no globalism</h2>
<p>The Open Source and Free Software movements were destroyed by
official victimhood. Status and leadership must be on the basis of code,
good code, and clever code, not on cheap claims of superior oppression.</p>
<p>The experience of the Open Source and Free Software movement
demonstrates that if victimhood is high status, code and code quality must
be low status. If victimhood is high status then “you did not build that”.
Rather, if victimhood is high status, then good code, silicon fabs, and
rockets spontaneously emerged from the fertile soil of sub-Saharan Africa,
and was stolen by white male rapists from the brave and stunning black
warrior women of sub-Saharan Africa, and social justice demands that the
courageous advocate for the brave and stunning black warrior women of
sub-Saharan Africa takes what you have, what you gladly would share,
away from you.</p>
<p>Unless, when a female contributor unnecessarily and irrelevantly informs
everyone she is female, she is told that she is seeking special treatment on
account of sex, and is not going to get it, no organization or group that
attempts to develop software is going to survive. Linux is a dead man walking.</p>
<p style="background-color: #ccffcc; font-size: 80%;"><a rel="license" href="http://creativecommons.org/licenses/by/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by/4.0/80x15.png" /></a><br />This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution 4.0 International License</a>.</p>
</body>
</html>

BIN
docs/images/anon_report_from_people_who_tried_to_keep_unmoderated_discussion_viable.webp Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 199 KiB

64
docs/scalable_reputation_management.html
View File

@ -1,64 +0,0 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style>
body {
max-width: 30em;
margin-left: 2em;
}
p.center {
text-align:center;
}
</style>
<link rel="shortcut icon" href="../rho.ico">
<title>Scalable Reputation Management</title>
</head>
<body>
<p><A href="./index.html"> To Home page</A> </p>
<h1>Scalable Reputation Management</h1><p>
The hardest part of the cypherpunk plan is scalable reputation management.</p><p>
We plan to have a global store of named rhocoins, thereby squaring Zooko’s
triangle. Associated with each name will be a nameserver, which tells you how
to contact that individual, his websites, etc, which have public keys signed by
the rhocoin private key. You start out assuming that he and all his associated
data are on that nameserver, and it gives you a permanent or temporary redirect,
signed by a public key authorized by his rhocoin private key to give such
redirects, which key contains a limit for that key and all the redirects.</p><p>
He has a collection of positive reviews, that chain to spent coins in the blockchain, via his offer or payment request, and also to a recent global hash. But what about negative reviews?.</p><p>
For that, we need reputation managers, two or three, that hold a replicated collection of negative reviews.</p><p>
The payment request chains to a name being monitored by the reputation monitors, but the person making the payment is generally anonymous. So he could manufacture positive reviews in unlimited number by sending payments to himself. So the reputation monitoring entities need to monitor spam, much as google has a problem with link farms. If the same entity gives reviews to entities that do not spam, or is unreasonably prone to giving frivolous negative reviews. One way around this is to give reviewers reputation points on the basis of the money they have paid to entities with good reputation. Paying one ro to a hundred entities gives you more reputation than paying money one hundred ro to one hundred entities..</p><p>
We really want to subdivide reviews into good, grey, and possible spam. which, suggests a logistic curve over the sum of a bunch of logistic curves.</p><p>
ln {B+&sum; ln(P<sub>i</sub>+1)}</p><p>
This means it is not enough to connect the review to the rocoins. Needs to be connected to a cheap but permanent identity. So, the transaction chains to the payers through a Merkle-patricia tree, which links to each payment request, which links to the durable named identity of the wallet receiving it, and the durable but possibly nameless wallet paying it. This part of the chain is not on global canonical blockchain, but in the private blockchains of the receiving and paying wallet, which can be visible, if the payer or the payee make parts of it public. Any conversations about the payment before the transaction are directly rendered immutable by the global blockchain, so we know the that Ann, the party that controls the wallet posting a review made the payment, but, without Bob’s cooperation, cannot know that parts of the conversation that Ann claims were seen by Bob after the transaction actually were seen by Bob. We can, however, if either Ann or Bob makes the payment request public, know that Bob requested payment for such and such, and Ann paid. If someone is telling fibs about what happened after the transaction, we can know from the global shared blockchain that Ann is not fibbing about what Ann paid and Bob promised to deliver.</p><p>
The transaction is on the global shared canonical blockchain, and links through a Merkle dac, which is not on the global shared canonical blockchain, to immutable information about who made the payment, who received the payment, and why. Subsequent conversations about the transaction are mutable, unless, of course, they result in another payment. If there is a continuing relationship, and continuing transactions between Ann and Bob, then the entire conversation up to the most recent payment is immutable.</p><p>
The problem is sybil attack. A transaction creates reputation for buyer and seller, creating an incentive to create a network of dummy transaction, to generate positive reputation for scammers, and to attack the reputation of good actors.</p><p>
But, we assume that there are a small number of big centralized reputation brokers, with big machines and custom algorithms that they continually tweek.</p><p>
One solution is to have sixty four different reputation colors, each represented by eight byte number. Known entities, that we have external information indicating that supply real goods and services, get a mix of colors reflecting the source and content of that external information. Unknown actors randomly and automatically get a color from a different palette. A transaction causes the parties get more of the same color as the entity that they transact with.</p><p>
Known link farms get colors from the bad palette.</p><p>
So, the main network of legitimate actors will tend to get all the same color mix, because every legitimate customer buys from lots of legitimate sellers, and every legitimate seller sells to lots of legitimate buyers.</p><p>
Networks of fakes will get their own distinct color, because the reputation circulates inside that network. The big giveaway will not so much be bad colors versus good colors, but the failure of colors to homogenize. All the good actors will tend to develop rather similar colors, each link farm will have its own distinct color. Every transaction inside your own little group will tend to result in more of your group color, and less of the general mix.</p><p>
With forty colors, we have a trillion different composite colors, so we randomly assign each seller entity that collects reviews an initial pool of distinct color, and they get additional color from feedback on each transaction of the entity transacted with. If feedback from a wallet never seen before, it has no color, so they get more of their own color, and it gets a pool of the color of the entity they gave feedback to proportional to the amount paid. Every completely unknown seller entity gets one hundred units of various randomly chosen colors. External reputational indications result in additions of color reflecting that external information.which will get mixed in with throughout the network of real actors and real feedback.</p>
<p style="background-color : #ccffcc; font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body></html>

11
docs/social_networking.md
View File

@ -11,7 +11,16 @@ Every uncensored medium of public discussion is getting the treatment.
We need a pseudonymous social network on which it is possible to safely
discuss forbidden topics.
We also have a crisis of shills, spamming, and scamming. So we need
We also have a crisis of shills, spamming, and scamming.
[lengthy battleground report]:
images/anon_report_from_people_who_tried_to_keep_unmoderated_discussion_viable.webp
"anon report_from people who tried to keep unmoderated discussion viable"
{target="blank"}
Here is a [lengthy battleground report] from some people who were on the front lines in that battle, and stuck it out a good deal longer than I did.
So we need
moderation. But to prevent censorship, we need entirely decentralized
moderation.