Status Core Dev Call #33 - June 29, 2020

The Status Core Development team meets every two weeks, here is a summary of their latest call.

• Meeting Date/Time: Monday 2020-06-29 at 12:00 UTC
• Meeting Duration: 1 Hour
• Video stream:

The full list of Core Dev meetings can be found on GitHub.

#Agenda

1. 1
   Assign notetaker
2. 2
   Agenda setting (~5’)
   a. Waku V2
   b. Stimbus
   c. Metrics
3. 3
   Announcements (~5’)
   a. Layer 2 solution for Status Pay is being discussed. Anyone interested can have a look
4. 4
   Review previous actions (~5’)
5. 5
   Specs review > open PR’s for Discussion (~10’)
   a. Add audio messages
   b. Address feedback
6. 6
   Expected changes/proposals
   a. Stimbus Implementation proposal - feedback (~10’)
   b. Waku version 2 - feedback (~10’)
   c. Layer2 solutions to remove gas cost barrier for in-Status SNT transactions - intro (~10’)
7. 7
   Notifications on iOS (progress, decisions that have been made) - update (~10’)
8. 8
   AOB (~5’)

#Minutes

https://notes.status.im/core-dev-call_33#

#Agenda setting

1a Waku 2

• Iuri: What is requested
• Oskar: Discuss thread. Assemble a team to work on it now. Missing someone from core, desktop and Stimbus and have a kickoff call. Tomorrow or sometime this week. Need clarity on who to involve
• Iuri: Start with Stimbus. From there go to Waku.
• Iuri: Integrating Desktop and Mobile into nim. Waku supposed to be first step
• Oskar: Someone who speaks on behalf of core when it comes to integration. Ultimate user Core, Desktop and Stimbus
• Oskar: Not much different from what is worked on
• Iuri: Discuss during kick-off integration call of Stimbus tomorrow.
• Iuri: Waku integration into Nim
• Oskar: Kick off call for Waku 2. In nim-waku and over libp2p
• Iuri: See it as suynergetic. Count on Iuri and see who to involve from Desktop
• Oskar: Is the conclusion that tomorrow it will be clear who this would be?
• Andre: Yes

1b Stimbus

• Iuri: For Stimbus we have a path, starting with shim. What else do you mean
• Oskar: 14:12 PN could be written in nim when integration is done
• Andrea: PN server, Ideally don’t right any new code in Status go if we move away from this. Nimbus provides a way to not write status-go, but nim and somehow integrate. Client is difficult to write in nim. challenging with keys, contacts, etc. Server is easier. Either nim that implements ipfs, not feasible in timeline or some other way. Clarity will help, else will need to write code in status-go
• Iuri: For keys acceptable to sign in status-go. Steadily move things over.
• Andrea: To surface everything. Roughly speaking, means fairly big changes to status-go. Doesn’t seem like something we want to do. Library in nim can surface encryption messages, but would need to send back to status-go. Requires shuffling
• Iuri: Can’t judge. Working on shim, and discuss again after implementing and having learned more about shim.
• Andrea: will keep working on notification service and will see what comes first
• Andre: Yes we need to ship, if we need to do a bit of double work, better than waiting

1c Metrics

• Iuri: different measures on what’s an active user
• Jakub: count now, take peer-ID of nodes connecetd to ouur nodes. Count number in timeslice. No differentiation between types. Includes e2e test. Skews things. Store data as log, not easy to query
• Oskar: Source of truth for DAU and retention. 14:19
• Oskar: Need to understand impact of e2e testing. Move to staging fleet?
• Jakub: QA wants to use what’s on production, this should be staging. More practical
• Eric: Too complex or feasible. Could we collect from e2e peer id, collect and remove from metrics
• Jakub: requires custom solution to query. Sure it’s doable but noticeable effort
• Eric: Easier, more feasible to run script on time (last 24h)
• Jakub: Have to have indices, hold data by peers of e2e. Substract peers for timeslice for given query. Not doable with Kibana now, needs to be written
• Andre: Why not separate staging?
• Jakub: Last time suggested there were objections
• Andre: 14:22
• Andrea: need to be more careful with process. Not running PR’s of unrelated code against staging. Might not have upgraded version of Status-go.
• Jakub: Alternative, modify logs to include names of peers, use in queries to limit. Indicate e2e build for test. Custom status-go version to detect nodes. Fleet to staaging is easiest. Already have a PR
• Iuri: Any objections?
• Andre: No
• Hester: No one of QA on the call
• Jakub: Included in PR - need to talk to them
• Oskar: … Other reasons to doubt accuracy of data
• Iuri: Found it suprising given activity on channel. Might be private, other public channels
• Oskar: Connected peers, makes sense given number?
• Jakub: Not informative for timeslice. Not useful count
• Oskar: Spike in March
• Iuri: Something happend in March
• Hester: Dark mode
• Andrea: Each test would be 2 nodes
• Jakub: Could be quite skewed by e2e test
• Oskar: Other metric is retention or stickiness DAU/MAU. Jakub added some graphics
• Jakub: Not a nice graph
• Oskar: Elastic search experience
• Oskar: Lagging, changing per month. Take MAU rolling
• Hester:. …
• Oskar: Stickiness. Clear documentation for marketing, fund raising, describe what data is captured exactly
• Oskar: Anyone who can help out
• Andre: Would like to take a look
• Jakub: Don’t believe this is doable with Elastic Search. Not queriable. Need to find a way to store data
• Oskar: Output log and run python script. Doesn’t require tooling
• Jakub: One of the possibilities
• Hester: No chat actions does node start. Understand what
• Jakub: question to Core. Request, not connect. Than it should not show up.
• Iuri: Ricaro is asking if there are privacy concerns
• Andre: Not tracking anything new. Just looking to use information better. Re-anonymize
• Oskar: All black box. We run cluster so we can get a better view. No analytics in app itself. Peers need to be identified. They have an idea.
• Iuri: Any claims can be independently verified
• Oskar: Can someone from Core follow up on when node is started
• Andre: I’ll follow up

#2. Announcements

2a Status Pay

• Iuri: Possible announcement Status Pay
• Eric: Already mentioned. Decision to use what L2 solution to have faster, cheaper transactions
• Iuri: Most looked at, promising?
• Eric: Optimistic rollups
• Iuri: Worried about sidechain, rollups are good
• Eric: zk and sidechains, optimistic rollups more chances ready to use in short term. A lot to like about zk rollups on paper
• Samuel: User retention features; 14:42 Can we discuss on a call? Specific implementation. Would like to continue to discuss
• Eric: After this call
• Oskar: Priority
• Eric: chat or side features related to wallet. Stopped using kudos dapp to lazy to ref
• Eric: Let users define username that doesn’'t have the same Stauts. Send and validate name anyway. Tradeoff between SNT utility and retention. Start emoji reactions
  …
• Jakub: Make phishing easier
• Eric: SNT reaction and TTT cannot brring retention with high costs on mainnet. Annoying, can’t talk till transaction is done. Now you have to ask wallet address first. For SNT reaction, ease of use, not having to do transaction. Sending 1SNT; imagine paying 20SNT in gas
• Oskar: 3 things: due diligence (incl security audits), how big bottleneck gas prices are (reason to believe it will continue?), user base? Users more price sensitive? These things to address before going into implementation details
• Eric: Status Pay going in own direction. Partnership with LeapDao. Protoype environment for Keycard team to play with. From core perspective interesting solution. To see if we can use it for user retention. Instant transactions. Need to verify.
• Iuri: Careful about what works and not. Sometimes don’t actually work or have a massive trade off
• Eric: optimistic rollups simpler mathemetically
• Tobias: If no pressure on implementing. Worth to wait and see optimistic rollups. Some security model cricitism
• Iuri: 14:55
• Eric: Could be that Status acts as validators
• Tobias: Looking at what happened in Plasma. Looking today resources invested would be wasted. Given retention and acqiosition focus, sit back and see what works
• Eric: For StatusPay, looking for solution in 4-5 months

#3. Review actions

Minutes to follow

#4. Specs

• Iuri: Any blockers
• Andrea: Not on audio, not on notifications
• Iuri: Address feedback
• Andrea: Significant change, if people want to have a look. No concern. Any spam protection will be blunt
• Andrea: Feedback offline

#5. Expected changes/proposals

5a Stimbus

• Iuri: Partically discussed. Proposal to implement shim. Any comments, objections, suggestions?
• Andrea: Already said, worth… opposite method to what Pedro used. Consider what was done and explain why different approach. … 15:00
• Iuri: Potential valid approach. Discussed in call. Recall Jacek saying something about that. Don’t have to exclude. Can go for this approach, even with shim. Talk to nim, which talks to status-go which talks to nim. Could be considered
• Andrea: So we’re aware of all options
• Iuri: Agree
• Iuri: Stimbus channel for updates. Call tomorrow at 8am ET, iteration meeting. People developing will be in call. If you want to join, welcome. Details in channel

5b Waku

• Iuri: Any comments on Waku version 2 feedback. @Oskar, any particular feedback
• Oskar: Asked people in private. On discuss for people to post. Main thing is resources to get libp2p in
• Iuri: Protocol itself well defined or looking for feeddback.
• Oskar: V1 well defined. V2, initially to port to libp2p. Same with some changes. Will be an issue and others can comment. Drafts PR not until next week. Feel free to post ideas in discuss or upcoming issues

5c Layer 2/Status Pay

#6. Notifications on iOS

• Andrea: Spec is out. Started implementation
• Hester…
• Andrea: Changes now, better than in a week. Now is the right time
  Gorush as push notification service. Middle notification service will take care of… query anonymously for people using access token. Not I am user x sending notification to user Y. Few nodes, one allowing only from contacts, another for everyone to publish notification. Achieve by encrypting token for each contact. … Can contact decrypt token. Same way Waku works. Server does not know whether user is allowed to send pushn notificaition… 15:10 no revealing identity

#7. AOB

• Iuri: anything else
• Jacek: announcement. Shared testnet launched for other clients, Nimbus participated successfully. Bunch of validators running on the network. Big congratulations to Nimbus team