Wish List
- Set up a 'GitHub Project'. Review the stuff below and make tickets out of whatever is useful
- This is now started as a GitHub Project
- Also review the Trello board for the same.
- The very first code task is to find some kind of public reputation network, ascertain that we are allowed to harvest data from it, and then have a go at harvesting that data. For now I am liking, 'the village of all English Wikipedia Admins' - partly because of the norm in that village of assuming good faith. The process of harvesting reputation data is uncomfortably close to identity theft. This could work for us or violently against us. If we (kinda) steal someone's identity, you can at least imagine that the person would be interested, maybe horrified. If we can quickly turn that interest into engagement with the project, we have won.
For a Wikipedia admin, there is deep knowledge and significant pride in the reputation system that they maintain. If we are able to suggest to them a generalization of that system into a broader set of governance questions than just managing the encyclopaedia, they might be very into it.
SO. We want their experience to be, (A) Holy crap these bastards stole my identity, but, (B) I am accultured to assume good faith, and so I'll have a look at it, and then (C) OK, so they stole it, and now they immediately want to give it back, but with new paint and wing mirrors, and (D) If I take it back, I can use the reputation I have husbanded for so long in Wikipedia and apply it anywhere.
The absolute initial code task is to make a minimum viable reputation network: Make a table of lists from Wikipedia data. One row per current Wikipedia admin. Each list shows all other Wikipedia admins they have @mentioned in the last X months. (Later, each row becomes one agent)
-
Once there are agents, we need a way to 'give them to their rightful owner.' Agents need storage and compute - ie resources. The project needs a model to pay for those resources ... so an obvious business model is to offer to host for a fee, at least in the first instance ... but also a strong ethic that the agents must be decentralized ... or, let's say, decentralizable ... and actually utter failure of the core concept in the project if this does not work. Social media to date is fuelled by advertising. It's turned out that means outrage for clicks, and it has been a disaster. This thing must run in the self-interest of entities that know their reputation is an asset. The plan is: Different fuel, different outcome.
-
Later still, we want to be able to merge and split agents. Overlapping villages are a key part of the architecture. If someone wants to manage their Wikipedian reputation agent as a separate agent from their GitHub agent, that has to be fine. If they want one reputation agent managing both datasets, also fine ... and if they want to move from one state to the other, this must also be fine.
-
We need a way for people to add new reputational data sources to their existing mix. If someone is using YouTube, SnapChat, WhatsApp data in their agent, and they want to add email and text, this must be possible
-
... and even, a step more 'meta' than this is that we need a way for people to be able to trade, adopt, and adapt reputational strategies. The strategies are pieces of code that must be evolvable
-
What the hell is a village? The absolute minimal position is that a village is just a reputational claim of membership by an agent. This minimal position has many advantages. It's super-clean. The reputational claim comes up against the norms of the village and carries risks if the other villagers believe the claim is false. In this view, if a village needs infrastructure, it is the task of the villagers to build that infrastructure. A village like Wikipedia has some formal, written norms, like Be Bold and Assume Good Faith ... as well as a complex ecosystem of unwritten norms ... including norms that may come in different stripes on different pages, or groups of pages. Ie Wikipedia is a village of many villages, and there may be norms that apply in different ways at different scales
It would be less clean, but potentially a better bootstrap, if the project had a way to build new villages. A the moment, this is what is says on the label: "Links: A project for building villages." This project could make infrastructure such that a group of people could request and pay for village infrastructure that is (initially, but not necessarily) hosted by the project. This would suggest a bunch of more challenging questions to be resolved: Are there formal, written, norms? What are the norms governing membership, application for membership, and cessation of membership? What about membership fees?
