Core Dev 28 - Reboot
Status Core Devs meet bi-weekly. This summary rounds up their notes.
- Meeting Date/Time: Monday 2020-04-20 at 12:00 UTC
- Meeting Duration 1.5 hours
- Video stream:
2. Core dev reboot (Oskar)
- Going back to roots https://discuss.status.im/t/status-devs-meeting-open-and-async-useful/124
- Now we have a protocol! And more team stability
- Focus on specs and protocol
3. Refresher on specs (Oskar)
- Purpose and state, ownership
- Blockers for writing?
4. Mini-workshop (?) (Rachel)
- Content? Outcome?
5. Waku v1.2 spec change (Samuel?)
- need spec diff (Whisper MUST->MAY; Waku SHOULD)
6. Other things already in v1 or v1.2 app
Specifics depends on legwork beforehand
- How we use IPFS gateway for stickers (impacts availability, censorship and privacy guarantees) - How notifications work since changes last few months (differences across platforms and so on) - How we interface with the Ethereum blockchain, i.e. use Infura and Cloudflare for transactions history etc (documenting this clearly also acts as requirements for research efforts such as Beam Sync) - How Status clients use Keycard - Other 3rd party APIs used for core functionality that impacts things like availability/censorship and privacy - Dapp browser API usage - As well as things on the horizon: mentions, images, etc - More?
7. Wall/Book of shame (Corey)
- Decision to be made?
8. DNS discovery (Dean? / Andre?)
- Decision to be made: yes/no?
- Next steps to get into draft / timeline impl
9. EIP 634: Storage of text records in ENS (Andre) https://eips.ethereum.org/EIPS/eip-634
- "I'd like to discuss EIP 634 and what improvements / changes we can make to it so we can start incorporating social features into the app."
- Decision to be made: ?
Oskar intro on purpose of core dev call & having solid specs again
What are current blockers in terms of adding to the Status specs? We document a lot of stuff, but something is missing.
I think the biggest pain point is lack of process around spec writing. a) we don’t have a clear format yet of what specs should look like. RFCs didn’t stick. b) We haven’t really structured sprints enough that we could enforce a format of feature request, spec, implementation, flow. (andre)
Another issue that makes this more difficult is that often there are discrepancies between specs and implementation. Regardless of which one you start with… you need to revise the specs after you start with implementation. Sometimes there’s pressure to get things out, so there’s not much time to go back to the specs. We could get protocol changes out as quickly as possible, without releasing it to users. Then we are free to change both specs and implementation without too much risk. (Andrea)
When you say specs don’t have a standard, what do you mean? We have more than 10 that follow a common layout and standard. (Dean)
A spec for protocol is very different than a spec for a feature and how a feature should work. I don’t think a feature requires the same level of scientific exactitude as a protocol. (Andre)
Agreed. We are mostly concerned with protocol specifications right now. What do you need to do to make a compatible Status client? (Oskar)
We sort of have a way to write specs in vac, but I don’t think that’s fully structured. There’s a lot of diversity and different POVs in how specs should be. Having more of a template would encourage people who haven’t written specs yet, and make it easier. (Andrea)
Is there any explicit documentation that details how specs are written, reviewed and authorized? That would help. (Samuel)
What would you like to see more formalized? (Oskar)
There’s no problem with the process as you describe it. I just didn’t know what that process is. (Sam)
That exists in the readme in the Status specs repo. (Oskar)
What was the question, what’s blocking the team? (Iuri)
What’s blocking people from writing specs for the Status client protocol specifications? (Oskar)
This is a project to handle something that is missing, and it has to be assigned. Project vs. process. (Rachel)
In the future, I think we just need to be more clear about what we need to write specs about. There are not many blockers, the process is simple, we just don’t know what to write about and if it needs to be done this week or later. Maybe during the retrospective. (Eric)
To add to what Rachel said, it would be good if we could include things into a proposal somewhere, like an issue, where many people can discuss before we move forward. (Oskar)
I agree, especially with things like that where there will be issues of forward and backward compatiblity for something as it evolves. (Eric)
In general, it’s hard to read through a spec and intuitively know what’s missing. The best way to figure this out is to try using them. Maybe just having people try to build some toy clients using the spec could help flesh out a lot of things. (Barry)
Have we already identified what’s missing? (Sam)
Yes, it’s in the discuss post. (Oskar)
Is there anyone who should have oversight for this? (Sam)
Previously, it’s been a parallel effort where we had a group that consisted of both people from vac and core, but I would love to see core take on the specs for Status clients. This is different from the vac specs. Ideally whoever’s owning something would also own the spec. It would be great if the missing items became specific issues in the repo. (Oskar)
Minimum requirements for documentation as a matter of course:
for each function, describe the main purpose in one line, any future TODOs that can make this better?
for each library/tool used, describe what it is, why do we need it, why it is chosen, not other alternatives
At this stage the code base is mature enough that without documentation future development becomes impossible. I’ve opened up one issue for one package, and that’s the package I’ve been working on since I started. My plan for this is to roll out a new issue after every package has been refactored or documented. (Sam)
Let’s fork the conversation between documentation and specs. (Oskar)
https://github.com/status-im/status-security/tree/master/threat-modeling (from Corey)
Can we go into specific issues here? (Oskar)
The first one here is the Waku v1.2 spec change. Maybe it’s a bit too early, if you’ve had time to look at it yet or not. (Oskar)
Was that a question to me? (Sam)
I haven’t actually had time to read this. (Sam)
Within the Status specs we wanted to reflect that you can use Waku and don’t need to use Whisper any more. (Oskar)
I’ve read the issue that you shared. Am trying to get up to speed. (Sam)
Has any progress been made on this list of to-dos? (Oskar)
I was going to assign this to people but as it happened last week just came and went. Right after this call Rachel and I are going to assign each item to people today. (Andre)
Is there anything that is not on this list that should be? (Oskar)
IPFS gateway for stickers, how notifications work, how we interface with the Ethereum blockchain, how clients use keycard, other third party APIs for functionality, DApp browser API usage.
Starter pack and referrals. Wrt DApp browser and API usage, can you clarify? (Andre)
Requires a browser and to have a functioning browser, and it depends how you deal with Infura, cookies, etc. Specs for the browser and APIs we expose. (Oskar)
Makes sense. (Andre)
When we give access to our public key you have to opt in for privacy reasons… (Oskar)
We do have some documentation for how the browser works already, like the way that you access a user’s wallet. (Rachel)
It would be great if we could put that in the specs repo then. (Oskar)
Wall of Shame? Corey?
DNS discovery, Dean?
The reason it’s in draft is because we decided not to merge anything until it’s implemented. (Dean)
Has there been any effort into proving or disproving those estimates for DNS? (Andre)
No. Algorithmically I think you would still hit that at some point, but that’s a core/core infra issue. (Oskar)
Are there any concerns that may prevent us from moving with this? (Oskar)
We talk about discovery but this is not…this is (about) boot nodes. (Andrea)
I think the idea is to use it as a basic (?) discovery, in order to derisk. So not only bootstrap. (Oskar)
It wasn’t for boot strap nodes. It’s currently only for waku nodes. So it’s traversing for waku nodes itself (Dean)
Maybe that doesn’t impact the specs, but this is a fairly static list. There are some issues of centralization for example. (Andrea)
Within the app you should be able to modify which list you use. The way Go Ethereum modifies the list is by scanning the DHT multiple times and finding the nodes that are most valuable and adding them to the DNS record. (Dean)
I think these questions need answering, I don’t think it’s very clear. The spec may not need to change. Before any implementation, we need to understand how to use it, what the value and advantage is going to be. (Andrea)
What do people suggest in terms of next steps? (Oskar)
It probably needs to be prioritized by someone. (Andrea)
Is it part of the core roadmap? (Oskar)
It is, but just not any time soon. We have group chat and notifications coming up. We have keycard, referrals and starter pack coming up. Capacity is still not an issue that we foresee hitting in the near future… (Andre)
That makes sense. Maybe we should mark it as raw or draft and then merge it. What do you think, Dean? (Oskar)
That sounds good. It’s marked as a draft right now. (Dean)
Is there an implementation that maps to that specific spec in terms of fetching waku nodes and POC? (Oskar)
We don’t need to write the implementation because we can use the one in go-ethereum if we’re still using status-go. (Dean)
Draft/raw means it’s changing. Stable means it’s in end user’s hands. It’s a contract between spec writer and users. (Oskar)
Are you suggesting to mark and merge it as raw? (Hester)
Mark & merge it. (Oskar)
This is a fun one. We’ve been talking about implementing more social features, including how to add profile pictures to Status. This EIP is a draft that hasn’t been picked up in 3 years. It’s broader than what we’re intending to do right now, ENS wants to work with us on this. They have a stnadard implemented in their… (Andre)
Who did you talk to from ENS? You’re probably better off talking to me than him because I’m on the technical team. (Dean)
I don’t want to bring anything into Status that isn’t a standard or defined in a spec somewhere. We could take over that EIP and bring it into fruition, or come into agreement with ENS on how this should work. I would like to propose a … field that links to Status’ universal links handler from the manager. (Andre)
Another option is 3box. (Sam)
They’re not a standard and have an opinion on how things should be done. (Andre)
Understood, though they are an active team working toward the same goal. (Sam)
Most EIPS remain in draft forever, including ERC20 (Dean)
Back on Wall of Shame - I’m here if you can hear me. I want to make sure people have a place where they can go to see what we have posted. (Corey)
The latest version of the Wall of Shame is on Dicuss threads. (Oskar)
Where should this live? (Corey)
I think GitHub is the best place for this, like a github label. (Andre)
Corey will take the current list and turn them into issues.