So lets try and work out a timeline for Governance deployment.
Alpha 6: July 13th
Peering code queries on chain contract (after connectivity has been established) and does not peer to peers not on the list. This will interact with a dummy contract so the interface will be somewhat mocked
A endpoint for forwarding TCR access requests (@Jehan bootstrapping all over again, thoughts?)
Some on chain contract progress (@Jehan specify please)
low bandwidth bootstrapping even for nodes outside of the TCR? Ok then I’m fine with that. There’s some attack surface there but we’ll have to cross that bridge at some point either way.
1) Mods to Aragon
a. Add node list functionality to Aragon (Jehan/7 days)
b. Fix bugs (Jehan/TBD) 2) Router software
a. Just to check to the subnet dao and connect to the subnet dao (Justin/TBD) 3) Payment
a. IP Leasing Fee Escrow contract design (Jehan/7-14 days)
b. Decide to use Ethereum for payment (Jehan/forever) 4) Payment frontend
a. Payment recipient - not sure what front end is needed to help get money off of Aragon (TBD/TBD)
b. End User - on Althea website, instructions for metamask - no APIs planned (TBD/4-7 days)
So I’ve been working on an implementation of this.
@Jehan how do we want to treat manual peers? They are the major edgecase here at the moment. Specifically because getting the exit identity is a little harder than per hop peers. At the same time I’m not sure we want to prevent users from manually adding peers that are not on the subnet dao.
The implementation simplification of this is pretty dramatic, as we can just check the ip’s of tunnels (mesh ip’s if they aren’t manual peers) and then kill them if they don’t pass the dao check. If we want a more nuanced implementation we will have to start keeping track of tunnels in more detail. Which may be a good idea anyway to assist in cleaning up old ones properly.
The other major implementation detail (other than how exactly we traverse a dao from rust) is what exactly we do about caching. Remember we’ll wan to query the dao pretty often in a naive implementation. Every time we get a hello packet we check. So some level of caching is required to keep things sane.
Pretty well I’d say, since we raised the full amount I haven’t halted payments development but in general I’m focusing manpower on things like improving base software stability. I’m hoping to see that pay dividends in the very near future.
with Sebastian on board I expect we’ll have a test blockchain up within a week or two, end of the month at most and be able to start integrating the dao stuff into the firmware. I’ve already been prepping for it’s integration with the stability stuff I’m doing.
In the meantime I’m going to keep payments moving, mostly to keep existing work from going stale and being wasted and to make sure we don’t make any choices that would dramatically increase the difficulty of integrating payments.
Either way we’ll have the subnet dao based stuff up soonest just for ease of integration reasons, then we can come back and extend the same infrastructure to build out the rest of payments.
No such thing as a ‘have it all’ plan, but this trades minimal extra time to dao integration for much cheaper and smoother payment integration (not to mention not abandoning existing work) so I’m happy with it.
As for literal timelines, EOM for stable networking and improved fundamentals, end of next month for test dao integration and much more rudimentary test payments unless something blocking comes up with Aragon. @Adam_Soltys what’s your impression of Aragon schedule wise so far?