A few thoughts on EOS WPS

There’s going to be the an EOS Governance conference call on Wednesday which I’m not able to attend, and here are a few thoughts for discussion:

WPS as a process

Once the funds get allocated, there needs to be an established and accountable process for distributing the funds. Probably the following structure would make sense:

1. A small WPS committee, not more than 10 people, helping the applicants in submitting their proposals, and watching out for scams. This should be a paid work, with clear responsibilities and accountability.
2. Telos WPS demands that the applicant deposits 3% of the grant before placing the proposal. This looks reasonable and reduces the noise.
3. Once a proposal is out for voting, the voting period should be quite short, maybe 4 weeks. I would rather see individual companies voting, and not capitals, so probably top 100 block producers, 1 vote per producer, would be a good match. A few well-known persons that are independent from any BP might be added to the list.
4. A proposal is passed if at least 20% of voters have voted, and more than half of the votes are positive. The WPS committee can veto a proposal if they consider it a misuse of the system. Probably 2 or 3 vetoing signatures should be sufficient (provided that the WPS committee is doing their job sincerely).
5. Once the voting period is finished, the funds should be distributed by a smart contract.

Work proposal ideas

One of possible projects that are worth public spending is a secondary layer of P2P endpoints. At the moment everyone is using p2p endpoints provided by BP, and the demand is constantly growing, while supply stays the same. Many public p2p endpoints are overloaded and rejecting connections. So, a new public p2p service that would span across the globe and grow according to demand would be a benefit for the whole network. My estimation of costs is $5k per month at the start, and probably up to $15k per month when the usage grows.

It would be great to see a working group that defines and implements a new standard for History API. The legacy API is outdated, and I would rather see Server-Sent Events (SSE) as delivery protocol because it’s adaptable to large sequences of data.

Up to now, there’s no standard way to request a payment via QR code or an NFC tag. It will be great to see a working group that defines a new standard for transaction requests. This is something that will definitely attract new users and dApps to the platform.