Epitaxy

language server protocol would be nice…

Epitaxy is a single transferable voting system for versioned documents on a distributed hash table.

It uses Kademlia DHT to store lookups of peers and content

documents and their changes are encoded using conflict-free replicated data types.

users write updates to proposals that reference their last version as a parent hash, but are full documents.

users may delegate portions of a document to be the vote or construction of a user they delegate. This web of trust is searched via djastra’s algorithm to find a document version the user endorses. Otherwise, they manually vote using ranked choice.

elections are solved internally by the user whenever they want to know the result - they select a document containing a list of peers they accept and run the calculation.

• could just publish on fediverse and solve the problem that way.

epitaxy includes a simple templating language:

## User Bios
{% for user in group:groupid %}
	- {% delegate user:userid %}
{% end %}
## Finance
{% issue:issueid %}
	{{ .Proposal:issueid }}
	- {{ .Delegate {{.Group groupid }} }}
	- {{ .Meek {{.Group groupid}}, {{.User userid}}}
{% end %}
{% proposal}

• keys
  • group (list of users)
  • user (user ID)
  • issue (template, something to submit proposals/votes for)
  • proposal (template, may contain issues)
• commands
  • delegate (user/group)
  • STV (grouplist)

{{range $key, $val := .Group.groupid}}

{{end}}

--- // yaml frontmatter of keyed votes
comments: "user comments here"
issue1:{{ .Delegate groupid }} // list of users
issue2:{{ .Delegate userid }} // single user
issue3:{0:proposal,1:proposal,2:proposal} //manual choices
issue4:{0:proposal,2:{{.Delegate userid}},} //delegate a vote
{{ .Meek groupid 2 }} //returns the two proposals by users in the groupid referencing this template with the most votes

somehow have logic that you want multiple issues to succeed with your first choice in a package (and, or) - include the transition discussion as a separate proposal

 | .Require proposal | // dependency
 | .Forbid proposal | // negative dependency

allow lists to contain lists (they’re lists of links to links to links until you reach users)

{{ issue1 }}

{{ issue2 }}

{{ issue3 }}

user interface tooltips / langserver:

• register .mdvote
• .Delegate quick lookup
• .Require quick lookup
• .Forbid quick lookup
• cache all known

cache file:

users:
	- hash:
		nickname
groups:
	- hash:
		nickname
		users:
			- user
issues:
	- hash:
		nickname
		author: author
		parent: issue
		markdown: markdown
		forks:
			- issue: user # could be the same user
			- issue: user
proposals:
	- hash:
		nickname
		issue: issue
		parent: proposal
		author: author
		frontmatter: frontmatter
		forks:
			- proposal: user # could be the same user

immutable folder structure:

.epitaxy/{users,groups,issues,proposals}.yaml
.epitaxy/users/:user:/:content hashes:
.epitaxy/groups/:group:/:content hashes:
.epitaxy/issues/:issue:/:content hashes:
.epitaxy/proposals/:proposal:/:content hashes:

editor folder structure:

//.epitaxy.yaml
key: hashvalue

editor documents outside the immutable structure show to the user as their nicknames, but inside it are saved as their hashes.

allows passing through a user’s plaintext alias and then later compiling to the immutable one with a comment

transition proposals included but revolutionary change is allowed, by voting on end state and transition proposals separately

could use very simple cloudflare workers packages

computed data is placed in the results/ folder

• kademlia IPs
• kademlia content