The core team met in Prague on April 27th, 28th and 29th. Everyone paid their own way to the meeting. Team members arrived during the day on the 27th from Canada, the US and Europe, and met for dinner at the Lokal Pub.
On the 28th the team spent the day around a conference table which got old by the end of the day, but everyone agreed was well worth the bit of drudgery.
On the morning of the 29th, the team met with community members.
In attendance were: stonehedge, infernoman, chaositec, defunctec, mdz/urban_idler, crowncoin_knight
SPECIFIC ITEMS DECIDED AT THE MEETING:
1. SPEEDING UP THE PACE – CORE TEAM MEET-UPS QUARTERLY
The core team will be meeting face to face for 3 day sessions including a community meet-up every three months instead of every six months. There is just too much to do. The team is looking to schedule the next meeting in Toronto in August.
The release schedule for wallet updates will continue to be roughly every six months. We do not expect this pacing to change.
2. COMMUNICATION & TRAINING TEAM
One of the lessons of the last two months is that this core team could do a lot better at communications and training. We think we have the right person to step in and help coordinate this effort, and the names of the folks who will end up being on this team probably won’t surprise many – but we agreed that this should be formalized, or at least coordinated rather than just being a well-intentioned scramble.
The members of the Communications and Training Team will be invited to come to August meeting, and all the future meetings of the Core Team.
We have decided that until an application economy is established on the network, the core team will not spend funds on marketing – but it will invest in the community by clearly communicating what we are doing and offering training to community members, node operators and developers.
As the application economy develops, it will be in the interest of application providers to market and advertise their services – and we would see this as the role of marketing in the system which is being developed.
3. NEXT RELEASE – END OF MAY
The next code/wallet update is scheduled for release at the end of May, 2017. The key features the update will include are throne voting and testnet capabilities. The voting will allow proposals and move governance of the project away from the core team and formally give everyone who is operating a throne a role in the governance structure.
The testnet will be useful as we get more disciplined about our quality assurance and testing processes.
Since we want to create a habit of under-promising and over-delivering, we are hoping to have some other important items in the update – but that will depend on infernoman, chaositec and whoever they can get to help them. If you have some time available and skills and want to help us deliver some surprises that we think the community will like – feel free to let us know.
4. GOVERNANCE
It is important to understand the level of trust that the team places in this community by handing over the governance of the platform to the community through the voting process. The team members will be in a role to influence the path of the project but that is all. Turning on the ability to vote the thrones will functionally make this a distributed autonomous organization if you like to call things by big names and are fan of that sort of thing (which means you like Ethereum).
We like to think of turning on throne voting as just implementing good governance – nothing magical just the way it should be done. This is not the last step, but really just the first step of building an effective representative governance structure for the community. If we look at real world analogs, places tend to have two independent representative structures – one for the people and one for the property holders. Since the British Houses of Parliament and the US Congress weren’t structured arbitrarily and they seem to be resilient structures, one can think of the throne voting as being structuring a House of Lords or a Senate. This is representing one tier of the community, the owners. But we need something else to make sure we represent people who don’t hold the token, but find value in its use. This isn’t as simple to do as one might hope.
We believe that the governance body which might be analogous to a House of Commons or Representatives could emerge from smaller staking wallets. This is one reason that staking has been added to the future feature list.
5. CORE TEAM & SKILL GAPS
Well, we should have a formal roadmap – and we will get to that in the next few months. The way the interest in the project has picked up since early march genuinely caught the team by surprise, and we are looking not just at how we add features to the product, but key skill sets to the team. Community members have noted the early stage of the project and some of these gaps, and all we can say is that we hope to be able to announce a few important additions to the team soon. Those discussions are ongoing.
It is worth pointing out that no one is paid to be on the core team. There are no salaries, although people can do work for bounties just like anyone else could – so the core team developers are in a position to receive those bounties. The rest of the team is just here to try to keep the project moving in what we believe will be a successful direction, and any economic gains are indirect insofar as they come through token ownership.
6. THRONE COLLATERAL AMOUNT UNCHANGED
Due to the increase in the price of the CRW token, the team discussed lowering the collateral required to run a throne on the network. The team decided not to change the collateral amount because of a belief that decisions like this should be made by the community and not just the team.
7. DEFINING THE “JOURNAL” OR NETWORK APPLICATION INTERFACE
In the Crown Papers, we discussed the Journal as where people would go to run applications through the Crown Network. The idea of calling it the Journal was just as a sort of place keeper while we looked at different way that we might implement what we wanted to do.
At this point it looks like the way of getting to the crown applications will be as simple as just using your browser, and setting up a “pay from” address. The real work here will be in thinking about how we do the user interface so that it creates a context for people when they are logged in to applications running through the Crown Network.
8. NEXT STEPS – NEW RESEARCH ITEMS BETWEEN NOW AND AUGUST
VOTABLE SPORKING – The throne collateral and also the issue of having fees for proposals in the governance system, as well as staking thresholds for smaller wallets raises the systemic issue of being able to adjust the fees or collateral amounts for services on the network. Since we expect the network to become more rather than less complex, we expect the number of these different thresholds to increase over time.
Operationally, sporking is a great tool for changing these levels without requiring everyone to update their wallets – but sporking raises serious governance issues. So what we will be trying to do is to look into how one might, instead of enabling spork keys for the core team – building a way for certain proposals when passed to execute a spork, such that a proposal could directly change the fee levels for proposals or collateral amounts for thrones, etc.
CHRONOS NODES – Crown will require tight network time consensus in the future. Since part of what we are seeking to do is to be able to use time with greater granularity than existing crypto systems are able to, we will be introducing a new sort of node on the network which we are calling the Chronos node, or the timekeeper. This will require integrating a Network Time Protocol (NTP) server and staking capabilities into the wallet.
A Chronos node will be required to have at least 100 CRW in collateral and the Chronos nodes will be paid through a Proof of Stake protocol. Once implemented, we will learn from the granularity which we are able to achieve on the network and proceed from there. We will also be looking at other uses in the governance structure for proof of stake and creating a sort of “house of commons” to make sure that we are listening to different stakeholders as the network and community grow.
API TESTING – We expect to start testing the API in the testnet in June. Keep an eye out for announcements on this, since developers and node operators with ideas which they might want to test out will be welcome to get involved with API testing, and this will also be a chance for folks to start building applications which would be ready to go when we would hope to release the API in the next update scheduled for late November or early December… about 7 months from now.
