thepaperpilot/pages
1
0
Fork 0
Code Issues 1 Pull requests 1 Projects Releases Packages Wiki Activity Actions

Updated content
All checks were successful
Build and Deploy / build-and-deploy (push) Successful in 1m11s
Details

Browse source
This commit is contained in:
thepaperpilot 2024-12-21 23:33:16 -06:00
parent 980810cb04
commit e42a43af3e
3 changed files with 4 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
Garden

@ -1 +1 @@
Subproject commit 14f6d7bb1eec4459bd0c18bf496a3c505c45f6f9
Subproject commit be2e43fe71f6b7ec89194200e42924daace42466

4
site/garden/chromatic-lattice/index.md
View file

@ -11,7 +11,7 @@ import { useData } from 'vitepress';
const pageData = useData();
</script>
<h1 class="p-name">Chromatic Lattice</h1>
<p>1467 words, ~8 minute read. <span v-html="data[`site/${pageData.page.value.relativePath}`]" /></p>
<p>1468 words, ~8 minute read. <span v-html="data[`site/${pageData.page.value.relativePath}`]" /></p>
<hr/>
<details><summary>Referenced by:</summary><a href="/garden/digital-locality/index.md">Digital Locality</a><a href="/garden/fedi-v2/index.md">Fedi v2</a><a href="/garden/incremental-social/index.md">Incremental Social</a><a href="/now/index">/now</a><a href="/garden/orchard/index.md">Orchard</a></details>
@ -72,7 +72,7 @@ This is a very centralized approach, and is the most common approach for multipl
This would make the game run on the [Agentic Fediverse](/garden/fedi-v2/index.md). Initially the private keys would likely be managed by incremental social, which would also be the default iroh node clients would connect to.
My concern with this approach is that it would be difficult to operate in a way that doesn't centralize the power. Being a multiplayer game it's important to ensure people can't just fabricate a history of actions with fake timestamps. In theory the fix for this would be something like the [Network of Vouches](undefined), but we're a long ways off from that being viable.
My concern with this approach is that it would be difficult to operate in a way that doesn't centralize the power. Being a multiplayer game it's important to ensure people can't just fabricate a history of actions with fake timestamps. In theory the fix for this would be something like the [network of vouches](/garden/decentralized-moderation/index.md#67525178-9f33-400c-9452-0a60d5e0f3a0) approach, but we're a long ways off from that being viable.
I'm also concerned about it's efficiency in regards to creating and maintaining entities to store each player's current mouse position.

2
site/garden/decentralized-moderation/index.md
View file

@ -36,7 +36,7 @@ The second concern is with malicious labelers. If a labeler decides to create a
Lastly, this is moderation through the use of blocklists. This isn't inherently bad, but it's a double edged sword, as I discuss [here](/garden/moderation/index.md#674531bb-952c-4346-8f0d-febf15e24879).
### Network of vouches
<span id="67525178-9f33-400c-9452-0a60d5e0f3a0"><h3>Network of vouches</h3></span>
Identities could have a system by which they vouch for or against other identities that they are human and make content worth looking at, and clients could use this network of vouches to filter posts to display or retrieve. For example, a user may say they only want to see posts made by identities within a chain of 4 vouches to themselves. Upon account creation, users could be prompted to vouch for IRL friends or some popular figures within topics they care about to get started. In theory the longer the chain can be, the more varied the content a user will see, and the more likely for it to be something they disagree with. This would allow users to customize how narrow their feed is at a given time by just changing the max chain length. They can also continue vouching for more people to more precisely expand their feed.