# Landlord chat

> document is published solely for feedback

- tag
alias:: cyber valley landlord chat

- communication chat for individuals who control land in cyber valley with common goals
- improve quality of investment in cyber valley region
- better coordinate on public good projects
- its chat (!)
- and does not involve any financial operations
- nor ownership, rights and obligations
- nor communication between legal entities
- it is pure information exchange between individuals
- and the biggest risk for participants is to loose access to chat
- reporting on all business transaction
- raising from these communication
- is responsibility of individuals who involved in chat
- communications are based
- on mutual trust
- some game theory
- and understanding that rules are mutually benefiting
- how to improve quality of investments?
- in order to minimize unhealthy investors
- we have to boost region's land market
- by providing high quality information about land available for sale
- and building a powerful network of finding optimal investors
- how to achieve that?
- creation of common verified land database with projection on 3d map
- with agreement of mutually benefiting incentives
- based on two key roles in any land operation
- `buy mediator` evenly split gain from land operation with `sell mediator`
- anyone in the chat have ability to mediate from both sides
- how to better coordinate on public good projects?
- filtering of `buyers` by community
- will inevitably lead to better involvement in public goods creation
- creating powerful feedback loop
- the more chat participants we have
- the more sophisticated offer of land we have
- the more ability to sell
- the higher quality of investments we can provide
- hence maximizing overall gain of active community
- and maximizing quality and amount of resources available for public goods
- analyzing the rules from game theoretic perspective we can deduce key risk of proposed mechanism
- the proposed mechanism does not imply disclosure of `seller` contacts
- so `buy mediator` could report land price higher than truth to maximize profits
- to mitigate this we must add two simple rules to the game
- setup `fixed margin` on land price and `minimum price step` of reducing price by new `buy mediator`
- under such rules the first `buy mediator` understand that if he report untruthful price
- someone can get into negotiation and win `buy mediator gain` from the `land`
- which benefits everyone except loosing `buy mediator`
- if negotiation process of the initial `buy mediator` was efficient and he reports the `price` truthfully he can be sure, that his tough work on finding real borders and negotiating price will be rewarded even in the case everyone knows the `seller`
- this holds true if `min price step` is not less than overall `buy mediator gain`
- hence if everyone can agree on two parameters `fixed margin` and `minimum price step` the resulting game is
- force truthful behavior without expensive controls
- mutually benefit any participant by maximizing outcomes within mutually defined `fixed margin`
- open enormous opportunity for expanding the project and advancing public goods in the region
- ## process
- the process organized using `google my maps` in which `land plots` moves through colorful `states`
- `state transition` section define strict rules of changing the `states` by either `buy mediator` or `sell mediator`
- for each `color` or `state` there is dedicated layer in `google my maps` with specific data according to `database specification`
- on every transition involved participant must notify chat members on changes
- <img src="https://mermaid.ink/img/IGZsb3djaGFydCBURAogICAgYmxhY2tbYmxhY2s6IGRyYWZ0XSAtLSBwcmljZSBhbmQgYm9yZGVycyAtLT4gYmx1ZQogICAgYmx1ZVtibHVlOiBmb3Igc2FsZV0tLSBsYW5kIGJ1eWVyIGFjY2VwdGVkIC0tPiBvcmFuZ2UKICAgIG9yYW5nZVtvcmFuZ2U6IHdhaXRpbmcgZGVwb3NpdF0tLSBidXllciBmYWlsIHRvIGRlcG9zaXQgaW4gdGltZSAtLT4gYmx1ZQoJb3JhbmdlLS0gZGVwb3NpdCBkb25lIC0tPiB5ZWxsb3cKICAgIHllbGxvd1t5ZWxsb3c6IHdhaXRpbmcgcGF5bWVudCBhbmQgZG9jc10tLSBsYW5kIGlzIHN0cnVjdHVyZWQgLS0-IGdyZWVuCiAgICB5ZWxsb3ctLSBzb21lIHByb2JsZW0gaGFwcGVucyAtLT4gYmx1ZQogICAgZ3JlZW5bZ3JlZW46IG93bmVkIGJ5IHBhcnRpY2lwYW50XS0tIGN2bGMgcGFydGljaXBhbnQgZXhpdCAtLT4gYmxhY2sKICAgIGdyZWVuLS0gY3ZsYyBwYXJ0aWNpcGFudCBzZWxsaW5nIC0tPiBibHVlCiAgICAK" />
{{renderer :mermaid_vfrfsq}}
- ```mermaid
flowchart TD
black[black: draft] -- price and borders --> blue
blue[blue: for sale]-- land buyer accepted --> orange
orange[orange: waiting deposit]-- buyer fail to deposit in time --> blue
orange-- deposit done --> yellow
yellow[yellow: waiting payment and docs]-- land is structured --> green
yellow-- some problem happens --> blue
green[green: owned by participant]-- cvlc participant exit --> black
green-- cvlc participant selling --> blue

- ## decisions
	- consensus: proportionally to the land size in `green` state and `blue` state which are direct offers of participants
	- decision types
		- `add to chat`
		- `remove from chat`
		- `propose project`
		- `change parameter`
	- paramteres
		- `buy mediator gain`: `50%`
		- `sell mediator gain`: `50%`
		- `fixed margin`: `20%`
		- `minimum price step`: `10%`
- ## state transitions
	- `black` to `blue` or initially `blue`
		- whoever add land first become `buy mediator` of  `land plot`
		- he must add `land plot` with `price` using simple formula `seller price` + `fixed margin`
		- anyone who can reduce the price by `minimum price step` can become new `buy mediator`
		- `buy mediator` is responsible for ensuring correctness of information on `price`, `borders` and `documents`
		- `size` field must match information from `documents` and the the size computed by `google my map` shape
		- while structuring the land in cyber valley i suffer from disgusting information
		- still even after having certificates i do not have clear understanding of borders
		- as certificates do not provide easy way to map points to actual surface and are not precise
		- i do not wish the same experience for new coming investors and my friends
		- `buy mediators` who consistently produce incorrect information on `price` and `borders` must be excluded from chat participants by community decision
		- once the `land plot` is added to `google my maps` `buy mediator` must notify participants by sending a new offer to the chat so they can initiate `sell mediation`
	- `blue` to `blue`: price reduction by new `buy mediator`
		- can be done by any `buy mediator` who is able to reduce the `price` for `minimum price step`
		- new `buy mediator` must notify chat about this change
		- old `buy mediator` learns from new `buy mediator` on more efficient negotiation
	- `blue` to `orange`: land plot reserved
		- `sell mediator` must ensure that `buyer` fits into [[cv/vision]]
		- after that he send notification to chat about community meeting with `buyer`
		- `sell mediator` role is to make this step comfortable for everyone involved
		- during community meeting `buyer` must commit to some `deposit date`
		- if community decide to accept `buyer`, `sell mediator` must move `land plot` from `blue` state to `orange`
		- sell mediator fill out field `deposit date` and `sell mediator` and ensure that payment is done within this time
		- from this point this `land plot` is not available for sale
	- `orange to blue`: sale fails
		- if deposit have not been payed before `deposit date` the state of `land plot` reverted to `blue`
		- in case of systematic deposit fails `sell mediator` is subject to removal from the chat by consensus
	- `orange` to `yellow`: making deposit
		- `sell mediator` must ensure that deposit is payed to `buy mediator` before `deposit date`
		- after that `sell mediator` must
			- change state of land from `orange` to `yellow` and fill out field `deposit date` and notify
		- `buy mediator` is responsible to move the deal further as he is closer to information
		- `buy mediator` control the flow of the deal and report on the steps
			- fill out field `contract number` when its signed by `buyer` and `seller`
			- control full payment from `buyer` and fill out `full payment` field to `yes`
			- control change of ownership in associated organizations
			- once the certificate comes `land plot` is ready to `green` state
	- `yellow` to `green`: finalization of deal implies
		- providing `proof of ownership`
		- adding `buyer` to chat
		- `buy mediator` is responsible for this step as its likely that he posses this information first
	- `yellow` to `blue`: rejection of the deal after deposit could happen in two cases
		- `seller` side problems
		- `buyer` side problems
		- in case of systematic problems associated `sell mediator` or `buy mediator` can be removed from chat by consensus
	- `green` to `blue`: sale by `cvlc participant`
		- cvlc participant decide sell the hole piece
		- during this process the land can be easily split by cvlc participant
		- after finishing state transition `cvlc participant` must notify other cvlc participants
	- `green` to `black`: could happen in two cases
		- participant voluntary decide to exit the chat
		- community based consensus is reached for removing participant
- ## database specification
	- `black`: owned by a non member
		- purpose: collect as much information on land as possible
			- `state` does not give `buy mediator` any incentive as this `state` does not involve providing information on the `price`
			- but `buy mediators` can use `black` state to signal other participants that he is in negotiation process on this particular plot, so `buy mediators` can coordinate better, without doing the same work twice
			- there is a loooot of land in the region, and better coordination gives us better total output
			- also understanding of ownership within the region could be useful for better collaborating with non participant neighbors and probably convince them to join our community chat
		- fields
			- `owner`
				- name of current owner for simple reference during communications
				- can be obfuscated or not real
			- `borders`
				- defined by polygons using `google my maps`
				- at this stage can be not very precise
			- `size`
				- the size of `google my map` shape must match the size of `document`
			- `buy mediator`
				- name of `cvlc participant` so `sell mediator` can easily route `buyer`
	- `blue`: land is available for sale
		- purpose: the heart of the system for providing high quality information for `buyers`
		- fields
			- `price`
			- `borders`
				- must be real in the sense that state based registries does not provide precise information
				- must be verifiable using google map coordinates without a need to show the land by potential `buyer`
				- must not cross borders of other `land plots`
			- `owner`
				- name of current owner for simple reference during communications
				- or name of cvlc participant if case the land sold by participant
			- `documents`
				- could be `pupil` or `certificate`
			- `size`
			- `buy mediator`
				- simple name so its possible to easily for `sell mediator` to route `buyer`
				- the name of cvlc participant who add or own the land plot
	- `orange`
		- purpose: fast track of deposits to ensure land availability
		- fields
			- `sell mediator`
			- `deposit date`
	- `yellow`
		- purpose: track process of changing ownership to cvlc participant
		- fields
			-
			- `contract number`
			- `full payment`: yes or no
	- `green`
		- purpose
			- chat participants layer
			- include only structured land owned by cvlc participants
		- fields
			- `owner`
			- `certificate`: proof of ownership
				- for every land piece with green state there must be a proof
				- photo of 2 side is sent to chat
			- `type`
				- right to build
				- right to use
				- milik
			- `expiration`
				- in case of rtb or rtu
			- `borders`
			- `size`
- ## on software
- currently for our purpose we decide to use `google my maps` due to the following reasons
	- anyone could usе familiar instruments which is `google maps`
	- simple to learn and use even for non specialists
	- powerful free to use tool for real time 3d mapping
	- provide custom data layer on top of 3d maps
	- information is portable using `kml` and `csv` for using in other apps
	- allow to surf result for anyone using [google earth](https://earth.google.com/web/@-8.29649429,115.0912005,1403.17676186a,2053.84421432d,30y,74.80750276h,63.23262994t,0r/data=MigKJgokCiAxdHhaaW9RS0JCdk9kbW94MUhhZDVhSS1aejRrVUVKSSACOgMKATA)
- use of `google earth` for surfing cyber valley
	- `scroll` to zoom the map
	- `↑`, `↓`, `←`, `→` to move the map
	- `shift + ↑` or `shift + ↓` to change perspective
	- `shift + ←` or `shift + →` to rotate camera
	- `click` on the `land plot` to see its details
	- `turn of` / `turn on` layers to get different perspective
- there are disadvantages to this solution
	- does not provide any means of granting custom right access except simple `right to write`
	- does not allow auditing of record changes
- at the scale below 7 participants the most important things are: (1) to establish trust and (2) show of the product
- so i truly believe that to bootstrap the process is enough to follow simple protocol
	- any change of `land plot` `state` or `data` is reported to chat by those who made this change
	- so afterwards its easy to reconstruct correct information in case of mistakes or misbehavour
	- those who consistently and non transparently change information without proper notification will be removed from the chat
- if this protocol will not work `cvhq` will remove `write access` to the map and hire dedicated person who will be responsible for changing the information based on the information provided in chat
- after the proposed mechanism proves viable cvhq will develop more transparent, auditable and sofisticated software
- ## join cyber valley landlord chat
	- in order to join the chat the process is the following
	- discover the [map of cyber valley](https://earth.google.com/web/@-8.29649429,115.0912005,1403.17676186a,2053.84421432d,30y,74.80750276h,63.23262994t,0r/data=MigKJgokCiAxdHhaaW9RS0JCdk9kbW94MUhhZDVhSS1aejRrVUVKSSACOgMKATA)
	- cyber valley [intro](https://hackmd.io/@cybervalley/cv-intro)